Category: Security & Breach Notification

Regular Testing and Evaluation

Also known as: Test and Evaluation, T&E

Simply put

Regular testing and evaluation is the practice of routinely checking whether the security and other protective measures around personal data actually work as intended. In a data protection context, it typically means periodically exercising systems, controls, or processes and analysing the results to confirm they still perform effectively over time. The available evidence describes testing and evaluation only in general terms, so the specifics of how often and in what form this occurs depend on the organisation's context and risk assessment.

Formal definition

Regular testing and evaluation refers to a recurring process by which a system or its components are exercised and the results analysed to provide performance-related information (Source 1). In the GDPR framework, this concept is generally understood to relate to the ongoing verification that technical and organisational measures protecting personal data remain effective; under the security-of-processing provisions, controllers and processors are expected to implement processes for periodically testing, assessing, and evaluating the effectiveness of such measures, though practitioners should verify the precise article reference and wording against the current official text. The evidence packet provided describes testing and evaluation only in generic, non-privacy terms and does not establish GDPR-specific requirements, frequency, or methodology; accordingly, the applicable cadence, scope, and form (for example, penetration testing, control reviews, or audits) should be determined through a documented risk assessment and may vary between the EU GDPR, the UK GDPR, and national implementing measures. This entry does not address specific testing techniques, and its boundary lies at the general definition of the activity rather than any prescribed compliance standard.

Why it matters

Security measures that are correct when first deployed can degrade over time as systems change, new vulnerabilities emerge, configurations drift, and threat environments evolve. Regular testing and evaluation matters because it provides the feedback that tells an organisation whether the protections around personal data still perform as intended, rather than relying on an untested assumption that controls remain effective. In broad terms, testing is a process by which a system or its components are exercised and the results analysed to provide performance-related information, and that information is what allows organisations to identify weaknesses before they are exploited.

In the data protection context, this activity is generally understood to support the security-of-processing obligations expected of controllers and processors, which typically call for processes to periodically test, assess, and evaluate the effectiveness of technical and organisational measures. Practitioners should verify the precise article reference and wording against the current official text, because the evidence available here describes testing and evaluation only in general, non-privacy terms and does not itself establish GDPR-specific requirements. It is worth noting that the applicable cadence and scope are not fixed by the general definition and may differ across the EU GDPR, the UK GDPR, and national implementing measures.

Because the specifics are not prescribed by the general concept, the value of testing and evaluation lies in it being a documented, repeatable practice tied to the organisation's own risk assessment. Without that grounding, an organisation cannot readily demonstrate that its measures remain appropriate, which is typically a key element of accountability. The boundary of this entry is the general activity itself; it does not endorse any particular testing technique or compliance standard as universally required.

Who it's relevant to

Data Protection Officers and Compliance Leads

DPOs and compliance leads typically use regular testing and evaluation as evidence that protective measures remain effective and that the organisation can demonstrate accountability. They generally need to confirm that the cadence and scope of testing are documented and justified by a risk assessment, and to verify the applicable expectations against the current official text and any regulator guidance, given that positions may differ across the EU GDPR, the UK GDPR, and national law.

Security Engineers and Technical Teams

Engineers responsible for the systems processing personal data are usually the ones who exercise systems or components and analyse the results to produce performance-related information. Their role is generally to translate a risk-based approach into concrete checks, though the specific techniques are not prescribed by the general definition and should be selected according to the organisation's context.

Controllers and Processors

Both controllers and processors are generally expected to implement processes for periodically testing, assessing, and evaluating the effectiveness of the measures protecting personal data. Because their respective responsibilities can differ, each should determine through documented risk assessment what testing is appropriate to its role, subject to verification against the applicable official text.

Privacy and Compliance Counsel

Lawyers advising on security-of-processing obligations typically need to frame testing and evaluation as a context-dependent, risk-based practice rather than a fixed standard. Counsel should note where the precise article reference and wording require confirmation, and flag that requirements and any supporting guidance may evolve and vary between jurisdictions.

Inside Regular Testing and Evaluation

Security of Processing Obligation

Regular testing and evaluation derives from the GDPR requirement (found in Article 32, which the reader should verify against the current official text) that controllers and processors implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Testing and evaluation is expressly named as one component of this obligation.

Process for Regularly Testing, Assessing and Evaluating

The measure typically consists of an ongoing process for testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing, rather than a one-off exercise at the point of implementation.

Technical Testing Activities

In most cases this includes activities such as vulnerability assessments, penetration testing, and review of configurations and controls. The specific methods appropriate for a given organisation are subject to a risk-based assessment and are not prescribed exhaustively by the Regulation text.

Organisational Evaluation Activities

