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

Assessment of Appropriate Level of Security

Also known as: Security Assessment, Cyber Security Assessment
Simply put

This is the process an organization uses to work out how much protection its systems and data actually need, and to check whether the safeguards it already has in place are strong enough. It typically involves looking at the risks an organization faces and evaluating how well its existing measures address them. The aim is generally to match the level of security to the level of risk, rather than applying a fixed one-size-fits-all standard.

Formal definition

An assessment of the appropriate level of security is a structured evaluation of an organization's information security risks and the effectiveness of its existing controls and countermeasures, used to determine whether the level of security is suitable for the risks identified. In practice it generally covers defining scope, analyzing the controls an organization has established, and identifying gaps for remediation, often aligned with applicable compliance requirements. What constitutes an 'appropriate' level is context- and risk-dependent, so this assessment supports an ongoing, risk-based judgment rather than certifying a permanent or absolute state of compliance. Note that the sources in this evidence packet describe security assessment practice generally and do not specify a particular statutory standard; readers should verify the exact obligations and any applicable article references against the current official text of the relevant law.

Why it matters

Under the GDPR, the obligation to implement security is framed around what is appropriate to the risk rather than a fixed technical checklist. This makes the assessment of an appropriate level of security a foundational compliance activity: without evaluating the risks an organization faces and testing whether existing safeguards address them, an organization cannot reliably demonstrate that its measures are proportionate. Because 'appropriate' is context- and risk-dependent, two organizations processing different data or facing different threats may legitimately arrive at different security postures. The assessment is therefore the mechanism through which a general legal standard is translated into concrete, defensible decisions.

A well-documented assessment also supports accountability. Where an organization can show that it analyzed its controls, identified gaps, and planned remediation, it is better positioned to evidence that its choices were reasoned rather than arbitrary, which matters both to regulators and in the aftermath of an incident. Conversely, treating security as a one-time, fixed standard tends to leave organizations exposed as threats, systems, and processing activities change over time.

The sources in this packet describe security assessment practice in general terms and do not specify a particular statutory standard or article reference. Readers should verify the exact security obligations, and any applicable article references, against the current official text of the relevant law, as the precise requirements and their interpretation can differ between the EU GDPR, the UK GDPR, and national implementing measures.

Who it's relevant to

Data Protection Officers and compliance leads
Those responsible for demonstrating accountability rely on documented security assessments to show that the organization's measures were matched to identified risks. The assessment provides the reasoning and evidence trail needed to support that safeguards were chosen deliberately, though readers should confirm the specific obligations against the current official text of the applicable law.
Security and engineering teams
Teams implementing and maintaining controls use the assessment to define scope, analyze existing countermeasures, identify gaps, and prioritize remediation. It helps translate a general 'appropriate to the risk' standard into concrete technical and organizational decisions that can be revisited as systems and threats change.
Legal advisers and risk owners
Lawyers and senior risk owners depend on the assessment to understand where residual risk sits and whether the organization's posture is defensible. Because appropriateness is context-dependent and can vary across the EU GDPR, UK GDPR, and national implementing law, they should treat the assessment as informing an ongoing judgment rather than a fixed guarantee of compliance.

Inside Assessment of Appropriate Level of Security

Risk-based standard
The assessment centres on identifying an 'appropriate' level of security rather than a fixed or absolute one, meaning the required measures scale with the risks presented by the processing. This aligns with the security of processing obligation under Article 32 GDPR.
State of the art and cost of implementation
Article 32 requires that measures take into account the state of the art and the costs of implementation, so the assessment weighs available technical solutions against what is proportionate for the organisation, subject to case-by-case judgement.
Nature, scope, context and purposes of processing
The evaluation considers the specific characteristics of the processing activity, since the same measure may be appropriate in one context and insufficient in another.
Risk to rights and freedoms of individuals
The assessment focuses on risks of varying likelihood and severity to natural persons, including risks arising from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
Illustrative technical and organisational measures
Article 32 names examples such as pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience of systems, restoration of availability after an incident, and regular testing of effectiveness. These are illustrative rather than mandatory in every case.
Ongoing testing and evaluation
Appropriateness is not a one-time determination; the framework contemplates a process for regularly testing, assessing and evaluating the effectiveness of measures over time.

Common questions

Answers to the questions practitioners most commonly ask about Assessment of Appropriate Level of Security.

