GDPR does not end with an audit. Article 32 requires a process for regularly testing, assessing and evaluating whether your security measures work. That means a recurring, documented routine after any review, with owners, a schedule and records you can show a regulator or a customer.
What does the text actually say?
Article 32 requires controllers and processors to apply technical and organisational measures that fit the risk. It lists examples: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore access after an incident, and, in point (d), "a process for regularly testing, assessing and evaluating the effectiveness" of those measures.
Note the wording. It asks for a process, not a point in time result. An assessment in January does not answer for the system you run in October.
Article 32 also says that following an approved code of conduct or certification mechanism may help demonstrate compliance. It helps. It does not replace the ongoing process.
What should the routine contain?
Think in layers, each with a cadence.
Every change. Dependency and code checks on each pull request. A new library that processes personal data should be visible before it ships.
Weekly or monthly. Access reviews for systems holding personal data, backup restore tests, and a review of open vulnerabilities with an age limit.
Quarterly. Test your incident response, including the notification path. Review processors and sub-processors for changes.
Yearly. Reassess risk, update your records of processing, and confirm your measures still match what you process.
What counts as evidence?
Regulators and customers want to see that the loop ran. Useful records include:
- dated scan results and the tickets that closed them
- access review sign offs
- restore test logs
- incident exercise notes and the changes that followed
- an SBOM per release, so you can say what software touched personal data
Keep them where they cannot be quietly edited, and name the person who owns each one.
Where does tooling help?
Automation fits the repetitive part: scanning on every change, collecting results, mapping findings to controls, and keeping a history. It does not decide your risk level or write your records of processing. Safeguard's compliance automation can map findings to control language and keep the history, and it does not certify you or replace legal advice.
What does a weak routine look like?
Three patterns come up again and again. The first is a test with no follow up: a scan runs, findings pile up, and nothing closes them. The second is a schedule that lives in one person's head. When that person leaves, the testing quietly stops. The third is evidence that cannot be dated, such as a screenshot with no timestamp or a spreadsheet that gets overwritten each quarter.
A regulator or a customer reviewer will not usually ask whether you test. They will ask when you last tested, what you found, and what you changed. If you can answer all three from records, you are in good shape. If you can only describe intentions, the process exists on paper only.
It also helps to keep a short log of decisions. When you accept a risk instead of fixing it, write down who accepted it, why, and when it will be looked at again.
What to do
- Write down which systems process personal data and who owns each.
- Set a cadence for each layer above and put it in a calendar, not a document.
- Add dependency and secrets checks to your pipeline so every change is tested.
- Run a restore test and record the result.
- Hold one incident exercise a quarter and log the actions that come out of it.
- Review processors twice a year.
- Store all records with dates and an owner.
Quick check
Does a certification mean I can stop testing?
No. Article 32 says a certification may help demonstrate compliance with the requirements, but the requirement for regular testing stays.
How often is "regularly"?
The article does not give a number. Pick a cadence that matches risk, write it down, and follow it. Missing your own schedule is the easiest finding to avoid.
Sources
Last reviewed: 18 October 2026.
