GDPR
Article 32 security testing, DPIAs, and breach notification evidence

GDPR in context: a principles-led regime that demands evidenced security

The General Data Protection Regulation (Regulation EU 2016/679) applied from 25 May 2018 and replaced the 1995 Data Protection Directive. The UK GDPR retains the substance of the EU GDPR alongside the Data Protection Act 2018 following the end of the Brexit transition period. The regulation is principles-led: lawfulness, fairness, and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Article 5(2) makes the controller responsible for, and able to demonstrate, compliance with each principle. Fines reach up to 20 million euro or 4 percent of total worldwide annual turnover, whichever is higher, for the most serious infringements.

For most security and risk teams the operational question is not whether GDPR applies; it is how to evidence the security side of the regulation, in particular Article 32, without rebuilding the artefact pack at every audit, supervisory inquiry, or DPIA. GDPR favours continuous accountability over snapshots, which is why the linkage between the records of processing activities, the asset inventory, the testing programme, and the breach register matters more than any individual document.

Who is in scope, and where the territorial test bites

Article 3 sets the territorial scope through two routes: establishment in the EU (or the UK, under UK GDPR) and targeting of data subjects from outside. Both routes apply regardless of the legal form of the entity, and the EDPB guidance on Article 3 turns the targeting test into a list of evidenced indicators rather than a subjective judgement.

Article 32: appropriate technical and organisational measures

Article 32 is the security article. It requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons. The four illustrative measures named in the article are not a closed list; the supervisor expects an evidenced control set that fits the risk profile of each processing activity.

The fourth illustrative measure (regular testing, assessing, and evaluating the effectiveness of the measures) is the article that pulls vulnerability assessments and penetration tests directly into GDPR. The penetration testing workflow and the vulnerability assessment workflow are designed for this kind of programme: scope, log findings against assets, track remediation against deadlines, and re-test before closure. Programmes operating under ISO 27001 or NIS2 already hold most of the underlying evidence; the GDPR-specific work is mapping it back to Article 32 and to the affected processing activity.

Article 35: when a Data Protection Impact Assessment is mandatory

A DPIA is required prior to the processing where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context and purposes of the processing. Article 35(3) gives three illustrative cases that always require a DPIA, and the EDPB and national supervisory authority guidance translates the high risk concept into reasoned triggers.

A DPIA is a structured exercise, not a long-form essay. Capture the description of the processing, the necessity and proportionality assessment against the lawful basis, the risks to data subjects with likelihood and severity reasoning, and the mitigations including the security testing results from the same workspace. Where high residual risk remains after mitigation, the controller must consult the supervisory authority under Article 36 before commencing the processing. For a structured method to keep the underlying risk model consistent, the cybersecurity risk assessment guide and the threat modelling guide cover the threat enumeration and risk treatment side that the DPIA reuses.

Articles 33 and 34: the 72-hour breach notification clock

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. Once the controller becomes aware of the breach, the 72-hour clock to notify the competent supervisory authority starts running unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the breach is likely to result in a high risk, affected data subjects must also be informed without undue delay.

Hitting the deadline is a function of pre-built templates, a clear handoff between detection and reporting, and a single source of truth for the incident record. The incident response workflow keeps triage, classification, containment, and recovery tied to the same record the supervisory notification references, so the technical timeline and the supervisor narrative tell the same story. For coordinated disclosure of vendor and product vulnerabilities that escalate into personal data breaches, pair the workflow with the vulnerability disclosure programme setup guide.

Article 30: the records of processing activities (ROPA)

The ROPA is the structural backbone of an accountability-first programme. Every processing activity in scope is described once, links to the lawful basis, the categories of data and data subjects, the recipients, the retention periods, the cross-border transfers, and the security measures. Each Article 32 testing cycle and each personal data breach attaches to the processing activity it concerns, so the picture stays coherent across audits and across years.

International transfers: adequacy, SCCs, BCRs, and the TIA

After the Schrems II ruling (CJEU C-311/18, July 2020), every transfer of personal data to a third country requires not only a transfer mechanism but also a documented assessment of whether the destination country regime undermines the essential guarantees of EU law. The EDPB Recommendations 01/2020 set out a six-step methodology, and the 2021 modular SCCs embed the obligation directly into the contract. The UK regime mirrors the substance with the IDTA and the UK Addendum.

Each cross-border flow gets a TIA in the workspace, with the destination country regime evaluated, the supplementary measures recorded (encryption with controller-held keys, pseudonymisation, contractual restrictions), and the position re-assessed after material legal changes in the destination. Treat the TIA as a living document tied to the processor record, not a PDF saved at contract signature.

