DSAR, Erasure and ISO 27001 Evidence in 2026

The email landed in Sarah’s inbox at 9:03 AM.

It was not the first Data Subject Access Request her fast-growing SaaS company had received. It was the first one that felt like a public audit.

The sender was a former employee, now a privacy advocate. The request cited GDPR articles by number and demanded all personal data, immediate restriction of processing, a list of every third-party service holding their data and verifiable proof of erasure from production and backup systems. A journalist was copied.

Within minutes, the gaps appeared. Engineering warned that “true deletion” from a multi-tenant database could affect other customers. Marketing was untangling user data across analytics platforms. Legal found an unresolved employment matter. Security worried that logs could reveal detection logic or another person’s data. Support had records under two email addresses. Finance had invoices under a third.

The clock had already started.

That scenario is no longer unusual. Data subject rights in 2026 are not a privacy inbox problem. They are a controlled business process that depends on asset inventories, lawful basis decisions, identity verification, access control, retention rules, legal holds, supplier coordination, secure disclosure, deletion evidence and audit-ready logging.

GDPR tells organizations what rights individuals have. ISO/IEC 27001:2022 gives security and compliance teams the management system discipline to prove those rights are handled consistently, securely and repeatably.

For CISOs, compliance managers, privacy leaders and business owners, the goal is not to create more paperwork. The goal is to build one reliable DSAR, erasure and restriction workflow that produces the evidence required by GDPR, ISO/IEC 27001:2022 audits and broader assurance expectations under NIS2, DORA, NIST CSF 2.0 and COBIT 2019.

Why ad-hoc DSAR handling fails under pressure

Most DSAR failures are not caused by bad intentions. They are caused by fragmentation.

A business may have a privacy notice, a DPO mailbox and a GDPR clause in supplier contracts, yet still struggle to answer basic operational questions:

• Who validates the requestor’s identity?
• Which legal entity is controller or processor?
• Which systems must be searched?
• Who owns each system?
• Which data is in scope?
• Which data must be redacted before disclosure?
• Which data cannot be erased because of tax, audit, litigation, fraud prevention or legal obligation?
• How is restriction of processing enforced technically?
• Which suppliers must support search, export, deletion or restriction?
• What evidence proves the request was handled on time?
• What happens if the DSAR reveals a personal data breach?

GDPR Article 5 requires personal data to be processed lawfully, fairly and transparently, collected for specified purposes, limited to what is necessary, kept accurate, retained no longer than necessary and protected with appropriate technical and organisational measures. Article 5(2) makes accountability explicit, the controller must be able to demonstrate compliance. Article 4 defines processing broadly, including collection, storage, use, disclosure, restriction, erasure and destruction.

That means the DSAR process itself is a processing activity. It must be controlled.

GDPR Article 3 also matters for cloud, SaaS, fintech and digital businesses outside the EU. If you offer goods or services to individuals in the Union, monitor their behaviour, or process personal data in the context of an EU establishment, GDPR can apply even when operations are outsourced or infrastructure is global.

ISO/IEC 27001:2022 brings structure to this reality. Clauses 4.1 to 4.4 require the organization to understand its context, interested parties, requirements, ISMS scope and interacting processes. A data subject is an interested party. GDPR rights are requirements. SaaS applications, identity providers, analytics platforms, support tools, data warehouses and cloud backups are interacting processes. A DSAR workflow belongs inside the ISMS, not beside it.

The three data subject rights that create the most pressure

Access, erasure and restriction expose the biggest gap between legal promise and operational capability.

GDPR Article 6 is central to this decision logic. You cannot process, retain, disclose or refuse erasure without understanding lawful basis. Article 9 raises the bar for special categories of personal data, such as health data, biometric data used for unique identification or data revealing sensitive characteristics. In a 2026 SaaS environment, this can affect onboarding, identity verification, fraud monitoring, customer support attachments and employee records.

Clarysec’s enterprise Data Protection and Privacy Policy [P17] frames the obligation directly. In Objectives clause 3.6, it requires the organization to:

Uphold data subject rights, including access, rectification, erasure, restriction, portability, objection, and protection from automated decision-making.

That objective becomes auditable only when it is tied to owners, registers, workflows, controls and evidence.

Start where auditors start: scope, stakeholders and ownership

In Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], the ISMS Foundation & Leadership phase, Step 2, focuses on stakeholder needs and ISMS scope. For GDPR, the Blueprint identifies regulator expectations as:

EU Regulators
(GDPR)

Lawful processing of personal
data, breach reporting in 72h,
data subject rights

Appoint data protection officer, establish
breach response process, procedures for
handling data requests.

This is the right starting point. Before automating tickets or configuring portals, define the scope of data subject rights processing:

1. Which legal entities act as controller, joint controller or processor?
2. Which products, services and territories are in scope?
3. Which categories of data subjects exist, such as customers, employees, trial users, prospects, suppliers, website visitors or app users?
4. Which systems, repositories and suppliers hold personal data?
5. Which roles approve disclosure, denial, erasure, restriction or escalation?
6. Which metrics are reported to management?

ISO/IEC 27001:2022 clauses 5.1 to 5.3 require leadership, policy alignment, resources and assigned responsibilities. That aligns directly with GDPR accountability.

The Data Protection and Privacy Policy [P17], Policy Implementation Requirements clause 6.4.1, states:

The Data Protection Officer (DPO) shall maintain documented processes for Data Subject Request (DSR) intake, validation, tracking, and response.

For SMEs, Clarysec’s Data Protection and Privacy Policy - SME [P17S] uses right-sized ownership. Governance Requirements clause 5.2.1 states:

The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods

That processing register is the operational heart of DSAR readiness. If it is incomplete, the DSAR team searches by memory, Slack messages and tribal knowledge. If it is accurate, the team searches by processing activity, data category, system owner, supplier and retention rule.

The Clarysec DSAR workflow: intake to closure

An audit-ready DSAR workflow should be simple enough to run under pressure, but controlled enough to withstand a regulator, customer assurance review or ISO/IEC 27001:2022 audit.

1. Intake and acknowledgement

Requests should enter a controlled channel, such as a privacy mailbox, portal, support form or legal intake queue. Staff must recognize plain-language requests. A person does not need to write “DSAR” to exercise a right. “What data do you have on me?” or “delete my profile” may be enough to trigger the workflow.

The Data Protection and Privacy Policy - SME [P17S], Policy Implementation Requirements clause 6.5.2, sets a clear service level:

The Privacy Coordinator must acknowledge requests within 3 working days and respond within 30 days

The acknowledgement should include request reference, scope clarification if needed, identity verification instructions and expected response timing.

2. Identity verification and authority check

A DSAR can become a personal data breach if information is sent to the wrong person. Verification should be proportionate and should not collect excessive new personal data. Use authenticated portals where possible. For former users, validate against known account data. For employees, coordinate with HR. For representatives, require proof of authority.

Retain evidence of the verification method, date completed, approver, any additional information requested and the decision if verification fails.

3. Classify the request

A single message may contain several rights. Classify each one separately because access, erasure, restriction, objection and portability require different decision logic and evidence. Also flag potential complaints, employee matters, children’s data, special category data and potential personal data breaches.

4. Search the inventory, not just obvious systems

This is where ISO/IEC 27001:2022 becomes practical. Zenith Blueprint [ZB], Controls in Action phase, Step 22, warns that inventory scope is broader than many organizations expect:

The scope of this inventory is broader than most realize. It should include:

✓ Physical assets : laptops, servers, phones, backup tapes, removable media, printed
records.
✓ Digital assets : documents, datasets, repositories, emails, source code, cloud-stored
files.
✓ Logical assets : user accounts, credentials, keys, software licenses, APIs.
✓ Service-related assets : SaaS platforms, managed security services, outsourced
storage.
✓ People as assets : not in a commodified sense, but in terms of assigned responsibilities,
access, and role-driven exposure to information.

