Identity Governance, Privacy, Ethics, and Compliance

Introduction

Authentication answers the question “Who are you?” Authorization answers “What may you do?” Identity governance asks a broader set of questions: Why should access exist? Is it proportionate to the person’s role? Was consent or another lawful basis established? Can the organization demonstrate that access decisions are fair, secure, accessible, reviewable, and compliant throughout the identity life cycle?

For full-stack developers, these questions are not confined to legal departments. They affect database schemas, user interfaces, API design, logging, administrative workflows, biometric integrations, account recovery, and deletion processes. A technically effective identity system can still be unethical or unlawful if it collects excessive data, excludes disabled users, enables unjustified surveillance, or cannot explain its decisions.

Identity governance is therefore a strategic discipline. It connects security controls with privacy principles, organizational accountability, human rights, risk management, and regulatory obligations.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish identity governance from authentication and authorization;
• apply consent, purpose limitation, data minimization, retention, and privacy-by-design principles;
• evaluate biometric authentication and surveillance risks;
• design access certification, segregation of duties, and auditable identity processes;
• use NIST, ISO/IEC, privacy, accessibility, and industry frameworks appropriately;
• analyze fairness, explainability, and accountability in identity decisions; and
• recommend controls that are proportionate to organizational and regulatory risk.

1. Identity Governance as a Life-Cycle Discipline

Identity governance is the set of policies, processes, roles, and technologies used to manage digital identities and their entitlements. It covers the identity life cycle:

1. Registration and proofing: establishing that an identity corresponds to a real person, organization, device, or service.
2. Provisioning: creating accounts and assigning initial permissions.
3. Use: authenticating the identity and enforcing authorization decisions.
4. Review: confirming that permissions remain necessary and appropriate.
5. Change: adjusting access after role, department, risk, or employment changes.
6. Suspension and revocation: removing or restricting access when circumstances require it.
7. Archiving and deletion: retaining or destroying identity data according to purpose, law, and policy.

Governance is not identical to identity and access management (IAM). IAM commonly describes the operational technologies that authenticate users, issue tokens, and enforce permissions. Identity governance adds oversight: policy ownership, risk decisions, evidence, review, accountability, and continuous improvement.

A useful governance principle is least privilege over the complete life cycle, not merely at login. A user may authenticate strongly and still possess excessive permissions. Conversely, a well-designed authorization policy may be undermined by weak account recovery or stale accounts.

Important roles

• Identity owner: accountable for the identity record and its quality.
• Resource owner: accountable for a system, dataset, or application.
• Access approver: evaluates whether requested access is justified.
• User or subject: the person or entity whose identity and access are managed.
• Privacy officer or data protection officer: advises on privacy obligations and individual rights where applicable.
• Auditor: independently evaluates whether controls operate as claimed.
• Administrator: implements or maintains access, but should not automatically approve their own access.

Clear ownership prevents the common failure in which everyone can change access but nobody is accountable for reviewing it.

2. Frameworks for Governance and Control

No single framework answers every governance question. Frameworks should be combined according to purpose.

NIST frameworks

The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes under Govern, Identify, Protect, Detect, Respond, and Recover. The Govern function is especially relevant to identity governance because it addresses organizational context, risk strategy, roles, policy, oversight, and supply-chain considerations.

NIST Special Publication 800-63 provides digital identity guidelines covering identity proofing, authentication, and federation. It uses assurance levels to help organizations select controls proportionate to risk. The important lesson is not to select the strongest control automatically, but to match identity assurance to the consequence of impersonation, fraud, or unauthorized disclosure.

NIST Privacy Framework supports privacy risk management through the functions Identify-P, Govern-P, Control-P, Communicate-P, and Protect-P. It emphasizes that privacy risk concerns problematic data processing, not only confidentiality breaches.

ISO/IEC standards

ISO/IEC 27001 provides requirements for an information security management system (ISMS). It requires an organization to establish a systematic, risk-based management process and maintain evidence of operation. ISO/IEC 27002 provides guidance for information security controls, including access control, logging, and segregation of duties.

ISO/IEC 27701 extends an information security management system toward a privacy information management system. It helps organizations assign privacy responsibilities and manage personal-data processing, but certification does not itself guarantee compliance with every privacy law.

