Preview · selected sections of Cybersecurity Governance Model v1.0
1. Purpose and scope
A cybersecurity governance model answers five questions in order, and it is only credible if it answers them in that order:
-
What must be governed, and which requirements — from every source — apply to it?
-
How well is it governed today, measured against something other than opinion?
-
Who decides what, on whose authority, and who is accountable for each outcome?
-
How are those decisions carried out, handed between parties and communicated?
-
How does the governing body know, from evidence, that all of this is working?
Most governance models fail on the third and fifth of these. They produce committees with terms of reference but no decision rights, so every decision drifts upward or nowhere; and they report a status someone chose rather than one the evidence supports, so the dashboard shows green until the incident. A third failure is quieter and more common still: the model cites procedures that do not exist, and nobody notices until an auditor asks for one. This method removes all three: every decision right sits with a named body or role that has the authority to exercise it, every interaction names the document that governs it, and every status reported upward is supported by the measures beneath it.
1.1 Scope
The method covers governance in the sense ISO/IEC 27014 uses the term: the system by which the organisation’s security activities are directed and controlled — the governing body evaluating, directing, monitoring and communicating — together with the ways executive management carries that direction into the work.
Governance is not management
The governing body sets direction, takes the decisions reserved to it, and holds management to account; management runs the function within that direction. A model that has the board approving firewall changes, or a CISO setting the organisation’s risk appetite alone, has confused the two. Keeping them distinct is the most important design discipline in this method.
The method uses the work of its two companion Practitioner Guides — Cybersecurity Strategy and Cybersecurity Operating Model — rather than repeating it. From the strategy it takes the themes, goals and strategic indicators. From the operating model it takes the service catalogue, the organisational units and the roles — the things that are governed and the parties who govern them. It does not cover control-by-control compliance testing, which uses the same consolidated requirements but is a separate discipline, nor the risk methodology, whose register it uses for key risk indicators.
1.2 Who does what
| Role | Responsibility in this method |
|---|---|
| Governing body board or its delegated committee |
Approves the governance charter, the reserved decisions, the delegation of authority and the risk appetite. Receives performance and assurance reporting. |
| Executive sponsor typically the CISO |
Owns the governance model. Approves the requirements baseline, the structures and the measures for submission. Chairs or sponsors the executive committee. |
| Governance lead the consultant or GRC lead |
Runs the assessment, maintains the requirements baseline and document register, and builds the RACI, interaction maps and communication plan. |
| Committee secretaries | Maintain committee charters, agendas, decision logs and action tracking — the evidence that the committees actually decide. |
| Department heads and service owners | Validate their RACI, interactions and procedures. Own the operational measures for their services. |
| Legal / company secretary | Validates the delegation of authority and the charter against the constitution and corporate instruments. |
| Finance | Supplies the financial delegation limits the security delegations inherit. |
| Human Resources | Supplies role definitions and workforce data for the workforce domain. |
| Internal audit | Provides independent assurance of the governance model and its operation. Consulted on design, never accountable for it. |
3. The method at a glance
The work runs in five phases. Each phase produces artefacts the next phase uses; nothing later in the sequence can be completed honestly without what comes before it.
The phases are not strictly serial in practice — the document inventory is usually collected while the maturity assessment runs, and RACI workshops surface missing procedures — but the dependencies are real. Decision rights cannot be assigned before the requirements are known. Interactions cannot be mapped before the service catalogue exists. Measures cannot be rolled up before the structure they report through is designed. A team that writes committee charters first and then looks for decisions for the committees to take has produced paperwork, not a governance model.
3.1 The governance model elements
The model is built from six elements that stack: each is only meaningful if the one beneath it exists. The portfolio of services and the measures of their performance sit at the top; the communication that keeps every party informed sits at the base.
3.2 The governance domains
Organise requirements, measures and maturity into four governance domains, derived from the ISO/IEC 27014 processes with a workforce dimension added — a governance model that ignores the people who must operate it is a set of instructions addressed to nobody.
| Domain | ISO/IEC 27014 process | What it covers |
|---|---|---|
| Establish | Evaluate | Mandate, charter, structures, risk appetite, policy framework, delegation of authority — the things that must exist before anything can be directed. |
| Direct and communicate | Direct · Communicate | Setting direction through strategy, policy and decisions; communicating to stakeholders, regulators and the workforce. |
| Evaluate, monitor and assure | Monitor | Performance measurement, compliance, internal and external assurance, management review. |
| Resilient workforce | — (added) | Roles, competence, accountability and culture; the governance of the people who run security. |
3.3 Working formats
Every artefact in this method can be produced with Word and PowerPoint. Anything with rows that will be cross-referenced is a Word table; anything that will be presented or needs to be seen as a whole is a PowerPoint slide.
| Kind of artefact | Suggested format | Tips |
|---|---|---|
| Registers (requirements, documents, delegations, measures) | Word table, one row per item | Give each row a simple sequence number so other tables can refer to it. |
| RACI matrices | Word table (landscape) | Processes down the side, bodies and roles across the top. |
| Structures and interaction maps | PowerPoint slide | Use the figures in this guide as the starting layout. |
| Charters and procedures | Word document from a fixed template | One template for every committee; one for every procedure. |
| Scorecards and dashboards | PowerPoint slide | Status colours with the rule used to set them stated on the slide. |
| Final document | Word | Section order in section 10; workshop slides go in the appendix. |
That is the preview. The full publication continues with 12 more sections — every phase summary, checklist, figure, quality check and appendix — available under licence.
Buy the full method