A DPO documents technical and organisational measures at system launch but never revisits them after a major architecture change that expands personal-data processing. What does GDPR-aligned security require?
Select an answer to reveal the explanation.
Short Explanation
Security measures aren't a graduation photo you hang and forget. When the system grows or morphs, the locks and processes have to keep up. Document once, then revisit when the risk picture changes—that's how TOMs stay 'appropriate.'
Full Explanation
Appropriate technical and organisational measures are risk-based and must remain suitable as processing evolves. When a major architecture change expands personal-data processing, TOMs documented at launch should be reviewed and updated so Article 32 expectations continue to be met. Security appropriateness is dynamic: new integrations, broader datasets, and changed user populations alter both threats and required controls. A DPO who never revisits measures after such change leaves the organisation defending yesterday’s risk picture.
Treating TOMs as a one-time binder exercise ignores expanded attack surface and data flows. Updating only encryption algorithms while freezing organisational measures is incomplete—roles, access reviews, training, and vendor oversight often shift with architecture. Supervisory authorities do not forbid revising documented TOMs after a first DPIA; accountability expects living controls aligned to current processing.
Exam caveat: launch documentation is a floor for history, not a permanent ceiling for compliance. Operational check: define change triggers (new processors, new data categories, major cloud moves), reassess TOMs, update records of processing and security annexes, and retest logging and access control. Public-sector platforms owe residents an updated security posture when city systems grow—not a framed certificate from go-live day left unchanged while the architecture quietly doubles in risk.