Step 22 also explains ownership:

Each asset should have a defined owner , not the person using it, but the one accountable for
its use, protection, and lifecycle. Ownership is essential for control alignment: who classifies
the asset (5.10), who decides its access level (8.3), who handles its deletion (8.10), who ensures
it’s returned (5.9 overlaps subtly with asset return procedures).

In Zenith Controls: The Cross-Compliance Guide [ZC], ISO/IEC 27002:2022 control 5.9, Inventory of information and other associated assets, is treated as a preventive control supporting confidentiality, integrity and availability. Its cybersecurity concept is Identify, its operational capability is Asset Management and its security domains include Governance, Ecosystem and Protection.

For DSARs, that means the inventory is not an IT spreadsheet. It is the map that tells privacy, legal and security where personal data could exist.

5. Review, redact and approve disclosure

A DSAR response should not be a raw export. Review must protect other individuals’ personal data, confidential business information, legal privilege, security-sensitive data, fraud signals and data outside the request scope.

Approval should be risk-based. Routine access responses may be approved by the Privacy Coordinator or DPO. Requests involving employees, litigation, special category data, children, fraud, security logs or large exports should involve legal, HR or security leadership.

6. Deliver securely

Do not attach large unencrypted files to email. Use authenticated portals, encrypted files with separate password delivery or secure transfer links with expiry and access logging. Record the delivery method, date, recipient account, expiry date and confirmation where available.

7. Close with evidence

The Data Protection and Privacy Policy [P17], clause 6.4.3, is explicit:

All actions taken shall be logged for audit purposes, including decisions to deny requests.

The Data Protection and Privacy Policy - SME [P17S], clause 6.5.4, states:

All responses to data subject requests must be logged in a secure register, with access restricted to the Privacy Coordinator and GM

A DSAR is not complete when the email is sent. It is complete when the register shows the request, identity check, decisions, systems searched, response, exceptions, approvals, delivery and closure.

Erasure is controlled destruction, not a delete button

Erasure requests reveal whether privacy has been engineered into systems or bolted on after launch.

Clarysec’s enterprise Data Retention and Disposal Policy [P14], Roles and Responsibilities clause 4.3.3, assigns responsibility for the role that:

Responds to erasure requests and ensures the timely, verifiable deletion of personal data where required.

The phrase “where required” is critical. GDPR erasure is not absolute. Organizations may need to retain data for legal obligations, audit, tax, regulatory duties, fraud prevention, security, litigation or the establishment, exercise or defence of legal claims. The workflow must include a lawful retention and exception decision.

Zenith Blueprint [ZB], Controls in Action phase, Step 19, explains ISO/IEC 27002:2022 control 8.10, Information Deletion, in operational terms:

This control ensures that data is not kept longer than necessary, and when it is no longer
needed, it must be securely and reliably deleted. Many organizations accumulate large
volumes of data over time, but without a clear deletion process, that data may sit idle and
unprotected, quietly increasing the risk of exposure, breach, or regulatory violation.

It also warns:

Don’t forget backups and archived systems, these often retain historical data long past its
operational value. Deletion policies must extend to:

✓ Backup retention settings,
✓ Snapshot lifecycles,
✓ Archived email or document repositories.

And it closes with evidence:

The deletion process itself must be logged , and, in the case of high-risk or regulated data,
reviewed or approved. This ensures traceability and protects against accidental or
unauthorized destruction of valuable records.

In Zenith Controls [ZC], ISO/IEC 27002:2022 control 8.10, Information deletion, is mapped as a preventive control focused on confidentiality, aligned to the Protect cybersecurity concept and tied to Information protection plus Legal and compliance operational capabilities.

For complex cloud architectures, cryptographic erasure may be appropriate where designed correctly. If personal data is encrypted with a subject-specific or tenant-specific key, destroying the key can make the data permanently inaccessible, including where encrypted remnants remain in backups until scheduled rotation. This must be carefully designed, documented, tested and approved. It is not a workaround for poor deletion architecture.

