Skip to content

BusinessPractitioner

7. Executive committee toolkit

For: team managers · executives and CIOsPrerequisites: Have read lessons 1 to 6 of the course.

Reading mode

This final lesson brings together the tools to move from analysis to decision: convince, respond, practice.

Five slides, ten minutes, one decision requested. Each slide has a set title, a figure and an instruction.

SlideTitleFigure to displayInstruction
1. The problemthe cost of incidents over twelve months€ and hours lost, with a low and high rangein CFO language, no jargon; the figure fits on one line
2. The solutionthe target architectureinvestment and annual costa simple diagram, three components at most, the phase 1 scope
3. The returngains and costs over three yearsgains to costs ratio, payback period in monthsone chart, two figures; assumptions in the appendix, for questions
4. Compliancethe measures you can demonstrateNIS2 measures demonstrable out of tenregulatory exposure presented as a risk, not as a gain
5. The askbudget, team, timelinephase 1 budget, headcounta clear decision: yes, no, or yes with conditions, with the date of the next review

Start with a three-month phase 1 with a checkpoint before committing to the rest: a committee is more willing to approve a first step than an entire program.

For each one: a direct answer, the figure to prepare from your own data, and a follow-up that brings the discussion back to the decision. Do not recite: before the committee, identify the two or three most likely objections given who will be in the room.

1. “We already have a tool, why change?” It is not necessarily about changing tools, but about getting more out of the one you have and keeping its cost under control. Figure to prepare: actual license usage (modules enabled, active users, data never looked at). Follow-up: would you agree to a two-week usage audit before the next renewal?

2. “This year’s budget is locked.” The project can start at constant budget by removing redundant tools; additional budget only comes in once the first gains have been observed. Figure to prepare: the annual cost of the redundant tools you have identified. Follow-up: can we launch the rationalization now and decide on the rest in the fall?

3. “We are too small for NIS2.” Scope depends on sector and size. The directive generally targets medium and large companies in the listed sectors. A company outside the scope may also have the same measures imposed on it by its customers, as part of the security of their supply chain. Figure to prepare: your written qualification from the legal team, and the list of customers already asking you for these measures. In France, ANSSI estimates that about 15,000 entities will be covered. Follow-up: have we asked our main customers to state their requirements in writing?

4. “This is a technical matter, not an executive committee matter.” Its consequences are financial and regulatory, and NIS2 makes management bodies responsible for overseeing cybersecurity measures. Figure to prepare: the cost of one hour of downtime on your main system. Follow-up: can we say, this morning, how much one hour of downtime on that system costs us?

5. “Let’s wait and see what our competitors do.” Waiting has an invisible cost: every month brings exposure to an incident detected late and to a customer requirement not met. Figure to prepare: the average monthly cost of your incidents. Follow-up: would you postpone by a year a project whose payback period is a few months?

6. “We’ll look at it after the cloud migration.” The migration is precisely when observability becomes essential: without instrumentation defined beforehand, you recreate the same blind spots, and you cannot even compare before and after. Figure to prepare: your current service levels, measured, which will serve as the baseline. Follow-up: can we make observability a prerequisite in the migration’s requirements?

7. “Not one more tool, we already have too many.” The goal is to remove some: unified collection replaces several specialized tools and cuts down on switching between consoles. Figure to prepare: the inventory of your monitoring tools and their cost. Follow-up: can we do that inventory before deciding?

8. “The team doesn’t have the skills.” Skills are built during implementation; the alternative is a lasting dependence on a service provider. Figure to prepare: the cost of an internal training plan compared with that of managed services over three to five years, based on real quotes. Follow-up: would you rather invest once in skills, or pay every year to do without them?

9. “If we do it, it has to work everywhere, right away.” A big-bang rollout piles up the risks and pushes back the first results. A phase 1 on a critical scope, then extended step by step, delivers measurable results within a few months. Figure to prepare: the phase 1 scope and the gains you expect from it. Follow-up: can we start with one critical domain and decide on the extension when we review phase 1?

