Skip to content

Compliance

GDPR
Penetration Testing

Component tests from $4,200, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need GDPR penetration testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • An EU customer’s data processing agreement requires regular security testing and evidence of it, and the renewal is coming up.
  • A DPIA flagged high-risk processing and the mitigations it relies on need to be verified in practice, not only documented.
  • You are expanding into the EU or UK market and buyers ask how personal data is protected before they sign.
  • A breach at a peer, or a supervisory authority enforcement action in your sector, made Article 32 evidence a board question.

Article 32

What Article 32 actually says

Article 32(1) requires controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk,” and point (d) names one of those measures explicitly: “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” The regulation leaves the method to you, which is deliberate. What a supervisory authority looks for after an incident is whether testing happened regularly, whether it covered the systems that held the data, and whether findings were acted on.

A penetration test answers all three, and the report is dated evidence. The same article’s references to pseudonymisation, encryption, and resilience map directly to the access-control, encryption, and breach-readiness findings the test produces.

Who needs it

Controllers, processors, and DPAs: who needs the test

Controllers

Organizations that decide why and how personal data is processed: retailers, publishers, employers, and any company with EU customers or users. Article 32 applies directly, and Article 33 obliges them to notify a breach within 72 hours, which makes the breach-readiness findings as important as the exposure findings.

Processors

Vendors that process personal data on a controller’s behalf, which is what most US SaaS, hosting, and analytics companies are for their EU customers. Article 28 requires the controller to use only processors with sufficient guarantees, and the data processing agreement is where “regular testing” becomes a contractual obligation with an audit right behind it.

What we assess

What your GDPR test covers

We test the systems that actually touch personal data and report findings by data-exposure risk, giving your DPO evidence of Article 32 testing rather than a generic scan.

Personal Data Exposure

The paths an attacker could take to reach, extract, or leak personal data.

We test for

  • Data exposure and exfiltration paths
  • Excessive data in responses
  • Insecure direct object references
  • Backup and export exposure

Access Control & Authentication

Who can reach personal data and how they prove who they are.

We test for

  • Access control and least privilege
  • Authentication and MFA
  • Session management
  • Privilege escalation

Encryption & Transmission

Whether personal data is protected at rest and as it moves.

We test for

  • Encryption in transit and at rest
  • TLS configuration
  • Key management
  • Cleartext data handling

Breach Readiness

Whether an intrusion against personal data would be detected and contained.

We test for

  • Logging and monitoring coverage
  • Detection of data access abuse
  • Segmentation around data stores
  • Incident response evidence

Article 33

Article 33 and breach readiness

The 72-hour notification clock in Article 33 starts when you become aware of a breach, and the notification must describe its nature, likely consequences, and the measures taken. That is only possible if intrusions against personal data are detected and contained quickly. The breach-readiness part of the test checks exactly that: whether access to data stores is logged, whether abuse of that access would be noticed, and whether segmentation limits how much data one compromised system exposes. The findings feed your incident response plan as much as your security backlog.

Methodology

How we test

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your compliance test runs through.

  1. 01

    Scope the boundary

    The systems your framework actually covers, and nothing you would pay to test twice.

  2. 02

    Test

    The component penetration tests run to PTES and OWASP standards by senior testers.

  3. 03

    Map to controls

    Every finding tied to the requirement or control it evidences.

  4. 04

    Report for the auditor

    Evidence formatted the way your assessor, examiner, or QSA expects to read it.

  5. 05

    Fix & retest

    A free retest so the audit shows closed findings, not open ones.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Map the data

    We identify each system that stores, processes, or transmits EU personal data.

  2. 02

    Article 32 test

    We test the technical measures that protect personal data, meeting Article 32.

  3. 03

    DPO report

    Findings ranked by personal-data exposure risk, as evidence for your DPO.

  4. 04

    Fix & retest

    Fix the findings, then a free retest that lowers your risk of a costly breach.

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study

Fintech · Payments

Post-Incident Web App Assessment

Medium risk

Excessive data exposure: API responses leaked transaction metadata, including precise geolocation, enabling real-world tracking of users.

Outcome. Surfaced the exposure and hardening gaps, prioritized by how readily an attacker could chain them, and delivered fixes plus a retest to confirm closure.

8

Findings

3

Medium

Post-incident

Engagement

Read the case study

FAQ

Frequently asked questions

What teams most often ask before GDPR testing.

Still have questions? 
01Does GDPR require penetration testing?

Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of your technical and organisational security measures. It does not name a method, but penetration testing is the most widely accepted way to demonstrate that testing actually happens.

02What systems are in scope for a GDPR test?

The applications, infrastructure, and integrations that store or process EU personal data. We confirm the data flows with you during scoping so testing concentrates on the systems that carry real exposure.

03How does this reduce our breach and fine risk?

Most reportable breaches trace back to exploitable technical flaws. Finding and fixing them first reduces the chance of a notifiable incident, and the report itself evidences the regular testing regulators look for when they assess how seriously you took Article 32.

04Where is our test data handled?

Testing artifacts and findings are handled under NDA, encrypted in transit and at rest, and retained only as long as needed for delivery and retest before secure destruction. If your engagement involves personal data covered by GDPR, we agree data-handling and residency terms during scoping so the test itself stays compliant.

05How much does a GDPR penetration test cost?

A GDPR test is scoped to the systems that process EU personal data, usually a web application and/or network test (from $5,200 and $4,200), quoted as a fixed price after scoping, with a free retest. Starting prices for every service are on our pricing page.

06Does GDPR apply to a US company?

Often, yes. Under Article 3, GDPR applies to organizations outside the EU that offer goods or services to people in the EU or monitor their behavior, regardless of where the company is based. A US SaaS company with EU customers is typically a processor under its customers’ data processing agreements, which pass Article 32 obligations down the chain. The DPA is usually where the requirement to test, and to show evidence of testing, first appears. US businesses with California customers may also fall under a separate California rule: the California Privacy Protection Agency’s regulations require a cybersecurity audit from businesses that meet set revenue and data-volume thresholds, and the audit must assess penetration testing where applicable. Our page on the CCPA cybersecurity audit covers who is in scope and the testing evidence it needs.

Ready to test your defenses?

Talk to our team about what your GDPR compliance requires.

Prefer the full scoping questionnaire? 

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.