Evaluation generally extends beyond technical controls to organisational measures, such as reviewing policies, staff awareness, access governance, and incident response arrangements, to confirm they remain effective in practice.

Risk-Based Calibration

The frequency, depth, and scope of testing are typically calibrated to the risk to the rights and freedoms of individuals, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing.

Documentation and Accountability

Records of testing and evaluation activities generally support the accountability principle by evidencing that measures are being reviewed and that identified weaknesses are addressed, though the precise documentation expected can vary between supervisory authorities.

Common questions

Answers to the questions practitioners most commonly ask about Regular Testing and Evaluation.

Does the GDPR require a specific frequency or schedule for testing security measures?

No. Article 32(1)(d) refers to a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures, but it does not prescribe a fixed interval or timetable. The appropriate frequency is generally determined by a risk-based assessment, taking into account the state of the art, the nature and scope of processing, and the risks to individuals. What counts as regular for one organisation may differ for another, so this should be documented and justified rather than assumed to follow a universal cadence.

Is regular testing and evaluation only about running technical penetration tests?

Not exclusively. While technical measures such as vulnerability scanning or penetration testing are commonly used, Article 32 refers to both technical and organisational measures. Testing and evaluation can therefore extend to organisational controls, policies, access management practices, and the effectiveness of procedures. Treating this obligation as a purely technical exercise typically overlooks the organisational dimension that the provision also covers.

Who within an organisation is typically responsible for carrying out testing and evaluation?

Responsibility for ensuring appropriate security measures generally rests with the controller, and with the processor for the processing it carries out on the controller's behalf, subject to the arrangements set out in an Article 28 data processing agreement. In practice, the testing itself may be performed by internal security or engineering teams, or by external specialists, but accountability for the process remains with the controller or processor as applicable. Roles should be defined clearly so it is evident who commissions, conducts, and acts on the results.

How should the results of testing and evaluation be documented?

Documentation typically supports the accountability principle under Article 5(2), enabling an organisation to demonstrate that measures are assessed and their effectiveness reviewed. In most cases it is advisable to record what was tested, the methodology, findings, identified weaknesses, and remediation steps taken. The level of detail should generally be proportionate to the risk of the processing. Organisations should verify record-keeping expectations against current supervisory authority guidance, which can vary between regulators.

How does regular testing relate to a Data Protection Impact Assessment under Article 35?

The two are distinct but can be complementary. A DPIA under Article 35 is an assessment carried out where processing is likely to result in a high risk to individuals, typically before processing begins, while testing and evaluation under Article 32(1)(d) is an ongoing process for verifying that security measures remain effective. Findings from regular testing may feed into the review of a DPIA, and a DPIA may identify measures whose effectiveness should later be tested. They should not be treated as interchangeable.

Should the scope of testing change when new processing activities or technologies are introduced?

Generally, yes, subject to assessment. Because the obligation is risk-based, material changes to processing, systems, or the threat environment can affect what measures are appropriate and how their effectiveness should be evaluated. In most cases it is prudent to reassess the scope and frequency of testing when new activities or technologies are introduced, rather than relying on a previously fixed programme. The precise triggers for re-evaluation depend on the organisation's risk profile and should be documented.

Common misconceptions

Regular testing and evaluation is a single annual audit that, once passed, demonstrates compliance.

The obligation is generally understood as an ongoing process rather than a fixed periodic event, and passing a test does not establish that an organisation is fully compliant. Compliance is context and risk dependent, and measures must remain appropriate over time as risks and technology evolve.

Testing and evaluation applies only to controllers.

The security of processing obligation typically applies to both controllers and processors. Processors are generally expected to implement and maintain appropriate measures, and the allocation of responsibilities is usually addressed in the Article 28 data processing arrangement between the parties.

Only technical penetration testing satisfies the requirement.

Testing and evaluation covers the effectiveness of both technical and organisational measures. Focusing solely on technical testing while neglecting policies, staff practices, and governance would, in most cases, leave part of the obligation unaddressed.

Best practices

Establish a documented, recurring schedule for testing and evaluating both technical and organisational measures, and calibrate its frequency and depth to the assessed risk to individuals rather than a fixed default.

Combine multiple methods where appropriate, such as vulnerability assessment, configuration review, and testing of incident response and access governance, rather than relying on a single technique.

Record testing activities, findings, and remediation actions to support the accountability principle and to evidence that measures are actively reviewed.

Feed identified weaknesses into a tracked remediation process and re-test to confirm that corrective measures are effective in practice.

Review and update the testing programme when processing activities, systems, or risk profiles change, so that measures remain appropriate over time.

Where processors are involved, confirm through the Article 28 arrangement how testing and evaluation responsibilities are allocated, and verify against the current official text and relevant supervisory authority guidance, as expectations can vary between regulators.