Security standards & governance
Your standards are years out of date, nobody follows them, and an upcoming audit or regulation is about to make that visible.
Security standards fail for one of two reasons. Either they are written for the auditor and ignored by delivery, or they are written by engineers and cannot be evidenced when the regulator asks. The work is producing a set that does both.
The engagement pattern
Start from what is actually being built. Standards written in isolation from current delivery describe a firm that does not exist.
Engage stakeholders deliberately and widely. I have run a full standards overhaul involving more than fifty stakeholders across risk, audit, legal and technology. The point of that effort is adoption after I have gone.
Map once, report many times. NIST CSF v2, DORA and ISO 27001 overlap heavily. Structuring the control set so a single piece of evidence satisfies several obligations is what separates a sustainable programme from a permanent reporting burden.
Regulatory context
Most of my work has been in financial services, where DORA and the FCA’s operational resilience expectations set the pace. The same patterns apply in any sector where an external body can compel you to demonstrate your controls rather than describe them.