ISO/IEC 29100 presents privacy principles and terminology. These principles support analysis of consent, purpose legitimacy, collection limitation, openness, accountability, and data-subject participation.

Privacy and security are related but distinct

Security seeks to prevent unauthorized access, alteration, disclosure, or destruction. Privacy concerns appropriate and legitimate processing of information about people. Encryption can protect a database while the organization still violates privacy by collecting information without a valid purpose. Conversely, a transparent and lawful process may still be insecure.

A mature program integrates both perspectives through a documented risk assessment, data inventory, records of processing, access controls, privacy notices, incident procedures, and individual-rights processes.

3. Consent, Purpose, and Data Minimization

Consent is not a universal solution

Consent is meaningful only when it is informed, specific, freely given, and expressed through an affirmative action. It should not be hidden in confusing language or bundled with unrelated purposes. In employment, education, or essential-service settings, a power imbalance may make consent insufficiently voluntary. Depending on the jurisdiction, other lawful bases may include contract necessity, legal obligation, vital interests, public interest, or legitimate interests subject to safeguards.

A developer should never assume that adding a checkbox makes processing ethical or lawful. The organization should document:

• what data is collected;
• why it is needed;
• who receives it;
• how long it is retained;
• whether it is transferred across borders;
• whether refusal affects service access; and
• how consent can be withdrawn.

Withdrawal should be practical. If withdrawing consent is substantially harder than giving it, the control is ethically defective.

Purpose limitation

Purpose limitation means collecting and using data for specified, explicit, and legitimate purposes. A photograph collected to issue an identity card should not automatically become a training set for facial-recognition development. A location record collected for fraud prevention should not silently become an employee-productivity surveillance system.

Secondary use requires a compatibility assessment, a new legal basis or consent where necessary, transparency, and technical controls. Data warehouses and analytics platforms are particularly prone to purpose drift because data can be reused long after its original context is forgotten.

Data minimization

Data minimization means collecting and retaining no more personal data than is reasonably necessary for the stated purpose. It applies to fields, precision, frequency, retention, and audience.

Examples include:

• storing an age band rather than an exact birth date when age verification is sufficient;
• storing a salted password hash rather than a password;
• returning an authorization decision rather than exposing a complete personnel record;
• using a short-lived claim instead of embedding unnecessary profile data in an access token; and
• retaining a verification result rather than a copy of an identity document when the copy is not required.

Minimization is not the same as deleting all data immediately. Some records are necessary for security investigations, financial accountability, or legal obligations. The correct approach is a documented balance between necessity, risk, rights, and retention requirements.

4. Privacy by Design and the Data Life Cycle

Privacy by design integrates privacy into architecture rather than adding it after deployment. Seven commonly cited principles are proactive prevention, privacy as the default, privacy embedded in design, full functionality, end-to-end security, visibility and transparency, and respect for user privacy.

A practical design review can ask:

1. What personal data enters the system?
2. What is the precise purpose of each field?
3. Which components can access it?
4. Can the process work with less data or lower precision?
5. How are correction, access, deletion, and objection requests handled?
6. What happens when the user refuses optional processing?
7. What evidence demonstrates that controls operate?

Privacy-enhancing techniques include tokenization, pseudonymization, encryption, access segmentation, aggregation, selective disclosure, and privacy-preserving analytics. Pseudonymization reduces direct identification risk but does not necessarily make data anonymous; a separately held mapping key can reconnect records to a person.

A data protection impact assessment (DPIA), or an equivalent privacy risk assessment, is particularly valuable for large-scale monitoring, sensitive data, systematic profiling, biometrics, vulnerable populations, and novel technologies. It should identify risks to individuals, evaluate necessity and proportionality, specify mitigations, and be revisited when processing changes.

5. Accessibility and Inclusive Identity

An identity control that excludes legitimate users is a governance failure. Accessibility applies to registration, multi-factor authentication, account recovery, consent notices, challenge mechanisms, and administrative support.

Potential barriers include inaccessible CAPTCHA systems, authentication apps that do not work with screen readers, touch or fingerprint requirements that exclude users with motor impairments, time limits that disadvantage cognitive disabilities, and recovery procedures that assume possession of a particular device.

The Web Content Accessibility Guidelines (WCAG) provide widely used guidance for perceivable, operable, understandable, and robust web content. Accessibility should also be evaluated against applicable disability-discrimination and public-sector laws in the relevant jurisdiction.

