5.1 Information Security Practices, Data Classification & Access Controls

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:

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

Controls by Function

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?

1. Classification gap — transaction history should have been classified at least Confidential (arguably Restricted given financial sensitivity), triggering stricter controls.
2. 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.
3. Least privilege violated — the analyst received broad database access instead of a narrow, purpose-specific view.
4. 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.
5. 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).