Most ISMS implementations have a data deletion policy. Most ISMS implementations don't have a data deletion process a Stage 2 certification auditor will accept without follow-up questions.
The gap I see most often: a log template exists, the policy exists, but the SLA, the certification step, and the monitoring all live in the auditor's questions instead of in the company's evidence. The same gap shows up in GDPR Article 17 inquiries from regulators and in customer due-diligence questionnaires from enterprise prospects.
This post walks through what an ISO 27001 auditor expects to see, the gaps that get flagged in internal audits, and a working template you can adapt to close them.
What Annex A.5.34 actually requires
ISO 27001:2022 Annex A.5.34 — Privacy and protection of PII — calls for the organization to identify and meet requirements regarding the preservation of privacy and protection of personally identifiable information, in line with applicable laws, regulations, and contractual requirements.
In practice for SaaS companies, that means:
- A documented procedure for handling data subject access requests (DSARs), including the right to erasure
- Defined timeframes (SLAs) aligned with the strictest applicable regulation
- A way to verify deletion was actually performed across all systems holding the data
- An audit trail that survives staff turnover and platform migration
ISO 27001 doesn't prescribe specific SLAs — but the regulations it cross-references do:
- GDPR Article 17 (right to erasure) — "without undue delay," interpreted by most supervisory authorities as one calendar month, extendable by two months for complex cases with notice
- CCPA / CPRA — 45 calendar days, extendable to 90 with notice to the requester
- PIPEDA, LGPD, and similar regimes — typically 30 days, with regional variations
If you operate across regions, the binding SLA for your process is the strictest applicable one — usually 30 days from verified receipt.
What "good" actually looks like
A defensible data deletion request process has six components. I'll list them, then walk through where each one breaks in practice.
1. A dedicated request intake channel
A specific email address, web form, or in-product privacy flow — not support@yourcompany.com as the default. Privacy requests need a separate route or an automatically-tagged inbox so they can be triaged against the SLA from the moment they arrive.
2. A documented SLA
Concrete numbers: "acknowledge within 5 business days, complete within 30 calendar days, with a documented extension protocol for complex cases." Written into the policy, mirrored in your DPA and privacy notice, and surfaced as a measurable target in your GRC platform.
3. A request log
Every request, dated, tracked through completion. This is the artifact an auditor will ask for first. Most teams have a template. Few are using it consistently across the full request lifecycle.
4. A scope checklist
What systems hold this person's data? Production database, read replicas, data warehouse, analytics platforms, third-party processors (Mixpanel, Segment, HubSpot), email service provider, customer support tool, billing system, observability platform — every one of those belongs on a list. Without a scoping checklist, deletion is "whatever the engineer remembered to delete."
5. A certification step
Someone signs off — in writing — that all in-scope deletions completed and that any backups containing the data will be purged on the next retention cycle. This is the step that distinguishes "we deleted some stuff" from "we performed a controlled, scoped deletion."
6. Monitoring
A recurring task to review the log, verify SLA adherence, and surface anomalies. Vanta and Drata both have templates for this; they're frequently configured but not actually run on cadence.
The gaps we flag in internal audits
Across ISO 27001 internal audits I've performed, these are the data-deletion gaps that come up repeatedly. Each one maps to A.5.34 and to GDPR Article 17 if your scope includes EU subjects.
Gap 1: Log template exists, but no SLA defined
The most common one. The team has a spreadsheet titled "Data Deletion Request Log" with columns for request date, requester, scope, and completion. There's no row in the policy or in the GRC platform that says "30 days from receipt." Without a target, you can't measure adherence — and an auditor can't tell whether you're meeting Article 17.
Gap 2: No certification step
The log records that a deletion happened. It doesn't record who confirmed it happened across all systems. If a request comes in and an engineer deletes from the production DB but forgets the analytics warehouse, the log still shows "complete." It isn't.
Gap 3: Backup retention not addressed
GDPR Article 17 doesn't require you to restore backups and selectively erase records. It does require you to address backups in your response. Most policies are silent here. The fix is a single sentence: "Backups containing erased records are retained per the existing backup policy and will be purged on the next retention cycle, after which the data is fully erased."
Gap 4: Third-party processors not in the deletion scope
Customer data sits in Mixpanel, Segment, HubSpot, your email service, your customer support tool, your marketing automation. The deletion checklist usually covers your own database. It rarely covers the eight third-party processors also holding that data — each of which is a separate erasure obligation under GDPR Article 28.
Gap 5: No monitoring task in the GRC platform
Vanta and Drata both ship monitoring task templates for "data subject requests handled within SLA." They get added during initial setup, then never actually checked. The result is a control that exists but doesn't operate — which is exactly the kind of thing a Stage 2 auditor surfaces.
A working template you can adapt
Here's the structure I recommend organizations adopt — and that I'd expect to see during an internal audit.
Policy section (in your Data Protection or Privacy Policy)
Acme Corp receives, processes, and fulfills data subject deletion requests in accordance with applicable privacy law. Requests are acknowledged within 5 business days and completed within 30 calendar days of verified receipt, extendable by 60 days for complex cases with written notice to the requester. All deletions are logged, scoped across in-scope systems, and certified upon completion.
Procedure document
- Request received via privacy@your-company.com or in-product privacy form
- Identity verification — pull verification artifacts (account email match, account holder confirmation)
- Scope assignment — assign to engineering lead; engineer pulls the scoping checklist
- Execute deletion — production DB, analytics warehouse, BI tools, third-party processors, support tickets, email logs, with backup retention noted
- Certification — engineer plus DPO (or designated approver) sign the certification template confirming all scope completed
- Log update — entry marked closed with all certification artifacts attached
- Requester notification — confirmation sent with timestamp, within SLA
Monitoring (Vanta or Drata)
- Quarterly task: "Review data deletion request log; confirm 100% SLA adherence" — assigned to DPO or designated owner
- Annual task: "Refresh scoping checklist with current third-party processors" — assigned to engineering lead, executed alongside the annual vendor review
Cross-system scoping — the part most teams miss
The most common reason a deletion technically completes but a complaint shows up six months later is that a downstream system kept a copy. Your scoping checklist should include, at minimum:
- Production database (primary)
- Read replicas and analytics database
- Data warehouse (Snowflake, BigQuery, Redshift)
- Customer data platforms (Segment, RudderStack)
- Product analytics (Mixpanel, Amplitude, Heap)
- Email service provider (Sendgrid, Postmark, Mailchimp)
- Customer support tool (Zendesk, Intercom)
- Marketing automation (HubSpot, Marketo)
- Logs and observability (Datadog, Splunk)
- Backups — with retention policy notation
- Any AI/ML training corpus — increasingly important under GDPR and ISO 42001
Maintain this list as part of the procedure document. Update it during quarterly vendor review so it doesn't drift.
What an audit looks for
A privacy program that handles data deletion well turns each request into a structured, repeatable workflow with a paper trail. During an ISO 27001 internal audit, I review:
- The policy with the SLA written into it
- The procedure document with the scoping checklist
- The log showing every recent request and SLA performance against target
- A signed certification template for at least one completed request in the audit period
- Evidence that the monitoring task in the GRC platform has actually been run during the audit period
If those five artifacts exist and are current, A.5.34 closes cleanly.
Frequently asked questions
What SLA should I target?
30 calendar days from verified receipt, with a documented extension protocol for complex cases. This satisfies GDPR Article 17 (the strictest commonly-applicable regulation) and gives you margin against CCPA's 45-day requirement.
Do I have to delete from backups immediately?
No. The accepted practice — recognized by data protection authorities and certification auditors — is to retain backups under your existing backup policy and purge the deleted record on the next retention cycle. Document this explicitly in your response to the requester so the obligation is closed in writing.
How do I prove the deletion actually happened?
A signed certification template, completed by the engineer who performed the deletion and the DPO (or designated approver) who reviewed the scope. Store it with the request log entry. This is the artifact that matters to a Stage 2 auditor.
What if a request involves data we have to keep for legal reasons?
GDPR Article 17(3) recognizes legal-obligation, public-interest, and legal-claims exemptions. Your response to the requester should cite the specific exemption and the data category retained. Document the rationale internally and in the log entry.
Does Vanta or Drata handle this for me?
Both platforms include task templates for monitoring data subject requests against an SLA. They don't replace the underlying policy, procedure, or scoping checklist. Use the platform as the monitoring layer; the substantive program lives in your documentation and team operations.
Where does this connect to ISO 42001?
If you train models on customer data, ISO 42001 Annex A.7 (Data for AI systems) and A.6.2.7 (System impact assessment) extend the deletion obligation into your training corpus. A scoping checklist that omits the AI training pipeline will fail an integrated ISO 27001 + ISO 42001 audit.