"Trusted by EU-operating firms from 50 to 5,000 employees."
Article 32 requires you to implement technical and organisational measures that ensure a level of security appropriate to the risk. Most organisations have policies — what DPAs actually test is whether the measures operate. We built the checklist that shows your legal team exactly what's required, and your security team exactly what to evidence.
Also: Run your domain through the free Domain Security Scanner →
What the regulation requires. Controllers and processors must implement 'appropriate technical and organisational measures' to secure personal data — taking into account the state of the art, implementation costs, and the nature, scope, and purposes of processing.
What that means in practice. Five mandatory categories: pseudonymisation and encryption of data at rest and in transit; ability to ensure ongoing confidentiality, integrity, availability and resilience; ability to restore access following an incident; regular testing and evaluation of security measures; and mechanisms to ensure availability is not accidentally or unlawfully destroyed.
What DPA enforcement looks like. The Irish DPC levied a €1.2bn fine on Meta for GDPR violations including inadequate technical measures. TikTok faced a €530m fine from the EDPB for transferring EU data to China without adequate safeguards. The common pattern: controls documented but not operating — or data flows to jurisdictions with no adequacy decision.
Article 15–22 rights (access, erasure, portability, rectification) must be fulfilled within 30 days. EDPB case law from 2024 shows supervisory authorities treating delays as systemic violations — the CNIL fined a firm €50,000 for a 90-day SAR backlog. Your DPO or privacy team needs a documented process, not just a policy.
Schrems II invalidated Privacy Shield in 2020; Standard Contractual Clauses now require Transfer Impact Assessments. Transfers to the US, India, and other non-adequate jurisdictions need documented technical and organisational measures proving 'essentially equivalent' protection. The EDPB'sطار transfer guidance (v3.1, 2024) requires per-country and per-transfer documentation — not boilerplate legal terms.
Article 28 requires a written Data Processing Agreement with all processors — including SaaS vendors, cloud providers, and email platforms. The Meta WhatsApp fine (€255m, 2021) included inadequate processor oversight. Your DPA should list every vendor that processes EU personal data on your behalf, with a signed DPA and documented security assessment for each.
Article 33 requires notification to the supervisory authority within 72 hours of awareness. The CNIL, DPC, and ICO have all published enforcement decisions where delayed or absent breach notification attracted independent fines. A documented incident response process with breach classification criteria — and evidence it runs — is the difference between a notification and a fine.
Article 35 requires a Data Protection Impact Assessment for any processing 'likely to result in a high risk.' EDPB threshold list makes this mandatory for AI/ML systems, large-scale profiling, and biometric processing. The Irish DPC's LinkedIn fine (€310m, 2024) included inadequate DPIA for behavioural profiling. If you're training models on EU user data without a DPIA, you're non-compliant — not partially compliant.
Article 22 prohibits automated decision-making with significant effects unless a DPIA is conducted, the individual is informed, and legitimate interests or explicit consent apply. Training data scraped from EU users without a legal basis violates Articles 6 and 9. The CNIL's investigation into ChatGPT in 2023 showed that 'legitimate interest' does not justify training without transparent disclosure and documented legal basis.
Each control below maps to Article 32(1). The evidence column shows what an auditor or supervisory authority will ask for during a review.
| Control | Evidence requirements (what a DPA expects) |
|---|---|
|
A1 — Encryption of personal data at rest
Art. 32(1)(a)
|
Database-level encryption confirmed (AES-256 or equivalent). Key management logs showing key rotation schedule. Proof that backups are encrypted. Configuration documentation for cloud storage buckets containing personal data. If using a cloud provider: their encryption at rest is default — document it in your processing register (Article 30).
|
|
A2 — Encryption of personal data in transit
Art. 32(1)(a)
|
TLS 1.2+ enforced across all data transfers. Certificate management policy and renewal logs. HSTS headers on web applications. Email encryption for sensitive personal data transfers (S/MIME or PGP). Third-party API integrations using TLS with certificate validation — no self-signed certs in production.
|
|
A3 — Pseudonymisation of personal data where feasible
Art. 32(1)(a)
|
Separation of identifying data from processing data. Key or token mapping stored separately with access controls. Risk assessment documenting where pseudonymisation was applied and where it was not (with rationale). Particularly relevant for analytics, ML training, and research datasets.
|
| Control | Evidence requirements |
|---|---|
|
B1 — Access controls and least privilege
Art. 32(1)(b)
|
Role-based access control policy with documented role definitions. Quarterly access review logs showing reviewed and revoked accounts. Provisioning/deprovisioning procedures for HR and IT. MFA enforced for all administrative access. Privileged access management (PAM) for production systems. Identity governance logs retained for 12 months minimum.
|
|
B2 — Security configuration management
Art. 32(1)(b)
|
Baseline security configuration for all systems processing personal data. Change management process with approval records. Vulnerability scanning results (at least quarterly). Patch management logs showing timely remediation of critical/high vulnerabilities. Hardening guides for OS and application layers.
|
| Control | Evidence requirements |
|---|---|
|
C1 — Backup and restoration capability
Art. 32(1)(b)
|
Documented backup policy specifying frequency, retention, and encryption of backups. Backup restoration test logs — at least annual, ideally quarterly. Off-site backup storage confirmed and tested. Recovery time objective (RTO) documented and tested. Backup logs retained for 12 months minimum.
|
|
C2 — Business continuity and DR testing
Art. 32(1)(f)
|
Business continuity plan covering personal data systems. Documented DR test results with RTO/RPO validated. Personal data systems included in BCP scope. Communication plan for data subjects during extended outages (Recital 39 — accountability). GDPR breach notification process integrated into incident response plan.
|
| Control | Evidence requirements |
|---|---|
|
D1 — Penetration testing
Art. 32(1)(d)
|
External penetration test at least annually. Internal network penetration test at least annually. OWASP Top 10 assessment for web applications. Remediation tracking from pen test findings. Executive summary and technical report retained for evidence. Third-party attestation letter for cloud infrastructure if applicable.
|
|
D2 — Security monitoring and incident detection
Art. 32(1)(b),(d)
|
SIEM or log aggregation covering all personal data systems. Alert rules and documented response procedures. Mean time to detect (MTTD) documented. Incident response plan tested at least annually. GDPR Article 33 breach notification process integrated into security incident response. Logs retained for minimum 12 months.
|
| Control | Evidence requirements |
|---|---|
|
E1 — Processor security assessments
Art. 32(1)(b)
|
Processing register (Article 30) listing all processors and their categories of processing. Signed DPAs with all processors (Article 28). Annual security questionnaire or assessment for critical processors. Evidence of reviewing processor sub-processors (GDPR Article 28(2)). Monitoring of processor security incidents affecting your data subjects.
|
|
E2 — DPIA conducted for high-risk processing
Art. 35
|
DPIA register listing all processing activities that required an assessment. Completed DPIAs for each identified high-risk activity — including AI/ML training, large-scale profiling, and cross-border transfers. DPIA results documented with mitigations implemented or documented risk acceptance. DPIA reviewed when processing changes.
|
10 controls · All evidence requirements mapped · Article 32(1) compliant
Used by DPOs, privacy counsel, and security teams at EU-operating firms preparing for supervisory authority reviews or internal GDPR audits. Includes evidence artefacts, owner assignments, and remediation sequencing.
No spam. Unsubscribe any time. Checklist delivered as PDF via Postmark within seconds.
Our Business session ($900) delivers Article 32-aligned training for all personnel in a single 2-hour live webinar. Individual attendance records with timestamps — the documented evidence your DPO and supervisory authority expect to see. We provide an evidence packet including the session summary, curriculum outline, and attendance log.
Personal — $150 → Executive — $390 → Business — $900 flat →Every GDPR training engagement includes these artefacts for your DPA review documentation:
Employee name, timestamp, session ID — Article 32(1) evidence for your accountability file (Recital 39).
Date, duration, topics covered, instructor name — Article 32(1)(d) training programme documentation.
Topics covered — phishing defence, data handling, SAR response, breach notification — satisfies Article 32(1)(b) confidentiality and integrity obligations.
Versioned curriculum with date, suitable for ICO, DPC, CNIL, or other supervisory authority review.
Yes — Article 32 applies to all controllers and processors 'taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing.' Small businesses aren't exempt, though the specific measures required scale with risk and processing complexity. A 10-person firm processing standard customer data needs encryption, access controls, and a breach notification process. A firm processing special category data (health, biometric, financial) at scale needs significantly more.
Article 32(1) lists five required measures: pseudonymisation and encryption of personal data; ability to ensure ongoing confidentiality, integrity, availability and resilience; ability to restore availability and access in a timely manner following a physical or technical incident; a process for regularly testing, assessing and evaluating technical and organisational measures; and mechanisms to ensure personal data is not made unavailable, lost or destroyed unintentionally. The key word is 'appropriate' — the ICO and other DPAs expect you to document your risk assessment and show how your measures are proportionate to the risk.
Article 37 makes DPOs mandatory only for public authorities, organisations that process large volumes of special category data as a core activity, or organisations that monitor individuals on a large scale. Article 32 does not require a DPO — but a DPO will typically oversee implementation of Article 32 measures. Many SMEs find that a DPO isn't required but an internal 'privacy champion' performing the same functions is good practice.
Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach — 'unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.' This is a clock that starts on awareness, not on the breach itself. Awareness often comes from an IT alert, a staff report, or a third-party notification — not from the breach event. Your incident response plan must include a process for classifying breach severity and triggering the notification window.
Where an incident affects both personal data (GDPR) and critical infrastructure (NIS2), both notification obligations run in parallel. NIS2 requires 24-hour early warning to the national competent authority and 72-hour full notification. GDPR Article 33 requires 72-hour notification to the supervisory authority. For NIS2 entities operating in the EU, the 24-hour NIS2 early warning creates an opportunity to assess the personal data impact in the subsequent 48 hours. Your incident response plan should map both obligations — a single breach may require notification to multiple authorities in multiple jurisdictions simultaneously.
A Data Protection Impact Assessment (DPIA) is required under Article 35 when processing is 'likely to result in a high risk' to individuals. The EDPB's threshold list makes DPIAs mandatory for systematic profiling, large-scale processing of special category data, and systematic monitoring of publicly accessible areas. In practice, any AI/ML system, automated credit scoring, employee monitoring system, or new surveillance infrastructure requires a DPIA before go-live. Conducting a DPIA late — after the system is live — creates a compliance gap and exposure.
No-form call. 30 minutes. We map your current processing activities to Article 32 gaps, identify your DPIA obligations, and give you a structured remediation sequence — free.