Cybersecurity Briefings
Short, practical notes on cyber risk, regulation and assurance for boards and senior leaders.
A NIS2 Programme Should Leave an Operating Model Behind
When a NIS2 programme closes, the steering committee stands down and the programme team disperses. The regulatory obligations continue: controls require ongoing evidencing, risk assessments require refresh, the incident notification capability requires testing, and the management body requires compliance reporting. These functions must be designed, owned and handed over before the programme closes.
What Boards Should Expect from Cybersecurity Reporting
Cybersecurity reporting that reaches most boards was built for a security operations function. Vulnerability counts, patch rates and phishing results measure what the security team has done. A governing body needs different answers: what the material risks are, what exposure remains after controls are applied, and where the board is required to make a decision.
ISO 27001 Certification and NIS2 Supervisory Scrutiny
ISO 27001 certification demonstrates that a management system was in place and conformed to the standard at the point of audit. NIS2 supervisory scrutiny asks a different set of questions: whether specific obligations under the directive are met at the time of inspection, including management body accountability, incident notification readiness and supply chain security in the form the directive requires.
Scoping a NIS2 Programme
A programme scoped too broadly cannot be delivered in time. One scoped too narrowly produces gaps that surface during supervisory inspection rather than during the programme. Both result from the same mistake: treating regulatory scope as programme scope rather than as its starting point.
NIS2 Is Not One Rulebook Across Europe
NIS2 is a European directive, not a regulation. Unlike a regulation, it does not apply identically across all EU Member States. Each Member State must enact its own implementing legislation, and the details matter: scope, supervision, evidence expectations and enforcement can differ materially between jurisdictions.
ISO 42001 Certification and EU AI Act Obligations
ISO 42001 provides a framework for managing AI risk through a documented management system. The EU AI Act imposes specific obligations on organisations that develop or deploy high-risk AI systems: conformity assessment before deployment, system-level transparency requirements and registration. These are product and deployment obligations.
The CRA Makes EU Market Access Conditional on Product Cybersecurity
The Cyber Resilience Act establishes mandatory cybersecurity requirements for products with digital elements sold in the EU. Products that do not meet those requirements cannot carry the CE marking and cannot be placed on the EU market. The compliance question is a market access question.
NIS2 Makes Cybersecurity a Leadership Duty
NIS2 does not only impose obligations on the security function. Article 20 places specific requirements on the management body: to approve the cybersecurity risk management measures the organisation adopts, to oversee their implementation, and to follow cybersecurity training. These obligations sit with senior leaders directly and cannot be discharged by the CISO or delegated to a technical team.
When a Fractional CISO Is the Right Appointment
Boards approach the CISO appointment as a headcount question. The prior question is what governance structure cybersecurity leadership requires, and whether a permanent appointment is proportionate to the organisation's scale, risk profile and current circumstance.
Zero Trust and Cloud Security Assurance
Boards approve cloud migrations. They rarely approve the access model that governs who can reach critical workloads once the migration is complete. Zero Trust is the architectural principle that makes that governance question explicit.