Identity systems hold some of the most sensitive personal data an organisation processes. Names, contact details, government ID images, biometric templates, device identifiers, location and a detailed record of every sign-in all flow through identity providers, proofing services, directories and logs. Identity teams also make decisions that are privacy decisions: what to collect at onboarding, how long to keep proofing evidence, what consent screens ask for, and what an OAuth app or AI agent may do on a user's behalf. This guide covers the privacy principles that apply to identity data, lawful basis, consent and delegated access, data subject rights, retention and accountability, for workforce and customer identity. It is written for identity architects, CIAM product owners and security teams who work with privacy and legal colleagues.
Key takeaways
- Collect less: ask for the attributes a decision actually needs, and prefer verifying an attribute to storing the evidence behind it.
- Biometric and identity document data needs extra protection. Biometric data used to uniquely identify someone is special category data under the GDPR and UK GDPR, and needs a condition under Article 9 as well as a lawful basis.
- Consent is not the default basis for security. Consent must be specific, informed, freely given and as easy to withdraw as to give, so it suits optional processing, not controls people cannot refuse.
- Identity logs are personal data. Keep them for a defined purpose and period, and apply the same rules to vendors and to delegation records for OAuth apps and AI agents.
- Build privacy by design into identity architecture: Article 25 requires that, by default, only the personal data necessary for each purpose is processed, stored and made accessible.
The identity data you hold
Start with an inventory. Most organisations underestimate how many copies of identity data exist, because the same attributes are synchronised to dozens of applications, cached by proofing vendors and duplicated in logs and analytics.
| Data | Where it lives | Privacy note |
|---|---|---|
| Profile and contact data | Directory, CIAM, HR, provisioned applications | Keep accurate; limit who can see it; propagate corrections |
| Identity documents and proofing evidence | Proofing providers, onboarding systems, support tools | High risk if breached; retain only as law requires |
| Biometric templates and images | Proofing and authentication systems | Special category data when used to uniquely identify. See the Biometrics Guide |
| Authentication and access logs | Identity provider, SIEM, data lake | Reveal behaviour, location and working patterns |
| Device and fraud signals | Fraud and bot defence tools | Fingerprinting may require consent under e-privacy rules |
| Consent and preference records | CIAM and consent management | Must be retrievable to prove consent |
| Delegation and grants | OAuth servers, SaaS integrations, agent platforms | Record who authorised what, for how long |
Support tools deserve special attention. In the Coinbase Insider Breach 2025, bribed support agents copied data on 69,461 people, including government ID images, according to Coinbase's notice to the Maine Attorney General. Proofing evidence that was kept and visible to support staff became the attackers' most valuable asset. See the Data Mapping and ROPA Guide for building the inventory.
Principles applied to identity
This is a practitioner summary, not legal advice. The principles below follow Article 5 of the GDPR and UK GDPR; many other privacy laws, including those in US states, apply similar ideas. See the US State Privacy Laws Guide.
- Lawfulness, fairness and transparency: identify the lawful basis for each identity data use and explain it in the privacy notice.
- Purpose limitation: do not repurpose sign-in and security data for unrelated uses, such as productivity scoring or marketing, without a proper basis.
- Data minimisation: data must be "adequate, relevant and limited to what is necessary". An age check needs "over 18", not a date of birth. See the Age Assurance Guide.
- Accuracy: identity decisions based on wrong data lock people out or let the wrong person in. See the Identity Data Quality Guide.
- Storage limitation: set retention for proofing evidence, templates, logs and delegation records.
- Integrity and confidentiality: identity stores are prime targets and must be protected accordingly.
- Accountability: the controller must be able to demonstrate compliance, which means records, assessments and evidence, not only good intentions.
- Privacy by design and by default (Article 25): the default settings should be the privacy-protective ones, covering the amount collected, the extent of processing, the storage period and accessibility.
Lawful basis by identity use
The right basis depends on the purpose, not the data. The table shows common starting points; confirm each with your privacy team.
| Identity use | Common starting point | Notes |
|---|---|---|
| Creating and authenticating a customer account | Contract (Article 6(1)(b)) | Limit to what the service needs |
| Customer due diligence and KYC records | Legal obligation (Article 6(1)(c)) | In the UK, the Money Laundering Regulations 2017 set the record-keeping period |
| Security monitoring and sign-in risk scoring | Legitimate interests (Article 6(1)(f)) | UK GDPR Article 6(11)(c) says network and information security "may" be a legitimate interest; the ICO says the three-part test still applies |
| Fraud prevention (UK) | Recognised legitimate interest (Article 6(1)(ea)) or legitimate interests | The ICO lists preventing, detecting or investigating crimes (including fraud) among the pre-approved purposes for the recognised legitimate interest basis |
| Biometric sign-in or matching | Lawful basis plus an Article 9 condition, often explicit consent | Offer a non-biometric alternative so consent is freely given |
| Marketing and profiling from identity data | Consent | Separate from terms; never bundled with security |
Consent in identity journeys
Under Article 7, a controller relying on consent must be able to demonstrate it; a consent request inside a wider declaration must be "clearly distinguishable from the other matters"; and "it shall be as easy to withdraw as to give consent". The ICO adds that consent should be unbundled from terms and conditions, with granular options for different types of processing, and that "there is no such thing as 'opt-out consent'".
- Separate consent to terms from consent to optional processing such as marketing or profiling, and never use pre-ticked boxes.
- Make consent granular, recorded with time, wording version and channel, and withdrawable from the same account page where it was given.
- Do not bundle security processing under consent. If users could refuse it, it is not the right basis for controls you must run anyway.
- Be careful with workforce identity. The ICO says freely given consent is more difficult to obtain where there is an imbalance of power, particularly for public authorities and employers, and the EDPB consent guidelines make the same point.
- Manage cookie and tracking consent consistently with fraud and bot defence needs, and document where an exemption applies. See the Device Intelligence and Fingerprinting Guide and the Consent Management Guide.
Delegated access and authorisation consent
When a user clicks "Allow" on an OAuth screen, or asks an AI agent to act for them, they are delegating access to their data. That is a privacy decision as well as a security one, and it is often made in seconds on a screen the user does not read. The Cyberhaven Chrome Extension Breach 2024 began when an employee approved a malicious OAuth app on a legitimate Google consent screen; no password or MFA was needed.
- Show clearly which application or agent is asking, what data and actions it wants, and for how long. See the OAuth 2.0 and OpenID Connect Guide.
- Request the narrowest scopes needed, and let users see and revoke grants in one place. OAuth token revocation (RFC 7009) gives clients a standard way to tell the authorisation server a token is no longer needed.
- For organisations, control which apps staff may consent to, and require admin approval for high-risk scopes. See the SaaS and OAuth App Governance Guide.
AI agents acting for people
Agents make delegation continuous: a single instruction can lead to many actions on data the user never sees. Keep the principal visible.
- Prefer delegation to impersonation. RFC 8693 (OAuth 2.0 Token Exchange) distinguishes the two: with delegation, the actor "still has its own identity separate from" the user, and tokens can carry both the subject and the actor.
- Record the principal, the agent, the scope, the purpose and the time limit of each delegation, so access and erasure requests can find what the agent touched.
- Do not let an agent widen the purpose. Data an agent retrieves to complete a task should not flow into model training, memory or analytics without a separate basis.
- See the AI Agent Authorisation Guide, the OAuth Token Exchange and Delegation Guide and the AI and Privacy Guide.
Data subject rights
Identity platforms are usually the place where rights requests start and the place where they are hardest to complete, because identity data is copied to so many systems.
- Access: be able to find a person's identity data across the IdP, CIAM, proofing provider, logs and connected applications. The ICO says organisations must respond without undue delay and within one month of receipt, with limited scope to extend.
- Rectification and erasure: propagate corrections and deletions downstream, including to provisioned applications. Article 19 requires controllers to communicate rectification or erasure to each recipient of the data unless this proves impossible or involves disproportionate effort. See the SCIM Provisioning Guide.
- Verify the requester: a rights request is also an attack route. Article 12(6) lets a controller with reasonable doubts ask for additional information to confirm identity. Verify proportionately, using existing authentication where you can, before disclosing or deleting data. See the Account Recovery and Help Desk Security Guide.
- Portability and objection: plan for exports of profile and consent data, and for objections to legitimate-interest processing such as behavioural analytics.
See the DSAR Guide for running the request process end to end.
Retention
The ICO's storage limitation guidance says you must be able to justify how long you keep personal data, have a policy with standard retention periods where possible, and periodically review and erase or anonymise data you no longer need. For identity data, set periods per data type:
| Data type | Driver | Practical approach |
|---|---|---|
| Customer due diligence records (UK regulated firms) | Money Laundering Regulations 2017, regulation 40 | Five years from the end of the business relationship or completion of an occasional transaction, then delete personal data unless another law or court proceedings require it |
| Document images and liveness media | Verification purpose | Delete once verification is complete unless a legal obligation applies; keep the result and evidence reference instead |
| Biometric templates | Ongoing authentication | Keep only while the user uses biometric sign-in; delete on withdrawal or account closure |
| Authentication and security logs | Incident investigation | Long enough to investigate incidents, then aggregate or delete |
| Consent records | Proof of consent | For as long as the processing relies on that consent, plus a defined period after withdrawal |
| Delegation and grant history | Accountability | Retain revoked grants long enough to answer "who had access" questions |
Apply retention to identity data held by vendors and check it in contracts. See the Data Retention and Secure Deletion Guide.
Assessments and accountability
- DPIAs: Article 35(3) requires a DPIA for, among other things, large-scale processing of special category data. The ICO's list of processing likely to need one includes biometrics, data matching, tracking and decisions about access to a service that involve special category data, each combined with criteria from the European guidelines. That covers proofing, biometrics, behavioural analytics and many AI agent deployments. See the DPIA Guide.
- Records of processing: keep a record of processing (Article 30) for identity systems and their vendors.
- Early involvement: work with the privacy team on identity architecture decisions before vendors are chosen.
- Management systems: organisations that run an ISO/IEC 27001 ISMS can extend it to privacy. See the ISO/IEC 27701 Privacy Information Management Guide.
- Frameworks: the NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk; version 1.1 is in draft. See the Identity Security Regulatory Map for related obligations.
Framework mapping
This table is an indicative NHI Mgmt Group alignment, not an official crosswalk. Article numbers were checked against the UK GDPR text on legislation.gov.uk (the EU GDPR uses the same numbering for these articles); NIST IDs against CSF 2.0 and the SP 800-53 Rev. 5 catalogue; CIS references against the CIS Controls (control level, with safeguard text from the CIS Controls Assessment Specification). ISO/IEC 27001:2022 Annex A names come from a published Annex A index.
| Requirement | GDPR / UK GDPR | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|---|
| Identity data inventory | Article 30 | ID.AM-07 | PM-5(1) | 5.12 Classification of information | Control 3 (3.1) |
| Lawful basis and purpose | Articles 5(1)(b), 6 | GV.OC-03 | PT-2, PT-3 | 5.34 Privacy and protection of PII | n/a |
| Consent capture and withdrawal | Article 7 | GV.OC-03 | PT-4, PT-5 | 5.34 Privacy and protection of PII | n/a |
| Special category data (biometrics) | Article 9 | PR.DS-01 | PT-7 | 5.34 Privacy and protection of PII | Control 3 (3.12) |
| Minimisation and privacy by default | Articles 5(1)(c), 25 | PR.DS-01 | SA-8(33), SI-12(1) | 8.11 Data masking | Control 3 |
| Access to identity data | Article 5(1)(f) | PR.AA-05 | AC-3, AC-6 | 5.15 Access control, 8.3 Information access restriction | Control 3 (3.3), Control 6 |
| Accuracy and rectification | Articles 5(1)(d), 16, 19 | ID.AM-07 | SI-18 | 5.34 Privacy and protection of PII | n/a |
| Retention and deletion | Articles 5(1)(e), 17 | PR.DS-01 | SI-12, SI-12(3) | 5.33 Protection of records, 8.10 Information deletion | Control 3 (3.4) |
| Impact assessment | Article 35 | GV.OC-03 | RA-8 | 5.34 Privacy and protection of PII | n/a |
| Vendor processing | Article 28 | GV.SC-05, GV.SC-07 | SA-9 | 5.19 Information security in supplier relationships | Control 15 |
Common failure patterns
- Keeping the evidence, not the result: document images and selfies stored indefinitely "in case", then exposed through support tools or a vendor, as in the Coinbase Insider Breach 2025.
- Consent as a catch-all: security and fraud processing placed under consent, which then cannot work for users who refuse, while marketing is bundled into the terms.
- Security data repurposed: sign-in logs and device data collected for security later used for productivity scoring or advertising.
- Deletion that stops at the IdP: an erasure or correction completed in the directory but not in provisioned applications, proofing vendors or analytics copies.
- Rights requests as an attack route: access or erasure requests fulfilled on weak verification, handing an attacker the data or locking out the real person.
- Linked data exposure: features that let one account see data about others. In the 23andMe Breach 2023, access to more than 18,000 accounts exposed data on almost 7 million people through DNA Relatives, and regulators found breaches of UK GDPR.
- Consent screens nobody can read: OAuth and agent permission prompts that hide scope, duration and the publisher, so users grant broad access without understanding it.
- No owner for delegation records: AI agent and OAuth grant histories kept by different teams, so nobody can answer what an agent accessed on a person's behalf.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Identity systems and vendors with documented purpose, basis and retention | Coverage of the inventory and records of processing | Up, towards 100% |
| Proofing evidence retained past its retention date | Whether deletion actually happens | Down, towards zero |
| Attributes collected at onboarding per journey | Minimisation in practice | Down or stable |
| Rights requests completed within the statutory period | Ability to find and act on identity data | Up |
| Downstream systems reached by erasure and correction | Propagation beyond the IdP | Up |
| High-risk OAuth scopes granted without admin approval | Control over delegated access | Down |
| AI agent delegations with recorded principal, scope and expiry | Accountability for agent actions | Up |
| High-risk identity processing with a current DPIA | Assessment coverage | Up |
Implementation roadmap
| Phase | Focus | Actions |
|---|---|---|
| First 30 days | Know what you hold | Inventory identity data by system, vendor, purpose, basis and retention; find stored document images and biometric data; list consent screens and OAuth consent settings |
| Days 31 to 90 | Fix the high-risk items | Delete proofing evidence past its purpose; separate marketing consent from terms; restrict support staff views of ID data; require admin approval for high-risk scopes; confirm DPIAs for biometrics and proofing |
| Days 91 to 180 | Automate rights and retention | Connect erasure and correction to provisioning and vendors; add requester verification based on existing authentication; automate log and evidence retention; build a single grant review page for users |
| Beyond 180 days | Design it in | Adopt attribute verification and selective disclosure where possible; record agent delegations with principal, scope and expiry; review identity processing annually with the privacy team |
Practitioner checklist
- Map identity data by system, vendor, purpose, lawful basis and retention.
- Minimise collection and prefer attribute verification over storing evidence.
- Protect biometric and identity document data with extra controls, an Article 9 condition and deletion by default.
- Make consent granular, recorded and revocable, and keep security processing on a proper basis.
- Limit what support staff and tools can see of identity documents and profiles.
- Show clear delegation screens and a single place to review and revoke grants, including for AI agents.
- Record principal, agent, scope, purpose and expiry for every agent delegation.
- Support rights requests across all identity stores, with proportionate requester verification.
- Propagate corrections and erasure to provisioned applications and vendors.
- Complete DPIAs for proofing, biometrics, behavioural analytics and agent deployments.
Standards and references
- legislation.gov.uk: Regulation (EU) 2016/679, United Kingdom General Data Protection Regulation
- EDPB: Guidelines 05/2020 on consent under Regulation 2016/679
- ICO: What is valid consent?
- ICO: When can we rely on legitimate interests?
- ICO: Biometric data guidance, Key data protection concepts
- ICO: When do we need to do a DPIA?
- ICO: A guide to subject access
- ICO: Principle (e), Storage limitation
- legislation.gov.uk: Money Laundering Regulations 2017, regulation 40 (record-keeping)
- NIST: Privacy Framework
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- IETF: RFC 8693, OAuth 2.0 Token Exchange
Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Biometrics Guide · GDPR Compliance Guide for Security Teams · Identity Security Regulatory Map · Agentic AI Compliance Guide. This guide summarises privacy principles and requirements that apply to identity data and is not legal advice.