Organisations should first determine which parts of the request fall within Article 15 and which do not. Personal data must be identified and provided, while unrelated business information, anonymous data, and other non-personal material can be excluded. Where records contain both, teams should extract only the relevant personal data, review it for accuracy, and avoid over-disclosure that creates unnecessary privacy risk.
How to separate personal data from non-personal material in one request
The practical first step is scope control. Teams should isolate the records and fields that are actually personal data, then treat everything else as outside the disclosure duty unless another legal basis requires release. That means understanding the structure of the record set, not just the request wording, so you can extract the relevant personal information without exposing unrelated business content.
Where a file, email thread, case note, or database row contains both personal and non-personal material, the response should be assembled from the personal-data elements only. This is especially important when the surrounding context could reveal more than the data subject asked for, because over-disclosure is a common failure mode in access handling.
For mixed records, the right method is usually selective extraction, not full-record release. Teams should review for embedded third-party information, confidential operational detail, and any content that is merely adjacent to the person rather than about them. The goal is to give a meaningful copy of the personal data while avoiding the temptation to include “just in case” material.
What Article 15 means for mixed datasets and record sets
Article 15 creates a right of access to personal data, but it does not turn every document that mentions a person into a wholesale disclosure obligation. The response must be anchored to the personal data itself, with non-personal content excluded unless it is inseparable from the personal data in a way that makes redaction impossible or would render the disclosure misleading.
That distinction matters in practice because personal data may sit alongside process notes, internal commentary, financial figures, project details, or system logs. The organisation should determine whether those elements are genuinely personal, whether they can be separated cleanly, and whether the remaining disclosed material still gives the requester a fair view of the personal data being processed.
Where mixed records are common, the strongest operating model is a repeatable disclosure workflow: identify the record sources, classify the content, redact or extract non-personal material, and validate the final package before release. For privacy teams, the aim is not maximal disclosure, but accurate disclosure with a controlled blast radius.
How to avoid over-disclosure without under-responding
The hardest judgement is usually not whether to disclose something, but how much surrounding context is needed for the personal data to make sense. If a sentence, table, or attachment is primarily about the data subject, disclosure is often appropriate after removing unrelated detail; if the material is mainly business or operational content with only incidental reference to the person, it should usually be withheld or summarised.
A good review process tests three questions: does the item contain personal data, can that personal data be separated, and would releasing the remainder create privacy risk without improving the subject’s understanding of their own data? That lens helps prevent two errors, over-redaction that makes the response meaningless, and over-sharing that exposes wider internal information.
In higher-volume environments, the most effective control is consistent reviewer guidance. Teams need common rules for mixed records, clear escalation for borderline items, and a quality check before release so that the final disclosure is aligned to the request rather than to the easiest document export.
Risk and Threat Considerations
Mixed personal and non-personal records create a disclosure risk because the surrounding material may reveal more than the subject’s data rights require. The main hazard is not usually a refusal to answer the request, but a response that discloses internal business context, third-party information, or operational detail that should have been removed first.
Failure mechanism: Reviewers treat an entire record as disclosable once it contains any personal data, or they use a blanket extraction process that fails to remove adjacent non-personal material before release.
Impact: The organisation can over-disclose confidential information, create privacy exposure for other individuals, and weaken trust in its access-request handling process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 15 — Right of Access by the Data Subject | Directly governs access requests for personal data in mixed records. |
| Art. 5(1)(c) — Data Minimisation | Supports limiting disclosure to what is relevant and necessary. | |
| Art. 25 — Data Protection by Design and by Default | Requires disclosure processes that limit unnecessary exposure by default. | |
| Recommendation — Separate personal data from non-personal material and disclose only what Art. 15 requires. Minimise disclosure to the personal data needed to answer the request. Build access-request workflows that default to selective extraction and redaction. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Supports handling of personal information in disclosure workflows. |
| Recommendation — Use privacy controls to review, redact, and release only authorised personal data. | ||
Practitioner Guidance
What to verify: Before release, confirm that the response is built from personal-data elements rather than from whole documents, and that any redactions preserve the meaning of the disclosed personal data. If the requester would understand the personal data more clearly from a targeted excerpt than from the full record, use the excerpt.
Common mistake: Teams often over-rely on the format of the source record, such as an email or case note, instead of the content boundary. The better rule is to disclose what is about the data subject, not everything that happens to be stored near that data.
Practitioner takeaway: Treat mixed records as a redaction and extraction problem, not a full-disclosure problem, and keep the review focused on whether the final package is accurate, proportionate, and limited to the personal data actually in scope.
Related resources from NHI Mgmt Group
- How should organisations handle identity verification before fulfilling data subject access requests under state privacy laws?
- How should organisations verify data subject requests without exposing personal data?
- How should organisations handle EU Data Act data access and sharing requests without weakening privacy controls?
- Why does privileged access management matter for GDPR compliance when organisations handle EU personal data across multiple systems and partners?
