Governance Structures¶
What you'll be able to do in this chapter
- Design a security committee with a clear purpose, membership and cadence.
- Use a RACI to make a specific decision unambiguous.
- Assign named, accountable owners to Scaldimet's significant systems and risks.
A strategy, a mandate, and nothing happening¶
By now you have a strategy (2.1), a mandate and a defined role (2.2), and a policy architecture (2.3). And yet, three months on, very little has actually changed at Scaldimet. There is no forum where security decisions get made, no regular moment when owners answer for their systems, and for several systems still no clear owner at all. The direction exists, but not the machinery to run it. Governance structures are that machinery: the committees, the decision rules, and the ownership that turn intentions into decisions and decisions into action.
Committees: where governance actually happens¶
A governing body for security gives the programme a place to live. For a company Scaldimet's size it should be light, not bureaucratic, but it must exist. A workable security committee has four defined elements:
- Purpose. To oversee security risk against the strategy and appetite, make the decisions that are genuinely the committee's, and hold owners to account. Not to do technical work.
- Membership. Chaired by the CISO, attended by the system owners (Alpha IT manager, Beta operations director), and sponsored by a named executive sponsor, a member of the ExCo who owns the committee's mandate, carries its decisions upward, and breaks the deadlocks it cannot resolve on its own. A sponsor with sufficient authority gives the committee a clear route for resolving issues that it cannot decide itself.
- Cadence. A fixed rhythm (monthly or quarterly for Scaldimet), not "when something goes wrong". Regularity is what stops the programme drifting.
- Inputs and outputs. In: a short risk and progress report (Chapter 2.5). Out: recorded decisions, with owners and dates. A committee that meets but records no decisions is only for show.
The bodies the committee answers to¶
The committee does not sit at the top. Above it are two different bodies, and telling them apart matters for the rest of the course.
- The executive committee (ExCo) is the senior management that runs Scaldimet day to day: the CEO and their direct reports. It is where the CISO takes most decisions and does most reporting: budget, resourcing, and the risks that need an executive call. Its name varies by country and company (management committee, comité de direction, directiecomité).
- The board holds ultimate oversight and accountability. It does not run the company; it directs and challenges those who do, approves the things only it can approve, and answers for the whole. It sees a distilled view, less often.
NIS2 uses neither word. It speaks of the management body, deliberately, because corporate structures differ across Europe: single boards, two-tier boards with a separate supervisory board, and everything between. Depending on Scaldimet's structure and national law, the "management body" the law holds accountable maps to the board, to the executive, or to both. Module 6 addresses that body directly.
A convention used from here on
Throughout this course, executive committee (or ExCo) means the executive management the CISO works with day to day; the board means the body holding ultimate oversight and accountability; and where the law is meant, we use NIS2's own term, management body, which, depending on your country and structure, maps to the board, the executive, or both.
Its summary, and the decisions it could not make alone, go up to the ExCo and, distilled and less often, to the board. That upward, board-facing oversight is what Module 6 covers from the other side.
RACI: making a single decision unambiguous¶
Committees decide which things; RACI documents who. For any significant decision or task, name who is:
- Responsible: does the work.
- Accountable: answers for the outcome (exactly one, a single-holder role).
- Consulted: asked for input before the decision.
- Informed: told after.
Its value is the conversation it forces: people routinely discover that everyone assumed someone else was accountable. Take a live Scaldimet question, who decides whether the maintenance contractor keeps remote access to Site Beta?
| Role | Who |
|---|---|
| Responsible | The IT/OT staff who implement and monitor the access |
| Accountable | The Site Beta operations director (a single-holder role) |
| Consulted | The CISO (risk), the plant manager, the vendor |
| Informed | The ExCo, and the board at altitude, via the committee |
Before the RACI, the answer to "who decides?" was "no one, it just continues". After it, a named owner must consciously decide. Note that the accountable owner is a first-line owner, not the CISO: that is the boundary from Lesson 2.2.B, applied.
Ownership: a single accountable role, not a team¶
Assigning a named owner to each significant system is the move that everything else rests on (recall from Lesson 1.2 that ownership is the basis for accountability). An owner is senior enough to be accountable and close enough to understand the system; they do not do the security work, but they answer for the system and its decisions and budget.
But how you name the owner matters, and there are three ways to do it, only two of which work:
- A team ("the OT team owns it") cannot be held accountable: when everyone answers, no one does. Never give accountability to a group.
- A role ("the Beta operations director") is usually the best choice. Accountability attaches to the post, so it survives the holder leaving as the successor inherits it and the document remains valid. This works only if the role has exactly one holder at a time ("an IT engineer" is as diffuse as a team), and if someone keeps a current record of who holds each role.
- A named individual ("J. Dupont") is right only for a point-in-time act that must capture who did something and when: signing a risk acceptance, being assigned an incident, owning one minuted decision. In a standing owner list it is the weakest option, because it becomes outdated when that person moves.
So the rule is not "name a person" but make sure accountability always has one clearly defined owner. For the systems and standing decisions in this Module, that owner is a single-holder role; a named individual with a date belongs on the point-in-time record, not the owner list. And resist making the CISO own everything (the CISO governs and oversees, the second line, while owners are the first line). That separation is deliberate.
One structural partner deserves an early mention, because the rest of the course leans on it: the security-architecture function. Where the committee decides and owners answer, this function is the design authority that turns governance's standards and risk's requirements into reusable, secure-by-default designs, so a standard is followed because the design makes it the default, not because people are reminded to. Most organisations Scaldimet's size have no dedicated security architect, and none is assumed here: the work is often done by the CISO, a senior engineer, or the GRC function itself, and what matters is that the deliverables exist and the design-authority work is performed, by whoever holds it. For now, note only that good architecture is one of the structures that makes governance operate, not a separate technical concern.
Scaldimet's structures, assembled
- Committee: a quarterly security committee, chaired by the CISO, with the Alpha IT manager, the Beta operations director and the operations executive; fed by the reporting pack from Chapter 2.5; minuted with decisions, owners and dates.
- Ownership: Alpha IT systems to the Alpha IT manager; Beta OT and SCADA to the Beta operations director; third-party access to the Beta operations director (CISO consulted); identity and access to the IT manager.
- RACI: applied to each real decision, with the accountable name always a first-line owner and the CISO consulted for the risk view.
None of this is technology. It is the structure that makes the strategy, mandate and policy from the previous chapters actually operate.
Application: design Scaldimet's governance structure¶
On paper, produce three things: (1) a one-paragraph terms of reference for Scaldimet's security committee (purpose, membership, cadence, inputs and outputs); (2) a RACI for one decision of your choice (for example, connecting Beta's network to the internet for vendor diagnostics); and (3) the owner list for Scaldimet's significant systems. Then check the structure against a single question: if a serious risk were found tomorrow, is there an owner (a single accountable role) to own it, a forum to decide on it, and an executive who can compel action? If yes, the machinery works.
Model answer (open after you've drafted yours)
Terms of reference (one paragraph). The Scaldimet Security Committee oversees security risk against the strategy and appetite, decides the matters that are the committee's to decide, and holds system owners to account. It is chaired by the CISO; attended by the Alpha IT manager and the Beta operations director; and sponsored by the operations executive as its executive sponsor. It meets quarterly. In: a short risk-and-progress pack (Chapter 2.5). Out: minuted decisions, each with an owner and a date.
RACI — connecting Beta's network to the internet for vendor diagnostics:
| Role | Who |
|---|---|
| Responsible | The IT/OT staff who would configure and monitor the link |
| Accountable | The Beta operations director (a single-holder role) |
| Consulted | The CISO (risk), the vendor, the Alpha IT manager |
| Informed | The ExCo, via the committee |
Owner list. Alpha IT / ERP / MES / IIoT → Alpha IT manager; Beta SCADA and OT → Beta operations director; third-party (contractor) access → Beta operations director, CISO consulted; identity and access → Alpha IT manager.
Check: a serious risk found tomorrow has an owner (a single accountable role, from the list), a forum (the quarterly committee), and an executive who can compel action (the sponsor). If all three exist, the machinery works.
Key takeaway
Direction without structures changes nothing. A light but real committee (clear purpose, the right membership including an executive, a fixed cadence, and recorded decisions) is where governance happens. RACI makes a single decision unambiguous, and its accountable name is a first-line owner, not the CISO. Ownership is assigned to a single accountable role, never to "the team", with the CISO governing rather than owning. Together, these structures turn strategy, mandate and policy into defined decisions and actions.
Next: Chapter 2.5 · KPIs, KRIs & Reporting to the executive and board →