Write the charter before you build the programme

Every other governance artefact a security programme produces — objectives, committee minutes, management reviews — assumes a charter already answered "what is in scope, who runs this, and who says so." Most programmes never write that document down; they accumulate the artefacts that assume it instead, in whatever order urgency demanded. Our security programme charter template is the fill-in-the-blanks version of the document that was supposed to come first.

It covers six things a charter has to state plainly:

• A mission and ISMS scope statement — which business units, systems, and data are explicitly in scope, stated with the same specificity ISO 27001 and NIST both expect, not left implicit.
• A statement of authority — who can require a control be implemented, and who can grant an exception.
• A starting RACI: one accountable name per governance area, as a worksheet to build a full Responsible/Consulted/Informed breakdown from — not a finished org chart pretending to be a charter.
• Committee terms of reference for each standing committee (a security steering committee, an incident review board), including a target date and review cadence.
• An objective format that ties each stated goal to an owner and a review date.
• The clause 9.3 management-review cycle — ISO/IEC 27001's requirement that top management review the ISMS at planned intervals, laid out as a repeatable cycle rather than a once-a-year scramble before an audit.

If you're building this out for the first time — or formalising a programme that has been running on habit rather than a written mandate — the template is free to read online, and the GRC persona page covers what CMDash does for the rest of the programme once the charter is signed.