How to run a GDPR security risk assessment

Start from the rated risks, not from a standard menu. For each risk that remains above the level you accept, pick a measure that reduces its likelihood or limits its impact on individuals, and name the owner who will run it. Record two lists separately: existing measures already operating, and planned measures with a responsible person and a date. The EDPB's small business guide treats both lists as part of the assessment, and the assessment should also verify that each measure does what it was chosen to do. Expect the list to contain technical settings such as encryption, access control, logging and backup, and organizational measures such as training, change control and supplier oversight. The detailed design of those technical controls is covered in their own guides in this group, so this assessment only needs to state which measure answers which risk.

Carry the results into your records. Article 30(1)(g) and (2)(d) expect a general description of security measures to appear, where possible, in the records of processing, so the register entry for each processing activity should point to the measures you chose for it. If you process personal data for customers, Article 28(3)(c) requires the processor contract to oblige you to take all measures Article 32 requires, so check that the security annex in each agreement matches the measures in your assessment. Ask your legal or procurement team to confirm the wording of those clauses, because the obligation is set by the regulation but the contract language is theirs to settle.

Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your measures, and the EDPB recommends periodic security audits that each produce an action plan monitored at the highest level of the organization. Decide the review cadence in writing, assign who runs each test, and keep the results with the risk register. Testing can be a configuration review, a restore test, an access review or a penetration test, depending on the risk. Where a rated risk is still high after the chosen measures, the same register is the input for deciding whether a DPIA under Article 35(1) is needed. An outside firm can help run the tests and prepare the evidence, but the controller remains responsible for the decisions.

The EDPB's small business guide recommends periodic security audits, and each audit should end in an action plan whose implementation is monitored at the highest level of the organization. The GDPR does not set a fixed interval, so the cadence is a decision you document. Choose an interval that matches how fast your processing changes, record why you chose it, and keep the risk management spreadsheet the EDPB suggests current between audits so that the next review starts from accurate data rather than memory.

Some events should trigger a re-assessment without waiting for the scheduled audit. These include a material change in processing, such as a new data category, a new purpose or a new hosting location; a new processor or sub-processor with access to personal data; a significant change to your architecture or access model; and a personal data breach, which can reveal a gap in an existing measure. Under Article 32(1)(d), the process must test whether your measures remain effective, so each trigger should lead to a documented review of the affected risks, not just a note in a ticket queue.

Each audit output should contain findings, a named owner and due date for every action, and a verification step that shows the measure works. Ask the person who signed off on the risk to confirm closure, and attach the evidence, such as a configuration export, a test result or a signed access review. Record the outcome in your records of processing, since Article 30 expects a general description of security measures there. If a remaining high risk cannot be reduced, the assessment may also require a DPIA under Article 35, which is covered later on this page.

A security risk assessment becomes a data protection impact assessment (DPIA) when the processing it examines is likely to result in a high risk to individuals. Article 35(1) requires a DPIA before that processing starts, and it names new technologies as a case that often triggers one. The security risk assessment is the input that reveals this. When you rate impact on individuals and find that the worst credible outcomes for a processing activity are serious, such as re-identification of health data or loss of access to records people depend on, you have already produced most of the evidence needed to decide whether a DPIA is mandatory.

Check the trigger for each processing activity, not only for the system as a whole. Article 35(1) allows one assessment to cover a set of similar processing operations that present similar high risks, so a group of comparable workflows can share a DPIA. Keep a note of which activities you grouped and why. Then ask a second question: after the measures you have chosen, is the residual risk still high? If it is, Article 36 requires you to consult the supervisory authority before processing begins. Illustrative example: a new analytics pipeline that still exposes pseudonymised records to a wide internal group after access controls are applied would likely need prior consultation rather than deployment.

Confirm three things before you close the assessment: which activities were screened, which were judged high risk and why, and who signed off on the residual risk. The contents of a DPIA, how to document it and when to review it are set out in the GDPR documentation, policies and DPIAs guides cluster, and the EDPB's endorsed WP29 guidance on DPIAs is the natural next read on the threshold itself. Your data protection officer, where you have designated one, should review the screening record.

The most common failure is scoring risk by what it costs the organization, such as downtime, fines or reputational damage, instead of the harm to the people whose data is exposed. Article 32(2) directs attention to destruction, loss, alteration, unauthorised disclosure of or access to personal data, and the EDPB's small business guide asks for impacts on individuals. A register that rates a customer database as moderate because restoring it is cheap has measured the wrong thing. Assessments also tend to list only staff and the company's own servers as risk sources. When a hosting provider, support vendor or software sub-processor holds the data, those parties often disappear from the analysis. Confirm the processor and sub-processor list against the records of processing, then score each supporting asset with its actual operator in mind.

The second failure is a register that lists measures without linking them to risks. Each risk should name the threat, the assets it affects, the existing and planned measures that address it, and the severity and likelihood that remain afterwards. Without that chain, a team can show that encryption and multi-factor authentication exist but cannot say which risk they reduce, and a high-likelihood account takeover risk may have no owner at all. Verification is the other gap. The EDPB guide expects each measure to be checked, which means someone tests that the control works: a restore test for backups, a review of a sample of leaver accounts, or a check that logs capture the events a risk depends on. A measure marked implemented in a spreadsheet, with no test behind it, is the first thing an assessor will probe. For every measure, record the test date, the tester and the result.

The last failure is treating the assessment as a one-time document. Article 32(1)(d) requires a process for regularly testing and evaluating the effectiveness of security measures, and the EDPB guide recommends periodic security audits, each producing an action plan that senior management monitors. When an incident occurs, a supervisory authority compares the register with what the systems looked like at the time. Recent enforcement shows the consequences of weak technical measures. The Swedish authority fined Miljödata for insufficient technical measures, approximately EUR 160,000 according to the EDPB's national news item, and the CNIL fined Hôpital Privé de la Loire EUR 500,000 after a health data breach. Read the full decisions before drawing conclusions about specific controls. Set review triggers for new processors, migrations and incidents, not only an annual calendar.