Access, correction and erasure

To meet the ISO/IEC 27701 access, correction and erasure requirement, you need a documented, repeatable process that lets PII principals request access to their PII, fix inaccuracies, and delete PII where applicable, with identity verification, scoped search across systems and third parties, tracked deadlines, and auditable outcomes ¹.

Key takeaways:

• Build one intake-to-closure workflow for access, correction, and erasure, then map it to every system that stores PII.
• Your biggest operational risk is incomplete fulfillment (missed systems, backups, and third parties), not the front-end request form.
• Keep evidence that you verified identity, searched all locations, applied exceptions, and executed changes with approvals.

“Access, correction and erasure” is a requirement you operationalize through workflow discipline and data mapping, not through a single policy. ISO/IEC 27701 expects you, as a PII controller, to implement “policies, procedures and/or mechanisms” that allow PII principals to exercise their rights to access their personal data, correct inaccurate data, and request erasure where your obligations require it ¹.

CCOs and GRC leads typically struggle in three places: (1) proving completeness (you searched every system and every relevant third party), (2) controlling identity verification without collecting more data than you need, and (3) managing edge cases (retention holds, legal obligations, security logs, and backups). Auditors also look for consistency: can you show the same workflow works for employee PII, customer PII, leads, and end-users, and that your teams execute it the same way every time?

This page gives you requirement-level implementation guidance: who owns what, what to build, what evidence to retain, and how to stand up a working program quickly without relying on vague “privacy mailbox” practices.

Regulatory text

Requirement (controller-facing): “The organization shall implement policies, procedures and/or mechanisms to meet its obligations to PII principals to access, correct and erase their PII.” ¹

What the operator must do: Put in place (1) documented rules (policy), (2) a working process people follow (procedure), and (3) technical and administrative methods (mechanisms) so individuals can:

• obtain a copy or view of their PII (access),
• fix inaccurate or incomplete PII (correction), and
• have PII deleted where required/appropriate (erasure), with outcomes you can evidence to an auditor ¹.

Plain-English interpretation

If a person asks, “What data do you have on me?”, “That address is wrong, fix it,” or “Delete my data,” you need a controlled way to (a) confirm it’s really them (or an authorized agent), (b) find the data everywhere you store or process it, (c) take the correct action in each system (including third parties), (d) document any exceptions, and (e) close the loop with the requester.

Your control is weak if it depends on one person’s memory of which systems exist, or if “deletion” means “we deleted it in the CRM” while it remains in data warehouses, support tools, analytics platforms, and downstream processors.

Who it applies to

In-scope entities

• PII controllers (explicitly called out in the provided applicability data) ¹.

In-scope operational contexts (practical scope)

This requirement becomes operationally real anywhere you:

• collect PII directly (web/app signup, HR onboarding, support intake),
• enrich or infer PII (marketing enrichment, fraud tooling),
• share PII with third parties (SaaS, payroll, benefits, call centers),
• store PII in multiple environments (production, BI/warehouse, logs, ticketing),
• have multiple identities per person (email + device ID + account ID).

What you actually need to do (step-by-step)

Step 1: Define a single request lifecycle (intake → verify → fulfill → close)

Create one documented procedure covering three request types (access, correction, erasure). Include:

• Intake channels (web form, email, support ticket escalation).
• Identity verification steps and acceptable evidence.
• Triage rules (what counts as access vs correction vs erasure; how to handle “do not sell/share” style requests if your program includes them).
• Assignment model (privacy office owns workflow; system owners execute tasks; security supports identity and abuse prevention).
• Closure requirements (what you send back; how you record completion).

Practical control: make every request a ticket with required fields. If it isn’t ticketed, it didn’t happen.

Step 2: Build your “PII location register” (the fulfillment map)

You cannot fulfill access/correction/erasure reliably without a list of places to look. Create a register that, at minimum, includes:

• system name and owner,
• PII categories stored,
• identifiers available (email, phone, customer ID),
• how to search/export/delete/correct,
• whether the system is a third party processor,
• dependencies (syncs downstream to other tools).

This register becomes your fulfillment checklist. Update it whenever you add a new system handling PII.

Step 3: Implement identity verification that is proportional

Document your verification method based on request risk:

• Low-risk access (e.g., account portal with authenticated session): allow self-service export.
• Higher-risk requests (email-only requests, agent requests): require additional verification steps.
• Authorized agent: require proof of authorization and verify agent identity.

Avoid creating a new sensitive data store by collecting excessive documents. If you do collect documents, define retention and access controls for that evidence.

Step 4: Fulfill “access” with a repeatable data retrieval package

Define what “access” means in your program (commonly a copy, a report, or secure portal view). Operationalize:

• search using known identifiers,
• export from each system in the register,
• normalize outputs into a consistent format where feasible,
• include key context so the data is understandable (system/source, timestamps, categories).

Quality gate: a second person checks completeness against the register for higher-risk profiles (VIPs, employees, regulated products).

Step 5: Fulfill “correction” through system-of-record rules

Correction fails when teams update one system and downstream systems re-populate the incorrect value.

You need:

• a system-of-record decision per data element (address, name, email, etc.),
• an update method for each downstream replica (sync job, API update, manual change),
• a confirmation step that the incorrect value is not reintroduced.

Treat correction like a data governance change, not a support edit.

Step 6: Fulfill “erasure” with a deletion standard and exceptions logic

Define what erasure means in your environment, by data store:

• hard delete,
• anonymization/pseudonymization,
• logical delete with access restriction,
• suppression (block further processing while retaining minimal data to honor the request).

Also define exceptions your organization may apply (for example, data you must retain for legal or security reasons). Keep the exceptions list controlled and approved. Auditors will ask who can approve an exception and how you ensure it is applied consistently ¹.