Inclusive controls should provide equivalent security rather than weaker “special” paths. Examples include multiple authentication modalities, accessible error messages, keyboard operation, sufficient time, human-assisted recovery, hardware alternatives, and testing with disabled users. Accessibility exceptions should be documented as risk decisions, not treated as user inconvenience.

6. Biometrics and Surveillance Ethics

Biometric authentication uses physical or behavioral characteristics such as fingerprints, facial features, iris patterns, voice, or typing behavior. Biometrics can improve convenience and resist some forms of credential sharing, but they create distinctive risks.

A password can be changed after compromise; a face or fingerprint generally cannot. Biometric systems can also produce demographic differences in error rates, perform poorly in uncontrolled environments, expose sensitive inferences, and create function-creep risks. Centralized biometric databases create attractive targets and may enable tracking across contexts.

Before deployment, an organization should evaluate:

• necessity compared with less intrusive alternatives;
• whether the biometric is used for verification or identification;
• false-match and false-non-match performance across relevant populations;
• presentation-attack resistance and liveness controls;
• template protection and key management;
• local processing versus centralized storage;
• retention and deletion;
• meaningful alternatives for people who cannot or do not wish to use biometrics; and
• independent oversight and impact assessment.

Biometric systems should not be described as infallible. A false match may grant access to the wrong person; a false non-match may deny access to the right person. Threshold selection is a governance decision involving security, usability, inclusion, and operational consequences.

Surveillance risk extends beyond biometrics. Persistent login telemetry, location tracking, keystroke monitoring, and behavioral profiling can chill lawful activity and alter power relationships. Proportionality requires a credible purpose, necessity, narrow scope, limited duration, transparency, access restrictions, and independent review.

7. Fairness, Explainability, and Human Oversight

Identity systems can create unfair outcomes through biased data, inaccessible processes, proxy variables, poor threshold selection, or unequal error costs. Fairness is not achieved merely by removing explicit demographic fields. Device type, language, location, name format, or employment history may act as proxies.

A governance review should examine outcomes across relevant groups, while respecting data-protection limits on sensitive attribute collection. Useful questions include:

• Are enrollment and authentication failure rates materially different across groups?
• Are support and recovery options equally available?
• Does an automated risk score trigger more scrutiny for some communities?
• Can a person challenge an incorrect decision?
• Is a human reviewer trained and authorized to override the system?

Explainability should be proportionate to impact. A low-risk session timeout may need a simple message. Denial of access to healthcare, education, employment, or essential services requires a meaningful explanation, an appeal path, and human review where appropriate.

Fairness metrics can conflict. For example, equal false-positive rates and equal false-negative rates may not both be achievable when groups have different base rates or score distributions. Consequently, fairness must be treated as a socio-technical judgment supported by measurement, consultation, and documented policy—not as the selection of one universal mathematical test.

8. Auditability, Evidence, and Accountability

Auditability means that an organization can reconstruct what happened, why it happened, who authorized it, and whether the action complied with policy. Audit logs should support accountability without becoming an uncontrolled source of personal-data exposure.

A useful access event may include a subject or service identifier, action, resource, decision, timestamp, policy version, authentication context, source system, and correlation identifier. Sensitive values should be minimized or protected. Logs require access control, integrity protection, time synchronization, retention rules, monitoring, and secure disposal.

Auditability has three layers:

1. Event evidence: records of requests, approvals, changes, and use.
2. Decision evidence: the policy, role, attribute, or risk rule that produced a decision.
3. Governance evidence: review results, exceptions, training, risk acceptance, and remediation.

A log is not automatically evidence of compliance. If administrators can silently alter logs, if timestamps are unreliable, or if no one reviews alerts, the organization has records but weak accountability.

9. Retention and Secure Disposal

Retention should be based on purpose, risk, operational need, and applicable legal requirements. “Keep everything forever” increases breach impact, discovery burden, and misuse opportunities. “Delete everything immediately” may undermine investigations, statutory duties, or individual rights.

A retention schedule should identify the record category, owner, purpose, retention trigger, duration or review event, legal hold process, storage location, and disposal method. Triggers may include account closure, contract completion, the end of a fiscal period, or resolution of a dispute.

