5.5 Technical, Administrative & Organizational Measures
Key Takeaways
- Indicator IV.A.4 requires the use of appropriate technical, administrative and organizational measures to mitigate risk — GDPR Article 32 makes the same set the legal security baseline.
- Article 32 names four capabilities explicitly: pseudonymization and encryption, ongoing confidentiality/integrity/availability/resilience, timely restoration of availability after an incident, and a process for regularly testing and evaluating effectiveness.
- Appropriateness is risk-calibrated, not absolute: state of the art, cost of implementation, nature and scope of processing, and the risk to individuals all feed the decision.
- The privacy manager's job is to specify the required outcome, verify it is delivered, and evidence it — not to engineer the control personally.
- Regularly testing and evaluating effectiveness is a standalone obligation: an untested control set is non-compliant even if every control is well designed.
The Phrase That Appears in Every Privacy Law
Performance indicator IV.A.4 — use appropriate technical, administrative and organizational measures to mitigate risk — restates the phrase that anchors security obligations across privacy law. GDPR Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk; the HIPAA Security Rule organises safeguards as administrative, physical and technical; US state comprehensive laws require reasonable administrative, technical and physical safeguards.
The CIPM does not test you as a security engineer. It tests whether you can specify the outcome, verify it was delivered, and evidence it to a regulator — and whether you can tell the three measure families apart, because scenario items routinely offer a technical control when the question asked for an organizational one.
The three families
| Family | What it is | Examples |
|---|---|---|
| Technical | Controls implemented in technology | Encryption at rest and in transit, key management, MFA, network segmentation, logging and alerting, vulnerability and patch management, backup and restore, DLP, endpoint protection |
| Administrative | Controls implemented through policy and process | Policies and standards, access approval and periodic review, security awareness and role-based training, background screening where lawful, joiner-mover-leaver process, change management, incident response procedures |
| Organizational | Controls implemented through structure and accountability | Named ownership, segregation of duties, governance bodies, vendor management, risk assessment cadence, audit function, board oversight |
Many frameworks fold organizational into administrative; the CIPM blueprint lists all three, so keep them separable. When a stem asks how the program should address a risk, the credited answer usually lives in the administrative or organizational column even when a technical option looks more decisive.
What Article 32 names explicitly
Article 32(1) calls out four capabilities, and each is examinable:
- Pseudonymization and encryption of personal data.
- Ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.
- Ability to restore availability and access in a timely manner after a physical or technical incident.
- A process for regularly testing, assessing and evaluating the effectiveness of the measures.
Point three surprises candidates: availability is a privacy obligation, not only a business-continuity one, so backup and restore capability sits inside the security duty. Point four is the one that turns a control set into a program — measures that are never tested cannot be shown to be effective, and Article 32(1)(d) makes that testing an obligation in its own right.
Article 32(4) adds a further duty: ensure that anyone acting under the controller's or processor's authority does not process personal data except on instructions, which is where access governance meets confidentiality undertakings.
Calibrating "appropriate"
Appropriateness is a risk calculation, not a maximum. Article 32 directs you to weigh the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons.
| Processing profile | Proportionate measure set |
|---|---|
| Small volume of business contact data | Baseline: encryption in transit, MFA, access control, backup, awareness training |
| Large-scale consumer transaction data | Add segmentation, key management, DLP, logging with alerting, formal access reviews, tested restore |
| Special-category data at scale | Add field-level encryption or tokenisation, strict need-to-know with justification, enhanced monitoring, independent testing |
| Children's data or highly sensitive inference | Add stricter defaults, minimisation by design, elevated approval for any new use |
Note the direction of the sensitivity dial: the risk that matters is risk to individuals, not risk to the organization. A control set designed only around corporate loss will consistently under-protect the exact processing regulators care most about.
Frameworks as scaffolding
Controls are easier to defend when they map to a recognised framework: ISO/IEC 27001 for the security management system with ISO/IEC 27002 control guidance, ISO/IEC 27701 (standalone since its October 2025 revision) for the privacy management system, the NIST Cybersecurity Framework and NIST Privacy Framework for outcome-based structuring, and SOC 2 trust services criteria for customer-facing assurance. The privacy manager's contribution is to ensure the framework's scope covers the processing that actually matters, and that privacy-specific outcomes — minimisation, purpose limitation, retention, rights support — are represented, because a purely security-shaped control set will not deliver them.
Worked scenario
An organization encrypts everything at rest, enforces MFA, and passes a penetration test — then loses six months of customer records when a ransomware event encrypts both production and the only backup, which was permanently mounted. Technically strong, organizationally hollow: nobody owned restore testing, and the Article 32(1)(c) capability to restore availability in a timely manner had never been exercised. The credited remediation is administrative and organizational rather than technical — immutable or offline backup copies, a named owner for restore testing, a documented restore exercise on a defined cadence, and the result reported as a metric under Domain V.
An organization encrypts data at rest, enforces multi-factor authentication and passes an annual penetration test. A ransomware event encrypts production and the permanently mounted backup, and no data can be restored. Which Article 32 requirement was most directly unmet?
A scenario asks how the privacy program should address the risk that employees can access customer records beyond their role. Which option best reflects an administrative or organizational measure rather than a technical one?