How Picus Can Help You Comply With the GDPR

What is the GDPR, and what does it require on security?

The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, is the European Union's data protection law. It has applied directly across all EU and EEA Member States since 25 May 2018, and it reaches any organization, wherever it is established, that processes the personal data of individuals in the EU in connection with offering them goods or services or monitoring their behaviour.

On security, the GDPR's central requirement is Article 32, "Security of processing." It obliges both controllers and processors to implement appropriate technical and organisational measures to protect personal data, and, critically, to regularly test whether those measures actually work. Most of the GDPR governs lawful processing, transparency, and the rights of data subjects, but Article 32 is the one obligation that sits squarely in cybersecurity.

Does the GDPR require security testing?

Yes. Article 32(1)(d) makes regular security testing an explicit legal obligation, requiring controllers and processors to maintain "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." The GDPR does not accept the existence of a security control as proof that it works; it requires organizations to demonstrate, on an ongoing basis, that their safeguards are effective against real risks.

This duty is reinforced by the accountability principle in Article 5(2), which requires controllers to be able to demonstrate compliance, not merely assert it.

Who must comply with the GDPR, and what are the penalties for a security failure?

Both controllers (who determine the purposes and means of processing) and processors (who process personal data on a controller's behalf) are directly bound by Article 32. Penalties for inadequate security are among the most significant in the GDPR and can be assessed under two tiers:

• An infringement of Article 32 (security of processing) falls under Article 83(4): administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher.
• Inadequate security can also be pursued as an infringement of the Article 5(1)(f) "integrity and confidentiality" principle, a basic principle of processing, which falls under Article 83(5): fines of up to €20 million or 4% of total worldwide annual turnover, whichever is higher.

In practice, supervisory authorities have cited Article 32 inadequacy in many of the largest data-breach fines on record, frequently alongside the Article 5 security principle. When a breach occurs, the first question a regulator asks is whether the security measures were appropriate to the risk, and whether their effectiveness had been tested.

A note on the 2026 Digital Omnibus (currency as of June 2026)

The 2026 Digital Omnibus does not change GDPR Article 32 or the obligation to regularly test the effectiveness of security measures. On 19 November 2025 the European Commission proposed amendments to the GDPR as part of the Digital Omnibus package, but as of June 2026 these remain proposals in the ordinary legislative procedure, not law. Adoption is expected in the second half of 2026, with application not before late 2027, and the EDPB and EDPS issued a critical Joint Opinion 2/2026 on them in February 2026.

The proposals touch the personal-data definition, records-of-processing thresholds, DPIA harmonisation, and breach-notification, including a higher "high-risk" threshold, a possible extension of the 72-hour deadline, and single-portal routing. Because they leave the substance of Article 32 intact, this guide is built on the in-force text, and where the breach-notification timeline is discussed, the current 72-hour rule applies.

Why does GDPR require proof that security controls work, not just documentation?

The GDPR treats control effectiveness, not documentation, as the heart of security because Article 32(1)(d) requires regular testing of effectiveness and Article 5(2) requires the controller to demonstrate compliance. Article 32 is deliberately risk-based rather than a fixed checklist: the appropriate measures depend on the state of the art, the cost of implementation, and the nature and risk of the processing. But that flexibility cuts both ways. A control that was adequate a year ago may no longer be, because detection rules degrade, access controls drift, segmentation weakens after changes, and new attack techniques emerge without ever being tested against existing defenses. An organization that assumes its controls work, rather than proving it, is exposed precisely where the GDPR is most demanding.

This is where the Picus Platform changes how GDPR security compliance is achieved. By continuously validating security controls against real adversary behavior, Picus turns technical control performance into operational, demonstrable evidence. It provides tangible proof that controls such as firewalls, EDR, and SIEM are effective, which is exactly what Article 32 and the accountability principle require.

How Picus Supports Key GDPR Security Requirements

The following sections map specific GDPR provisions to the Picus Platform's validation capabilities. Each section identifies the requirement, explains what it demands of controllers and processors, and demonstrates how continuous security validation supports compliance with defensible, audit-ready evidence.

• Article 32(1)(d): Regularly Testing, Assessing, and Evaluating the Effectiveness of Security Measures
• Article 32(1)(b): Ongoing Confidentiality, Integrity, Availability, and Resilience
• Article 32(2) & Article 5(1)(f): Protecting Personal Data Against Unauthorised Access, Disclosure, and Destruction
• Article 33: Personal Data Breach Notification (the 72-Hour Rule)
• Article 25: Data Protection by Design and by Default
• Article 35: Data Protection Impact Assessment (DPIA)
• Article 24 & Article 5(2): Accountability — Demonstrating Compliance
• Article 28: Processors and Sufficient Guarantees

GDPR Article 32(1)(d): Regularly Testing, Assessing, and Evaluating the Effectiveness of Security Measures

Explanation of the provision

This is the GDPR's flagship requirement for security validation, and it is stated as a binding measure in its own right. Article 32(1) lists four illustrative categories of security measure, and point (d) makes the regular testing and evaluation of effectiveness one of them. The European Data Protection Board treats "state of the art" as a dynamic concept that must be reassessed continuously as technology evolves: a measure that once provided adequate protection may cease to do so, and the controller is expected to know this and act on it. In short, the GDPR does not merely permit effectiveness testing. It obliges it, and it expects testing to be a recurring process rather than a one-off event.

How does Picus support the requirements of GDPR Article 32(1)(d)?

Picus operationalises Article 32(1)(d) directly. Instead of relying on annual assessments that go stale the moment a configuration drifts or a new technique emerges, the Picus Platform runs the whole validation loop continuously (validate, decide, fix, re-validate) through exposure validation capabilities.

• Picus Breach and Attack Simulation (BAS) executes adversary-emulated techniques mapped to real-world TTPs across network, endpoint, cloud, and identity layers, measuring whether the controls protecting personal data block, detect, log, and alert as intended. Its Picus Threat Library is kept current by the Picus Red Team under a 24-hour SLA for critical threats, including those carrying proof-of-concept exploitation, CISA alerts, and active threat-actor and APT campaigns, so testing reflects the EDPB's "state of the art" standard rather than a frozen scope.
• Picus Autonomous Penetration Testing adds live exploit-chain proof wherever an exploit can safely run: it scopes itself from real signals, such as a new CVE or an infrastructure change, and chains real exploitation across reachable hosts to show what an attacker could actually reach and combine into a path toward the systems holding personal data, with every action auditable and human-in-the-loop control at any stage.
• The platform also covers what live exploitation cannot safely reach (the regulated, business-critical, and air-gapped systems that often hold personal data, and newly disclosed CVEs with no safe exploit yet) by proving exploitability through inference. Its TTP-Chain Validation maps each CVE to the chain of techniques its exploitation requires and tests every link against your deployed controls: if the environment breaks any required link the exposure is contained, and if every link holds it is genuinely exploitable. This turns thousands of findings into a defensible decision for each one, so teams focus on what truly threatens personal data and can safely deprioritize the theoretical noise.

Together these run as one loop, producing a continuously updated, MITRE ATT&CK-mapped record of control performance, including prevention scores, detection coverage rates, and remediation tracking, which is exactly the "process for regularly testing, assessing and evaluating the effectiveness" of security measures the Article requires.

When a supervisory authority asks an organization to show that it regularly tests effectiveness, it can produce validated, time-stamped results showing what was tested, what was blocked, what was detected, and what was not, rather than a narrative assurance.

GDPR Article 32(1)(b): Ongoing Confidentiality, Integrity, Availability, and Resilience

Explanation of the provision

Article 32(1)(b) requires controllers and processors to ensure the ongoing confidentiality, integrity, availability, and resilience (the "CIA" triad plus resilience) of the systems that process personal data. The word "ongoing" is significant: it is not enough to architect these properties once; they must be sustained as systems change and threats evolve.

How does Picus Platform support GDPR Article 32(1)(b) compliance for security resilience?

Article 32(1)(b) names four properties – confidentiality, integrity, availability, and resilience – but the operative word is "ongoing": they are not properties you architect once and assume, but properties that must be sustained as systems change and threats evolve.

Picus provides the evidence that they actually hold. It safely executes the real attacker techniques that threaten each one: against confidentiality (unauthorised access, lateral movement toward personal data, and exfiltration), integrity (tampering and unauthorised alteration), and availability (destructive and ransomware-style impact). It then confirms whether the controls intended to preserve each property hold under attack rather than merely existing on paper.

The "ongoing" standard is exactly where point-in-time testing falls short. Picus runs validation as a continuous loop of validate, decide, fix, and re-validate, and re-tests as the environment changes. This approach surfaces the moment a previously effective control degrades and gives teams what they need to restore the property before an attacker can exploit the gap. That same loop addresses the resilience standard: the organisation can demonstrate, with evidence, not just that confidentiality, integrity, and availability were designed in, but that they continue to hold, and that the services processing personal data continue to operate, as systems change and new techniques emerge.

GDPR Article 32(2) & Article 5(1)(f): Protecting Personal Data Against Unauthorised Access, Disclosure, and Destruction

Explanation of the provision

Article 32(2) names the specific risks security measures must address: accidental or unlawful destruction, loss, alteration, unauthorised disclosure, and unauthorised access to personal data. Article 5(1)(f) elevates the same concern to a foundational principle of processing. Together they define, in concrete terms, the threats against which an organization's controls must demonstrably protect – and, as noted above, a failure here can be pursued under either the Article 32 tier or the higher Article 5 principles tier.

How does Picus Platform support the requirements of GDPR Article 32(2) and Article 5(1)(f)?

Article 32(2) and Article 5(1)(f) each pair two kinds of risk: accidental loss or destruction, and unlawful access, disclosure, alteration, and destruction. Picus addresses the adversarial half, and it does so in a way that speaks directly to 32(2)'s instruction to account for these risks when setting the appropriate level of security: it shows which of them are genuinely exploitable in your environment, so that level is calibrated on evidence rather than assumption.

Breach and Attack Simulation runs the attacker TTPs behind those unlawful risks, the credential-access, exfiltration, tampering, and destructive or ransomware-style techniques, against your live prevention and detection stack (EDR, SIEM, firewall, WAF, DLP, segmentation), measuring what each control blocks, detects, or misses. Where a live exploit can safely run, Autonomous Penetration Testing chains real exploitation across reachable hosts to show whether the systems holding personal data are actually reachable. For the business-critical or restricted stores a live exploit cannot safely touch, the platform maps each CVE to its TTP chain, derived from the vulnerability class rather than published exploit code, and tests it against that asset's controls for a verdict even on day one.

This gives controllers control-level evidence that the protection against unauthorised and unlawful processing required by Article 5(1)(f) actually holds, and resolves each adversarial exposure into a defensible decision. Protection against accidental loss or destruction sits with backup, recovery, and resilience controls, outside what validation tests.

GDPR Article 33: Personal Data Breach Notification (the 72-Hour Rule)

Explanation of the provision

Article 33 requires controllers to notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it; where the breach is likely to result in a high risk to individuals, Article 34 additionally requires communication to the affected data subjects. The clock and the obligation rest on an assumption that is easy to overlook: an organization cannot notify a breach it has not detected, and it cannot characterise the scope of a breach without the telemetry to do so.

How does Picus Platform support the requirements of GDPR Article 33?

The 72-hour clock rests on an assumption that is easy to overlook: an organisation cannot notify a breach it has not detected, and cannot characterise its scope without telemetry granular enough to support the assessment a notification requires. Picus validates that assumption with evidence rather than leaving it to trust. Through Breach and Attack Simulation, it runs adversary-emulated techniques (including the latest attacker TTPs) against your live detection stack (EDR, XDR, IDS, SIEM) and proves what is actually detected, what is logged with enough granularity to characterise a breach, and where the visibility gaps are. The result is a defensible answer to the question the deadline already assumes you can answer: would this breach be seen, and seen well enough to notify accurately and in time?

Where a technique slips through, or a detection is too thin to support notification, Picus does not stop at a red mark on a dashboard:

• it supplies ready-to-deploy detection rules, then
• re-runs the same technique to confirm the alert now fires.

This closes the loop and turns detection readiness into evidence, not assumption. And because controls drift and attacker techniques change, Picus re-validates continuously, so the readiness the clock depends on stays defensible as the environment moves.

The Digital Omnibus has proposed adjusting this threshold and timeline, but the detection capability any breach-notification regime depends on is unchanged by it.

GDPR Article 25: Data Protection by Design and by Default

Explanation of the provision

Article 25 requires data protection to be built into processing from the outset (by design) and as the default configuration (by default), including through measures such as pseudonymisation. The operative word, again, is "effective": the safeguards integrated into a system must work, not merely be present in the design.

How does Picus Platform support the requirements of GDPR Article 25?

Article 25's operative word is "effective": a safeguard integrated into a system must work, not merely be present in the design. Picus provides the evidence that the technical security measures built in "by design," and enforced "by default," actually hold in the deployed environment rather than only on the architecture diagram. By running adversary-emulated scenarios against the live system, it proves whether those safeguards block and detect the techniques they were meant to stop – turning a design intent into a demonstrated, evidence-backed control.

That evidence cannot be a one-time check at go-live.

Here is the revised version with the em dash removed:

Every new deployment or configuration change can silently weaken a control that was effective the day before, so Picus re-executes the same scenarios against the updated environment to confirm the safeguards still resist attack, and surfaces it when a change has eroded them. This closes the gap between a control that exists in an architecture diagram and one that demonstrably resists attack, which is the standard Article 25 sets: data protection that is effective, and stays effective as the system evolves.

GDPR Article 35: Data Protection Impact Assessment (DPIA)

Explanation of the provision

For processing likely to result in a high risk to individuals, Article 35 requires a Data Protection Impact Assessment that assesses the risks and sets out the measures envisaged to address them and to demonstrate compliance. A DPIA that identifies risks but cannot show that the mitigating measures actually work leaves its central question unanswered.

How does Picus Platform support the requirements of GDPR Article 35?

Picus helps organizations support the technical security component of a Data Protection Impact Assessment by validating which attack paths, exposures, and control gaps could create risk to systems processing personal data. Instead of relying only on vulnerability scores or assumed control coverage, Picus provides evidence of what attackers could exploit, what security controls can block or detect, and which risks require remediation, mitigation, monitoring, or acceptance.

This directly supports Article 35(7)(c), which requires an assessment of risks to the rights and freedoms of data subjects, by helping teams understand whether security exposures could realistically lead to unauthorized access, disruption, or compromise of environments where personal data is processed.

For Article 35(7)(d), Picus helps demonstrate the measures envisaged to address those risks by validating whether security controls can block or detect relevant attacker techniques, providing actionable mitigation guidance, and revalidating after fixes are applied. This gives organizations evidence that identified security risks have been addressed and that compliance-supporting measures continue to work over time.

GDPR Article 24 & Article 5(2): Accountability — Demonstrating Compliance

Explanation of the provision

The accountability principle is one of the GDPR's defining features: it is not enough to comply, an organization must be able to demonstrate compliance. For security, this means producing evidence, to a supervisory authority, an auditor, or a customer, that the technical and organisational measures required by Article 32 are in place and effective.

How does Picus Platform support the requirements of GDPR Article 24 & Article 5(2)?

Picus helps controllers support the security dimension of GDPR accountability with evidence. Article 5(2) requires the controller to be responsible for, and able to demonstrate compliance with, the GDPR principles. Article 24(1) requires the controller to implement appropriate technical and organisational measures to ensure and demonstrate that processing is performed in accordance with the Regulation.

For security, this means showing that relevant technical measures are not only defined, but also tested, effective, and reviewed over time. Picus supports this by continuously validating exposures and security controls across the organization’s environment. It shows what was tested, what was blocked, what was detected, what was logged, and what remained exposed.

This gives security and compliance teams time-stamped, MITRE ATT&CK-mapped validation evidence that can support accountability discussions with auditors, supervisory authorities, customers, and internal leadership. Instead of preparing evidence only when an audit begins, teams can use current validation data to demonstrate that security controls are working in practice and that exposure-related risks are being reviewed and addressed over time.

GDPR Article 28: Processors and Sufficient Guarantees

Explanation of the provision

Article 28 requires controllers to use processors that can provide sufficient guarantees that appropriate technical and organisational measures are in place. These guarantees are closely connected to the security obligations of Article 32, including the ability to protect personal data through measures appropriate to the risk. For processors, this creates a need to show that security safeguards are not only documented, but also tested, maintained, and effective in practice.

How does Picus Platform support the requirements of GDPR Article 28?

For organizations acting as processors, Picus helps provide current, validated evidence for the security measures that support sufficient guarantees under Article 28. By continuously validating exposures and security controls, Picus shows whether relevant safeguards can block, detect, log, and respond to attacker techniques in practice.

This gives processors technical evidence they can use to support customer assurance, audit discussions, and Article 32 related security obligations. Instead of relying only on policy statements, contractual assertions, or static control descriptions, processors can show time-stamped validation data that demonstrates how their controls perform against real attack behaviors.

Picus does not replace legal review, data processing agreements, or the broader assessment of technical and organisational measures required under Article 28. It strengthens the security evidence layer by helping processors prove that relevant controls are working in practice and that exposure related risks are being reviewed, addressed, and revalidated over time.

Enforcement and Administrative Fines

The GDPR is enforced by the independent supervisory authority in each Member State, and its administrative fines are designed to be effective, proportionate, and dissuasive. As set out above, a security failure can be assessed under Article 83(4) as an Article 32 infringement (up to €10 million or 2% of total worldwide annual turnover) and, where it engages the Article 5(1)(f) integrity-and-confidentiality principle, under Article 83(5) (up to €20 million or 4%) — in each case, whichever amount is higher, and calculated on the turnover of the wider undertaking. Beyond fines, authorities can order processing bans, data erasure, and remediation, and individuals can bring compensation claims.

This is where continuous validation becomes a compliance and governance asset rather than a cost. When a regulator investigates a breach, the determinative question is whether the security measures were appropriate to the risk and whether their effectiveness had been tested. This is exactly what Article 32 requires and exactly what Picus evidences. By validating control effectiveness continuously and mapping every result to MITRE ATT&CK, Picus lets controllers and processors show that they tested their safeguards, identified weaknesses, and remediated them – and, where Picus supplied a ready-to-deploy detection rule or signature to close the gap, that the remediation was re-validated and confirmed. That is the difference between a breach treated as misfortune and one treated as negligence..

Making GDPR Security Compliance Resilient with Validation

The GDPR was written to ensure that the measures protecting personal data work in practice, not just on paper. The Regulation says so in its own text: controllers and processors must maintain a process for regularly testing, assessing, and evaluating the effectiveness of their security measures, and they must be able to demonstrate that compliance. For any organization processing the personal data of people in the EU, this is not a documentation exercise – it is a standing obligation to prove, continuously, that defenses hold.

Picus helps controllers and processors move from periodic, assumption-based compliance to continuous, evidence-based assurance. By validating control effectiveness against real attack behavior (and turning every exposure into a defensible decision) Picus makes GDPR security compliance a living, defensible posture: one that satisfies supervisory authorities, auditors, and customers not just at the time of assessment, but continuously.

Get your demo and see how Picus helps you meet your GDPR security obligations with audit-ready evidence.

Key sources

• Regulation (EU) 2016/679 (GDPR) — in particular Article 5 (principles, including 5(1)(f) and 5(2)), Article 24 (responsibility of the controller), Article 25 (data protection by design and by default), Article 28 (processor), Article 32 (security of processing), Article 33 (breach notification to the supervisory authority), Article 34 (communication to data subjects), Article 35 (data protection impact assessment), and Article 83 (administrative fines, tiers under 83(4) and 83(5)).
• European Data Protection Board (EDPB) guidance on security of processing, personal data breach notification, and the calculation of administrative fines (Guidelines 04/2022).
• EDPB–EDPS Joint Opinion 2/2026 on the Digital Omnibus proposal (February 2026).

This guide reflects the legal position as of June 2026. The GDPR applies in its current form; the Digital Omnibus proposals to amend it remained in the legislative process at the time of writing and had not altered Article 32 or the in-force 72-hour breach-notification rule under Article 33. Quotations of GDPR provisions other than Article 32 and Article 83 should be confirmed against the official EUR-Lex text before publication.