Providing copy of PII processed

To meet the ISO/IEC 27701 “providing copy of PII processed” requirement, you must be able to deliver an individual a copy of the personal data you process about them, upon request, and provide it in a commonly used, machine-readable format where applicable ¹. Operationally, this means verified identity, complete data extraction across systems, safe delivery, and provable records of what you sent and why.

Key takeaways:

• Build a repeatable “export my data” workflow that works across all systems where PII lives.
• Define formats, redaction rules, and exceptions so responses are consistent and defensible.
• Keep evidence: request intake, identity verification, system queries, the exported package, and delivery logs.

“Providing copy of PII processed” sounds simple until you try to do it across production databases, SaaS tools, logs, support tickets, analytics, and backups. ISO/IEC 27701 Clause 7.3.8 is a capability requirement: you need the technical and procedural ability to produce a complete, accurate copy of the PII you process for a given person, and deliver it in a format they can realistically consume and re-use where applicable ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an operational “data export” control with four pillars: (1) intake and identity verification, (2) data discovery and mapping, (3) standardized export packaging with redaction and quality checks, and (4) secure delivery and audit-ready records. This page gives requirement-level implementation guidance you can hand to Privacy Ops, Security, IT, and Product teams and then test in an internal tabletop.

Regulatory text

Requirement (verbatim): “The organization shall be able to provide a copy of the PII that is processed upon request by the PII principal, in a commonly used and machine-readable format where applicable.” ¹

What an operator must do: You need an end-to-end capability to (a) receive a request from an individual, (b) identify the correct person, (c) gather the PII you process about them from applicable systems, (d) package it in a commonly used, machine-readable format when applicable, and (e) deliver it securely with an auditable trail ¹.

Plain-English interpretation

If a person asks “send me the personal data you have on me,” you must be able to do it reliably. The response should not be an unreadable dump or screenshots. Where it makes sense, provide structured files (for example, CSV/JSON) so the person can consume or transfer it. “Where applicable” matters: some data (free-text notes, scanned documents, recordings) may not convert cleanly into a strict tabular format, but you still need to provide a copy in a reasonable, commonly used form ¹.

Who it applies to

Entity scope: PII Controllers ¹.

Operational context where this becomes real:

• You run customer/user accounts and store profile, billing, usage, or support data tied to an identifiable person.
• You process employee or applicant data (HRIS, recruiting, background checks).
• You collect device, telemetry, or event data that can be linked back to an individual through identifiers you control.
• You outsource processing to third parties (cloud hosting, CRM, support desk). You still need to respond, even if the data sits in third-party systems, because the capability requirement is on the controller ¹.

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

1) Define the “copy of PII” scope you will export

Create a written export scope that engineers and privacy ops can execute consistently:

• PII elements: identifiers, contact info, account metadata, preferences, transactions, communications, and other data linked to the person.
• System boundaries: production DBs, data warehouse, CRM, ticketing, marketing tools, file stores, and any other system used to process PII.
• Excluded categories (must be explicitly defined): data that cannot be attributed to the person without disproportionate effort, or data you do not “process” in practice. Keep this tight and defensible because auditors will look for gaps against your data map.

Deliverable: a one-page “PII Copy Export Specification” that lists systems, fields, owners, and export method.

2) Build a request intake workflow with identity verification

Minimum operational pieces:

• Intake channels: web form + email alias + postal address if your org accepts it.
• Case management: ticket type “PII Copy Request” with required fields (requester identity, account identifiers, jurisdiction if you track it, systems in scope).
• Identity verification: define how you confirm the requester is the data subject (or authorized agent). Common approaches: authenticated account access, verified email domain, or additional verification steps for sensitive accounts.

Artifact: a standard operating procedure (SOP) that states what counts as “verified,” and when to escalate.

3) Inventory and connect your data sources (the hard part)

Operationalize a system-by-system approach:

• System owner assigned for each source of PII.
• Export mechanism documented: API endpoint, SQL query, admin console export, or third-party support request.
• Linking key defined: user_id, email, customer_id, employee_id. If you lack stable keys, you will miss data and fail the requirement.

Practical tip: if your org is large, run a “dry export” for an internal test identity and record which systems produced data and which could not.

4) Standardize formats and packaging

ISO/IEC 27701 calls out “commonly used and machine-readable format where applicable” ¹. Convert that into an internal standard:

• Primary structured outputs: CSV or JSON for structured datasets (profiles, transactions, logs that are already structured).
• Document outputs: PDF for documents when you need stable rendering, plus original files when feasible.
• Media outputs: provide original audio/video where stored and attributable.

Package guidelines:

• Use a manifest file listing every included file, data source, extraction date, and field descriptions.
• Use consistent naming (e.g., account_profile.json, tickets.csv, invoices.pdf).

5) Apply redaction and third-party data rules

Most exports contain information about other people (support tickets, shared workspaces, email threads). Define rules before you automate:

• Redact third-party PII unless you have a clear basis and it’s required by the request.
• Protect security-sensitive data (password hashes, secret answers, API tokens). Provide the person with the meaningful data about them, not material that increases breach risk.

Artifact: a redaction decision log template (what was removed and why), used consistently.

6) Quality checks before release

Treat this like a regulated customer communication:

• Completeness check: confirm all “in-scope” systems returned data or documented why they didn’t.
• Accuracy check: sample for obvious mismatches (wrong account, merged identities).
• Format check: files open and are readable; JSON validates; CSV has headers.