Application readiness is therefore essential. Clarysec’s Application Security Requirements Policy - SME [P09S], clause 6.5.1.3, requires applications to:

allow the secure export and deletion of personal data when legally required (e.g., GDPR Article 17 – right to erasure).

If product teams do not build export and deletion capability, privacy teams are forced into database scripts, vendor tickets and inconsistent manual work.

Legal hold and deletion suspension

A mature erasure workflow must include a “do not delete” path. This is not an excuse to ignore erasure. It is a controlled exception.

Clarysec’s SME Data Retention Policy and Secure Disposal Policy - SME [P14S], Governance Requirements clause 5.4, states:

Data subject to Legal Hold and Deletion Suspension (e.g., in the event of litigation, audit, or investigation) must be clearly identified in the system and protected from deletion, even if the scheduled retention period has expired.

The Data Retention and Disposal Policy [P14], clause 6.4.1, mirrors the same principle:

If a legal hold and deletion suspension is issued (e.g., pending litigation, investigation, or audit), data otherwise subject to destruction must be preserved beyond its normal retention period.

Auditors want both sides of the story, evidence of timely deletion and evidence of justified retention.

Restriction of processing: the underestimated right

Restriction requests do not always require deletion. They require the organization to limit active processing while retaining data under controlled conditions.

Common examples include:

• A customer disputes accuracy and asks you to stop using the data while it is verified.
• A former employee objects to processing, but the record is needed for legal claims.
• A user requests erasure, but minimal data must be retained to maintain a suppression list.
• A fraud investigation requires retention but not normal operational use.

A practical restriction workflow should include a legal decision, system flag, access control adjustment, marketing suppression, analytics exclusion, supplier instruction, periodic review and exception evidence.

In Zenith Controls [ZC], ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, is treated as a preventive control supporting confidentiality, integrity and availability. It maps to Identify and Protect, with operational capabilities of Information Protection and Legal and Compliance.

Zenith Blueprint [ZB], Controls in Action phase, Step 23, summarizes the audit test:

Confirm that your organization has implemented privacy measures (5.34) aligned with
applicable legal requirements. Verify classification of PII, proper access controls, secure
handling practices, and awareness training. Validate whether subject access requests, data
deletion, or processing logs are supported operationally, not just by policy.

The key phrase is “supported operationally, not just by policy.”

Mapping DSAR workflows to ISO/IEC 27001:2022 evidence

ISO/IEC 27001:2022 does not replace GDPR. It organizes evidence.

Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, risk acceptance criteria, risk owners, control selection, a Statement of Applicability and a risk treatment plan. DSAR risks include unauthorized disclosure, missed deadlines, incomplete erasure, unlawful retention, excessive identity verification, supplier non-cooperation and inability to restrict processing.

Clause 8.1 requires organizations to plan, implement and control ISMS processes, retain documented evidence, control changes and ensure externally provided processes, products and services relevant to the ISMS are controlled. That fits DSAR operations because requests cross internal functions and external processors.

A strong evidence pack includes the DSR procedure, DSR register, processing activity register, asset inventory, data retention schedule, legal hold register, identity verification procedure, redaction guidance, secure disclosure method, erasure procedure, restriction procedure, supplier playbook, exception register, training records, internal audit results and management review reporting.

A practical workflow for access, erasure and restriction

This workflow turns Sarah’s crisis into an auditable process. Each stage has an owner, a control basis and evidence.

Cross-compliance value beyond GDPR

A DSAR workflow is rooted in GDPR, but the same controls support broader frameworks.

NIS2 Article 20 makes cybersecurity a management responsibility for essential and important entities. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, business continuity, supply-chain security, effectiveness assessment, cyber hygiene, training, access control, asset management, authentication and secure communications. DSARs rely on many of those same capabilities.

DORA applies from 17 January 2025 to many financial entities and sets uniform ICT risk management, incident reporting, resilience testing and ICT third-party risk requirements. Articles 5 and 6 require governance and documented ICT risk management. Articles 17 to 20 address incident detection, classification, escalation, communication and closure. Articles 24 to 30 address resilience testing, ICT third-party risk, service registers, audit rights, data location, incident assistance and exit strategies. A fintech handling DSARs through cloud platforms should align privacy request handling with its ICT service register.