Deletion must address replicas, backups, caches, exports, analytics copies, and vendor systems. Where immediate deletion from immutable backups is impractical, the organization should restrict restoration access and apply a documented expiry process. Cryptographic erasure can be effective when encryption keys are uniquely controlled and destroying the key renders the data computationally inaccessible; it is not a universal substitute for lifecycle management.

10. Segregation of Duties and Access Certification

Segregation of duties (SoD) prevents one person from controlling incompatible stages of a sensitive process. For example, the same administrator should not create a privileged account, approve its access, and certify that access without independent review.

Typical incompatible combinations include:

• requesting and approving one’s own access;
• developing and deploying code directly to production without review;
• creating a vendor and approving its payment; and
• administering identity policies while independently approving audit exceptions.

SoD can be preventive, detective, or compensating. A small organization may lack enough staff for perfect separation, so it should use compensating controls such as independent review, immutable logging, time-limited elevation, dual approval, and post-event reconciliation.

Access certification is a periodic or event-driven review in which an accountable resource owner confirms that entitlements remain appropriate. Effective certification is not a “click all” exercise. Reviewers need understandable entitlement descriptions, risk context, recent usage where appropriate, conflict warnings, and the authority to revoke access. Reviews should be triggered by role changes, reorganizations, acquisitions, incidents, and changes in data sensitivity—not only by a calendar.

11. Regulatory Obligations and Shared Responsibility

Regulatory obligations vary by jurisdiction, sector, organization role, and processing activity. Common themes across modern privacy regimes include transparency, lawful processing, purpose limitation, data minimization, accuracy, security, retention limitation, individual rights, breach response, and accountability.

Examples of relevant regimes and obligations may include:

• comprehensive privacy laws, such as the EU General Data Protection Regulation, which addresses lawful bases, data-subject rights, security, breach notification, processor relationships, and accountability;
• sectoral requirements for health, finance, education, or children’s data;
• accessibility and anti-discrimination laws;
• contractual standards such as payment-card security requirements; and
• organizational control frameworks such as SOC 2, which evaluates controls against trust-service criteria.

These instruments are not interchangeable. A control framework can help demonstrate disciplined practice, but it does not replace legal analysis. Developers should involve privacy, legal, security, and compliance specialists when processing is high-risk or crosses jurisdictions.

Cloud and software vendors create shared responsibility. A customer may remain responsible for lawful collection, configuration, access decisions, and retention even when the provider secures the underlying infrastructure. Contracts should address processing instructions, subprocessors, breach cooperation, deletion, audit rights, location, and assistance with individual requests.

12. Illustrative Case: University Identity Platform

Background

A university plans a single identity platform for students, faculty, contractors, library users, and visitors. It proposes facial recognition for examination access, continuous location collection for “campus safety,” and automatic access to research systems based on department membership.

Problem

The proposal creates risks of excessive collection, function creep, unequal biometric performance, inaccessible alternatives, stale permissions, and unclear responsibility between the university and its cloud provider. Department membership alone may not justify access to sensitive research data.

Analysis

A governance team maps the data life cycle and performs a DPIA. It distinguishes authentication from attendance monitoring and from emergency response. It finds that facial recognition is not necessary for ordinary examination access because strong multi-factor authentication and supervised identity checks can achieve the purpose with less intrusion. It also finds that continuous location collection is disproportionate for general campus safety.

The team identifies role conflicts: departmental administrators request access, approve it, and later certify it. It also discovers that the proposed recovery process requires a smartphone, excluding some users.

Approach and solution

The university adopts:

• phishing-resistant multi-factor authentication for staff and privileged users;
• several accessible authentication and recovery methods;
• no compulsory facial recognition for ordinary examinations;
• narrowly scoped, event-based location processing with published purpose and retention limits where legally justified;
• attribute-based access decisions requiring role, project membership, training, and data-owner approval;
• automated joiner-mover-leaver workflows;
• quarterly high-risk access certification and event-driven reviews;
• SoD rules separating request, approval, implementation, and certification;
• protected, reviewable audit logs;
• a retention schedule for identity documents, access records, and security events; and
• a vendor contract covering processing, deletion, incidents, subprocessors, and assistance with rights requests.

Outcome

The university reduces biometric and surveillance exposure, improves accessibility, and produces clearer evidence for audits. Some convenience is lost, and the project requires more governance work, but the resulting architecture is more proportionate and sustainable.

Learning points

