Skip to main content
Privacy Track
Category: Security & Breach Notification

Process for Regularly Testing and Evaluating

Also known as: Process for regularly testing, assessing and evaluating the effectiveness of security measures, Article 32(1)(d) testing requirement, Security effectiveness testing process
Simply put

This is a requirement under data protection law that an organisation must have an ongoing way of checking whether its security measures actually work, rather than setting them up once and assuming they are effective. The idea is that security is tested and re-evaluated over time to confirm it still protects personal data. The law describes the outcome required but does not tell organisations exactly which testing methods to use.

Formal definition

Under Article 32 of the UK GDPR (mirrored in the EU GDPR), controllers and processors are generally required to implement a process for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures adopted to ensure the security of processing. According to ICO guidance, this is a specific obligation and not merely good practice. The Regulation is method-neutral: it does not prescribe a particular technique, frequency, or tool (for example, vulnerability assessments or penetration testing are commonly used approaches referenced in industry guidance, but are not mandated by the Article text). What constitutes an appropriate testing process is subject to assessment, typically calibrated to the state of the art, costs of implementation, and the nature, scope, context and purposes of processing, as well as the risks to individuals. This entry addresses the testing and evaluation limb of Article 32 specifically and does not restate the full scope of security obligations under that Article; readers should verify the precise wording and any applicable national derogations against the current official text.

Why it matters

Security measures degrade over time. A configuration that was appropriate when deployed can become inadequate as threats evolve, systems change, and new vulnerabilities emerge. The testing and evaluation requirement under Article 32 recognises this reality: it treats security not as a one-off implementation but as an ongoing state that must be actively verified. According to ICO guidance, this is a specific obligation rather than merely good practice, meaning an organisation that implements strong measures but never checks whether they still work may fall short of what the law expects.

From a compliance perspective, the requirement matters because it shifts the evidentiary burden. Being able to demonstrate a documented, repeated process of testing and evaluation supports accountability and helps show that security decisions are calibrated to current risk. Where a security incident occurs, the presence or absence of a meaningful testing regime is likely to be relevant to how a supervisory authority assesses whether appropriate technical and organisational measures were in place. It is important to note that no testing process guarantees compliance; the adequacy of any given approach is subject to assessment against the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risks to individuals.

The requirement is method-neutral, which is both a flexibility and a source of uncertainty. The Article text does not name a particular technique, frequency, or tool, so organisations must exercise judgement about what is proportionate to their risk profile. This means there is no single benchmark that definitively satisfies the obligation, and readers should be cautious about treating any vendor's proposed framework or a particular testing cadence as settled legal requirement rather than one reasonable interpretation.

Who it's relevant to

Controllers
As the party determining the purposes and means of processing, a controller is generally responsible for ensuring appropriate security measures are in place and, under Article 32, for having a process to regularly test, assess and evaluate their effectiveness. Controllers should be able to demonstrate that their testing approach is proportionate to the risks their processing poses to individuals.
Processors
Article 32 applies to processors as well as controllers. A processor handling personal data on a controller's behalf is generally expected to maintain its own testing and evaluation process for the measures it operates. The specific allocation of testing responsibilities between the parties is also typically addressed in the Article 28 data processing agreement, which is a distinct instrument from the Article 32 obligation itself.
Data Protection Officers and compliance leads
Those responsible for oversight and accountability need to confirm that a testing process exists, is documented, and is genuinely operating over time. They are often the people who must evidence the process to a supervisory authority or during an incident review, and who assess whether the frequency and rigour of testing remain appropriate as risks change.
Security and engineering teams
The teams that design, deploy, and maintain systems are typically responsible for carrying out the actual testing, whether through vulnerability assessments, penetration testing, automated tooling, or other methods. Because the Article is method-neutral, these teams exercise significant judgement in selecting techniques appropriate to the organisation's risk profile and in feeding findings back into remediation.

Inside Process for Regularly Testing and Evaluating

Testing of technical and organisational measures
A structured process for assessing the effectiveness of the security and privacy safeguards that a controller or processor has implemented. Under Article 32 GDPR, this forms part of the requirement to have a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing. The specific measures appropriate to a given organisation are subject to a risk assessment and depend on context.
Regularity and cadence
The requirement is described as ongoing rather than a one-off exercise. GDPR does not prescribe a fixed frequency or interval; the appropriate cadence is generally determined by the nature, scope, context, and purposes of processing and the risks to individuals. Practitioners should verify expectations against current regulatory guidance, which can vary between supervisory authorities.
Assessment and evaluation of effectiveness
Beyond testing that a control exists, the process typically includes evaluating whether the control actually achieves its intended protective outcome. This distinguishes the activity from a mere inventory check and connects it to the risk-based approach that runs throughout the GDPR's security provisions.
Relationship to broader accountability
This process supports the accountability principle, under which controllers must be able to demonstrate compliance. Documenting testing and evaluation activities generally helps evidence that appropriate measures were selected and remain effective, though documentation alone does not establish compliance, which is context and risk dependent.