NIST CSF 2.0 helps translate the same work into cybersecurity outcomes. GOVERN addresses legal, regulatory and contractual requirements, risk strategy, roles, policy and oversight. IDENTIFY and PROTECT align strongly with asset visibility, data classification, access control, deletion, supplier governance and privacy protection.

COBIT 2019 asks governance questions. Who owns the process? What objectives are defined? How is performance measured? How are exceptions approved? How is assurance obtained? DSAR evidence can support objectives such as APO13 Managed Security, APO14 Managed Data and DSS06 Managed Business Process Controls.

The auditor’s lens

Do not create separate evidence for every framework. Create one reliable DSAR workflow and map it well.

DSAR metrics management should see

Management cannot oversee what it cannot see. Useful metrics include request volume by right type, average acknowledgement time, average closure time, deadline performance, identity clarification rates, deletion exceptions, legal hold cases, supplier response times, partial denials, incidents identified during handling and open remediation actions.

These metrics show whether data subject rights are operationally healthy or dependent on heroics.

Common DSAR readiness gaps

Clarysec commonly sees the same weaknesses across SaaS, fintech, professional services and cloud-first SMEs:

• No owner for each system containing personal data
• Processing register not aligned with actual SaaS usage
• Marketing, analytics and data warehouse platforms excluded from searches
• No documented identity verification standard
• No redaction review before disclosure
• Production deletion performed without backup treatment
• No legal hold check before erasure
• Restriction handled manually with no system flag
• Supplier contracts missing DSAR assistance terms
• Denials and partial denials not documented
• No internal audit sampling of completed DSARs
• Frontline staff not trained to recognize requests

Your 2026 DSAR readiness checklist

Use this as a maturity test:

• Do we have a documented DSR intake, validation, tracking and response process?
• Do we acknowledge requests within a defined internal SLA?
• Do we maintain a secure DSR register with restricted access?
• Do we have a current processing activity register with categories, purposes, lawful bases and retention periods?
• Do we know every system, SaaS platform, repository and supplier that may hold personal data?
• Does every relevant asset have an accountable owner?
• Can we export personal data securely?
• Can we delete personal data securely where legally required?
• Can we restrict processing technically or procedurally?
• Do we check legal hold before deletion?
• Do we document denial, partial denial and exception decisions?
• Do supplier contracts support DSAR assistance?
• Do we test the workflow through internal audit or tabletop exercises?
• Do we report DSAR performance to management?
• Do we map DSAR controls into ISO/IEC 27001:2022 risk treatment and the Statement of Applicability?

If several answers are “not consistently,” the next request may expose the gap.

Turn data subject rights into audit-ready evidence

Data subject rights in 2026 require more than good intentions and a privacy inbox. They require a workflow that can find data, validate identity, make lawful decisions, coordinate suppliers, protect disclosure, execute erasure, enforce restriction and preserve evidence.

Clarysec helps organizations build that workflow without creating a parallel compliance bureaucracy. Start with Zenith Blueprint to place data subject rights in the right ISMS phase and steps. Use Clarysec’s Data Protection and Privacy Policy, Data Protection and Privacy Policy - SME, Data Retention and Disposal Policy, Data Retention Policy and Secure Disposal Policy - SME and Application Security Requirements Policy - SME to define ownership and operating rules.

Then use Zenith Controls to map ISO/IEC 27002:2022 controls 5.9, 5.34 and 8.10 into cross-compliance evidence for GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 and COBIT 2019 assurance.

If you want to know whether your DSAR, erasure and restriction workflows would survive an audit tomorrow, Clarysec can help you test the process, close the gaps and build the evidence pack before the next request arrives. Download the relevant Clarysec policy templates or book a DSAR readiness assessment to move from reactive response to controlled, audit-ready privacy operations.