Decommissioning & Data Deletion Procedure
Document control
| Field | Value |
|---|---|
| Owner | Ron Benisty — CTO & CSO (ron.b@iontwrks.com) |
| Status | Approved |
| Version | 1.0 |
| Classification | Confidential |
| Approved by | Ron Benisty — CTO & CSO |
| Approval date | 2026-05-26 (Tuesday) |
| Last reviewed | 2026-05-26 |
| Review cycle | Annual — next review due May 2027 |
| Parent policy | Secure SDLC (SSDLC) |
Satisfies ISO/IEC 27001:2022 A.8.10 (information deletion) and A.5.11 (return / removal of assets); supports GDPR Article 17 (right to erasure) and Amendment 13 deletion obligations. Closes Gap 16 of the SSDLC gap analysis. The technical mechanism is built into the architecture (Multi-Tenancy, Architecture); this policy states the procedure.
1. Triggers
| Trigger | Procedure |
|---|---|
| Tenant cancellation or non-renewal (per Admin user flow — Clients, the annual access toggle) | §2 — Tenant decommissioning |
| GDPR / Amendment 13 right-to-erasure request | §2 — Tenant decommissioning (with anonymization tombstone — see §2a) |
| S.E.T-team departure | §3 — Staff offboarding |
| Contractor-developer departure | §3 — Contractor offboarding |
| Sub-processor change / removal | §4 — Sub-processor offboarding |
2. Tenant decommissioning procedure
| Step | Action | System | Owner | SLA |
|---|---|---|---|---|
| 1 | Confirm authorization (signed cancellation / verified erasure request) | Internal | CTO & CSO | Immediate |
| 2 | Disable the WorkOS Organization (tenant's auth) | WorkOS | S.E.T team | ≤ 1 hour after step 1 |
| 3 | Revoke all active tenant access tokens / refresh tokens | WorkOS + API | S.E.T team | Immediate at step 2 |
| 4 | Place tenant in grace period (read-only export available to the MSSP) | Application | S.E.T team | 30 days |
| 5 | At end of grace: DROP SCHEMA tenant_xxx CASCADE (Multi-Tenancy §Strengths) | Postgres | S.E.T team | Day 31 |
| 6 | Purge tenant prefix from S3 Evidence + Documents buckets (delete all object versions) | S3 | S.E.T team | Day 31 |
| 7 | If BYOK premium with per-tenant KMS key — schedule key deletion (7-day grace, then destroy) | KMS | S.E.T team | Day 31 + 7 |
| 8 | Tenant audit_events retention — see §2a below | Postgres | S.E.T team | Per §2a |
| 9 | Cross-region encrypted backups age out per existing lifecycle (35 d PITR) — no separate action; document the cutoff date | AWS Backup | CTO & CSO | Logged at day 31 |
| 10 | Object-Locked S3 backup archive — Object Lock retention period continues to run; deletion record notes the eventual expiry date | S3 Backup bucket | CTO & CSO | Logged at day 31 |
| 11 | Issue Deletion Certificate to the MSSP — signed PDF: tenant ID, schema name, scope of deletion, dates, residual-retention notes for §9–§10 | Internal | CTO & CSO | Day 31 |
| 12 | Record the decommissioning in the Evidence Register | Internal log | CTO & CSO | Day 31 |
2a. Audit-log retention exception
The customer audit_events table is normally retained for 7 years (regulatory). On tenant decommissioning:
- Default: retained 7 years inside an archived schema (read-only role; not loaded into the live cluster) so regulator / auditor lookups remain possible.
- GDPR Article 17 right-to-erasure: replace personally identifying fields with hashes / sentinels (anonymize) and keep a tombstone row per event for control-integrity purposes; record the erasure in the Deletion Certificate.
This balance — keep the audit history, remove the PII — is what GDPR Recital 26 / Article 17(3)(b)(e) explicitly contemplates for regulated records.
3. Staff & contractor offboarding
| Identity | Access removed | SLA | Reference |
|---|---|---|---|
| S.E.T-team member | GitHub, AWS IAM (all accounts), WorkOS admin, Logz.io, Cloudflare, hardware MFA tokens collected | ≤ 24 hours | Access Reviews §4 |
| Contractor developer | GitHub collaborator removed; any session tokens revoked | ≤ 24–48 hours | Supply Chain §3 contract clauses |
| Compromised credential | Revoked immediately as part of IR | Immediate | Incident Response |
Offboarding produces an access-revocation record retained ≥ 12 months (Evidence Register).
4. Sub-processor offboarding
When a sub-processor is removed (replaced or de-scoped):
- Disable / revoke all integration credentials at the sub-processor.
- Confirm the sub-processor has deleted S.E.T data per their DPA + obtain a deletion certificate from them.
- Update the customer DPA sub-processor list; notify customers per the DPA-mandated notice period.
- Update Architecture and any other doc referencing the sub-processor.
- Archive the change in the Evidence Register.
5. Media / physical decommissioning (out of scope today)
S.E.T runs entirely on AWS / GitHub / WorkOS / Cloudflare / Logz.io — no physical media owned by S.E.T. AWS handles device sanitization for retired EBS / S3 storage per their own SOC 2 / ISO 27001 controls; we point at AWS's published shared-responsibility model rather than running our own physical-decommissioning procedure.
6. Document change history
| Version | Date | Author | Description of change | Approved by |
|---|---|---|---|---|
| 1.0 | 2026-05-26 | Ron Benisty (CTO & CSO) | Initial version — establishes tenant, staff, contractor, and sub-processor decommissioning procedures. | Ron Benisty (CTO & CSO) |