7) Secure delivery

Common secure delivery patterns:

• Authenticated download in the user portal, time-bound.
• Encrypted file delivered via secure link; encryption key shared through a separate channel.
• Avoid sending raw exports as email attachments unless your risk posture explicitly permits it.

Keep delivery logs: when it was delivered, method, and who approved release.

8) Recordkeeping and metrics (so you can prove the capability)

ISO/IEC 27701 is often assessed through evidence. Your goal: show that you can perform the export reliably, not that you did it once.

Keep a register of requests, outcomes, and exceptions, and feed recurring issues into engineering backlog (missing identifiers, systems without export paths, manual steps that break under load).

Required evidence and artifacts to retain

Maintain an audit-ready folder (or GRC system record) per request:

• Request intake record (date received, channel, request text).
• Identity verification record (method, outcome, approver).
• Data source checklist showing each system queried, by whom, and when.
• Query evidence: SQL scripts, API call logs, export screenshots, or admin export confirmations.
• The exported package (or a hash of the package if you cannot store the content) and the manifest.
• Redaction decision log (if applicable).
• Delivery record (secure link log, portal download log, or courier receipt).
• Post-close review notes for exceptions and remediation tasks.

Common exam/audit questions and hangups

Auditors and cert assessors typically probe:

• Coverage: “Which systems are in scope, and how do you know you didn’t miss any?”
• Format: “Show me the format you provide and why it is commonly used and machine-readable where applicable.” ¹
• Repeatability: “Is this ad hoc, or a documented process with trained staff?”
• Security: “How do you prevent unauthorized disclosure during identity verification and delivery?”
• Third parties: “How do you extract data from third-party systems you use to process PII?”

Hangups that stall assessments:

• No reliable way to link identities across systems.
• Data warehouse exports that are technically possible but not approved for privacy ops to run.
• Manual redaction with no documented rule set, leading to inconsistent outputs.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating this as a single-system export. Fix: maintain a living system inventory tied to PII processing, with owners and export methods.
• Mistake: Over-sharing security secrets. Fix: create a “never export” list (credentials, secret tokens, internal fraud signals) and enforce it in code and review.
• Mistake: No proof of what was delivered. Fix: store a signed manifest and cryptographic hash of the export package, plus delivery logs.
• Mistake: Redaction decisions made by whoever is on call. Fix: define redaction rules and escalation paths; train privacy ops and legal reviewers.
• Mistake: Third-party tools ignored. Fix: include CRM, support desk, marketing automation, and payment platforms in scope if they process PII for your purposes.

Enforcement context and risk implications

No public enforcement case references were provided in the source catalog for this requirement, so this page focuses on control design and audit defensibility. Practically, failure modes create two kinds of risk: (1) privacy rights failure (you cannot produce the data you process) and (2) security incident risk (you produce it unsafely or to the wrong person). Your control design has to manage both.

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an owner for “PII copy export” (Privacy Ops or GRC with Engineering counterpart).
• Draft the PII Copy Export Specification (systems, fields, owners, export method).
• Stand up an intake workflow in your ticketing system with identity verification steps.
• Run two internal dry runs (employee account + customer test account) and document gaps.

By 60 days (Operational capability)

• Build repeatable exports for the highest-risk systems (core product DB, CRM, support desk).
• Publish formatting and packaging standards (CSV/JSON + manifest; secure delivery method).
• Implement review gates: completeness checklist + redaction rules + approval step.
• Train staff and run a tabletop exercise for a tricky case (shared workspace, multiple identities, third-party data).

By 90 days (Scale and audit readiness)

• Expand coverage to remaining systems (data warehouse, marketing tools, file stores).
• Automate evidence capture: export logs, hashes/manifests, delivery logs stored with the case.
• Add recurring reconciliations: compare your system inventory to procurement/SaaS inventory so new tools don’t slip in.
• If you use Daydream for third-party risk management and compliance workflows, map third-party processors that hold PII to contract requirements and operational runbooks, so exports can be executed without scrambling across vendors during a live request.

Frequently Asked Questions

What counts as a “commonly used and machine-readable format” in practice?

Use formats like CSV or JSON for structured data because they are widely supported and machine-readable. For documents or media, provide a commonly used file type that preserves readability, and include a manifest so the package is understandable ¹.

Do we have to include data stored in third-party SaaS tools?

Yes if you use those tools to process PII for your purposes as the controller. Operationally, include those systems in your export specification and document the export method and owner.

Can we exclude internal notes, fraud flags, or security signals?

Define exclusions carefully and document them. Keep a “never export” list for secrets and security-sensitive material, and use a redaction decision log so exclusions are consistent and reviewable.

What if we can’t reliably match the requester to a single identity across systems?

Treat identity resolution as a prerequisite control: define authoritative identifiers and implement account-linking rules. If you must make assumptions, document them and escalate for review before release.

Should we store the full export package for evidence?

Store it if your retention and security posture allow it; otherwise store a manifest plus a cryptographic hash and exact extraction parameters so you can prove what was produced without retaining extra PII.

How do we prevent sending one person another person’s data?

Tighten identity verification, require a second-person approval for sensitive accounts, and add a pre-release validation step that checks the export’s identifiers against the verified requester record.

Footnotes

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