The security obligations inside privacy law, and the point where a privacy regulator starts asking a security question. This domain usually reaches the security team through the data protection office.
What we track
GDPR and UK GDPR security duties
EU and UK. Article 32 measures, breach notification, and how supervisory authorities are reading both in practice.
EDPB guidance and opinions
EU. Processor security obligations, anonymisation, web scraping, and binding corporate rules approvals.
International transfers
EU and UK. Transfer mechanisms, and the security conditions attached to keeping them valid.
Singapore PDPA
Singapore. Protection and breach notification obligations for organisations operating in the region.
US state privacy laws
US. The security and breach duties added state by state, and where they diverge from each other.
Sector overlays
All jurisdictions. Health, financial and children’s data rules that impose more than the general regime does.
Who is in scope
Controllers and processors both, and the distinction decides which duties you owe. A controller decides why and how personal data is processed. A processor acts on instructions, under a narrower but real set of security and notification obligations under Article 28 and Article 32.
Territorial reach is wider than establishment. An organisation with no European presence is caught if it offers goods or services to people in the EU, or monitors their behaviour. That brings in a great many US and Asian companies who assumed otherwise.
Where the deadlines fall
Breach notification runs on a 72 hour clock to the supervisory authority from awareness, with communication to affected individuals required without undue delay where the risk is high. Those are the only hard clocks in this domain, and they are the ones that get missed.
Everything else is cyclical: transfer mechanism reviews, records of processing updates, and the reassessment that follows new guidance. Guidance is the moving part here, and a settled position from the EDPB can change what adequate means without any change in the law itself.
Where organisations get caught
Processor obligations. After a supply chain breach the question moves quickly from what your provider did to what you specified, verified and documented. The contract you signed becomes evidence about your own diligence, and a data processing agreement that was signed unread is worse than useless at that point.
Parallel notifications. A breach notification and an incident notification under NIS2 can describe the same event to different regulators on different clocks and different thresholds. Inconsistency between the two is its own finding.
Security as a legal standard. Article 32 asks for measures appropriate to the risk, taking account of the state of the art and the cost of implementation. That is a proportionality test decided after the fact by someone reading your risk assessment, which makes the assessment itself the artefact to spend time on.
Questions worth asking now
- Where are we a controller and where are we a processor, and is that documented per processing activity?
- Could we notify a supervisory authority inside 72 hours, using a form we have seen before?
- Which of our processors hold the most sensitive data, and when did we last verify anything they told us?
- Does our breach process reconcile with our NIS2 or DORA process, or do they run separately?
- When did we last update the risk assessment behind our Article 32 measures?
- Which transfers rely on which mechanism, and who reviews them?
Related domains
Incident reporting covers the parallel clocks. Third-party and supply chain risk covers processor assurance. AI governance covers training data and the lawful basis questions attached to it.