Overseeing and challenging the programme¶
What you'll be able to do in this chapter
- Know what the board must formally approve, and what 'oversee' means in practice.
- Ask a CISO the questions that reveal the true state of the programme.
- Recognise and avoid approving without real scrutiny.
- Understand the board's distinct role in a cyber crisis, including cross-border decisions.
Approval is not the same as oversight¶
Scaldimet's board reaches the cyber item again. The CISO presents a security programme and asks the board to approve it. The papers are thick, the language is confident, and the meeting is running late. A director proposes: "It looks thorough (shall we approve and move on)?" The directors hesitate.
This illustrates the difference between formal approval and effective oversight. Approving a programme you have not tested is approval in name only (rubber-stamping): and under Article 20 it is the board's own accountability that is at stake, not the CISO's. Approval that follows real scrutiny discharges the board's duty and genuinely protects the organisation. Approval that is merely a signature does neither; it just creates a record that the board was shown the problem and approved it without sufficient scrutiny. This final Lesson is about doing oversight properly: approving the right things for the right reasons, resourcing them realistically, challenging well, and knowing the board's distinct role when an incident actually hits.
What the board must actually approve¶
Chapter 6.1 established that the board must approve the organisation's cybersecurity risk-management measures. What are those measures? NIS2's Article 21 sets out the categories every in-scope entity must address (and while the board does not design them, it should recognise the shape of what it is approving).
Technical explainer (read & discuss, don't build): the Article 21 measures
NIS2 Article 21 requires in-scope entities to take appropriate measures across a defined set of areas. In plain terms, the board should expect the programme it approves to cover, at least:
- Risk analysis and information-security policy: knowing your risks and setting the rules that govern them. Everything else builds on this.
- Incident handling: detecting, responding to and recovering from incidents.
- Business continuity: the plan for keeping the business running, or restoring it fast enough to survive, when a serious incident hits. Backup and disaster recovery are one part of it, not the whole.
- Supply-chain security: assessing and addressing the risk that suppliers and service providers bring to you (the security of the relationship, not responsibility for their internal security).
- Security in acquiring, developing and maintaining systems, including handling vulnerabilities.
- Policies to test whether the measures actually work.
- Basic cyber hygiene and training.
- Cryptography, and where appropriate encryption.
- Access control, asset management, and staff security.
- Multi-factor authentication and secured communications, including the means to communicate securely during an incident.
The board's job is not to engineer these. It is to confirm the programme credibly addresses each area, is proportionate to Scaldimet's risk, and is properly resourced (and to notice if a whole area is missing).
When the CISO's programme arrives, the board's approval should be conditional on having checked that it covers this ground, fits the risk appetite set in Chapter 6.2, and can actually be delivered with the people and money available. Which leads to the duty boards most often overlook.
Resourcing: the duty hidden inside "approve"¶
A board can approve a flawless plan and still fail, if it approves the plan without the resources to deliver it. Approving an ambitious programme without the resources to deliver it creates a documented gap between the decision and the expected outcome.
So a real part of the board's job is the practical resourcing question: does the CISO have what this plan requires? At Scaldimet this is acute. The French site has three IT staff and ageing systems; the company has never funded a security function at all. A board that approves "segment the French network and bring the OT under management" without funding it has approved the objective without providing the resources needed to achieve it. Realistic resourcing is inseparable from proper approval: and a CISO who is given the duty but not the means should say so to the board, on the record.
The questions that reveal the truth¶
Oversight depends on the quality of the board's questions. Good questions are not technical; they are the questions that expose whether a programme is real. A board should keep a short list of questions and use it on every cyber report:
- "So what, to the business?" (the test from Chapter 6.2, applied to everything).
- "Against our stated appetite, is this inside or outside tolerance (and who judged that)?"
- "What are you NOT doing, and what risk are we therefore accepting by omission?" (the most revealing question of all); every programme leaves things untreated, and the board should know what, deliberately.
- "If our largest customer audited us tomorrow, where would we fail?"
- "What would you do first with more resources (and what does that tell us about where we are most exposed)?"
- "When were we last tested (and what did it find)?" (until the programme has been tested, its effectiveness remains unverified).
A CISO who can answer these crisply is running a real programme. A CISO who avoids answering them is showing the board exactly where to look harder. Either way, the questions do the board's work.
The board in a crisis: decisions only you can make¶
Most of cybersecurity is the CISO's to run. Some incident decisions may require board involvement, depending on the organisation's delegated authorities and crisis-governance arrangements. A board that has never thought about them in advance will make them badly, under pressure, at the worst possible moment.
When ransomware stops a Scaldimet line, the technical response belongs to the CISO and the responders. But several decisions sit above them:
- Whether to pay a ransom. This is a business, legal and ethical decision with no purely technical answer (it belongs to the board, ideally against a position thought through before the crisis, not invented during it).
- What to disclose, to whom, and when: customers, the market, the public. Reputation and legal exposure ride on this.
- Authorising regulatory notification. NIS2 requires serious incidents to be reported to the authorities on tight deadlines (the Compliance Module covers the mechanics). The board must ensure this happens and happens on time (a missed notification is its own breach, stacked on top of the incident).
Scaldimet's cross-border complication
Scaldimet operates in Belgium (Site Alpha, headquarters) and France (Site Beta). A serious incident at the French site may engage two national authorities under two national transpositions of NIS2, with their own contacts and deadlines. This should be established before an incident occurs. The board should have satisfied itself, in calm conditions, that the CISO knows which authorities must be told, in which countries, within what deadlines (and that someone is empowered to authorise those notifications immediately when minutes matter). A board that asks this question once, in advance, has done more for Scaldimet's resilience than any signature on a thick programme document.
Application: three challenge questions for the first board pack¶
The CISO's very first board pack is in front of you. It proposes a security programme, shows a mostly-green heat map, and requests approval and a budget. Write down three challenge questions you would ask before approving (chosen to test whether this programme is real and deserves the board's signature). Decide before the debrief.
A strong set:
- "What are you deliberately not doing in this plan, and what risk are we accepting by leaving it out?" (surfaces the untreated risks a tidy plan hides, and turns silent omissions into conscious board decisions).
- "Is the budget you're requesting actually enough to deliver what we'd be approving (and if not, what would we be signing off that can't be done)?" (connects approval with realistic resourcing, and protects the board from approving a plan it knows to be underfunded).
- "If a serious incident hit the French site next week, who decides on ransom, disclosure and regulatory notification (and in which countries)?" (tests crisis-readiness and the cross-border question before it is urgent).
Each question protects the board precisely because it makes an important issue explicit: the omissions, the resourcing gap, the crisis decisions. Those questions turn formal approval into substantive oversight.
Key takeaway
Oversight is more than approving a programme. The board should ensure that the programme addresses the relevant NIS2 requirements, reflects the organisation's risk appetite and is adequately resourced. Its role is to ask questions and challenge the basis for important decisions, including ‘what are we deliberately not doing?’ and ‘so what, to the business?’.
During a serious incident, some decisions may require board involvement, depending on the organisation's governance and delegated authorities. For Scaldimet, the cross-border reporting arrangements should therefore be established before an incident occurs. NIS2 makes management-body oversight a legal responsibility, with the precise consequences governed by the applicable national law.