Security Program Charter Template fourteen sections for mandate, authority, scope, decision rights, governance, sign-off, and amendment triggers
A free, copy-ready security program charter template. Fourteen structured sections covering document control and version history, executive summary in plain language, mission and purpose, programme scope (in-scope, out-of-scope, shared-responsibility), operating principles, authority and decision rights with three named decision tiers, governance structure (steering committee, escalation path, advisory roles), organisational structure and reporting lines, roles and responsibilities with named role definitions, programme outcomes and capability commitments, resourcing and capacity and budget posture, programme cadence layered across annual and quarterly and monthly and event-driven and audit-cycle rhythms, programme dependencies and interfaces, and sign-off and amendment and version-control discipline. Aligned with ISO/IEC 27001 Clause 5.1 and 5.2, SOC 2 CC1.1 and CC1.5, NIST CSF 2.0 GV.OC and GV.RR, NIST SP 800-53 PM-1, PCI DSS Requirement 12.1, NIS2 Article 20, DORA Article 5, and HIPAA 164.308(a)(2).
Carry the charter on the live workspace record, not on a static document drive
SecPortal pairs the signed charter to a programme engagement record so the sponsor sign-off, the steering committee acknowledgement, the annual review, and the amendment history all live on one workspace with named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Fourteen sections that give the security programme its mandate, authority, and scope
A security programme charter is the constitutive document that names the programme, defines its mandate, authority, scope, principles, and operating boundary, and is signed by an executive sponsor who can commit budget and override organisational priorities when security work demands it. It is not the security policy that codifies what the organisation expects users and engineers to do, and it is not the security strategy that names what the programme will pursue over the next two or three years. The charter is the founding artefact every other security document reads against, and the audit-ready evidence that the security organisation was authorised to act.
The fourteen sections below cover the durable shape of a charter against ISO/IEC 27001 Clause 5.1 (leadership and commitment) and Clause 5.2 (information security policy), SOC 2 CC1.1 (commitment to integrity and ethical values) and CC1.5 (accountability for control responsibilities), NIST CSF 2.0 GV.OC (organisational context) and GV.RR (roles, responsibilities, and authorities), NIST SP 800-53 PM-1 (information security programme plan), PCI DSS Requirement 12.1 (information security policy), NIS2 Article 20 (governance), DORA Article 5 (ICT risk management framework), and HIPAA 164.308(a)(2) (assigned security responsibility). Pair the charter with the security programme quarterly review template for the cadence the chartered governance runs on, the risk register template for the chartered risk acceptance discipline, and the security KPI dashboard template for the measurement of the chartered outcomes. Copy the section that fits your stage and paste the rest as you grow the programme into the shape it needs.
Copy the full charter template (all fourteen sections) as one block.
1. Document control and version history
Open the charter with the boundary, the version, and the authority. A reviewer should be able to read in the first lines which organisation the charter belongs to, when it was signed, who signed it, and how the current version connects to its predecessors. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the document control header makes the charter traceable across review cycles rather than a loose collection of paragraphs.
Document title: Information Security Programme Charter
Organisation: {{ORGANISATION_LEGAL_NAME}}
Programme name (the name the rest of the organisation refers to the security organisation by): {{PROGRAMME_NAME}}
Document identifier (used for cross-references from policies, standards, and operating procedures): {{DOCUMENT_IDENTIFIER}}
Current version: {{CURRENT_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled annual review date: {{NEXT_ANNUAL_REVIEW_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}
Custodian (the role that maintains the document between sign-offs):
- Role: {{CUSTODIAN_ROLE}}
- Named person at time of publication: {{CUSTODIAN_NAME}}
Version history (each row carries: version, effective date, summary of change, revision trigger, sign-off references):
- v1.0 {{V1_EFFECTIVE_DATE}}: Initial charter sponsored by {{V1_SPONSOR_NAME}}. Trigger: programme founding. Sign-off references: {{V1_SIGN_OFF_REFERENCES}}.
- v{{VN_VERSION}} {{VN_EFFECTIVE_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}. Sign-off references: {{VN_SIGN_OFF_REFERENCES}}.
Revision trigger that produced this version (one of: scheduled annual review, material estate change, sponsor change, regulatory environment change, threat environment reset, structural reorganisation, audit or regulator finding naming the charter as root cause):
- {{CURRENT_REVISION_TRIGGER}}
Related programme artefacts (the documents that derive their authority from this charter):
- Information security policy (top-level): {{INFOSEC_POLICY_REFERENCE}}
- Vulnerability management policy: {{VM_POLICY_REFERENCE}}
- Audit evidence retention policy: {{AUDIT_EVIDENCE_RETENTION_REFERENCE}}
- Data classification policy: {{DATA_CLASSIFICATION_REFERENCE}}
- Vulnerability disclosure policy: {{VULNERABILITY_DISCLOSURE_REFERENCE}}
- Risk management methodology: {{RISK_METHODOLOGY_REFERENCE}}
- Programme strategy document (the multi-year direction the charter authorises): {{PROGRAMME_STRATEGY_REFERENCE}}
Workspace pairing:
- The charter is held as a versioned document paired to a programme engagement record.
- The sign-off chain is recorded on the workspace activity log with named actor and timestamp.
- The custodian is identified in team management with the role gate applied to read and amend access.
2. Executive summary
The first page after document control summarises the programme in plain language. A board member or audit committee chair who has only ninety seconds should walk away with a clear understanding of why the security programme exists, who is accountable, what authority the programme carries, and what the organisation gets in return. The summary is the cover narrative; the supporting sections produce the structure the summary stands on.
Programme purpose paragraph (one paragraph, three to five sentences, plain language):
{{ORGANISATION_LEGAL_NAME}} operates a chartered information security programme that exists to {{PROGRAMME_PURPOSE_PARAGRAPH}}.
Sponsor and accountability paragraph:
The programme is sponsored by {{SPONSOR_ROLE}} ({{SPONSOR_NAMED_PERSON}}) and operated by {{ACCOUNTABLE_OPERATOR_ROLE}} ({{ACCOUNTABLE_OPERATOR_NAMED_PERSON}}). The sponsor accepts accountability to the executive committee and the {{GOVERNING_BODY}} for the programme outcomes named in this charter. The accountable operator runs the programme work day to day and reports on programme posture against the chartered cadence.
Authority and scope paragraph:
The programme carries the authority to {{TOP_LEVEL_AUTHORITY_STATEMENT}}, exercised through the three decision tiers named in Section 6. The chartered scope covers {{TOP_LEVEL_SCOPE_STATEMENT}} as named in Section 4, and explicitly excludes {{TOP_LEVEL_OUT_OF_SCOPE_STATEMENT}}.
Outcomes paragraph:
The programme commits to the {{NUMBER_OF_CHARTERED_OUTCOMES}} chartered outcomes named in Section 10, evidenced through the cadence in Section 12 and the audit cycles named in the audit and compliance posture work.
Acknowledgements:
- This charter supersedes prior charters or charter-equivalent documents listed in Appendix A.
- This charter does not codify operating procedures (held in the policy library), strategy commitments (held in the multi-year strategy document), or operating cadence outputs (held on the workspace engagement record).
- This charter is reviewed annually and amended on named-trigger basis between scheduled reviews.
3. Mission and purpose
The mission and purpose section names the durable why of the programme. It is the part of the charter that does not change quarter on quarter and produces the language the rest of the organisation uses to talk about security. Keep it specific to the business: a charter that mirrors a generic template paragraph is harder to defend at an audit committee than one that names the business model, the customer commitments, and the regulatory environment the programme operates inside.
Programme mission statement (one sentence, plain language, business-specific):
The information security programme exists to {{PROGRAMME_MISSION_STATEMENT}}.
Programme purpose (the durable reasons the programme exists, named explicitly):
1. {{PURPOSE_REASON_1}} (for example: protect customer-entrusted data against unauthorised access, modification, loss, or disclosure).
2. {{PURPOSE_REASON_2}} (for example: maintain the availability, integrity, and continuity of the products and services the organisation delivers).
3. {{PURPOSE_REASON_3}} (for example: meet regulatory and contractual obligations across the operating jurisdictions and customer segments).
4. {{PURPOSE_REASON_4}} (for example: protect the workforce against social engineering, account compromise, and insider risk).
5. {{PURPOSE_REASON_5}} (for example: preserve the organisation s reputation, market position, and stakeholder confidence in the face of a security event).
6. {{PURPOSE_REASON_6}} (for example: support the business in pursuing growth opportunities by demonstrating defensible security posture to customers, partners, regulators, and investors).
Programme audience (who the programme serves):
- Primary customers (paying customers, public users, regulated counterparts whose trust the programme protects): {{PRIMARY_CUSTOMERS}}.
- Secondary stakeholders (partners, investors, regulators, auditors, insurers, governments, lenders): {{SECONDARY_STAKEHOLDERS}}.
- Internal audience (the workforce the programme protects and partners with): {{INTERNAL_AUDIENCE}}.
Business model context the programme operates inside:
- Sector: {{SECTOR_NAME_AND_REGULATORY_PROFILE}}.
- Customer segment shape: {{CUSTOMER_SEGMENT_SHAPE}}.
- Operating geography: {{OPERATING_GEOGRAPHIES_AND_REGULATORY_OVERLAYS}}.
- Data sensitivity shape: {{DATA_SENSITIVITY_SHAPE_INCLUDING_REGULATED_DATA_CATEGORIES}}.
- Operating model: {{OPERATING_MODEL_DESCRIPTION_CLOUD_AND_HYBRID_AND_ON_PREMISE_SHAPE}}.
- Workforce profile: {{WORKFORCE_PROFILE_PERMANENT_AND_CONTRACTOR_AND_PARTNER_SHAPE}}.
Mission boundary (what the mission deliberately does not claim):
- The programme does not claim absolute prevention; the mission balances risk reduction with business agility.
- The programme does not claim to substitute for other functions accountable for related concerns (legal, finance, HR, privacy, fraud).
- The programme does not claim authority over business risk acceptance; risk acceptance lives with the chartered acceptance authority (Section 6).
4. Programme scope
The scope section is the part of the charter most often fails the audit read because it is written as aspirational language ("the programme covers all information assets") rather than as enforceable boundary. A defensible scope section names three lists: in-scope, out-of-scope, and shared-responsibility. Writing scope in three lists rather than as a paragraph forces the programme to name boundaries the audit can reconcile to, and makes the charter durable when the business adds an acquisition or spins off a unit.
Scope statement (one paragraph, names the chartered domain in plain language):
The programme covers {{TOP_LEVEL_SCOPE_DOMAIN}} across {{OPERATING_GEOGRAPHIES_NAMED}} for {{BUSINESS_UNITS_OR_TENANT_OR_PRODUCT_LINES_NAMED}}.
In-scope (the asset classes, business units, environments, and operating contexts the programme owns end-to-end):
- Asset class A: {{IN_SCOPE_ASSET_CLASS_A_AND_RATIONALE}}.
- Asset class B: {{IN_SCOPE_ASSET_CLASS_B_AND_RATIONALE}}.
- Asset class C: {{IN_SCOPE_ASSET_CLASS_C_AND_RATIONALE}}.
- Business unit or product line A: {{IN_SCOPE_BU_A_AND_RATIONALE}}.
- Business unit or product line B: {{IN_SCOPE_BU_B_AND_RATIONALE}}.
- Operating environment A (production, staging, build, integration): {{IN_SCOPE_ENV_A_AND_RATIONALE}}.
- Operating environment B: {{IN_SCOPE_ENV_B_AND_RATIONALE}}.
- Geography or jurisdiction A: {{IN_SCOPE_GEO_A_AND_RATIONALE}}.
- Workforce segment A (permanent staff, contractors, vendor staff, partner staff): {{IN_SCOPE_WORKFORCE_A_AND_RATIONALE}}.
Out-of-scope (the asset classes, business units, environments, and operating contexts the programme explicitly does not cover):
- Functional out-of-scope (security work owned by another function and the named function): {{FUNCTIONAL_OUT_OF_SCOPE_AND_NAMED_FUNCTIONS}}.
- Operating out-of-scope (security work the programme has decided not to perform and the reasoning): {{OPERATING_OUT_OF_SCOPE_AND_REASONING}}.
- Geographic out-of-scope (operating regions or entities outside the charter): {{GEOGRAPHIC_OUT_OF_SCOPE_AND_REASONING}}.
- Asset out-of-scope (research enclaves, isolated lab environments, joint ventures with separate security organisations): {{ASSET_OUT_OF_SCOPE_AND_REASONING}}.
- Workflow out-of-scope (work the programme does not perform end-to-end but supports as input): {{WORKFLOW_OUT_OF_SCOPE_AND_REASONING}}.
- Future out-of-scope (capabilities the programme has explicitly decided not to pursue in the chartered horizon): {{FUTURE_OUT_OF_SCOPE_AND_REASONING}}.
Shared-responsibility (the contexts where ownership is split with a named counterparty):
- Cloud-provider responsibility split: {{CLOUD_PROVIDER_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- SaaS-provider responsibility split: {{SAAS_PROVIDER_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Contractor-managed responsibility split: {{CONTRACTOR_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Customer-environment responsibility split (for product-side organisations): {{CUSTOMER_ENVIRONMENT_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Partner-integrated responsibility split: {{PARTNER_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Group, parent, or affiliate responsibility split: {{GROUP_SHARED_RESPONSIBILITY_DESCRIPTION}}.
Scope review cadence:
- Scope is reviewed at the annual charter review and on the named triggers in Section 12 (material estate change, acquisition, divestiture, new product line, new geography, regulatory environment change).
- A material estate change without a charter amendment is treated as a control finding the audit reads against the charter.
5. Operating principles
Operating principles state the durable values the programme uses to decide when no rule applies. They are not policies (which name what users and engineers do) and not procedures (which name how operators run the work). The principles are the lens the programme uses to defend a position, resolve an ambiguity, or shape a strategy commitment. Keep them small in number and specific to the organisation rather than generic.
Operating principles (each principle carries: name, statement, and one short example of how the principle resolves a real ambiguity):
Principle 1: {{PRINCIPLE_1_NAME}} (for example: Default to evidence)
- Statement: {{PRINCIPLE_1_STATEMENT}}.
- Example: {{PRINCIPLE_1_EXAMPLE}}.
Principle 2: {{PRINCIPLE_2_NAME}} (for example: Reduce blast radius before reducing likelihood)
- Statement: {{PRINCIPLE_2_STATEMENT}}.
- Example: {{PRINCIPLE_2_EXAMPLE}}.
Principle 3: {{PRINCIPLE_3_NAME}} (for example: Privilege durable controls over compensating workarounds)
- Statement: {{PRINCIPLE_3_STATEMENT}}.
- Example: {{PRINCIPLE_3_EXAMPLE}}.
Principle 4: {{PRINCIPLE_4_NAME}} (for example: Make security work visible on the operating record, not on a side spreadsheet)
- Statement: {{PRINCIPLE_4_STATEMENT}}.
- Example: {{PRINCIPLE_4_EXAMPLE}}.
Principle 5: {{PRINCIPLE_5_NAME}} (for example: Pair every chartered authority with a chartered accountability)
- Statement: {{PRINCIPLE_5_STATEMENT}}.
- Example: {{PRINCIPLE_5_EXAMPLE}}.
Principle 6: {{PRINCIPLE_6_NAME}} (for example: Treat exceptions as deferred risk, not as cleared risk)
- Statement: {{PRINCIPLE_6_STATEMENT}}.
- Example: {{PRINCIPLE_6_EXAMPLE}}.
Principle 7: {{PRINCIPLE_7_NAME}} (for example: Take the cheapest defensible position rather than the most fashionable one)
- Statement: {{PRINCIPLE_7_STATEMENT}}.
- Example: {{PRINCIPLE_7_EXAMPLE}}.
Principle reading discipline:
- Principles are not optional or aspirational. They are the lens used to defend a decision when no policy applies.
- A decision that contradicts a principle requires a named override on the workspace activity log with rationale, owner, and review date.
- Principles are reviewed at the annual charter review. Adding, removing, or reshaping a principle is a chartered amendment, not an operating change.
6. Authority and decision rights
The authority section converts the chartered mandate into observable decision rights. A defensible authority section names three tiers of decision authority so the operating record can reconcile decisions to the chartered authority. Without an explicit decision tier the authority section reads as posture rather than as enforceable rights, and the operating record cannot reconcile decisions to the charter.
Top-level authority statement (the chartered authority the programme carries):
The information security programme is authorised by {{AUTHORISING_BODY}} to {{TOP_LEVEL_AUTHORITY_STATEMENT}}. The authority is exercised through three decision tiers named below.
Tier 1: Programme decisions the accountable operator takes alone (named decision types):
- Operational security work including findings triage, prioritisation, scanner configuration, and queue management.
- Vulnerability acceptance below the documented risk band of {{TIER_1_RISK_BAND_CEILING}} subject to the exception register and review cadence.
- Third-party security review sign-off below {{TIER_1_THIRD_PARTY_SPEND_CEILING}}.
- Security testing scope changes within an approved engagement.
- Security incident classification below a Sev1 declaration.
- Operating decisions inside the chartered scope (Section 4) that do not change the scope or the chartered outcomes.
Tier 2: Programme decisions taken with a named co-decider (named decision types and named co-decider role):
- Vulnerability acceptance above the documented risk band of {{TIER_1_RISK_BAND_CEILING}} and up to {{TIER_2_RISK_BAND_CEILING}}: co-decider {{TIER_2_RISK_COODECIDER_ROLE}}.
- Third-party security review sign-off above {{TIER_1_THIRD_PARTY_SPEND_CEILING}} and up to {{TIER_2_THIRD_PARTY_SPEND_CEILING}}: co-decider {{TIER_2_THIRD_PARTY_COODECIDER_ROLE}}.
- Security tooling consolidation, replacement, or addition above {{TIER_2_TOOLING_SPEND_CEILING}}: co-decider {{TIER_2_TOOLING_COODECIDER_ROLE}}.
- Exception approvals beyond {{TIER_1_EXCEPTION_DURATION_CEILING}}: co-decider {{TIER_2_EXCEPTION_COODECIDER_ROLE}}.
- Sev1 incident declaration: co-decider {{TIER_2_SEV1_COODECIDER_ROLE}}.
- Material changes to security operating procedures that affect partner functions: co-decider {{TIER_2_PROCEDURE_COODECIDER_ROLE}}.
Tier 3: Programme decisions escalated to the executive sponsor or the steering committee (named decision types):
- Risk acceptance above the chartered ceiling of {{TIER_2_RISK_BAND_CEILING}}.
- Programme scope changes (addition or removal of in-scope categories, business units, or geographies).
- Capacity decisions that miss the chartered capability commitments (Section 10).
- Material control deficiencies the steering committee has to weigh against business risk.
- Sev0 or major-incident declaration and the resulting executive engagement.
- Charter amendment recommendations between annual review cycles.
- Strategy commitments outside the chartered scope.
Decision-rights observability discipline:
- Every Tier 1 decision is captured on the workspace activity log with named actor, timestamp, and rationale.
- Every Tier 2 decision is captured on the workspace activity log with both named actors and the chartered co-decider rule referenced.
- Every Tier 3 decision is captured as a steering committee or executive sponsor minute and referenced from the workspace activity log.
Limits on chartered authority:
- The programme does not have authority to direct work outside the chartered scope (Section 4).
- The programme does not have authority to override decisions made by other functions inside their chartered scope (legal, finance, HR, privacy, fraud).
- The programme does not have authority to accept risk above the chartered ceiling.
- The programme does not have authority to commit budget outside the resourcing envelope (Section 11) without sponsor approval.
7. Governance structure
The governance section names the standing bodies that exercise the chartered authority and the escalation path that connects the operating tier to the executive tier. Without a defined governance structure the chartered authority lives in role descriptions rather than in a body that can decide. The structure should be small, named, and durable rather than a long list of overlapping committees.
Standing governance bodies (each body carries: name, purpose, membership, cadence, chair, secretariat, decision authority):
Body 1: Security Steering Committee
- Purpose: {{STEERING_COMMITTEE_PURPOSE}}.
- Membership: {{SPONSOR_ROLE}}, {{ACCOUNTABLE_OPERATOR_ROLE}}, {{STEERING_MEMBER_3_ROLE}}, {{STEERING_MEMBER_4_ROLE}}, {{STEERING_MEMBER_5_ROLE}}, {{STEERING_MEMBER_6_ROLE}}, {{STEERING_MEMBER_7_ROLE}}, {{STEERING_MEMBER_8_ROLE}}.
- Cadence: {{STEERING_COMMITTEE_CADENCE}} (recommended quarterly).
- Chair: {{SPONSOR_ROLE}}.
- Secretariat: {{ACCOUNTABLE_OPERATOR_ROLE}} or delegate.
- Decision authority: Tier 3 decisions, charter amendment recommendations, capability commitment review.
Body 2: Security Operating Committee
- Purpose: {{OPERATING_COMMITTEE_PURPOSE}}.
- Membership: {{ACCOUNTABLE_OPERATOR_ROLE}}, heads of operating disciplines (AppSec, VM, GRC, security engineering, security operations, identity, cloud security where applicable, product security where applicable, detection engineering where applicable).
- Cadence: {{OPERATING_COMMITTEE_CADENCE}} (recommended monthly or biweekly).
- Chair: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Secretariat: {{OPERATING_COMMITTEE_SECRETARIAT_ROLE}}.
- Decision authority: cross-discipline operating decisions, Tier 2 decisions when the named co-decider sits on the committee.
Body 3: Security Programme Quarterly Review
- Purpose: {{QUARTERLY_REVIEW_PURPOSE}} (the cadence vehicle that bridges the operating queue and the strategic posture).
- Membership: {{ACCOUNTABLE_OPERATOR_ROLE}}, heads of operating disciplines, sponsor for the strategic posture read.
- Cadence: quarterly.
- Chair: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Secretariat: scribe captured on the workspace activity log.
- Decision authority: trajectory commitments, named decisions sought at the review meeting, action log capture.
Escalation path (the route a decision takes when it exceeds the operating tier authority):
- Operating-tier owner -> Operating Committee -> Accountable Operator -> Sponsor -> Steering Committee -> Executive Committee -> Board Risk Committee where applicable.
- Each tier records the escalation on the workspace activity log so the audit can reconstruct the path the decision took.
Advisory roles (consulted but not deciding):
- Legal counsel: consulted on regulatory-adjacent decisions and contractual security commitments.
- Privacy officer: consulted on personal-data-adjacent decisions.
- Internal audit: consulted on control-design and assurance-related decisions.
- External assurance provider: consulted on framework-specific evidence questions.
- Workforce representatives where applicable: consulted on decisions that affect workforce monitoring or workforce-facing controls.
Governance discipline:
- The standing committees meet on calendar-anchored cadences set at the start of the year.
- Each committee carries a brief signed minute on the workspace document store with action capture on the workspace activity log.
- Members named in this charter take primary responsibility; named delegates only attend when documented in the committee minute.
8. Organisational structure and reporting lines
The charter names the durable organisational shape of the programme rather than the people who currently occupy the roles. Keeping the role definitions in the charter and the named occupants on a separate organisation chart means the charter does not need amendment on every hire, departure, or reorganisation. The reporting line of the accountable operator is named here because the reporting line is one of the durable indicators of programme maturity and independence.
Accountable operator reporting line:
- Role: {{ACCOUNTABLE_OPERATOR_ROLE}} reports to {{ACCOUNTABLE_OPERATOR_REPORTS_TO_ROLE}}.
- Dotted-line reporting (where applicable): {{ACCOUNTABLE_OPERATOR_DOTTED_LINE_ROLE}}.
- Independence assurance: the accountable operator has direct access to {{INDEPENDENCE_ASSURANCE_AUTHORITY}} for material risk concerns that the primary reporting line cannot resolve.
Programme operating disciplines (the durable functions the programme carries; the names in this charter are role definitions rather than current occupants):
Discipline 1: Application security and product security
- Purpose: {{APPSEC_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{APPSEC_LEAD_ROLE_TITLE}}.
Discipline 2: Vulnerability management
- Purpose: {{VM_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{VM_LEAD_ROLE_TITLE}}.
Discipline 3: Governance, risk, and compliance
- Purpose: {{GRC_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{GRC_LEAD_ROLE_TITLE}}.
Discipline 4: Security engineering
- Purpose: {{SECENG_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{SECENG_LEAD_ROLE_TITLE}}.
Discipline 5: Security operations
- Purpose: {{SECOPS_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{SECOPS_LEAD_ROLE_TITLE}}.
Discipline 6: Identity and access (where applicable)
- Purpose: {{IDENTITY_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}} or {{IDENTITY_REPORTS_TO_ROLE}}.
- Discipline lead role title: {{IDENTITY_LEAD_ROLE_TITLE}}.
Discipline 7: Cloud security (where applicable)
- Purpose: {{CLOUD_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Discipline lead role title: {{CLOUD_LEAD_ROLE_TITLE}}.
Discipline 8: Detection engineering (where applicable)
- Purpose: {{DETECTION_DISCIPLINE_PURPOSE}}.
- Reports to: {{ACCOUNTABLE_OPERATOR_ROLE}} or {{SECOPS_LEAD_ROLE_TITLE}}.
- Discipline lead role title: {{DETECTION_LEAD_ROLE_TITLE}}.
Cross-functional touchpoints (the roles outside the programme the disciplines work with):
- Platform engineering and infrastructure: {{PLATFORM_TOUCHPOINT_ROLES}}.
- Product engineering: {{PRODUCT_TOUCHPOINT_ROLES}}.
- Legal: {{LEGAL_TOUCHPOINT_ROLES}}.
- Privacy: {{PRIVACY_TOUCHPOINT_ROLES}}.
- Finance: {{FINANCE_TOUCHPOINT_ROLES}}.
- People (HR): {{HR_TOUCHPOINT_ROLES}}.
- Internal audit: {{INTERNAL_AUDIT_TOUCHPOINT_ROLES}}.
Current organisation chart reference:
- The current organisation chart is held at {{ORG_CHART_REFERENCE}} and reflects the named occupants of the chartered roles at any point in time. Updates to the organisation chart do not require a charter amendment.
9. Roles, responsibilities, and accountability
The roles section names the durable accountabilities of the chartered roles rather than the day-to-day tasks. Each role carries one short accountability paragraph and a small named-responsibility list. The accountability statement is what the role is answerable for at the steering committee and the audit committee; the responsibilities are what the role does to discharge the accountability.
Role 1: Executive sponsor
- Accountability: ultimately accountable to the executive committee and the governing body for the security programme outcomes named in this charter.
- Responsibilities: sponsor the charter and amendments, chair the steering committee, defend the programme s budget and capacity asks at the executive committee, exercise Tier 3 decision authority, represent the programme to the governing body, intervene when business priorities cut across chartered security decisions.
Role 2: Accountable operator (CISO, head of security, or equivalent)
- Accountability: accountable to the sponsor for the day-to-day operation of the programme and the delivery of chartered outcomes.
- Responsibilities: lead the operating committee, exercise Tier 1 decision authority, escalate Tier 2 and Tier 3 decisions per the decision-rights framework, sign the annual charter reconfirmation, hold the programme cadence (Section 12), present quarterly programme posture to the steering committee, defend the programme to the audit committee, hire and retain the operating discipline leads.
Role 3: Discipline lead (per chartered operating discipline)
- Accountability: accountable to the accountable operator for the discipline outcomes named in the chartered capability commitments (Section 10).
- Responsibilities: run the discipline cadence, exercise discipline-specific decisions inside Tier 1 authority, escalate discipline decisions beyond Tier 1, hire and retain the discipline workforce, manage the discipline budget envelope, contribute to the quarterly review pack and the annual charter review.
Role 4: Programme custodian
- Accountability: accountable to the accountable operator for the maintenance of the charter document and the document history.
- Responsibilities: hold the version-controlled charter on the workspace document store, schedule the annual review, capture amendment recommendations, manage the sign-off chain, maintain the document history.
Role 5: Steering committee member (non-sponsor)
- Accountability: accountable for representing the function the member leads at the steering committee and for committing the function s support to chartered programme outcomes.
- Responsibilities: attend steering committee, review the programme posture pack ahead of the meeting, commit cross-functional support to chartered work, raise function-specific concerns the programme needs to weigh.
Role 6: Workforce as participants
- Accountability: every member of the workforce is accountable for following the security policies derived from this charter and for raising security concerns through the chartered channels.
- Responsibilities: complete security awareness training, follow the policies derived from this charter, report security concerns through the chartered channels, support security testing and assurance work in the chartered scope.
Workforce communication of the charter:
- The charter is summarised in the security awareness training.
- The charter is referenced in the onboarding pack for new workforce members.
- The charter is available on the {{INTERNAL_DOCUMENT_PORTAL_REFERENCE}} for the workforce to read.
Workforce contact channel:
- Security concerns may be raised through {{WORKFORCE_REPORTING_CHANNEL}} which carries the workspace activity-log capture for triage.
10. Programme outcomes and capability commitments
The outcomes section names what the programme commits to deliver in the chartered horizon. It is not a project plan and not the strategy. The outcomes are the durable capability commitments the chartered authority gives the programme the resources, mandate, and authority to deliver. Keep the list short and observable rather than aspirational, and name how each outcome is measured.
Programme outcomes (each outcome carries: outcome name, observable measure, owning discipline, framework expectations the outcome evidences):
Outcome 1: Maintain a chartered vulnerability management capability
- Observable measure: the programme operates an active vulnerability management process that intakes, triages, prioritises, remediates, and verifies findings across the chartered scope, with audit-ready evidence on the operating record.
- Owning discipline: vulnerability management.
- Framework expectations: ISO/IEC 27001 Annex A 8.8, PCI DSS Requirement 6.3, NIST SP 800-53 RA-5, NIST CSF 2.0 ID.RA and PR.PS, DORA Article 9.
Outcome 2: Maintain a chartered security testing capability
- Observable measure: the programme runs scheduled and on-demand security testing across the chartered scope, with documented coverage and exclusion list.
- Owning discipline: AppSec and product security plus vulnerability management.
- Framework expectations: ISO/IEC 27001 Annex A 8.29, PCI DSS Requirement 11.4, NIST SP 800-53 CA-8, NIST CSF 2.0 ID.RA-5, DORA Article 25.
Outcome 3: Maintain a chartered incident response capability
- Observable measure: the programme operates a declared incident response process with named runbooks, declared activation criteria, and post-incident review discipline.
- Owning discipline: security operations.
- Framework expectations: ISO/IEC 27001 Annex A 5.24 to A 5.27, SOC 2 CC7.3, NIST SP 800-61 Rev. 2, NIS2 Article 23, DORA Articles 17 and 19, HIPAA 164.308(a)(6).
Outcome 4: Maintain a chartered audit and compliance posture
- Observable measure: the programme produces audit-ready evidence packs for the named frameworks the organisation operates under, with retention and reconciliation discipline.
- Owning discipline: GRC and compliance.
- Framework expectations: ISO/IEC 27001 Clauses 7.5 and 9.2, SOC 2 CC4.1, PCI DSS Requirement 12, NIST SP 800-53 PM and CA, NIST CSF 2.0 GV.OV.
Outcome 5: Maintain a chartered identity and access integrity capability (where applicable)
- Observable measure: the programme assures the integrity of identity and access controls for the chartered scope, with documented joiner-mover-leaver discipline and privileged access governance.
- Owning discipline: identity and access (or shared with platform engineering).
- Framework expectations: ISO/IEC 27001 Annex A 5.15 to A 5.18, PCI DSS Requirement 7 and 8, NIST SP 800-53 AC, NIST CSF 2.0 PR.AA.
Outcome 6: Maintain a chartered third-party security capability
- Observable measure: the programme operates a third-party security review, ongoing oversight, and exit discipline for vendors and partners in the chartered scope.
- Owning discipline: GRC and compliance plus vulnerability management.
- Framework expectations: ISO/IEC 27001 Annex A 5.19 to A 5.22, NIST SP 800-53 SR and SA-12, NIST SP 800-161, SOC 2 CC9.2, NIS2 Article 21, DORA Articles 28 to 30.
Outcome 7: Maintain a chartered security awareness capability
- Observable measure: the programme delivers role-banded security awareness training across the chartered workforce with completion tracking and refresh cadence.
- Owning discipline: GRC and compliance plus security operations.
- Framework expectations: ISO/IEC 27001 Annex A 6.3, PCI DSS Requirement 12.6, NIST SP 800-53 AT, NIST CSF 2.0 PR.AT.
Outcome 8: Maintain a chartered measurement and reporting capability
- Observable measure: the programme produces measurement and reporting at the operating, programme, and executive cadences with audit reconciliation discipline.
- Owning discipline: accountable operator with discipline-lead contributions.
- Framework expectations: ISO/IEC 27001 Clauses 9.1 and 9.3, SOC 2 CC4.1 and CC4.2, NIST SP 800-53 CA-7 and PM-9, PCI DSS Requirement 12.4, NIST CSF 2.0 GV.OV.
Outcome boundary:
- The named outcomes are the chartered capabilities the programme commits to operate. Outcome maturity (initial, defined, managed, optimised) is named in the strategy document rather than in the charter.
- Specific initiatives, projects, and time-bound commitments that pursue or refine the outcomes are named in the multi-year strategy document and the annual operating plan rather than in this charter.
11. Resourcing, capacity, and budget posture
The resourcing section names the durable posture the programme operates inside rather than the line items of a particular year s budget. It pairs to the executive sponsor s commitment to defend programme capacity at the executive committee. The chartered resourcing posture protects the programme from year-on-year budget pressure that would erode the chartered capability commitments without an explicit chartered amendment.
Resourcing posture statement (the durable expectation, not the current year s budget):
The programme is resourced to deliver the chartered outcomes (Section 10) at the chartered cadence (Section 12) for the chartered scope (Section 4). The sponsor commits to defend the chartered resourcing posture at the executive committee and to escalate resourcing gaps that risk a chartered capability.
Workforce posture:
- The chartered programme runs with a workforce envelope that supports each operating discipline (Section 8) at a sustainable headcount.
- The workforce envelope is named in the annual operating plan rather than in the charter so the envelope can adjust to business growth and contraction without a charter amendment.
- A material change to the workforce envelope that risks a chartered outcome is a Tier 3 decision and triggers a steering committee read.
Tooling posture:
- The programme operates a tooling stack that supports each chartered outcome.
- Tooling consolidation, replacement, or addition decisions follow the tier framework in Section 6.
- A single workspace platform (SecPortal) holds the operating record (findings, engagements, retests, evidence, exceptions, audit pack, activity log) so the operating, programme, and audit reads are the same record at different cadences.
Capital posture:
- Programme capital expenditure follows the organisation s capital approval process.
- Programme capital asks that the chartered authority cannot fund inside the chartered envelope are escalated to the sponsor as a Tier 3 decision.
External assurance posture:
- The programme retains the named external assurance partners required to evidence the chartered outcomes: {{NAMED_EXTERNAL_ASSURANCE_PARTNERS}}.
- External assurance retention decisions follow the third-party security review process inside the chartered scope.
Sponsor commitment:
- The sponsor commits to defend the chartered resourcing posture at the executive committee.
- The sponsor commits to escalate resourcing gaps that risk a chartered capability to the executive committee with a named ask and a named timeline.
- The sponsor commits to support the programme s ask of partner functions for cross-functional capacity inside the chartered scope.
Resourcing review cadence:
- Resourcing is reviewed at the steering committee at the cadence in Section 7.
- Resourcing is reviewed at the annual charter review.
- A material resourcing gap that emerges between scheduled reviews is escalated immediately rather than carried to the next review cycle.
12. Programme cadence and amendment triggers
The cadence section names the governance rhythm the chartered authority is exercised on rather than the operating cadence. The cadence is calendar-anchored, sponsor-owned, and audit-readable so the chartered governance is exercised on a fixed rhythm rather than only when something breaks. The amendment triggers convert the charter from a static document into a living artefact with a defined refresh discipline.
Governance cadence (the disciplined rhythm at which the chartered authority and posture are exercised):
Annual cadence: Charter review
- Owner: accountable operator with the sponsor.
- Trigger: calendar-anchored to {{ANNUAL_REVIEW_CALENDAR_ANCHOR}}.
- Output: signed reconfirmation of the charter or a redlined amendment package presented to the steering committee.
- Sponsor read: the sponsor reads the reconfirmation or the amendment package and signs.
- Workspace pairing: the reconfirmation or amendment package is held on the workspace document store with the sign-off chain on the workspace activity log.
Quarterly cadence: Steering committee read
- Owner: accountable operator with the sponsor.
- Trigger: calendar-anchored to {{QUARTERLY_STEERING_CALENDAR_ANCHOR}}.
- Output: the quarterly programme posture pack read against the chartered outcomes, with named Tier 3 decisions and the action log.
- Workspace pairing: the pack is held on the workspace document store with the action capture on the workspace activity log.
Monthly or biweekly cadence: Operating committee
- Owner: accountable operator with the discipline leads.
- Trigger: calendar-anchored to {{OPERATING_COMMITTEE_CALENDAR_ANCHOR}}.
- Output: cross-discipline operating decisions, the cross-cutting programme work, and the action log.
Event-driven cadence: Out-of-cycle escalation
- Trigger: a Sev1 or Sev0 incident declaration, a regulatory notification, a material control finding, a material estate change, or a material business event the chartered programme has to respond to.
- Output: the steering committee or executive sponsor is convened out-of-cycle with the event-specific read and decision package.
Audit cycle: External assurance and internal audit
- Trigger: the audit cycle calendar set by the audit committee, the external assurance provider, and the regulators.
- Output: the audit-ready evidence pack derived from the operating record and the chartered cadence outputs.
Amendment triggers (the named events that force an out-of-cycle charter amendment):
1. Material change in the in-scope asset population (acquisition, divestiture, new product line, new geography).
2. Change in the executive sponsor or the named signers.
3. Change in the regulatory environment that places new chartered obligations on the programme.
4. Material change in the threat environment (sector incident pattern, board-level risk reset).
5. Structural reorganisation that changes the reporting line of the accountable operator.
6. Control finding from an audit or regulator that names the charter as the root cause of a gap.
Amendment process:
- The custodian captures the trigger on the workspace activity log.
- The custodian drafts the amendment with the accountable operator.
- The amendment is reviewed by the steering committee and signed by the sponsor.
- The amendment is paired to the new charter version with a row in the version history (Section 1).
- The workforce communication of the charter is refreshed where the amendment changes role definitions, the scope, or the operating principles.
13. Programme dependencies and interfaces
The dependencies section names the partner functions the programme relies on to deliver chartered outcomes and the interfaces the programme offers to the rest of the organisation. The chartered scope (Section 4) names what the programme owns; this section names what it cannot do alone and what others can come to the programme for.
Partner function dependencies (the functions the programme relies on to deliver chartered outcomes):
Dependency 1: Platform engineering and infrastructure
- Programme relies on the partner for: {{PLATFORM_DEPENDENCY_DESCRIPTION}} (for example, cloud configuration baseline application, identity provider operation, network segmentation, observability ingestion, infrastructure-as-code change controls).
- Programme interfaces: the operating committee includes platform engineering representation; the security engineering discipline pairs with platform engineering on shared work.
Dependency 2: Product engineering and software development
- Programme relies on the partner for: {{PRODUCT_DEPENDENCY_DESCRIPTION}} (for example, secure design practices, secure coding, code review, dependency hygiene, secret hygiene, release governance).
- Programme interfaces: the AppSec and product security discipline pairs with product engineering on shared work; security champions or product security partners are named per product or team area.
Dependency 3: Legal and compliance
- Programme relies on the partner for: {{LEGAL_DEPENDENCY_DESCRIPTION}} (for example, regulatory interpretation, contractual security clauses, litigation support, regulator engagement).
- Programme interfaces: legal is a standing advisory role to the steering committee and is consulted on regulatory-adjacent decisions.
Dependency 4: Privacy
- Programme relies on the partner for: {{PRIVACY_DEPENDENCY_DESCRIPTION}} (for example, lawful basis for processing, data subject rights, privacy impact assessments, breach notification rules).
- Programme interfaces: privacy is a standing advisory role; the data classification policy and incident response procedures are co-owned with privacy.
Dependency 5: People (HR)
- Programme relies on the partner for: {{HR_DEPENDENCY_DESCRIPTION}} (for example, joiner-mover-leaver mechanics, workforce screening, security awareness deployment, workforce monitoring rules).
- Programme interfaces: HR is consulted on workforce-affecting decisions; security awareness deployment is jointly owned.
Dependency 6: Finance
- Programme relies on the partner for: {{FINANCE_DEPENDENCY_DESCRIPTION}} (for example, budgetary support, vendor procurement, fraud prevention liaison).
- Programme interfaces: finance is consulted on budget-affecting decisions and third-party spend.
Dependency 7: Internal audit
- Programme relies on the partner for: {{INTERNAL_AUDIT_DEPENDENCY_DESCRIPTION}} (for example, independent assurance, control design review, audit fieldwork).
- Programme interfaces: internal audit is a standing advisory role; assurance scope is agreed annually.
Interfaces the programme offers to the rest of the organisation (what others can come to the programme for):
- Security review of new initiatives at the chartered intake point: {{SECURITY_REVIEW_INTAKE_DESCRIPTION}}.
- Security incident reporting channel: {{INCIDENT_REPORTING_CHANNEL}}.
- Vulnerability disclosure intake (internal and external): {{VULNERABILITY_DISCLOSURE_INTAKE}}.
- Third-party security review request: {{THIRD_PARTY_REVIEW_REQUEST_CHANNEL}}.
- Security advisory channel for ambiguous design or operating decisions: {{ADVISORY_REQUEST_CHANNEL}}.
- Audit evidence request fulfilment for external audits: {{AUDIT_EVIDENCE_FULFILMENT_CHANNEL}}.
Interface discipline:
- Each interface carries a named intake point, a named owner, an expected response posture, and a published service level where applicable.
- Interfaces are reviewed at the annual charter review.
- A material change to the interface contract is communicated to partner functions before it takes effect.
14. Sign-off, amendment, and version control
The sign-off section closes the charter by capturing the names, roles, signatures, and dates that give the charter its authority. A charter without an explicit sign-off chain is a draft. The sign-off chain plus the version history (Section 1) produce the audit-ready evidence trail that the chartered authority was exercised through a documented governance event.
Sign-off chain (named, signed, dated):
Executive sponsor:
- Role: {{SPONSOR_ROLE}}.
- Named person: {{SPONSOR_NAMED_PERSON}}.
- Signature: {{SPONSOR_SIGNATURE}}.
- Sign-off date: {{SPONSOR_SIGN_OFF_DATE}}.
Accountable operator:
- Role: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Named person: {{ACCOUNTABLE_OPERATOR_NAMED_PERSON}}.
- Signature: {{ACCOUNTABLE_OPERATOR_SIGNATURE}}.
- Sign-off date: {{ACCOUNTABLE_OPERATOR_SIGN_OFF_DATE}}.
Board risk committee chair (where applicable):
- Role: chair, board risk committee.
- Named person: {{BOARD_RISK_COMMITTEE_CHAIR_NAMED_PERSON}}.
- Signature: {{BOARD_RISK_COMMITTEE_CHAIR_SIGNATURE}}.
- Sign-off date: {{BOARD_RISK_COMMITTEE_CHAIR_SIGN_OFF_DATE}}.
Audit committee acknowledgement (where applicable):
- Role: chair, audit committee.
- Named person: {{AUDIT_COMMITTEE_CHAIR_NAMED_PERSON}}.
- Acknowledgement: I confirm that the audit committee has read this charter as part of the annual programme assurance read.
- Acknowledgement date: {{AUDIT_COMMITTEE_ACKNOWLEDGEMENT_DATE}}.
Annual reconfirmation block:
- Reconfirmation year: {{RECONFIRMATION_YEAR}}.
- Reconfirmation outcome (one of: reconfirmed without change, reconfirmed with editorial amendments only, reconfirmed with material amendments listed below, full re-sign required): {{RECONFIRMATION_OUTCOME}}.
- Material amendments (where applicable): {{RECONFIRMATION_MATERIAL_AMENDMENTS_LIST}}.
- Reconfirmation signed by sponsor: {{RECONFIRMATION_SPONSOR_SIGNATURE_AND_DATE}}.
- Reconfirmation signed by accountable operator: {{RECONFIRMATION_AO_SIGNATURE_AND_DATE}}.
Amendment block (used for out-of-cycle amendments):
- Amendment identifier: {{AMENDMENT_IDENTIFIER}}.
- Amendment trigger: {{AMENDMENT_TRIGGER_DESCRIPTION}}.
- Amendment effective date: {{AMENDMENT_EFFECTIVE_DATE}}.
- Amendment description: {{AMENDMENT_DESCRIPTION}}.
- Amendment signed by sponsor: {{AMENDMENT_SPONSOR_SIGNATURE_AND_DATE}}.
- Amendment signed by accountable operator: {{AMENDMENT_AO_SIGNATURE_AND_DATE}}.
- Amendment captured in version history (Section 1).
Charter acknowledgement statement (the closing block of the charter):
- This information security programme charter is the founding document of the security programme at {{ORGANISATION_LEGAL_NAME}}.
- The chartered authority, scope, principles, governance, and outcomes are exercised through the named cadence and recorded on the workspace operating record.
- The chartered authority is reviewed annually and amended on named-trigger basis between scheduled reviews.
- Policies, standards, and procedures derive their authority from this charter; where any subordinate document conflicts with this charter, this charter prevails until the subordinate is realigned.
Seven failure modes the charter has to design against
A charter fails the audit read and the leadership read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the charter so the customisation does not weaken the discipline that makes the charter credible.
The charter is signed by the CISO only
A charter signed only by the accountable operator with no executive countersignature does not carry the executive sponsorship that the audit committee, the board risk committee, and most regulators expect. The fix is the named executive sponsor sign-off plus, where applicable, the board risk committee chair countersignature and the audit committee acknowledgement.
The scope is written as aspirational language
A scope section that reads "the programme covers all information assets" leaves the boundary implicit and forces the security organisation to defend boundary decisions case by case. The fix is the three-list structure (in-scope, out-of-scope, shared-responsibility) with named asset classes, business units, geographies, and shared-responsibility splits the audit can reconcile to.
The authority section names mandate but not decision rights
A charter that says "the programme has authority to direct security work" without naming the decision tiers reads as posture rather than as enforceable rights. The fix is the three-tier decision framework (Tier 1 operator, Tier 2 named co-decider, Tier 3 sponsor or steering committee) with explicit decision categories and ceilings for risk acceptance, third-party spend, and tooling decisions.
The charter is treated as a one-off document
A founding charter signed once at the start of the programme and never refreshed becomes a stale artefact that the audit reads as evidence that the programme is not governed. The fix is the annual review discipline plus the six named amendment triggers between scheduled reviews, with the version history capturing every refresh.
The charter and the policy library are confused
A charter that codifies operating procedures or workforce behaviour rules drifts into policy territory and becomes hard to keep durable. The fix is keeping the charter at the constitutive layer (who the programme is, what authority it carries, what scope it covers) and letting the policy library, the standards, and the operating procedures sit underneath with their own review cycles.
The organisation chart is embedded in the charter
Embedding the current named people in the charter forces an amendment on every hire, departure, and reorganisation. The fix is keeping the role definitions in the charter and the current named occupants on a separate organisation chart that updates without requiring a chartered amendment.
The dependencies on partner functions are unwritten
A charter that names the programme s scope without naming the partner functions the programme relies on to deliver chartered outcomes leaves the cross-functional contract implicit. The fix is the dependencies section that names the seven partner functions (platform engineering, product engineering, legal, privacy, HR, finance, internal audit) the programme relies on and the interfaces the programme offers in return.
Ten questions the charter has to answer
A defensible charter answers each of these ten questions explicitly. Capture the answers in the sections above rather than relying on the executive sponsor and the accountable operator to recall them at the steering committee. The ten questions are the operational floor of a charter; richer programmes answer more, but the ten below are the durable minimum.
1.Who sponsors this programme and who signs as the accountable operator, and how are the signatures evidenced on the workspace record.
2.What does the programme exist to do, named in business-specific language rather than as a generic mission paragraph.
3.What is in scope, what is out of scope, and where is the responsibility shared with a named counterparty.
4.What authority does the programme carry, and how is that authority exercised across the three named decision tiers.
5.What standing committees and escalation path exercise the chartered authority, and how often do they meet.
6.Which operating disciplines does the programme carry, and what reporting line does the accountable operator have.
7.Which durable accountabilities sit with which roles, and how do they connect to the chartered outcomes.
8.What are the chartered outcomes the programme commits to deliver, and how is each outcome measured against framework expectations.
9.What resourcing posture does the sponsor commit to defend, and how does the programme escalate a chartered capability at risk.
10.When is the charter reviewed, which events trigger out-of-cycle amendment, and how is each version recorded.
How the charter pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs security testing, vulnerability remediation, evidence collection, and finding tracking on a workspace, the charter becomes the founding document the operating record reads against rather than a separate authoring project. SecPortal pairs the signed charter to a programme engagement record through engagement management, so the programme boundary, the sponsor, the named operator, the version history, the sign-off chain, and the amendment log live alongside the rest of the security record rather than in a side folder.
The charter is held as a versioned document through document management so the audit reads the founding artefact one click away from the current operating record. Access to the charter is gated by team management role-based access control with the four roles (owner, admin, member, viewer) shaping who can read and amend the document, and protected by multi-factor authentication for the sign-off events.
The activity log captures the sign-off chain, the annual reconfirmation, the amendment trigger, the amendment effective date, and the workforce communication events with named actor, timestamp, and 30, 90, or 365-day retention by plan, so the chartered governance discipline (when was the charter signed, who signed it, when was it last reconfirmed, which triggers fired amendments) is observable rather than asserted.
The Tier 1, Tier 2, and Tier 3 decision-rights framework in Section 6 pairs to the finding overrides feature for the structured override record (false positive, accepted risk, severity override) and to the vulnerability acceptance and exception management workflow for the operating discipline that exercises the chartered authority on the live findings record.
The chartered outcomes in Section 10 read against the compliance tracking feature where ISO 27001, SOC 2, Cyber Essentials, PCI DSS, NIST CSF 2.0, NIST SP 800-53, NIS2, DORA, and HIPAA mapping reads against the live findings record with CSV export, so the chartered capability commitments are observable on the same record the audit reconciles against. The chartered measurement and reporting outcome reads against the security KPI dashboard template and the security programme quarterly review template which together produce the chartered cadence outputs in the operating record.
The AI report generation workflow drafts the executive summary, the mission paragraph, the outcomes summary, and the workforce communication of the charter from the underlying workspace record so the custodian edits rather than writes from a blank page. The notifications and alerts feature dispatches the annual review trigger, the amendment trigger event, and the steering committee read invitations to the named signers and the standing committee with the same audit trail.
For the cadence pack the chartered governance produces, see the security programme quarterly review template. For the measurement underneath the chartered outcomes, see the security KPI dashboard template. For the risk discipline that the chartered acceptance ceilings exercise authority across, see the risk register template. For the cross-cadence narrative, see the security leadership reporting workflow. For the maturity model the charter is read against by the audit committee, see the enterprise security programme maturity guide. For the framework anchors, see the framework pages for ISO 27001, SOC 2, NIST CSF 2.0, NIST SP 800-53, and COBIT 2019. SecPortal does not replace the executive sponsor, the accountable operator, or the steering committee. The sponsor signs the charter; the accountable operator runs the programme; SecPortal carries the durable workspace record the charter operates against and the audit reads after.