Deleting a VAR Partner's Customer Data

Under GDPR-style rules the controller decides deletion and the processor acts on its instructions. If the end company is the controller and the VAR is just a reseller, a VAR request alone may not be a valid instruction. We may need the end company's sign-off.

Look for "delete", "return", "delete or return", and retention periods. Many contracts let the customer choose between return and deletion, and some require deletion within N days of expiry whether or not anyone asks.

"Their data" might mean VAR orders, reseller users and pricing, not the learning data of thousands of end users. We should get the request in writing and pin down its scope.

Regulators accept proper anonymization as erasure. A contract can still be stricter, so this affects which path we take.

Portfolio users can add a personal email (users.solid_career_email) separate from their work login, and build a public portfolio. A certificate earned by a person arguably belongs to that person, not their employer's reseller. Deleting the person might destroy data the VAR has no claim to.

One users row can belong to several accounts and companies through account_users and company_users. The safe default: remove the VAR company's memberships, and only erase the person if that company is the only thing they belong to.

It's personal data about the user, collected because the company paid for the seat. The answer decides whether a company-level request reaches it.

GDPR (portability), CCPA, PIPEDA for Canadian users, and FERPA if any customers are schools all bear on this. Separately, it's good practice to let users download their certificates.

Invoices, orders and tax records usually have required retention periods, which are a legitimate exception to deletion. Confirm which tables fall under them.

Deletion won't reach RDS snapshots. The standard answer is "deleted from production now, purged from backups as they expire within N days". We need the real N.

Tim's lists suggest expiry-based timing. A grace period (e.g. 30–90 days) protects against re-subscription regret.

Today, a bulk hard delete would mostly fail on the blocking FKs. Where it succeeds it leaves orphaned skill-validation rows, S3 files, and records in Cognito, Stripe, ChurnZero and Segment. Company delete only hides the company. Backups keep everything until they expire. Doing this correctly means writing new code (see sections 05 and 06).

Their Cognito identity still exists, so they can likely authenticate and then hit a missing platform user. That's a broken or confusing experience untested. With proper cleanup they'd see a normal "no account" login failure and could register fresh, starting from zero.

Their personal email (solid_career_email), portfolio, projects, galleries and external certificates are all tied to the user and disappear with them. This is the strongest argument for removing the company membership rather than the person when someone has a personal portfolio, pending Legal's view on ownership (section 02).

Correct after a hard delete. Backups aren't a practical restore path for individual companies. After anonymization the company's structure (account, groups, seats) could be revived, but not who the users were. A grace period before deletion is the real protection.

Yes. user_achievements cascades on user delete, and any shared certificate or verification links stop working. Offering a certificate download beforehand avoids most of the harm.

Partly. There's a VAR company-user CSV export (routes/v1/var/index.php, ExportCompanyUsers) and admin course view-statistics exports. There's no full per-user export covering progress, certificates and portfolio. That would mean new code or manual SQL.

Possibly. It depends on the contract, the jurisdiction and who the controller is. It's a question for Legal (section 02), not engineering.

Authority to delete; users shared with other companies; invoice and tax retention; backups; personal data in logs; outside systems; written proof of deletion; and the CS/support impact if a user calls after we've deleted them. All of these are covered above.