Common questions

Answers to the questions practitioners most commonly ask about Process for Regularly Testing and Evaluating.

Does 'regularly testing and evaluating' mean a single annual assessment is enough?
No. A one-off yearly exercise is generally treated as a starting point rather than a complete process. The obligation to test, assess, and evaluate the effectiveness of technical and organisational measures is framed as an ongoing activity, and the appropriate frequency typically depends on the risk profile of the processing, the sensitivity of the data, and the rate of change in systems. In most cases you should combine periodic scheduled reviews with event-driven testing triggered by significant changes. Treat 'regularly' as a risk-based cadence rather than a fixed calendar rule, and verify expectations against the current official text and applicable regulator guidance.
Is testing security measures purely a technical or IT task?
Not generally. While technical testing (such as vulnerability scanning or penetration testing) is an important component, the process is typically understood to cover both technical and organisational measures. That can include evaluating policies, staff awareness, access governance, incident response readiness, and third-party arrangements. Responsibility is usually shared across security, compliance, and data protection functions rather than sitting solely with IT. The precise allocation of roles depends on the organisation's structure and should be documented as part of the accountability posture.
How should we decide how often to test and evaluate our measures?
Frequency is generally determined by a risk-based assessment rather than a prescribed interval. Factors that typically inform the cadence include the sensitivity and volume of the personal data, the likelihood and severity of potential harm, the complexity and rate of change of systems, and any special category data involved. Higher-risk processing usually warrants more frequent or continuous evaluation. In most cases organisations combine a baseline schedule with additional testing after material changes. Document the rationale so the chosen cadence can be justified if questioned.
What types of testing are commonly included in this process?
Approaches vary by context, but organisations commonly draw on a mix of methods such as vulnerability assessments, penetration testing, configuration and control reviews, access recertification, tabletop or incident response exercises, and audits of organisational measures. The appropriate combination typically depends on the risk profile and the nature of the systems and processing. No single method is treated as universally sufficient, so the selection should be tailored and periodically reconsidered as risks evolve.
How should test results be documented and used?
Results are generally recorded to support accountability and to demonstrate that measures are being actively evaluated. In most cases this includes capturing the scope, findings, risk ratings, and remediation actions with owners and timelines, and then tracking those actions to closure. Documentation typically feeds back into updating the measures themselves, so testing and remediation form a continuous cycle rather than isolated events. Retention and format of such records should align with your broader documentation and record-keeping practices.
How does this process relate to other privacy and security activities?
The testing and evaluation process is typically integrated with, rather than separate from, activities such as risk assessments, data protection impact assessments where applicable, incident management, and vendor oversight. Findings from testing can inform whether existing measures remain appropriate to the identified risk, and can surface issues that feed into those adjacent processes. The precise interfaces depend on the organisation's governance model, so it is generally advisable to define clearly how outputs from testing flow into decision-making and remediation.

Common misconceptions

The GDPR sets a mandatory testing schedule, such as annual penetration testing.
The Regulation requires a process for regularly testing, assessing, and evaluating effectiveness but does not, in its text, prescribe a specific interval or method. The appropriate frequency and approach are generally determined by risk and context, and practitioners should confirm any expected cadence against current supervisory authority guidance rather than assuming a fixed figure.
Passing a test or completing an evaluation means the organisation is fully compliant.
Testing and evaluation are components of a risk-based security process, not a guarantee of compliance. Compliance is context and risk dependent, and a single successful test does not establish that all technical and organisational measures remain appropriate over time or across all processing activities.
This testing requirement is a separate obligation unrelated to the rest of the security framework.
The requirement to have a process for regularly testing and evaluating is part of the security of processing obligations and connects to the accountability principle. It is best understood as one element within a broader, risk-driven approach to selecting and maintaining measures rather than a standalone task.

Best practices

Set the testing and evaluation cadence based on a documented risk assessment reflecting the nature, scope, context, and purposes of your processing, rather than adopting a fixed interval by default.
Distinguish clearly between confirming that a control exists and evaluating whether it is effective, and design your process to cover both.
Maintain records of testing and evaluation activities and outcomes to support the accountability principle, while recognising that documentation supports but does not by itself establish compliance.
Feed the results of testing back into your selection and adjustment of technical and organisational measures, treating the process as ongoing rather than a one-off exercise.
Verify any expected testing methods or frequencies against the current official GDPR text and applicable supervisory authority guidance, noting that expectations can vary between regulators.
Where UK GDPR or national implementing law applies, check for any divergence in expectations rather than assuming the EU position transfers directly.