First, the strongest-looking technology is not necessarily the most appropriate control. Second, privacy and accessibility must be designed before implementation. Third, access governance depends on accountable human roles as well as automation. Finally, a lawful and ethical system must be able to explain its decisions and correct errors.

13. A Practical Governance Method for Developers

When designing an identity feature, use the following sequence:

1. Define the decision: What access or identity decision is being made?
2. Identify the affected people: Include users, bystanders, administrators, and vulnerable groups.
3. Specify the purpose: State the legitimate, narrow purpose in plain language.
4. Select proportionate assurance: Match proofing and authentication strength to risk.
5. Minimize data: Remove fields, precision, copies, and retention not required.
6. Design alternatives: Provide accessible and non-biometric options where feasible.
7. Separate duties: Prevent self-approval and uncontrolled privilege escalation.
8. Make decisions reviewable: Record sufficient evidence without excessive personal data.
9. Set lifecycle controls: Automate provisioning, change, revocation, review, and disposal.
10. Test outcomes: Evaluate security, usability, accessibility, fairness, and failure recovery.
11. Document exceptions: Record who accepted residual risk, for how long, and with what compensating controls.
12. Reassess change: Revisit the analysis when purpose, technology, law, vendor, or population changes.

Challenges and Limitations

Governance cannot eliminate all risk. Stronger authentication may reduce fraud but increase exclusion. More logging may improve accountability but increase privacy exposure. Data minimization may limit future analytics. Human review may correct automation errors but introduce inconsistency or delay. International operations create conflicts among laws, contractual requirements, and cultural expectations.

Frameworks also have limitations. They provide structured language and controls, but they do not determine whether a particular purpose is morally justified. Compliance checklists can encourage superficial evidence rather than genuine accountability. Risk assessments may reproduce organizational bias if affected communities are not consulted. Therefore, governance should combine technical testing, legal analysis, ethical reasoning, user research, independent review, and continuous monitoring.

Chapter Summary

Identity governance extends authentication and authorization into a full life-cycle system of accountability. It requires clear ownership, proportionate assurance, least privilege, access certification, segregation of duties, reliable audit evidence, and timely revocation. Privacy governance requires lawful and transparent processing, meaningful consent where consent is relied upon, purpose limitation, data minimization, retention control, individual participation, and privacy by design. Accessibility and fairness are security and governance requirements, not optional enhancements. Biometrics and surveillance demand especially careful proportionality analysis because they can create persistent and difficult-to-reverse harms. NIST, ISO/IEC, privacy, accessibility, and industry frameworks provide complementary guidance, but none replaces context-specific judgment. The central professional obligation is to build identity systems that are secure, explainable, inclusive, auditable, and limited to legitimate purposes.

Key Terms

Identity governance: Policies, processes, roles, and technologies that manage identities and access throughout their life cycle.

Identity life cycle: The stages from registration and provisioning through use, review, change, revocation, and deletion.

Data minimization: Collecting, using, and retaining no more personal data than necessary.

Purpose limitation: Restricting processing to specified, explicit, and legitimate purposes.

Consent: An informed, specific, freely given, affirmative permission for processing.

Privacy by design: Integrating privacy safeguards into architecture and operations from the beginning.

Pseudonymization: Processing data so direct identification is reduced while re-identification remains possible with additional information.

Biometric data: Data relating to physical or behavioral characteristics used to identify or authenticate a person.

Surveillance: Systematic observation, recording, or analysis of people or their behavior.

Accessibility: Designing services so people with diverse abilities can use them effectively and independently.

Fairness: The requirement that identity processes avoid unjustified or discriminatory differences in treatment or outcomes.

Auditability: The ability to reconstruct and evaluate actions, decisions, and accountability evidence.

Retention schedule: A documented rule specifying how long records are kept and when they are reviewed or destroyed.

Segregation of duties: Dividing incompatible responsibilities among people or controls to reduce abuse and error.

Access certification: Formal confirmation that existing entitlements remain necessary and appropriate.

Least privilege: Granting only the minimum access required for an authorized purpose.

Data protection impact assessment: A structured assessment of privacy risks, necessity, proportionality, and mitigations.

Accountability: The duty to demonstrate responsible processing and effective operation of controls.

Review Questions

Short Answer Questions