Does the GDPR set a fixed list of security measures we must implement to be compliant?
No. The GDPR does not prescribe a mandatory checklist of controls. Article 32 requires security measures that are appropriate to the risk, taking into account factors such as the state of the art, the costs of implementation, and the nature, scope, context, and purposes of the processing, as well as the varying likelihood and severity of risk to individuals. This is a risk-based and context-dependent standard rather than a fixed technical specification. The Regulation gives examples (for instance, encryption and pseudonymisation) but frames them as measures to consider where appropriate, not universal requirements. You should verify the specific wording against the current official text.
If we adopt strong encryption, does that mean our processing is fully secure and compliant?
Not necessarily. Encryption is one measure that may be appropriate, but no single control makes processing 'fully compliant' or eliminates risk in all cases. The appropriateness of security is assessed against the specific risks to individuals and the processing context, and it must be maintained over time as threats and the state of the art evolve. Article 32 also refers to measures such as ensuring ongoing confidentiality, integrity, availability, and resilience, and a process for regularly testing and evaluating effectiveness. Security is context and risk dependent, so encryption should be treated as part of a broader, documented assessment rather than a guarantee of compliance.
How do we actually carry out an assessment of the appropriate level of security in practice?
In most cases the assessment begins by identifying the processing activities and the personal data involved, then evaluating the likelihood and severity of risks to individuals if confidentiality, integrity, or availability were compromised. Organisations typically weigh candidate measures against the Article 32 factors, including the state of the art and costs of implementation, and document why the selected measures are appropriate to that risk. The process is generally iterative and should be revisited periodically. The precise methodology is not dictated by the Regulation, so approaches vary; you should confirm expectations against current regulator guidance, which can differ between authorities.
Who is responsible for the security assessment when a processor is involved?
Both controllers and processors have security obligations under Article 32, so the assessment is generally a shared responsibility rather than the controller's alone. The controller typically remains accountable for ensuring appropriate security across the processing, while the processor must implement appropriate measures for the processing it carries out. These responsibilities are usually reflected and allocated in the data processing agreement required under Article 28, which is a distinct instrument from the security assessment itself. The exact division depends on the arrangement and should be documented; verify the specific obligations against the current text and any applicable guidance.
How does the security assessment relate to a Data Protection Impact Assessment (DPIA)?
They are related but distinct. A DPIA under Article 35 is a broader assessment of risks to the rights and freedoms of individuals arising from certain high-risk processing, and it typically includes consideration of security measures among other safeguards. The Article 32 security assessment focuses specifically on the appropriateness of technical and organisational security measures relative to risk. In practice, findings from a security assessment often feed into a DPIA where one is required, but conducting a DPIA does not automatically discharge the standalone security obligation, and vice versa. Confirm when a DPIA is mandatory against the current text and applicable guidance.
How often should we revisit the assessment, and what should we document?
There is no single prescribed interval in the Regulation, but security appropriateness is generally treated as an ongoing obligation because risks, threats, and the state of the art change over time. Article 32 refers to a process for regularly testing, assessing, and evaluating the effectiveness of measures, which implies periodic review, particularly after significant changes to processing, technology, or the threat environment. Organisations typically document the risks considered, the measures chosen and the rationale, and the outcomes of reviews to support accountability. Because expectations on frequency and documentation can vary between regulators, confirm against current guidance.

Common misconceptions

Encryption is always required for compliance.
Encryption is listed in Article 32 as an example of a measure that may be appropriate, but the Regulation frames it as one option among several to be considered against the assessed risk. Whether it is required depends on the nature, context and risk of the specific processing, and other measures may be appropriate instead of or alongside it.
Once security measures are assessed and implemented, the organisation is 'fully compliant' and the task is complete.
The standard is context and risk dependent and expects ongoing review. Article 32 references regular testing and evaluation of effectiveness, so an assessment that was adequate at one point may need to be revisited as risks, technology and processing activities change.
The assessment of appropriate security is the same exercise as a Data Protection Impact Assessment (DPIA).
The security assessment derives from the Article 32 security of processing obligation, whereas a DPIA is a distinct instrument under Article 35 addressing high-risk processing more broadly. They are related and may inform each other, but they are not interchangeable.

Best practices

Document how the nature, scope, context and purposes of the processing, and the likelihood and severity of risks to individuals, were factored into the choice of measures, so the reasoning behind 'appropriate' is evidenced.
Consider the illustrative Article 32 measures, such as pseudonymisation, encryption, and ensuring confidentiality, integrity, availability and resilience, but select and justify measures based on the specific assessed risk rather than treating any single measure as mandatory.
Establish a process to regularly test, assess and evaluate the effectiveness of technical and organisational measures, and revisit the assessment when processing, risks or available technology change.
Balance the state of the art against the cost of implementation transparently, recording why the selected measures are proportionate to the risk in the given context.
Include a plan for restoring the availability of and access to personal data in a timely manner following a physical or technical incident.
Verify the specific requirements and any national implementing or UK GDPR variations against the current official text, as member state derogations and regulatory guidance may affect the position.