How does data subject work?

What a data subject is in privacy law

A data subject is the person privacy law can recognise as being linked to personal data. That recognition is not just a definitional point, it determines whether the organisation must treat the record as protected personal data, respond to the individual, and apply the right rules for collection, use, retention, sharing, and deletion. The practical question is whether you can confidently tie data back to a real person.

That relationship matters because privacy obligations attach to the identified or identifiable person, not just to the dataset. If your systems cannot tell whether a record belongs to a specific person, you can misclassify it, over-disclose it, or fail to honour a rights request. If they can, then your privacy processes need to follow that link consistently across intake, storage, search, and deletion.

Why identification quality changes the privacy outcome

Data subject handling depends on identity matching, but not in the narrow authentication sense used for login. The operational problem is determining whether the same individual is being referred to across forms, logs, customer systems, support tickets, and backups. DSAR Guide: Handling Data Subject Requests is useful here because it shows how request intake, identity verification, and search scope affect whether the right person is served.

Weak matching creates two common errors: treating the wrong person as the subject of the data, or failing to find all data that belongs to the right person. Both failures can distort legal basis decisions, retention, redaction, and disclosure controls. The more fragmented the data estate, the more likely the same individual is represented by multiple identifiers, aliases, or account states.

Privacy teams also have to distinguish between data that merely looks identifying and data that is actually attributable to a person in context. That is why data minimisation and consent logic are often paired with records management. Identity Data Privacy and Consent Guide helps connect that identity-to-data relationship with lawful handling and retention decisions.

What organisations need to do when a person exercises rights

When a data subject asks for access, correction, deletion, portability, or objection, the organisation has to verify the person, find the relevant records, and apply exemptions or limits where the law allows. That workflow is usually where data subject handling becomes operational rather than theoretical. The key is to recognise the data subject relationship early enough to avoid searching too narrowly, but carefully enough to avoid disclosing someone else’s information.

Good practice is to separate the person’s identity proof from the scope of the response. You do not need more identity data than necessary to validate the request, but you do need enough confidence to search the right systems and preserve evidence of what was done. For requests that may involve third-party data, joint accounts, or delegated access, the privacy team usually needs a stricter review path than for a routine self-service correction.

In regulatory terms, this is where GDPR-style principles become operational: accuracy, minimisation, purpose limitation, storage limitation, and data subject rights all depend on correctly recognising the person behind the record. EU General Data Protection Regulation (GDPR) is the clearest external reference for those duties, especially where rights handling, special category data, and privacy by design intersect.

Risk and Threat Considerations

Misidentifying a data subject can create both privacy harm and compliance exposure. If the organisation links records to the wrong person, it may disclose personal data to an unauthorised recipient, delete data it should have retained, or deny a valid rights request. If it cannot reliably link records at all, it may miss data in logs, shadow systems, or downstream services.

Failure mechanism: Identity fragmentation, duplicate profiles, weak matching logic, and inconsistent identifiers cause the organisation to apply privacy decisions to the wrong record set or the wrong person.

Impact: The result can be unlawful disclosure, incomplete DSAR fulfilment, incorrect retention, failed deletion, or inaccurate legal basis handling, all of which increase privacy and regulatory risk.

Practitioner Guidance

What to verify: Check whether the organisation has a single, documented rule for deciding when two records belong to the same person, and whether that rule is applied consistently across support, CRM, logs, and backups. If different teams use different match thresholds, privacy decisions will drift even when the policy looks sound.

Decision rule: If the request involves access, deletion, correction, or objection, treat identity resolution as part of the control, not a clerical step. If you cannot confidently link the requester to the data set, escalate for manual review rather than forcing automation to guess.

Practitioner takeaway: The most important control is not collecting more personal data, it is building enough certainty to know whose data you are handling so privacy rights, retention, and disclosure decisions stay accurate.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• Who should own data subject request handling when the work lands with security operations?
• How should teams operationalise data subject requests in modern privacy programmes?
• What breaks when AI agents are allowed to touch production data during integration work?