GDPR
GDPR Security Testing and Article 32
Article 32 contains the closest thing in GDPR to a testing mandate: a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational measures.
- Anchored on Article 32 and appropriateness
- Supports breach defensibility, not just certification
- Findings framed around personal data flows
What Article 32 requires
Article 32 obliges controllers and processors to implement technical and organisational measures appropriate to the risk, and it lists a process for regularly testing, assessing and evaluating the effectiveness of those measures as one of the things that may be appropriate.
No method is specified and no frequency is set. What the article does introduce is the word appropriate, and appropriateness is judged against the risk to data subjects, the state of the art and the cost of implementation. That framing is more demanding than a checkbox in one respect: you have to be able to justify your choices.
Why testing matters more after an incident than before
GDPR's practical force arrives during a breach investigation. A supervisory authority assessing your response will ask what measures you had implemented and how you knew they worked. Fines under the regulation take into account the technical and organisational measures in place.
An organisation that can show regular testing, a risk-based treatment process and evidence of remediation is in a materially different position from one that can only produce a policy document. Testing is not primarily about avoiding a breach here; it is about being defensible when one occurs.
How we scope a GDPR-driven engagement
Scope follows personal data rather than system boundaries, which usually widens it. We map where personal data enters, where it is stored, who can reach it and where it flows outward, then test that path.
- Access control on personal data, including internal roles and support tooling with broad visibility
- Data subject rights functionality — access, export and erasure endpoints, which are frequently newer, less tested, and able to return other people's data
- Pseudonymisation and encryption where you rely on them, since Article 32 names both
- Data flows to processors and sub-processors, where your obligations continue
- Logging sufficient to determine what was accessed during an incident, which directly affects your breach notification position
- Retention and deletion behaviour, including whether deleted data actually leaves backups and analytics systems
The finding that recurs
Data subject access and export endpoints are a reliable source of serious findings. They are built to satisfy a compliance obligation, are often added later than the rest of the product, and are designed to return large amounts of personal data by design. An authorisation flaw in an export endpoint is both a security finding and, if exploited, a reportable breach of the regulation the endpoint was built to satisfy.
What you receive
- Findings framed around personal data exposure, so their regulatory significance is legible to your DPO and your legal team
- An assessment of whether your logging would let you scope a breach for notification purposes
- Confirmation of whether pseudonymisation and encryption are effective where you rely on them
- A record of testing and remediation suitable as evidence of an Article 32 process
Common questions
Does GDPR require penetration testing?
Not by name. Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of your security measures, which is a testing obligation without a prescribed method. Penetration testing is a well-recognised way to satisfy it, and the absence of a specified method means you can direct effort by risk rather than by checklist.
How does testing help if we suffer a breach anyway?
It affects how the incident is assessed. Supervisory authorities consider the technical and organisational measures that were in place, and enforcement outcomes have differed sharply between organisations that could evidence a genuine security programme and those that could not. Regular testing with documented remediation is among the strongest evidence available.
Do we need testing if we only process a small amount of personal data?
Article 32 is risk-based, so a small volume of low-sensitivity data justifies lighter measures. Volume is not the only factor though: sensitivity, the consequences for data subjects and the nature of processing all count. A small dataset of health or financial information can warrant more protection than a large dataset of newsletter subscribers.
Do you test our data subject access and export endpoints?
Yes, and they are a reliable source of serious findings. They are built to satisfy a compliance obligation, are usually added later than the rest of the product, and return large volumes of personal data by design. An authorisation flaw there is both a security finding and, if exploited, a reportable breach of the regulation the endpoint exists to satisfy.
Does GDPR apply to us if we are based in India?
It can, through the regulation's extraterritorial scope. If you offer goods or services to people in the EU or monitor their behaviour, it applies regardless of where you are established. It also reaches you contractually when you process personal data on behalf of an EU controller, which is the more common route for Indian technology firms.
What does Article 32 mean by measures appropriate to the risk?
That the standard is proportionate rather than fixed. Appropriateness is judged against the risk to the people whose data you hold, the state of the art, and implementation cost. The practical consequence is that you must be able to justify what you chose and why, which is why documented testing and a risk-based treatment record matter more than any specific control.
Does deleting a record actually delete it in most systems?
Frequently not, and it is worth testing. Deletion often removes a row from the primary database while leaving copies in backups, search indexes, caches, analytics pipelines, exported reports and third-party processors. Erasure obligations apply to the data, not to the primary table, so we follow where a record travelled and check what survived.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.