Study guide
5.1 Information Security Practices, Data Classification & Access Controls
Certified Information Privacy Manager CIPM
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 CIPM Exam Facts & Format 1.2 The CIPM Body of Knowledge: Six Domains & How the Exam Is Built 1.3 Study Strategy, Timeline & How to Use This Guide
2 Domain I: Developing a Privacy Program Framework
2.1 Program Scope, Strategy & Governance Model 2.2 Stakeholders, Privacy Team Structure & Common Vocabulary 2.3 Applicable Regulations, Oversight Agencies & Non-Compliance Impact 2.4 Personal Information Sources, Cross-Border Operations & AI Privacy Risk 2.5 Business Model, Operating Environment & Risk Appetite 2.6 Structuring the Privacy Team: DPO, CPO, Representatives & Resourcing 2.7 Vision, Mission & the Privacy Program Communication Plan 2.8 Policy Access, Version Control & Role-Relevant Updates 2.9 Codes of Conduct, Certifications & Self-Certification Mechanisms
3 Domain II: Establishing Program Governance
3.1 Privacy Policies & Life-Cycle Processes 3.2 Breach, Complaint, DSR & Retention Plans 3.3 Roles, Responsibilities, Metrics & Continuous Legal Monitoring 3.4 Training & Awareness Activities 3.5 Governance Bodies, Program Charter & Escalation Paths 3.6 Governing Internal & External Data Sharing and Disclosure 3.7 Retention Schedules & Defensible Disposal 3.8 Regulatory Change Monitoring & Enforcement Systems
4 Domain III: Operational Life Cycle — Assessing Data
4.1 Data Inventories, Flows & Life-Cycle Mapping 4.2 Data Discovery, System Integrations & Keeping the Inventory Current 4.3 Policy Compliance Measurement & Gap Analysis 4.4 Processor/Vendor Evaluation & Physical/Environmental Controls 4.5 Third-Party Risk Life Cycle & Sub-Processor Chains
5 Domain III (continued): Assessing Data — Technical & Physical Controls, M&A Risk
4.6 Technical Controls, Use/Retention Limits & Data Location 4.7 Physical & Environmental Controls in Depth 4.8 Mergers, Acquisitions & Divestitures Data Risk
6 Domain IV: Operational Life Cycle — Protecting Personal Data
5.1 Information Security Practices, Data Classification & Access Controls 5.2 Privacy by Design Principles & the SDLC 5.3 Organizational Guidelines for Data Use & Secondary-Use Governance 5.4 Privacy-Enhancing Technologies & Technical Control Enforcement 5.5 Technical, Administrative & Organizational Measures 5.6 Access Reviews, Monitoring & Enforcing Technical Controls
7 Domain V: Operational Life Cycle — Sustaining Program Performance
6.1 Privacy Metrics for Program Performance 6.2 Auditing the Privacy Program 6.3 Continuous Assessment: PIA, DPIA, TIA, LIA & PTA 6.4 Risk Mitigation, Post-M&A Assessment & Ethical AI Use
8 Domain VI: Operational Life Cycle — Responding to Requests & Incidents
7.1 Data Subject Access Requests & Consent/Rights Processes 7.2 Global Privacy Legislation on Data Subject Rights 7.3 Incident Handling, Breach Response & Records 7.4 Post-Incident Review & IR Plan Improvement 7.5 Privacy Notices & Transparency Obligations 7.6 Complaint Handling & Regulator Interaction 7.7 Breach Communications to Regulators, Individuals & Other Stakeholders
9 Final Review & Exam Strategy
8.1 Mixed-Domain Scenarios & Common Exam Traps 8.2 Test-Day Logistics, Score Strategy & Credential Maintenance
5.1 Information Security Practices, Data Classification & Access Controls
Key Takeaways Explain This Topic AI
Data classification is the foundation of every downstream access, retention, and protection decision — each tier (public, internal, confidential, restricted) maps to a control baseline, and a classification that does not trigger proportionate controls is a classification failure
Controls are categorized along two axes the exam tests: by type (administrative, technical, physical) and by function (preventive, detective, corrective) — defense in depth layers both axes so a single control failure does not expose personal data
RBAC grants access to roles but is coarse; ABAC evaluates user, resource, action, and environment attributes for finer granularity; least privilege and need-to-know are principles that tighten any model; MFA is a baseline for confidential and restricted data, not an optional enhancement
Just-in-Time (JIT) access replaces standing privileged access with time-boxed, task-specific grants that auto-expire — the primary control for reducing persistent privileged-access risk
The privacy manager's IV.A duty is to classify data, select controls proportionate to sensitivity, and implement access controls that match — not to design the cryptographic primitives, which is IV.C collaboration
Last updated: August 2026
Classifying Data to the Applicable Classification Scheme
Data classification is the foundation on which every downstream access, retention, and protection decision rests. The CIPM Body of Knowledge (IV.A) expects the privacy manager to apply the organization's classification scheme consistently so that each data element receives controls proportionate to its sensitivity and the risk it poses to data subjects.
Common Classification Tiers
Most organizations adopt a three- or four-tier scheme. The exam does not require a specific label set — it requires you to classify data to the applicable scheme , meaning the scheme the organization has actually adopted. Common tiers:
- Tier Typical Label Examples Default Handling
- 1 Public Marketing content, published filings No access restriction; integrity controls only
- 2 Internal Internal memos, aggregate analytics Employee access; no external sharing without approval
3 Confidential Customer personal data, employee records, contracts Need-to-know access; encryption in transit and at rest; access logging
4 Restricted Health data, biometric data, government IDs, payment credentials Strictest controls: MFA, JIT access, full audit trail, encryption with managed keys
Some organizations add a Secret tier above Restricted for cryptographic keys and credentials. The key exam point: the label matters less than the consistency of application — every system and vendor must map its data to the same scheme so controls are comparable across the organization.
Classification Drives Control Selection
Classification is not an end in itself. Each tier maps to a control baseline — the minimum set of administrative, technical, and physical controls that must be in place. A Confidential classification that does not trigger encryption, access logging, and a need-to-know access model is a classification failure, not a control failure. The privacy manager verifies that the mapping between tiers and controls is documented, approved, and enforced.
Understanding Control Purposes and Limitations
The BoK requires you to understand the purposes and limitations of different control types. Controls are categorized along two axes: by type (administrative, technical, physical) and by function (preventive, detective, corrective).
Controls by Type
Control Type Purpose Examples Limitation
Administrative Direct human behavior through policy and procedure Acceptable-use policy, access-approval workflow, training, vendor due diligence Depends on compliance; can be bypassed by determined insiders
Technical Enforce controls through system logic RBAC, encryption, MFA, logging, DLP, intrusion detection Can be misconfigured; vulnerable to exploitation; needs patching
Physical Protect tangible assets and access to systems Badge access, locked server rooms, biometric door locks, secure media disposal Can be defeated by tailgating, lost badges, social engineering of guards
Controls by Function
Function Purpose Examples
Preventive Stop an adverse event before it occurs Access approvals, encryption, firewalls, segregation of duties
Detective Identify an event that has occurred or is occurring Access-log review, intrusion detection, DLP alerts, anomaly monitoring
Corrective Restore the system after an event and limit damage Incident response, backup restoration, account revocation, patch deployment
A defense-in-depth strategy layers preventive, detective, and corrective controls across administrative, technical, and physical types so that the failure of any single control does not expose personal data. The exam tests whether you can identify which control type or function is missing in a given scenario.
Identifying Risks and Implementing Access Controls
Access controls are the operational expression of data classification. The BoK expects you to identify risks and implement applicable access controls.
Core Access Control Models and Principles
Role-Based Access Control (RBAC) — access is granted to roles, not individuals; users are assigned roles. Most common in enterprises. Scalable but coarse: a role may grant more access than a specific user needs.
Attribute-Based Access Control (ABAC) — access decisions evaluate attributes of the user, resource, action, and environment (e.g., allow if user.department = billing AND data.tier = confidential AND time = business-hours). More granular than RBAC but more complex to maintain.
Least privilege — each user receives only the access necessary for their current task, and no more. Reviewed periodically; access revoked when the task ends.
Need-to-know — access is granted based on a demonstrated, specific business need, not on role or seniority alone. Tighter than least privilege because it is task-scoped.
Multi-Factor Authentication (MFA) — requires two or more independent factors (something you know, have, are). The BoK treats MFA as a baseline for access to confidential and restricted data, not an optional enhancement.
Just-in-Time (JIT) access — elevated or privileged access is granted for a limited time window to complete a specific task, then automatically revoked. Replaces standing privileged access, which is a persistent risk.
Access Control Risk Patterns the Exam Tests
Privilege creep — users accumulate access over time as they change roles; old access is never removed. Mitigated by periodic access reviews and automated role-change triggers.
Over-entitled roles — an RBAC role grants broader access than most role-holders need. Mitigated by role mining and splitting broad roles into narrower ones.
Shared credentials — multiple users share one account, destroying individual accountability. Mitigated by unique IDs and technical enforcement against shared logins.
Standing privileged access — administrators hold always-on elevated rights. Mitigated by JIT access and privileged access management (PAM).
Worked Scenario: Classification and Access Control Failure
A regional bank classifies customer account numbers as Confidential but does not classify the associated transaction history at all. A data analyst in marketing is granted read access to the Confidential customer table for a campaign-matching project. Because transaction history was unclassified, the analyst's broad database access also covers transactions. The analyst exports 200,000 customer transaction records to a personal laptop to work remotely.
What went wrong at the IV.A level?
Classification gap — transaction history should have been classified at least Confidential (arguably Restricted given financial sensitivity), triggering stricter controls.
Access control not tied to classification — the analyst's access was granted for the customer table but, because transaction history was unclassified, no separate approval was required.
Least privilege violated — the analyst received broad database access instead of a narrow, purpose-specific view.
No JIT or need-to-know enforcement — standing access to production data for a marketing project that could have been served by a de-identified extract.
Administrative control absent — no policy requiring off-system export approval or endpoint controls for Confidential data.
The fix is not only technical (revoke access, classify transactions) but also administrative (require classification review before access provisioning, enforce export approval, add endpoint controls for Confidential data leaving approved systems).