10. “Why not wait for AI to automate everything?” AIOps only works on clean, consistent and labeled signals: observability is its prerequisite. Figure to prepare: current coverage of your critical services and the consistency of their tags. Follow-up: can we treat observability as the foundation of our AI strategy?

Sixty questions for your executive committee

Section titled “Sixty questions for your executive committee”

These are the questions a CIO should be able to ask their leadership, or answer without notes. Reread them every quarter: those whose answer has changed, or no longer holds up, signal drift more reliably than a dashboard.

  1. What share of revenue does our IT budget represent? Compare with a recent industry study, and cite it.
  2. How much does one hour of downtime on our main system cost? In lost margin, with the CFO. If there is no answer, that is already a conclusion.
  3. What share of the observability budget goes to licenses, and what share to the people who run it? Very heavy license costs can signal tools that are paid for but not used.
  4. What is the measured return on our last major IT project? “Not measured” is acceptable once, not twice.
  5. How many monitoring tools are we paying for? Draw up the complete list: duplicates show up quickly.
  6. What is the trajectory of license spending over three years? Check the indexation clauses in the contracts.
  7. How much do useless alerts cost us? Hours lost multiplied by fully loaded cost; the alert fatigue simulator does the math.
  8. How dependent are we on our main vendor? If a large share of the tooling budget goes to a single supplier, write a reversibility plan.
  9. Have we put a figure on the value of incidents avoided? It is the figure that is always missing, and the one that shifts the conversation from cost to value.
  10. What is the ratio between time spent on reliability and time spent on development? Reliability time often saves development time lost to incidents.
  11. What share of the budget goes to maintenance, and what share to transformation? Track the trend year over year.
  12. What would we do if our main supplier raised its prices by 30%? An answer to prepare in advance, not to improvise.
  1. What is our target observability architecture three years out? A one-page diagram, decided in committee, not by a single person.
  2. Are we dependent on a single vendor? Identify the contractual and technical lock-ins.
  3. Does our monitoring data leave the European Union? Map flows and locations, document the legal basis.
  4. Do we have a reversibility plan for each major solution? Written, dated, tested at least once.
  5. How do we version our observability configurations? If they live only in user interfaces, they are fragile.
  6. What share of our instrumentation uses OpenTelemetry? That is your reversibility indicator.
  7. Would we know if the observability platform itself went down? Monitoring of the monitoring is often missing.
  8. Do we correlate metrics, logs and traces? One tool per signal, with no link between them, slows down every diagnosis.
  9. Do we observe industrial IT? For manufacturers, convergence with OT brings its own protocols (Modbus, OPC UA, MQTT).
  10. Does every critical application have documented SLOs? An unwritten SLO is a hope.
  11. How long does it take to instrument a new application? Measure it; it is an indicator of platform maturity.
  12. Can the observability platform handle a large traffic spike? Load test it: it has to hold up during the incident it is observing.
  1. Are we an essential entity, an important entity, or outside the scope of NIS2? A written qualification, dated, signed off by legal.
  2. How many of the ten measures in Article 21 can be demonstrated with evidence? The self-assessment distinguishes “in place” from “demonstrable.”
  3. When did we last test our business continuity plan? Continuity is one of the Article 21 measures; a plan that has never been tested proves nothing.
  4. Could we issue an early warning within 24 hours? With a prefilled template, tested in a simulation.
  5. Are we covered by DORA, directly or as a provider to the financial sector? Check the clauses in your customer contracts.
  6. Have we inventoried our AI systems and their risk level? High-risk systems under Annex III of the AI Act become subject to their obligations on 2 December 2027; the inventory needs to happen now.
  7. Does the Cyber Resilience Act apply to us? If we place digital products on the market, reporting of actively exploited vulnerabilities has applied since 11 September 2026.
  8. Are our audit logs immutable, and is their retention period justified? Immutability that can be demonstrated, not just claimed.
  9. Can our CISO report independently of the IT department? A question of reporting line and independence, for leadership to decide.
  10. Do our supplier contracts include security requirements? Supply chain security is part of Article 21.
  11. What does our cyber insurer ask of us? Its questionnaires often focus on detection and logging.
  12. Has leadership taken the training NIS2 requires of it, and how does it oversee the measures? That is Article 20.
  1. How many reliability engineers do we have relative to our developers? A ratio that is too low turns SREs into firefighters.
  2. Is our on-call rotation properly sized? Compare with the benchmarks in lesson 5.
  3. What is the turnover rate in our SRE and security roles? A high rate signals a management or pay problem.
  4. Do we have a continuing education plan that is costed and tracked?
  5. Who is accountable, in the RACI sense, for the availability of our main application? One person, not a team.
  6. Is our on-call compensated, and are hours outside working time measured? It is a legal obligation in France as much as a management issue.
  7. Do we have a blameless post-mortem charter, written down and applied?
  8. How many major projects is our observability team running in parallel? Beyond two or three, everything takes longer.
  9. Who decides to switch to degraded mode during an incident? A designated role, not an improvised escalation.
  10. Do we have a skills matrix, reviewed every year?
  11. Does our culture allow for mistakes? Ask the teams, not management.
  12. Do we have a regular ritual between the IT department and executive leadership? Monthly review, quarterly check-in, annual assessment.
  1. What are the three business indicators that depend directly on the information system? They must appear on the executive dashboard.
  2. Can we detect business drift in real time (orders, shopping carts, production)?
  3. Do our business units have a dashboard for their own area? Sharing creates alignment.
  4. Can we anticipate activity peaks and size capacity accordingly?
  5. How much time do we spend answering audit requests? If it is a lot, the evidence is not being produced continuously.
  6. Have we identified the weak signals that precede our major incidents? See lesson 6.
  7. Does our observability cover the end user’s experience? Browser-side measurement, synthetic tests: without them, you see the infrastructure, not the customer.
  8. Can we attribute the cost of cloud and observability by business area?
  9. How do we compare with our industry? Rely on a sourced benchmark, or say that you do not have one.
  10. Do our business units know how long they can hold out without each critical system?
  11. Do we make technical debt visible? You cannot pay down a debt you do not measure.
  12. What would we do within two hours if our main system went down completely? Without a written and tested scenario, the honest answer is: we would improvise.

