Introduction
Most boards treat GDPR as a compliance team problem. That's the mistake that surfaces when a breach happens at 11 PM on a Friday.
Articles 32, 33, and 34 create time-bound, operationally specific security obligations — not just documentation requirements. The 72-hour breach notification window is the clearest test of whether your governance is real or filed away in a policy binder.
Organizations that haven't built and tested their detection-to-notification workflow before an incident will spend those 72 hours figuring out who owns the decision, not executing one.
This post covers what GDPR's security articles actually require, what makes the 72-hour rule executable, what boards must own versus delegate, and how to assess whether your organization is genuinely ready — with working processes, not just policies on paper.
TL;DR
- Article 32 requires four specific security measures, including mandatory periodic testing — not just documented controls
- The 72-hour clock starts at awareness, not when forensic investigation concludes
- Article 24 makes accountability demonstrable: boards cannot delegate away legal responsibility
- 443 breach notifications per day reached European regulators in 2025 — up 22% year-over-year
- Only 48% of boards have participated in a cyber tabletop exercise — the exact rehearsal GDPR requires
GDPR Security Controls: What Article 32 Actually Requires
The Foundation: Security Is Built In, Not Bolted On
GDPR's security obligations don't start at Article 32. They begin earlier.
Article 5(1)(f) establishes integrity and confidentiality as a core processing principle. Personal data must be protected against unauthorized processing, accidental loss, and destruction. Article 25 then requires data protection by design and by default — security measures must be embedded in system architecture from the start, not retrofitted after deployment.
Article 32 builds on that foundation with four specific requirements:
- Pseudonymization and encryption of personal data
- Ongoing confidentiality, integrity, availability, and resilience of processing systems
- Ability to restore availability and access to personal data in a timely manner after an incident
- Regular testing, assessing, and evaluating the effectiveness of security measures
Point four is the one most organizations underestimate. It's not a recommendation — it's a legal obligation. A control that exists but has never been tested doesn't satisfy Article 32(1)(d). Picus Security's 2025 Blue Report found that overall prevention effectiveness in tested environments declined from 69% to 62% — meaning organizations are deploying controls without ever testing whether they work.
"Appropriate" Is Risk-Based, Not Checkbox-Based
The regulation deliberately avoids prescribing specific technologies. "Appropriate" is assessed against the risk to individuals' rights and freedoms, the state of the art, and implementation costs. That flexibility cuts both ways: organizations can't claim compliance by pointing to a tool purchase. They need to show the tool addresses a documented risk and has been tested.
Controllers, Processors, and Accountability Gaps
Article 28 requires written contracts with processors that specify security obligations and incident response timelines. Controllers remain accountable for what processors do with personal data — including how quickly processors notify them of a breach. If your processor contract doesn't specify notification timing, your 72-hour window is already compromised.
Boards should also validate third-party contracts directly. Key questions for audit and risk committees:
- Does each processor contract specify breach notification timing (not just "promptly")?
- Are sub-processor arrangements covered by equivalent obligations?
- Has the organization tested whether processors actually meet their contractual commitments?
When DPIAs Are Required
Article 35 requires a Data Protection Impact Assessment before high-risk processing begins — not after. The four required elements are:
- A systematic description of the processing and its purposes
- An assessment of necessity and proportionality
- An assessment of risks to individuals' rights and freedoms
- Measures to address those risks, including safeguards and security controls
A missing DPIA is both a design-control failure and an accountability failure. Boards should ask whether every high-risk processing activity has a completed DPIA on file — and whether DPIA findings actually changed system design, or just generated paperwork.
The 72-Hour Breach Notification Rule: Articles 33 and 34
What Triggers the Clock
Article 33 requires notification to the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach.
A personal data breach includes any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data — including temporary availability loss that impacts individual rights. The trigger is broad.
What matters operationally: the EDPB's Guidelines 9/2022 define "aware" as having "a reasonable degree of certainty" that a security incident has occurred and personal data has been compromised.
The clock does not wait for a completed forensic investigation. It starts when your team has reasonable certainty — which means your detection and triage capabilities determine whether you have any working time left when it matters most.
What the Article 33 Notification Must Contain
- The nature of the breach (categories and approximate numbers of affected data subjects and records)
- Contact details for the Data Protection Officer
- Likely consequences of the breach
- Measures taken or proposed to address it
Incomplete information is not a reason to delay submission. Submit what you have on time and commit to follow-up. Supervisory authorities expect this. What they don't forgive is missing the 72-hour window because the organization was still assembling information.
Article 34: Notifying Affected Individuals
When a breach is likely to result in high risk to individuals' rights and freedoms, Article 34 requires direct notification to affected people — without undue delay.
Exceptions exist: effective encryption that renders data unintelligible to unauthorized parties, or subsequent technical measures that eliminate the high risk. Both require documented risk assessment judgment — not assumption — before you can rely on them.
The Execution Sequence
Pre-built workflows are what keep a 72-hour window from becoming a compliance failure. Every step below needs a named owner before an incident occurs — not during one.
- Initial detection — automated alerting or staff report
- Triage and breach confirmation — is personal data involved?
- Scope and impact assessment — how many records, what categories?
- Supervisory authority notification — within 72 hours of awareness
- Data subject notification — if high risk to individual rights
- Documentation — complete the Article 33(5) breach log
- Post-incident review — update controls and test findings
Each step requires a named owner and authority defined in advance — decisions made in real time during a breach are decisions made late.
What Boards and Executive Teams Must Own — Not Just Delegate
Accountability Is Not Delegable
Article 24 places responsibility with the controller — the legal entity, which means its leadership. ICO guidance states directly that compliance responsibility must be upheld at the highest management level. The board and C-suite can assign execution, but they cannot transfer accountability.
In practice, demonstrable accountability means:
- Board minutes show GDPR governance was discussed and reviewed
- Escalation thresholds are documented and pre-approved
- Testing evidence exists — not just policy documents
- Assigns decision rights to named roles, not vague committees
Decision Rights Boards Must Define Before an Incident
The 72-hour window is not survivable if these questions are answered for the first time during a breach:
- Who has authority to confirm a breach has occurred?
- Who decides whether supervisory authority notification is required?
- Who approves the notification content before submission?
- What threshold brings this to the full board?
Pre-defined escalation paths — built before pressure, tested in tabletop exercises — are what make compliance executable. In Tyson Martin's board advisory work, these decision rights are captured in escalation matrices with named owners, impact thresholds, and documented authority at each decision point. The goal is a one-page reference that executives can use under pressure, not a governance document that takes 20 minutes to find.
The DPO Question
Article 37 requires a DPO where an organization conducts large-scale systematic monitoring of individuals, processes special category data at scale, or is a public authority. Article 38 requires the DPO to report directly to the highest management level, have sufficient resources, and operate without instruction-giving interference.
Appointing a DPO satisfies one requirement. Building the infrastructure that role needs to function — reporting access, authority to run tests, and clear escalation pathways — is what makes the appointment real. The board's governance role is to verify the latter, not just confirm the former.
What an Independent Advisor Sees That Internal Teams Miss
The DPO infrastructure gaps described above are exactly where independent advisory adds the most value. An outside advisor can assess governance honestly — without the internal pressure that causes gaps to get smoothed over before they reach the board. Tyson Martin's advisory work is deliberately independent of the in-house security team and vendors — the value is governance validation, not operational support. That independence matters most when the assessment needs to be credible to a regulator, not just to internal stakeholders.
The Governance Gap: Why Most Organizations Aren't Ready
The Three Most Common Failure Modes
Organizations that believe they are GDPR-ready but aren't typically fall into one of these patterns:
- Policy without workflow: GDPR documentation exists, but the detection-to-notification sequence has never been executed under realistic conditions
- Clock spent on discovery: The 72-hour window is consumed identifying that a breach occurred and who owns the decision, rather than executing a pre-built response
- Unclear notification authority: Breach determination has been delegated to teams without explicit, pre-approved thresholds for supervisory authority notification
Tabletop Exercises Are a Legal Requirement, Not Just Good Practice
Article 32(1)(d) mandates regular testing and evaluation of security measures' effectiveness. A tabletop exercise that walks the executive team and board through detection, escalation, notification decision, and communication fulfills that requirement while stress-testing governance.
WSJ Pro and NACD research found that only 48% of company boards had participated in a cyber tabletop exercise. For GDPR purposes, that means the majority of boards have never rehearsed the exact decision sequence the regulation requires them to execute within 72 hours.
That gap is where structured preparation pays off. Tyson Martin's tabletop exercises for executive teams run approximately 60–90 minutes, cross-functional across CEO, legal, comms, IT, and the affected business unit. Outputs include a decision tree, updated contact list, and draft communication templates. The result is documentation that has been stress-tested against real decision pressure.
Third-Party Processor Risk
Article 33(2) requires processors to notify controllers "without undue delay" after becoming aware of a breach. But processor contracts that don't specify timing, contact points, or minimum information to be provided leave controllers unable to meet the 72-hour window even when internal processes are solid.
Controller accountability doesn't pause because a vendor was slow. If your processor contracts don't include explicit breach notification timelines and escalation requirements, that gap belongs on your next board agenda.
GDPR Penalties and Recent Enforcement
The Two-Tier Fine Structure
Article 83 establishes two penalty tiers:
| Violation Category | Maximum Fine |
|---|---|
| Lower-tier: inadequate security measures, processor agreement failures, record-keeping gaps | €10 million or 2% of global annual turnover |
| Upper-tier: core data processing principle breaches, unlawful transfers, data subject rights violations | €20 million or 4% of global annual turnover |
The DLA Piper January 2026 survey reports approximately €1.2 billion in GDPR fines in 2025 alone and €7.1 billion in aggregate fines since May 2018 (as of January 10, 2026). Regulators are issuing fines at scale — and the cases show a consistent pattern in what draws scrutiny.
What Enforcement Actually Targets
The ICO's £20 million fine against British Airways and £18.4 million fine against Marriott were both rooted in Articles 5(1)(f) and 32 — security-of-processing failures that exposed hundreds of thousands of customers. Both cases turned on operational security failures: controls that weren't proportionate to the risk, monitoring gaps, and integration vulnerabilities that went undetected.
The lesson for boards: regulators are examining whether security measures were appropriate to the risk and whether organizations can demonstrate they tested and evaluated those measures. Policy documents alone don't answer that question.
Beyond Fines: Corrective Orders
Supervisory authorities can order organizations to cease processing activities entirely under Article 58. The DPC's order against TikTok — requiring compliance within six months with the threat of processing suspension if it failed — illustrates the business continuity risk that makes GDPR governance a board-level concern, not a compliance team matter. Stopping processing is operationally catastrophic for most organizations.
A Board-Level GDPR Security Readiness Checklist
Eight governance-level questions. Boards that can answer all eight with evidence are doing oversight. Boards that can only answer them with policy documents are not.
- Article 30 records current? — Records of processing activities reviewed within the last 12 months
- DPIAs completed? — All high-risk processing activities have a DPIA with all four Article 35(7) elements
- Article 32 controls tested? — Security measures in place and evaluated against a documented risk assessment — not just deployed
- Detection capability verified? — Mean time to detect is known, measured, and trending in the right direction
- 72-hour workflow tested? — Notification sequence documented, owner-assigned, and rehearsed in a tabletop exercise
- Article 28 contracts specify timing? — Processor agreements include explicit breach notification timelines and escalation contacts
- DPO appointed and resourced? — If required, DPO has board-level reporting access and operating independence
- Board receives stable metrics? — Regular security governance reporting on trend, not just incident-triggered briefings
Boards that ask these eight questions quarterly are exercising genuine oversight. The checklist also serves the accountability principle: it creates the documented evidence that Article 24 requires organizations to produce on demand.
Most boards can get through the checklist. Fewer can produce the evidence behind each answer. Tyson Martin's 90-day engagement converts checklist awareness into verified readiness — named owners, tested workflows, and metrics a regulator can inspect. An outside advisor brings one thing internal teams structurally cannot: an honest read of where the gaps actually are, before a regulator finds them first.
Frequently Asked Questions
Frequently Asked Questions
What are GDPR security requirements?
Articles 5(1)(f), 25, and 32 require organizations to implement appropriate technical and organizational measures — encryption, pseudonymization, system resilience, and regular testing — proportionate to the risk to individuals' rights. "Appropriate" is a risk-based standard, not a fixed control list.
What triggers the GDPR 72-hour breach notification requirement?
The Article 33 clock starts when the organization "becomes aware" of a breach, meaning the EDPB standard of reasonable certainty that an incident occurred and personal data was compromised. Accidental loss, unauthorized access, and temporary availability loss all qualify if they affect individual rights.
What is the board's role in GDPR compliance?
Under Article 24's accountability principle, the controller (board and senior leadership included) cannot delegate away legal responsibility. The board's role is to ensure governance structures, decision rights, and escalation thresholds exist and have been tested, not merely to receive reports after incidents occur.
What is Article 32 of GDPR?
Article 32 is GDPR's primary security-of-processing article, requiring four categories of measures: encryption and pseudonymization, ongoing confidentiality/integrity/availability and resilience, ability to restore data access after incidents, and regular testing of security measure effectiveness.
What are the penalties for GDPR non-compliance?
Article 83 establishes two tiers: up to €10 million or 2% of global annual turnover for lower-tier violations (including inadequate security measures), and up to €20 million or 4% for upper-tier violations including data processing principle breaches. Cumulative fines have exceeded €7.1 billion since 2018.
Does GDPR apply to US companies?
Yes. GDPR applies to any organization that offers goods or services to EU/EEA residents, monitors their behavior, or processes their personal data — regardless of where the organization is located. US companies in financial services, healthcare, and retail with EU customer exposure are commonly subject to its full requirements.