1. How does identity governance differ from ordinary identity and access management?
2. Why is consent not always an appropriate lawful basis for identity processing?
3. Give two examples of data minimization in an authentication system.
4. What is the purpose of segregation of duties?
5. Why are biometric identifiers difficult to replace after compromise?

Long Answer Questions

1. Explain how NIST and ISO/IEC frameworks can be combined to govern an identity platform.
2. Discuss the relationship among purpose limitation, retention, and secure disposal.
3. Evaluate the accessibility requirements of a multi-factor authentication system.
4. Explain how access certification and joiner-mover-leaver processes reduce identity risk.
5. Discuss why privacy, security, fairness, and usability may require trade-offs in identity design.

Analytical / Application Questions

1. A company wants to collect continuous employee location data to detect unauthorized access. Analyze necessity, proportionality, minimization, retention, transparency, and alternatives before recommending a design.
2. An automated identity-risk engine rejects users from one region more often than others. Propose an investigation covering data quality, error rates, fairness, appeal, human oversight, and remediation.
3. Design a governance process for a privileged cloud-administration role that includes request, approval, provisioning, monitoring, certification, emergency access, and revocation.

Multiple Choice Questions with Answers

Question 1

Which activity is most directly associated with identity governance rather than basic authentication?

A. Verifying a password against a stored hash

B. Issuing a session cookie after login

C. Reviewing whether a user’s existing permissions remain necessary

D. Displaying a login form

Correct Answer: C. Reviewing whether a user’s existing permissions remain necessary

Question 2

Which practice best demonstrates data minimization?

A. Keeping identity documents indefinitely for convenience

B. Collecting an exact birth date when only an age threshold is required

C. Storing a verification result instead of an unnecessary document copy

D. Adding every available user attribute to an access token

Correct Answer: C. Storing a verification result instead of an unnecessary document copy

Question 3

Which statement about consent is most accurate?

A. A checkbox always makes processing lawful

B. Consent should be informed, specific, freely given, and affirmative

C. Consent cannot be withdrawn after account creation

D. Consent is always voluntary in an employment relationship

Correct Answer: B. Consent should be informed, specific, freely given, and affirmative

Question 4

Why do biometric systems create a distinctive governance concern?

A. Biometric data is never useful for authentication

B. Biometric characteristics can usually be replaced as easily as passwords

C. Compromised biometric characteristics are difficult or impossible to replace

D. Biometrics eliminate all authentication errors

Correct Answer: C. Compromised biometric characteristics are difficult or impossible to replace

Question 5

Which control best supports segregation of duties?

A. Allowing an administrator to approve their own privileged access

B. Separating access request, approval, implementation, and certification

C. Giving all reviewers unrestricted administrative privileges

D. Removing all audit logs after each review

Correct Answer: B. Separating access request, approval, implementation, and certification

Question 6

What is the main purpose of access certification?

A. To create a password for every employee

B. To confirm that existing entitlements remain appropriate

C. To replace all authentication factors with biometrics

D. To prevent users from changing roles

Correct Answer: B. To confirm that existing entitlements remain appropriate

Question 7

Which statement correctly distinguishes privacy from security?

A. Privacy and security are identical concepts

B. Security concerns protection, while privacy also concerns appropriate and legitimate processing

C. Privacy applies only after a data breach

D. Security makes purpose limitation unnecessary

Correct Answer: B. Security concerns protection, while privacy also concerns appropriate and legitimate processing

Question 8

Which feature most improves auditability of an authorization decision?

A. Recording only that a user logged in

B. Recording the decision, timestamp, policy context, and relevant correlation identifier

C. Allowing administrators to edit logs without detection

D. Deleting access records immediately after use

Correct Answer: B. Recording the decision, timestamp, policy context, and relevant correlation identifier

Question 9

What is a suitable response when a biometric control excludes users with disabilities?

A. Require the excluded users to accept lower security

B. Remove all authentication controls

C. Provide an equivalent accessible authentication alternative and test it

D. Ignore the issue because security always overrides accessibility

Correct Answer: C. Provide an equivalent accessible authentication alternative and test it

Question 10

Which statement best describes pseudonymization?

A. It always makes data anonymous and outside privacy obligations

B. It reduces direct identification while re-identification may remain possible

C. It is the same as deleting data

D. It prevents all unauthorized processing automatically

Correct Answer: B. It reduces direct identification while re-identification may remain possible