A thirty-minute exercise to test, under pressure, what the lessons have built.

TrackObjectiveLesson
Detectionfind the cause from metrics, logs and traces1, 6
Complianceprepare the early warning to the competent authority2
Governanceactivate the RACI and incident roles3
Communicationprepare the five-minute briefing for leadership7

Scoring grid (out of 15 points)

Criterion3 points2 points1 point
Time to detectunder 5 minutesunder 15 minutesover 15 minutes
Early warningcompleteincomplete on one pointnot prepared
RACI activationimmediatewithin 10 minuteslonger
Communication to leadershipproactiveon requestnone
Team coordinationsmoothadequateconfused

Above 12 points, the organization holds up in a crisis. Between 8 and 12, review the procedures. Below 8, targeted crisis management training is needed. Within thirty days: a workshop on roles and escalations, an update of the incident procedure with the notification steps, and a simulation every quarter.

In the training, each participant builds a strategic observability plan for their organization over the course of the lessons, then presents it in ten minutes.

StepLessonContent
1. Assessment3map the current state, place yourself on the maturity grid
2. Business case1cost of incidents, gains, ROI, payback period
3. Compliance2qualification, NIS2 self-assessment, priority actions
4. Roadmap3phases, RACI, quick wins, milestones at 3, 6 and 12 months
5. Steering6executive indicators, dashboard mockup
6. Pitch7five slides, peer feedback, thirty-day action plan