UK GDPR: the parallel regime, the adequacy clock, and reform

The UK GDPR mirrors the EU GDPR in substance, with UK-specific changes and the Data Protection Act 2018 alongside. The Information Commissioner Office is the UK supervisory authority. UK organisations subject to both regimes typically run a single security programme and surface the regime-specific obligations (representative under Article 27, national supervisory authority, transfer mechanism choice) where they actually differ.

Articles 24 to 28: accountability, data protection by design, and the controller and processor relationship

Article 24 puts accountability on the controller, Article 25 introduces data protection by design and by default, and Article 28 sets out the controller and processor relationship and the mandatory clauses of the data processing agreement. The DPA covers the subject matter, duration, nature and purpose of processing, the type of personal data, the categories of data subjects, the obligations and rights of the controller, processing only on documented instructions, confidentiality undertakings, security measures, sub-processor authorisation, assistance with data subject requests, security obligations, breach notification, DPIA and prior consultation, deletion or return of personal data on termination, and audit rights.

Tie the DPA register to the supplier security programme and to the Article 32 testing results so the supervisor sees a coherent picture rather than parallel paperwork. For consultants delivering GDPR readiness and Article 32 testing to multiple clients, the security consultants workspace bundles client-scoped engagements with the branded client portal and AI-generated reports, so each engagement deliverable looks as polished as the underlying work.

GDPR alongside ISO 27001, SOC 2, NIS2, DORA, and HIPAA

GDPR sits next to, not on top of, the security frameworks most organisations already operate. Annex A of ISO 27001 provides the operational vocabulary for Article 32 controls. SOC 2 Trust Services Criteria around security, availability, and confidentiality are direct evidence for Article 32 obligations. NIS2 Article 21 measures and DORA ICT risk management overlap heavily with Article 32 for in-scope EU entities, and the breach notification timelines need to be reconciled (24-hour, 72-hour, one-month under NIS2; 72-hour under GDPR; both with their own thresholds). For US health entities, HIPAA Security Rule risk analysis methodology gives an evidenced approach the GDPR risk assessment can borrow directly. Healthcare and life sciences organisations carrying both EU and US exposure commonly consolidate the underlying control set under the HITRUST CSF, which inherits requirements from GDPR Article 32 alongside HIPAA, ISO 27001, and PCI DSS on a single requirement set. Where personal data is processed in a public cloud on behalf of customers, the ISO 27018 framework page covers the public cloud PII processor obligations that map closely to the Article 28 and Article 32 clauses GDPR places on processors, and that many cloud providers publish attestations against. For controllers and processors building a certifiable privacy management system on top of an ISO 27001 ISMS, the ISO 27701 framework page covers the PIMS extension whose Annex D supplies the official cross-walk to GDPR Articles 5 to 49, and which is the most direct way to evidence the technical and organisational measures GDPR Articles 25, 28, 30, 32, 33, 34, and 35 require.

Evidence the supervisory authority (and your DPO) actually want

Programmes that fail review usually fail because the artefacts are scattered across drives, ticket systems, and screenshots, with no clear line from a processing activity to the controls protecting it. Build the evidence pack as the work happens, retain raw scanner output and test reports alongside the summary, and tie every artefact back to the processing activity, the asset, an Article 32 obligation, and an owner. The supervisor narrative writes itself when the underlying record is consistent.

Where SecPortal fits in the GDPR workflow

SecPortal is the operating layer for the security side of the GDPR programme, not a replacement for the Data Protection Officer, the supervisory authority, or the privacy function. The platform handles scope, scans, findings, control mapping, breach records, engagement evidence, and the report output, so the Article 32 work runs as a structured workflow rather than a long email thread.

GDPR is a multi-year programme, not a one-off project. The first year of compliance focuses on the ROPA, the lawful basis review, the DPIA backlog, the Article 32 baseline, and the breach playbook. Subsequent years tighten the supplier register, deepen the testing programme, and integrate the privacy and security functions so the DPO and the security lead read from the same record. Running the work as a managed workflow pays off most over time: historical findings, classified breaches, processor records, and remediation timelines stay linked, so each supervisory engagement is a refresh rather than a rebuild.

For programmes that want continuous detection and trend evidence between manual tests, the continuous monitoring capability and external scanning capability produce the cadence and coverage record GDPR Article 32 testing programmes are expected to keep.