Article 32 is the GDPR requirement to protect personal data with technical and organisational measures appropriate to the risk. In practice, it expects encryption, confidentiality, resilience, restoration capability, and regular testing. The standard is flexible, but organizations must be able to justify control choices and show that safeguards work in real operating conditions.
Expanded Definition
GDPR Article 32 is the operational security clause that translates privacy obligations into risk-based control decisions. It does not prescribe a fixed toolset. Instead, it requires controllers and processors to consider the nature of the data, the state of the art, implementation costs, and the likelihood and severity of risks to rights and freedoms when selecting safeguards. That is why Article 32 is often read alongside the EU General Data Protection Regulation (GDPR) as a practical test of whether security measures are proportionate and defensible.
In NHI and agentic AI environments, Article 32 matters because service accounts, API keys, signing certificates, and tokens often process personal data at machine speed and across many systems. The control expectation is not just to encrypt data, but to prove confidentiality, resilience, restoration capability, and regular testing in real conditions. That aligns closely with lifecycle governance described in the Ultimate Guide to NHIs, especially where secrets, access paths, and offboarding remain distributed across pipelines and cloud services. Definitions vary across vendors on how much technical detail belongs in Article 32 mapping, but no single standard governs this yet. The most common misapplication is treating Article 32 as a one-time policy statement, which occurs when organisations write broad security language without evidence that controls are monitored, tested, and recoverable.
Examples and Use Cases
Implementing Article 32 rigorously often introduces evidentiary overhead, requiring organisations to balance stronger assurance against the cost of continuous testing, logging, and recovery validation.
- Encrypting personal data in transit and at rest for workloads that use machine identities, then retaining evidence that keys, certificates, and rotation processes are controlled.
- Running restore tests for databases and object stores that support AI agents, showing that personal data can be recovered without exposing secrets or breaking access boundaries.
- Using Ultimate Guide to NHIs guidance to identify where service accounts and API keys handle personal data and whether those paths are included in resilience testing.
- Mapping security design to the EU General Data Protection Regulation (GDPR) so that risk assessments reflect data sensitivity, processing scale, and business impact.
- Testing incident response for token leakage or credential compromise, because Article 32 expects controls that still work when a machine identity is abused in production.
Why It Matters in NHI Security
Article 32 becomes critical when machine identities are the mechanism that moves personal data through modern infrastructure. If a token is over-privileged, a secret is left in code, or an API key is never rotated, the organisation may fail not only confidentiality expectations but also resilience and accountability expectations. That is where NHI governance and privacy governance converge. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows why Article 32 cannot be satisfied by human-centric access controls alone.
Security teams should treat Article 32 as a proof requirement: encryption must be operational, recovery must be tested, and control choices must be justifiable against risk. This is especially important where agentic systems call downstream services that store or transform personal data, because failures can cascade quietly across multiple environments. Organisations typically encounter Article 32 scrutiny only after a breach, failed audit, or inability to restore service without exposing personal data, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Article 32 is about protecting data with appropriate safeguards and tested resilience. |
| NIST Zero Trust (SP 800-207) | Zero Trust supports Article 32 by verifying access and limiting implicit trust. | |
| NIST AI RMF | GV-1 | Risk-based control selection mirrors the Article 32 standard of appropriate measures. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret exposure and poor lifecycle control are core NHI risks impacting Article 32. |
| NIST SP 800-63 | AAL2 | Assurance levels inform the strength needed for identities accessing personal data. |
Protect personal data with encryption, recovery testing, and verified handling of machine identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