Step 7: Extend fulfillment to third parties

For each third party in the PII location register:

• confirm contract language supports access/correction/erasure assistance,
• define the operational path (portal, API, support ticket),
• record evidence of the request sent and the third party’s confirmation.

Most “failed erasures” happen here. If you cannot reach a third party quickly, you will miss your internal targets and struggle to show control effectiveness.

Step 8: Instrument tracking, evidence, and metrics

Track:

• request type,
• verification method used,
• systems searched,
• actions taken per system,
• exceptions invoked and approver,
• dates opened/closed,
• requester communications.

If you use Daydream, make it the system of record for the intake ticket, fulfillment checklist by system, evidence attachments, and approvals. That gives you a clean audit trail without piecing together emails, screenshots, and chat logs during an ISO surveillance audit.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository (ticketing system, GRC tool, or Daydream workspace) with access controls:

Policies and procedures

• Access/correction/erasure policy and SOP (versioned, approved).
• Identity verification procedure.
• Exceptions and approvals matrix.

Operational records ¹

• intake record (date, channel, request type),
• identity verification evidence (or method and outcome),
• system-by-system fulfillment checklist,
• exports provided (or secure delivery confirmation),
• correction records (before/after, system-of-record confirmation),
• erasure records (deletion/anonymization/suppression actions),
• third party correspondence and completion confirmations,
• closure communication.

Governance

• PII location register / data inventory excerpt used for fulfillment.
• Training records for staff who execute requests.
• Change management record when adding new systems to the register.

Common exam/audit questions and hangups

Auditors tend to probe these points because they reveal whether your control works beyond the policy:

1. Completeness: “Show me how you know you searched all systems that contain this person’s PII.”
2. Identity assurance: “How do you prevent social engineering through DSAR-style requests?”
3. Consistency: “Do you process employee requests the same way as customer requests? If not, why?”
4. Third parties: “How do you ensure downstream processors also erase or correct?”
5. Exceptions governance: “Who can deny or partially fulfill a request, and where is that documented?”
6. Evidence quality: “Can you reproduce the record without relying on screenshots and inbox searches?”

Frequent implementation mistakes and how to avoid them

Mistake	What it looks like in practice	Fix
Treating this as a “privacy@ inbox”	Requests handled ad hoc with no checklist	Route every request into a ticket with required fields and tasks
No PII location register	Teams only check the CRM and app DB	Maintain a living register tied to onboarding new tools
Over-collecting ID documents	Storing passports in shared drives	Use proportional verification; tightly control any documents retained
Correction without system-of-record rules	Data reverts after nightly sync	Define system-of-record per field and validate downstream updates
“Erasure” that ignores backups/logs	Deletes in app, leaves analytics and support tickets	Define deletion/anonymization/suppression per system and document exceptions
Third party blind spot	No proof third party completed erasure	Predefine third party request paths and retain confirmations

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, your risk clusters into:

• Regulatory nonconformance risk under ISO/IEC 27701 audits if you cannot show implemented mechanisms and evidence ¹.
• Security risk if weak identity verification allows account takeover or data disclosure.
• Operational risk if deletions break referential integrity, reporting, or fraud monitoring because engineering did not define deletion patterns.

Practical 30/60/90-day execution plan

Use phases so you can start operating quickly while you harden coverage.

First 30 days (stand up a working workflow)

• Publish the SOP for access/correction/erasure and identity verification.
• Stand up a single intake mechanism and ticket workflow with required fields.
• Build an initial PII location register from your highest-volume systems (app DB, CRM, support tool, marketing automation, data warehouse).
• Define a standard response package for access requests and a secure delivery method.
• Draft exception criteria and approval routing.

Days 31–60 (expand coverage and control quality)

• Add third parties to the PII location register and test request paths with at least one dry run.
• Implement system-of-record rules for common correction fields and document sync behavior.
• Add QA checks (peer review) for high-risk request types.
• Train system owners and support teams; document the training.

Days 61–90 (harden, test, and audit-proof)

• Run tabletop tests: one access request, one correction request, one erasure request across multiple systems and a third party.
• Close gaps found in the register (shadow SaaS, spreadsheets, exports).
• Add management reporting: request volumes, backlog aging, exception counts, and recurring failure points.
• Centralize evidence retention in Daydream (or your chosen system) so you can produce a complete audit trail on demand.

Frequently Asked Questions

Do we need separate procedures for access, correction, and erasure?

You can keep one SOP with three fulfillment paths, as long as triage and evidence requirements are explicit for each request type. Auditors mainly care that the workflow is repeatable and complete ¹.

What’s the minimum identity verification we can do without over-collecting data?

Use proportional verification based on request risk and the channel used. Prefer authenticated account actions and knowledge-based verification over collecting government IDs, and tightly control any documents you do collect.

How do we handle erasure if we must retain some data for legal or security reasons?

Define an exceptions matrix with an approval step and document what action you take instead (for example, suppression or restricted retention). Retain evidence showing the exception applied and who approved it.

Are backups and logs in scope for “erasure”?

Treat them as part of your data landscape and define how erasure is handled for each store (delete, anonymize, suppress, or exception). What matters for ISO/IEC 27701 audits is that you have a defined mechanism and can evidence your practice ¹.

How do we prove we searched “everywhere”?

Maintain a PII location register and attach a system-by-system checklist to each request showing search results and actions taken. The register is your defensible “scope of search” artifact.

What should we require from third parties to support access/correction/erasure?

Contractually require assistance with individual rights requests, then operationalize it with a named request path and evidence retention. Track third party completion confirmations in the same ticket as your internal actions.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management