Skip to content
compliancebase
ISO 27001A.8 — Information deletion

A.8.10

Information deletion

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Delete information stored in information systems, devices, or other storage media when no longer required.

Points of focus

  • Retention periods are defined per data category, not a single blanket rule
  • Deletion covers primary stores, backups, replicas, logs, and analytics/warehouse copies
  • Customer-initiated deletion (account closure, GDPR/CCPA erasure requests) has a defined SLA
  • Deletion jobs are tested to confirm data is actually unrecoverable, not just flagged
  • Sub-processors and downstream vendors are included in the deletion chain

Implementation notes

Start with a data inventory that tags each store — primary database, object storage, backups, logs, search index, data warehouse, and CRM/support tools — with the personal or customer data it holds and the retention rule that applies. Automate deletion as scheduled jobs rather than manual tickets: TTL fields in DynamoDB or Postgres, S3 lifecycle rules, and warehouse ETL jobs that exclude or purge rows past their retention window. Backups are the most commonly missed surface — either shorten backup retention to match your policy or document that backups age out and are never restored past the retention window, and be explicit about which approach you use. Build a account-closure or 'right to erasure' workflow that fans out the deletion request to every system in the inventory and produces a completion record with a timestamp, because this is the artifact auditors and regulators both want to see. Extend the same rigor to sub-processors: your vendor contracts should include a data-deletion clause, and your offboarding runbook should include verifying that the vendor actually deleted the data, not just requesting it. Finally, test deletion jobs periodically the same way you'd test a backup restore — delete a synthetic record and confirm it is gone everywhere, including cached and denormalized copies.

Audit tip: Pick one customer account that was actually deleted and trace it end to end: application database, backups, search index, data warehouse, and any third-party tool that had a copy. A single sampled trace with dated confirmations beats a retention policy document every time.

Evidence auditors typically request:

  • Data retention schedule mapping data category to retention period and deletion trigger
  • Cron/job logs or Airflow DAG runs showing scheduled deletion jobs executing successfully
  • A sampled data subject erasure request with timestamped confirmation of completion within SLA
  • S3/object storage lifecycle policy or database TTL configuration screenshots
  • Verification test showing a deleted record no longer appears in the search index or data warehouse

Common gaps

  • Application soft-deletes a record (sets a flag) but the hard-delete job that removes it from backups and the warehouse never runs or was never built
  • Deletion SLA is documented for the primary database but log pipelines and analytics events retain the same personal data indefinitely
  • A sub-processor holding customer data (email vendor, support-ticket tool) has no deletion clause or verification step in the offboarding process

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.8.10This control
SOC 2CC6.5Related Trust Services Criteria themes — map in your crosswalk; not identical requirements.

Primary sources

Frequently Asked Questions

Not necessarily. You can document a bounded backup retention window (e.g. 30-90 days) after which backups age out naturally, as long as that window is disclosed and backups are never selectively restored to reintroduce deleted data.

It's in scope. Build the deletion or anonymization job into your ETL pipeline so warehouse tables reflect deletions on the same cadence as production, and document the lag if there is one.

Keep the deletion job's execution log — record ID, timestamp, and outcome — rather than the data itself. A log entry showing 'account X purged at Y across Z systems' is the evidence, not the absent data.

Yes, heavily, but they aren't identical. GDPR Article 17 sets legal conditions for when erasure must happen; A.8.10 is the operational capability to delete data reliably regardless of which legal basis triggers it.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above