What is a vulnerability management program charter?

A vulnerability management program charter is the constitutive document that authorises the vulnerability management programme to exist as a chartered discipline inside the security organisation, names its executive sponsor and accountable operator, defines its mandate and operating boundary, and sets the chartered authority it carries over remediation work, exception decisions, and tooling investment. It is not the vulnerability management policy that codifies what the organisation expects users, engineers, and asset owners to do across the lifecycle, and it is not the vulnerability management RACI that names which role is Accountable for each lifecycle step. The charter sits above both: the policy and the RACI derive their authority from it. A defensible charter answers five questions specific to vulnerability management. Who sponsors the programme and accepts accountability for the chartered outcomes. What the programme exists to do across the discover, ingest, deduplicate, triage, prioritise, route, remediate, verify, govern lifecycle. What authority the programme carries over remediation SLAs, exception ceilings, scanner-tooling decisions, and risk acceptance. What scope the programme covers and explicitly does not cover across asset classes, environments, business units, and shared-responsibility splits. What governance cadence keeps the chartered authority alive across annual review, quarterly steering committee, event-driven escalation, and audit-cycle reads. Without a written and signed charter the programme runs on implied authority that erodes the moment a delivery deadline cuts across a remediation deadline, and the audit reading cannot reconstruct who authorised the vulnerability management organisation to act.

How is the charter different from the vulnerability management policy, the RACI, and the SLA policy?

Four artefacts sit at four different layers and answer four different questions. The charter answers who the programme is and what authority it carries. The vulnerability management policy answers what the organisation expects across the lifecycle (intake, triage, prioritisation, routing, SLA, verification, exceptions, cycle metrics, governance). The vulnerability management RACI answers which role is Accountable, Responsible, Consulted, and Informed for each lifecycle step. The vulnerability SLA policy answers what remediation timelines apply by severity, asset class, exposure, and exploitability. A mature programme keeps the four in sync. The charter is signed by the executive sponsor and refreshed annually or when scope changes materially. The policy is refreshed on an annual review cycle aligned to the charter review. The RACI is refreshed when roles change. The SLA policy is refreshed when remediation capacity, threat exposure, or regulatory expectations shift. If a policy ever conflicts with the charter the charter wins. If the RACI names a role outside the chartered scope the RACI has to realign. If the SLA policy commits a remediation tempo the chartered resourcing cannot fund the charter has to expand by amendment or the SLA targets have to be revised.

What sections does a defensible vulnerability management program charter contain?

Thirteen sections produce a charter that survives an executive sign-off, an audit committee read, a regulator read, and an internal audit independent review. Document control and version history. Executive summary in plain language. Mission, purpose, and chartered outcomes statement. Programme scope (in-scope asset classes, out-of-scope, shared-responsibility with cloud providers and SaaS providers and customers and partners). Operating principles (risk-led prioritisation, asset criticality weighting, exploitability weighting, business-context weighting, single-record discipline). Authority and decision rights with three named decision tiers for SLA exceptions, risk acceptance ceilings, scanner-tooling decisions, and remediation campaign escalation. Governance structure (vulnerability management steering committee, escalation path, advisory roles across platform engineering, product engineering, GRC, internal audit, legal, privacy). Programme operating model and organisational structure (named teams across discover and ingest, triage and prioritise, route and remediate, verify and close, govern and report, with reporting line to the accountable operator). Roles, responsibilities, and accountability with named role definitions. Chartered outcomes and capability commitments (mean time to remediate by severity, exception backlog ceiling, SLA compliance by asset class, scanner coverage by asset class, audit-evidence freshness). Resourcing, capacity, and budget posture (named headcount commitments, tooling stack commitments, contractor capacity commitments). Programme cadence (annual charter review, quarterly steering committee, monthly operating committee, weekly triage huddle, event-driven escalation, audit-cycle read). Sign-off, amendment, and version control. The thirteen sections cover what the programme is, what it owes the business, and how it is governed without claiming individual remediation commitments that belong in the operating record or operating procedures that belong in the policy library.

Who sponsors the charter and who signs it?

The charter is sponsored by the executive who carries accountability for vulnerability management outcomes. In smaller organisations this is the CISO or head of security. In mid-size and larger organisations the sponsor is typically the CISO with co-sign from the CIO or CTO whose engineering organisation owns much of the remediation work, and acknowledgement from the chief risk officer where the risk acceptance ceilings cross into enterprise risk. The named accountable operator is the head of vulnerability management or the vulnerability management programme lead. Where the organisation has a board risk committee or a technology risk committee, the committee chair acknowledges the charter as part of the annual programme assurance read. Where the organisation has an audit committee, the audit committee chair acknowledges the charter as part of the annual cyber assurance read. Beyond the executive signers, the charter names the standing committee members (heads of platform engineering, product engineering, infrastructure, AppSec, GRC and compliance, internal audit, privacy, legal, and where applicable, regulatory compliance) so the cross-functional dependencies are visible on the founding artefact. A charter signed only by the head of vulnerability management with no executive countersignature does not meet the bar most audit committees, regulators, and cyber-insurance underwriters expect.

What evidence does the charter produce, and how does the workspace help?

A signed vulnerability management charter is the founding evidence for several framework controls and many regulatory expectations specifically directed at vulnerability management. ISO/IEC 27001:2022 Annex A 8.8 management of technical vulnerabilities expects a documented programme with a named owner and an operating cadence; the charter is the document the audit reads first. SOC 2 CC7.1 detection and monitoring and CC7.2 evaluation of security events read the chartered scope and outcomes. NIST CSF 2.0 ID.RA (risk assessment) and PR.IR (technology infrastructure resilience) read the chartered programme. NIST SP 800-53 RA-5 vulnerability monitoring and scanning reads the chartered scanner coverage and cadence. PCI DSS Requirement 6.3 and 11.3 expect a documented vulnerability management process with named ownership; the charter is the upstream authority document. NIS2 Article 21 technical and operational measures and DORA Article 9 ICT operations security and Article 24 advanced testing read the chartered programme as a foundational ICT risk management artefact. CISA Cyber Performance Goals 1.E and 2.A read the chartered baseline. SecPortal carries the charter as a versioned document paired to a programme engagement record through document management, the sign-off chain (sponsor, accountable operator, board risk committee chair, audit committee acknowledgement) appears on the workspace activity log with named actor and timestamp and 30, 90, or 365-day retention by plan, and the compliance tracking feature pairs the charter sections to the relevant framework controls for the audit-ready evidence pack.

How should the scope section be written so it is enforceable?

The scope section is the part of the vulnerability management charter most often fails the audit read because it is written as aspirational language ("the programme covers all assets") rather than as enforceable boundary. A defensible scope section names three lists: in-scope, out-of-scope, and shared-responsibility, with asset-class granularity that maps to the scanner stack and the operating record. The in-scope list names asset classes (external attack surface, public-facing web applications, public-facing APIs, internal corporate IT, identity systems, cloud control plane, cloud workloads, container registries and runtime, code repositories and dependencies, mobile applications, IoT or OT systems where applicable), business units, geographies, products, and operating environments the programme owns end-to-end. The out-of-scope list names asset classes the programme explicitly does not cover (for example research lab environments isolated from production, joint ventures with separate vulnerability management programmes, third-party SaaS platforms covered by separate provider attestations, or personal devices outside the BYOD policy). The shared-responsibility list names where ownership is divided (cloud infrastructure under shared responsibility with the cloud provider, customer-managed environments under shared responsibility with the customer, vendor-managed assets under joint controls). Writing scope as three asset-class lists rather than as a paragraph forces the programme to name boundaries the audit can reconcile to, the scanner stack can be tuned against, and the operating record can route findings against. Asset classes that are in-scope on the charter but uncovered by the scanner stack are a recognisable failure pattern audit reads as a control gap.

How does the authority section translate into operational vulnerability management decisions?

The authority section converts the chartered mandate into observable decision rights specific to the vulnerability management programme. A defensible authority section names three tiers of decision authority. Tier 1 (programme decisions the accountable operator takes alone) covers operational work including scanner configuration, finding triage and CVSS validation, false-positive disposition, deduplication and merge decisions, severity overrides within a documented band, SLA exception approval below a documented duration ceiling, risk acceptance approval below a documented severity and exposure band, retest scheduling, and routine campaign launch. Tier 2 (programme decisions taken with named co-decider) covers SLA exception approval above the documented duration ceiling and below the executive band, risk acceptance approval above a documented severity band, scanner-tooling consolidation decisions, third-party security review sign-off above a documented spend threshold, programme-level metric definition changes, and material campaign launch. Tier 3 (programme decisions escalated to the sponsor or steering committee) covers risk acceptance above a chartered ceiling, SLA exception above a chartered duration ceiling, programme scope changes, capacity changes that miss capability commitments, scanner-stack replacement decisions, and material control deficiencies the steering committee has to weigh against business risk. 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 chartered authority. Decision-tier reconciliation is what makes the chartered authority defensible at the audit committee, the regulator, and the underwriter.

How often should the charter be reviewed and what triggers an amendment?

The charter is reviewed annually as a calendar-anchored discipline, and amended on a named-trigger basis between scheduled reviews. The annual review is owned by the head of vulnerability management with co-author from the executive sponsor, runs at a fixed point in the year (typically one to two months before the budget cycle so the resourcing posture in the charter informs the next-year tooling and headcount conversation), and produces a confirmation that the existing charter remains accurate or a redlined amendment package. Between annual reviews, seven named triggers force an out-of-cycle amendment specific to vulnerability management. A material change in the in-scope asset population (acquisition, divestiture, new product line, new cloud account population, new geography, new on-premise estate). A change in the executive sponsor, the accountable operator, or the named signers. A change in the regulatory environment that places new chartered obligations on the programme (NIS2 in scope, DORA in scope, sector-specific regulation activated, CISA Cyber Performance Goals expectation shift). A material change in the threat environment (sector incident pattern, board-level risk reset, mass exploitation event the chartered cadence has to absorb). A structural reorganisation that changes the reporting line of the accountable operator. A scanner-stack replacement that changes the operating capability commitments. A control finding from an audit, internal audit independent review, regulator, or cyber-insurance underwriter that names the charter as the root cause of a gap. Treating the charter as a static one-off document is a recognisable failure pattern; treating it as a living artefact with a refresh cadence is what the audit and the board expect.

How should the chartered outcomes be framed so they are auditable rather than aspirational?

Chartered outcomes are the part of the charter the steering committee reads against at quarterly cadence and the audit committee reads against at annual cadence. Outcomes framed as aspirational language ("the programme will reduce vulnerability exposure") cannot be reconciled to evidence. Outcomes framed as capability commitments with named measurement methods, named reporting cadence, and named acceptable variance produce a chartered cadence the operating record can defend. A defensible outcomes section names seven capability commitments. Mean time to remediate by severity (critical, high, medium, low) with the SLA target the chartered policy commits to. Exception backlog ceiling expressed as a percentage of the open finding population and an absolute count. SLA compliance rate by asset class measured at the cycle boundary. Scanner coverage by in-scope asset class measured at the cycle boundary. Audit-evidence freshness measured as the age of the most recent evidence per chartered framework. Re-open rate measured as the percentage of findings that re-appear after verification. Cycle-on-cycle backlog change measured against the chartered acceptable trajectory. Each outcome carries a named measurement method, a named reporting cadence, a named acceptable variance band, and a named escalation trigger when the band is breached. The seven-outcome structure produces a steering committee read that is reconciliation rather than narrative, and the audit reads the same seven outcomes against the same seven evidence trails.

How does the charter handle the relationship with the engineering organisation that does the remediation work?

The vulnerability management programme does not perform the remediation work end to end; it triages, prioritises, routes, verifies, and governs while the platform engineering, product engineering, infrastructure, and asset-owner functions perform the actual patch, configuration, code, or design change. The charter has to name the boundary explicitly so the cross-functional contract is enforceable rather than implicit. A defensible charter names four engineering interfaces. Platform engineering and infrastructure interface (cloud configuration changes, infrastructure-as-code changes, network segmentation changes, identity provider changes, observability ingestion of vulnerability evidence). Product engineering and software development interface (application-side code fixes, dependency updates, design changes, secure-coding feedback into the SDLC). Operations interface (patch deployment, configuration change windows, change management coordination, rollback handling). Vendor and procurement interface (third-party patch availability, vendor-managed patch coordination, end-of-life replacement decisions). Each interface names the work the engineering function owns end-to-end, the work the vulnerability management programme owns end-to-end (triage, prioritisation, routing, verification, audit-evidence collection), and the joint discipline that connects them (SLA expectations from the chartered policy, finding ownership rules from the chartered RACI, escalation rules from the chartered authority, audit-evidence rules from the chartered cadence). A charter without an explicit engineering interface section forces every finding-routing dispute to be defended one at a time; a charter with the explicit interfaces gives the programme a defensible position against engineering capacity disputes, missed SLA escalations, and chartered scope ambiguity.

How should the resourcing and capacity posture be written so the steering committee can defend it?

The resourcing section is the part of the charter the steering committee reads against at quarterly cadence and the executive sponsor escalates from when chartered capability commitments are at risk. A defensible resourcing section names four resourcing layers. Headcount posture (named roles, named seniority, named headcount commitment per role, named contractor capacity commitment, named succession depth for accountable-operator-and-deputy continuity). Tooling stack posture (named scanner categories, named scanner products in scope, named tooling renewal cycle, named tooling-replacement budget posture, named tooling-coverage gaps known to the programme). Knowledge posture (named training commitment, named certification posture, named cross-functional rotation discipline, named threat-intelligence subscription posture). Capacity posture (named cycle-load expectations across triage capacity, remediation tracking capacity, verification capacity, audit-evidence collection capacity, governance reporting capacity). Each layer names the current posture, the chartered floor below which the steering committee is convened out-of-cycle, and the escalation pathway when the floor is at risk. The four-layer structure produces a resourcing section the steering committee can defend at the executive committee and the audit can reconcile against the chartered capability commitments. A resourcing section written as a single budget number that the audit and the steering committee cannot reconcile to chartered outcomes is a recognisable failure pattern.

What governance cadence should the charter set up for vulnerability management?

The charter names the governance cadence rather than the operating cadence. The governance cadence is the disciplined rhythm at which the chartered authority, scope, posture, and outcomes are reviewed and signed. A defensible cadence layers five rhythms specific to vulnerability management. Annual: charter review, signed reconfirmation or amendment, executive sponsor read and steering committee read, annual report to the audit committee and where applicable the board risk committee. Quarterly: vulnerability management steering committee read of programme posture against chartered outcomes with the programme scorecard as the input artefact, quarterly risk acceptance reauthorisation across exception backlog, quarterly read of scanner coverage and tooling posture. Monthly: monthly operating committee that runs the programme work, monthly read of SLA compliance by asset class, monthly read of cycle-on-cycle backlog change, monthly threat-intelligence read for emerging exploitation patterns. Event-driven: charter amendment, material risk acceptance escalation, mass-exploitation event response, scanner-stack incident response, control finding response, regulatory notification, cyber-insurance underwriter request. Audit-cycle: external audit, interim assurance read, internal audit fieldwork, regulator examination, cyber-insurance underwriter assurance read. The five-rhythm structure separates governance from operations and pairs each governance artefact to the executive sponsor, the steering committee, the board risk committee, and the audit committee so the chartered authority and accountability are exercised on a fixed cadence rather than only when something breaks.

Free Tool

Vulnerability Management Program Charter Template
thirteen sections that authorise the programme, name the sponsor, set decision rights, and pair the outcomes to a workspace operating record

A free, copy-ready vulnerability management programme charter template for CISOs, heads of vulnerability management, security operations leaders, GRC and compliance teams, internal security teams, security engineering leaders, and platform engineering partners. Thirteen structured sections covering document control and version history, executive summary in plain language, mission and chartered outcomes, programme scope (in-scope asset classes, out-of-scope, shared-responsibility with cloud providers and SaaS providers and customers and partners), operating principles, authority and decision rights with three named tiers for SLA exceptions and risk acceptance ceilings and scanner-tooling decisions, governance structure (steering committee, escalation path, advisory roles), operating model and organisational structure with named teams across discover and ingest and triage and prioritise and route and remediate and verify and govern, roles and responsibilities with named role definitions, chartered outcomes and capability commitments across mean time to remediate by severity and exception backlog ceiling and SLA compliance and scanner coverage and audit-evidence freshness, resourcing and capacity and budget posture, programme cadence layered across annual and quarterly and monthly and event-driven and audit-cycle rhythms, and sign-off and amendment and version-control discipline. Aligned with ISO/IEC 27001:2022 Annex A 8.8 management of technical vulnerabilities and Clause 5.1 leadership, SOC 2 CC7.1 detection and monitoring and CC7.2 evaluation, NIST CSF 2.0 ID.RA and PR.IR, NIST SP 800-53 RA-5 vulnerability monitoring and scanning, NIST SP 800-40 enterprise patch management, PCI DSS Requirement 6.3 and 11.3, NIS2 Article 21, DORA Article 9 and Article 24, CISA Cyber Performance Goals 1.E and 2.A, and HIPAA Security Rule 164.308.

Get Started Free

No credit card required. Free plan available forever.

Thirteen sections that authorise the vulnerability management programme and connect the chartered authority to a workspace operating record

A vulnerability management programme charter is the constitutive document that authorises the vulnerability management programme to exist as a chartered discipline inside the security organisation, names its executive sponsor and accountable operator, defines its mandate and operating boundary, and sets the chartered authority it carries over remediation work, exception decisions, and tooling investment. It is not the vulnerability management policy that codifies what the organisation expects across the lifecycle, it is not the vulnerability management RACI that names which role is Accountable for each lifecycle step, and it is not the vulnerability SLA policy that names remediation timelines by severity and asset class. The charter sits above all three: the policy, the RACI, and the SLA policy derive their authority from it.

The thirteen sections below cover the durable shape of a vulnerability management charter against ISO/IEC 27001:2022 Annex A 8.8 management of technical vulnerabilities and Clause 5.1 leadership, SOC 2 CC7.1 detection and monitoring and CC7.2 evaluation of security events, NIST CSF 2.0 ID.RA and PR.IR, NIST SP 800-53 RA-5 vulnerability monitoring and scanning, NIST SP 800-40 enterprise patch management, PCI DSS Requirement 6.3 and 11.3, NIS2 Article 21, DORA Article 9 and Article 24, CISA Cyber Performance Goals 1.E and 2.A, and HIPAA Security Rule 164.308. Pair the charter with the parent security program charter template for the umbrella security programme this charter is subordinate to, the vulnerability management programme scorecard for the steering-committee read of the chartered outcomes, the security exception register for the ledger of accepted risk the chartered authority defends, and the risk register template for the enterprise risk view the chartered acceptance ceilings reconcile against. 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 thirteen 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, which programme it authorises, 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 vulnerability management programme charter traceable across review cycles rather than a loose collection of paragraphs.

Document title: Vulnerability Management Programme Charter
Organisation: {{ORGANISATION_LEGAL_NAME}}
Programme name (the name the rest of the organisation refers to the vulnerability management programme by): {{PROGRAMME_NAME}}
Parent programme (the security programme this charter is subordinate to): {{PARENT_SECURITY_PROGRAMME_NAME}}
Document identifier (used for cross-references from policies, standards, RACI, operating procedures, and the operating record): {{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 or accountable operator change, regulatory environment change, threat environment reset, scanner-stack replacement, structural reorganisation, audit or regulator or underwriter finding naming the charter as root cause):
- {{CURRENT_REVISION_TRIGGER}}

Related programme artefacts (the documents that derive their authority from this charter):
- Vulnerability management policy: {{VM_POLICY_REFERENCE}}
- Vulnerability SLA policy: {{VM_SLA_POLICY_REFERENCE}}
- Vulnerability management RACI: {{VM_RACI_REFERENCE}}
- Vulnerability disclosure policy: {{VULNERABILITY_DISCLOSURE_REFERENCE}}
- Vulnerability remediation runbook: {{VM_REMEDIATION_RUNBOOK_REFERENCE}}
- Risk acceptance form: {{RISK_ACCEPTANCE_FORM_REFERENCE}}
- Security exception register: {{SECURITY_EXCEPTION_REGISTER_REFERENCE}}
- Parent security programme charter: {{PARENT_SECURITY_CHARTER_REFERENCE}}

Workspace pairing:
- The charter is held as a versioned document paired to a programme engagement record dedicated to vulnerability management.
- The sign-off chain (sponsor, accountable operator, steering committee acknowledgement, audit committee acknowledgement) 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 chartered vulnerability management programme in plain language. A board member, audit committee chair, or cyber-insurance underwriter who has only ninety seconds should walk away with a clear understanding of why the vulnerability management programme exists as a chartered discipline, who is accountable, what authority the programme carries over remediation and exception decisions, 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 vulnerability management programme that exists to {{PROGRAMME_PURPOSE_PARAGRAPH}} across the in-scope asset population by running a disciplined discover-ingest-deduplicate-triage-prioritise-route-remediate-verify-govern lifecycle paired to the live operating record.

Sponsor and accountability paragraph:
The programme is sponsored by {{SPONSOR_ROLE}} ({{SPONSOR_NAMED_PERSON}}) and operated by {{ACCOUNTABLE_OPERATOR_ROLE}} ({{ACCOUNTABLE_OPERATOR_NAMED_PERSON}}), typically titled head of vulnerability management. The sponsor accepts accountability to the executive committee and the {{GOVERNING_BODY}} for the chartered 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 across SLA exception approval, risk acceptance ceilings, scanner-tooling decisions, and remediation campaign escalation. 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 across mean time to remediate by severity, exception backlog ceiling, SLA compliance by asset class, scanner coverage by in-scope asset class, audit-evidence freshness, re-open rate, and cycle-on-cycle backlog change, evidenced through the cadence in Section 12 and the audit cycles named in the audit and compliance posture work.

Acknowledgements:
- This charter supersedes prior vulnerability management charter-equivalent documents listed in Appendix A.
- This charter does not codify operating procedures (held in the vulnerability management policy and the remediation runbook), per-finding work (held on the workspace engagement record), or SLA targets (held in the vulnerability SLA policy that derives authority from this charter).
- This charter is reviewed annually and amended on named-trigger basis between scheduled reviews.

3. Mission, purpose, and chartered outcomes statement

The mission section names the durable why of the vulnerability management 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 the programme. 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 asset population, the customer commitments, the regulatory environment, and the operating constraints the programme operates inside.

Programme mission statement (one sentence, plain language, business-specific):
The vulnerability management programme exists to {{PROGRAMME_MISSION_STATEMENT}} so that {{BUSINESS_OUTCOME_THE_PROGRAMME_PROTECTS}} is defensible against the threat environment named in the parent security strategy.

Programme purpose (the durable reasons the chartered programme exists, named explicitly):
1. {{PURPOSE_REASON_1}} (for example: maintain a single defensible record of vulnerability findings across external attack surface, public web and APIs, internal corporate IT, identity systems, cloud control plane and workloads, container registries and runtime, code repositories and dependencies, mobile applications, and where applicable IoT or OT estate).
2. {{PURPOSE_REASON_2}} (for example: run a disciplined intake, triage, deduplication, prioritisation, routing, remediation, verification, and governance lifecycle across the in-scope asset population).
3. {{PURPOSE_REASON_3}} (for example: enforce SLA discipline and exception governance so the open finding population stays inside the chartered backlog ceiling).
4. {{PURPOSE_REASON_4}} (for example: meet regulatory and contractual obligations specifically directed at vulnerability management including ISO/IEC 27001 Annex A 8.8, SOC 2 CC7.1 and CC7.2, NIST CSF 2.0 ID.RA and PR.IR, NIST SP 800-53 RA-5, PCI DSS 6.3 and 11.3, NIS2 Article 21, and DORA Article 9 and 24).
5. {{PURPOSE_REASON_5}} (for example: produce the audit-evidence pack across the operating cycle so the audit, internal audit independent review, regulator examination, and cyber-insurance underwriter assurance read can reconcile to the live record).
6. {{PURPOSE_REASON_6}} (for example: feed structural learning back into the SDLC, the infrastructure baseline, the cloud configuration baseline, the third-party vendor management programme, and the security testing programme so the vulnerability surface contracts over time).

Chartered outcomes (the capability commitments the programme is held to, each with a named measurement method, named reporting cadence, named acceptable variance band, and named escalation trigger):
1. Mean time to remediate by severity (critical, high, medium, low) measured against the chartered SLA policy.
2. Exception backlog ceiling expressed as a percentage of the open finding population and an absolute count.
3. SLA compliance rate by asset class measured at the cycle boundary.
4. Scanner coverage by in-scope asset class measured at the cycle boundary.
5. Audit-evidence freshness measured as the age of the most recent evidence per chartered framework.
6. Re-open rate measured as the percentage of findings that re-appear after verification.
7. Cycle-on-cycle backlog change measured against the chartered acceptable trajectory.

Programme audience (who the chartered programme serves):
- Primary stakeholders (the executive sponsor, the audit committee, the board risk committee, the customers and regulators whose trust the programme protects): {{PRIMARY_STAKEHOLDERS}}.
- Secondary stakeholders (partners, investors, cyber-insurance underwriters, internal auditors, external auditors): {{SECONDARY_STAKEHOLDERS}}.
- Internal partners (the engineering, platform, infrastructure, AppSec, GRC, internal audit, legal, privacy, and product functions the programme runs alongside): {{INTERNAL_PARTNERS}}.

Mission boundary (what the mission deliberately does not claim):
- The programme does not claim absolute remediation; the mission balances risk reduction with engineering capacity and business agility through the chartered SLA discipline and exception governance.
- The programme does not perform engineering remediation work end to end; the chartered model triages, prioritises, routes, verifies, and governs while the engineering organisation performs the patch, configuration, code, or design change.
- The programme does not claim authority over business risk acceptance above the chartered ceiling; risk acceptance above the ceiling 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 assets") rather than as enforceable boundary. A defensible scope section names three lists: in-scope asset classes, out-of-scope, and shared-responsibility, with asset-class granularity that maps to the scanner stack and the operating record. Asset classes that are in-scope on the charter but uncovered by the scanner stack are a recognisable failure pattern audit reads as a control gap.

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 asset classes (each named with current scanner coverage commitment, named operating owner, and named in-scope rationale):
- External attack surface (publicly resolvable hostnames, IP space, exposed services): {{EAS_SCOPE_AND_RATIONALE}}.
- Public-facing web applications: {{PUBLIC_WEB_SCOPE_AND_RATIONALE}}.
- Public-facing APIs: {{PUBLIC_API_SCOPE_AND_RATIONALE}}.
- Internal corporate IT (managed endpoints, internal services, internal applications): {{INTERNAL_IT_SCOPE_AND_RATIONALE}}.
- Identity systems (identity provider, directory service, SaaS identity layer): {{IDENTITY_SCOPE_AND_RATIONALE}}.
- Cloud control plane (cloud-account configuration, IAM, encryption, logging): {{CLOUD_CONTROL_PLANE_SCOPE_AND_RATIONALE}}.
- Cloud workloads (cloud-resident compute, storage, database, messaging): {{CLOUD_WORKLOAD_SCOPE_AND_RATIONALE}}.
- Container registries and runtime (image-side findings and runtime posture): {{CONTAINER_SCOPE_AND_RATIONALE}}.
- Code repositories and dependencies (SAST findings, SCA findings, secret detections): {{CODE_SCOPE_AND_RATIONALE}}.
- Mobile applications (where applicable): {{MOBILE_SCOPE_AND_RATIONALE}}.
- IoT or OT estate (where applicable): {{OT_IOT_SCOPE_AND_RATIONALE}}.

Business unit, geography, and operating-environment scope:
- In-scope business units or product lines: {{IN_SCOPE_BU_LIST_AND_RATIONALE}}.
- In-scope geographies or jurisdictions: {{IN_SCOPE_GEO_LIST_AND_RATIONALE}}.
- In-scope operating environments (production, staging, build, integration): {{IN_SCOPE_ENV_LIST_AND_RATIONALE}}.

Out-of-scope (the asset classes, business units, environments, and operating contexts the programme explicitly does not cover):
- Asset-class out-of-scope (named asset classes excluded with reasoning, for example research lab environments isolated from production, retired legacy systems with documented compensating controls, joint ventures with separate vulnerability management programmes): {{ASSET_OUT_OF_SCOPE_AND_REASONING}}.
- 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 (work the programme does not perform end-to-end but supports as input, for example regulatory legal interpretation in organisations where legal owns the regulatory read): {{OPERATING_OUT_OF_SCOPE_AND_REASONING}}.
- Geographic out-of-scope (operating regions or entities outside the charter): {{GEOGRAPHIC_OUT_OF_SCOPE_AND_REASONING}}.
- Future out-of-scope (asset classes 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 (the provider runs the infrastructure under their attestation; the programme runs the configuration and workload security inside the provider): {{CLOUD_PROVIDER_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- SaaS-provider responsibility split (the provider runs the platform under their attestation; the programme runs the tenant configuration, identity integration, and data classification): {{SAAS_PROVIDER_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Customer-environment responsibility split (for product-side organisations): {{CUSTOMER_ENVIRONMENT_SHARED_RESPONSIBILITY_DESCRIPTION}}.
- Vendor-managed responsibility split (vendor runs the operational work; the programme runs the security oversight and outcome verification): {{VENDOR_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 13 (material estate change, acquisition, divestiture, new product line, new cloud account population, 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 are the durable rules the chartered programme applies when a specific decision is not pre-decided by the policy, the runbook, or the SLA targets. The principles section is what the audit reads to understand how the programme makes consistent decisions across thousands of findings and hundreds of exception requests. Keep the principles few, durable, and specific to vulnerability management rather than copying generic security-programme principles.

Principle 1: Risk-led prioritisation
- The programme prioritises remediation by risk, not by raw severity score.
- Risk-led prioritisation reads severity (CVSS), exploitability (KEV inclusion, EPSS percentile, exploit availability), asset criticality (data sensitivity, business criticality, blast radius), exposure (internet-facing, authenticated, internal), and business context (customer commitment, regulatory expectation) together.
- The prioritisation method is documented in the vulnerability management policy; the chartered authority enforces application of the method across the operating record.

Principle 2: Single-record discipline
- Every chartered finding lives on a single operating record paired to the programme engagement.
- Duplicates from multiple scanners are merged using documented deduplication rules; findings without an asset-binding are quarantined until an owner is assigned.
- The single-record discipline is what makes the chartered cadence outputs (SLA compliance, backlog change, audit-evidence freshness) defensible against the audit and the steering committee read.

Principle 3: Exception governance before exception accumulation
- Every SLA exception, risk acceptance, severity override, and false-positive disposition is captured as a structured record with the documented decision chain.
- Exceptions carry an expiry date and an owner; a chartered renewal cadence prevents exception drift.
- The exception backlog ceiling in Section 10 is what the chartered authority defends through Tier 2 and Tier 3 review.

Principle 4: Scanner-stack coverage discipline
- The scanner stack is treated as a chartered programme commitment with named coverage by in-scope asset class.
- Scanner coverage gaps known to the programme are captured on the programme engagement record alongside the remediation strategy for closing the gap.
- A scanner-stack change above a documented threshold is a chartered amendment trigger.

Principle 5: Engineering partnership rather than enforcement
- The programme does not run the engineering remediation work end to end; the chartered model relies on platform engineering, product engineering, infrastructure, and asset-owner functions performing the actual change.
- The chartered authority over remediation is exercised through SLA discipline, exception governance, escalation, and audit-evidence reads rather than through direct engineering instruction.
- The engineering interface section (Section 8) names the cross-functional contract that translates chartered authority into operational practice.

Principle 6: Evidence-grade record discipline
- Every chartered decision (triage, prioritisation, routing, SLA exception, risk acceptance, verification, closure) leaves an evidence-grade record on the workspace activity log with named actor and timestamp.
- The chartered cadence outputs read against the evidence-grade record rather than against narrative reporting.
- The audit-evidence pack is a byproduct of the operating record rather than a separate authoring project.

Principle 7: Closure on the verification record, not on the ticket record
- A finding is chartered as closed when verification evidence is paired to the finding record on the workspace operating record.
- A ticket marked done in a downstream ticketing system without paired verification is not chartered as closed; the chartered authority maintains the verification gate.
- The re-open rate chartered outcome (Section 10) measures the durability of the closure discipline cycle by cycle.

6. Authority and decision rights

The authority section converts the chartered mandate into observable decision rights specific to vulnerability management. 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 chartered authority. Decision-tier reconciliation is what makes the chartered authority defensible at the audit committee, the regulator, and the cyber-insurance underwriter.

Tier 1 (programme decisions the accountable operator takes alone, recorded on the workspace activity log):
- Scanner configuration changes within the chartered scanner stack.
- Finding triage and CVSS validation.
- False-positive disposition with structured record.
- Deduplication and finding-merge decisions within documented merge rules.
- Severity overrides within a documented +/-{{TIER_1_SEVERITY_BAND}} band with documented reasoning.
- SLA exception approval below {{TIER_1_SLA_DURATION_CEILING}}.
- Risk acceptance approval below a documented severity band ({{TIER_1_RISK_BAND}}) and below a documented exposure band ({{TIER_1_EXPOSURE_BAND}}).
- Retest scheduling and verification disposition.
- Routine remediation campaign launch within the chartered cadence.
- Routine vendor security review sign-off within {{TIER_1_VENDOR_SCOPE}}.

Tier 2 (programme decisions taken with a named co-decider, recorded on the workspace activity log with both signatures):
- SLA exception approval above {{TIER_1_SLA_DURATION_CEILING}} and below {{TIER_3_SLA_DURATION_CEILING}}; co-decider: {{TIER_2_SLA_CO_DECIDER}}.
- Risk acceptance approval above {{TIER_1_RISK_BAND}} and below {{TIER_3_RISK_BAND}}; co-decider: {{TIER_2_RISK_CO_DECIDER}}.
- Scanner-tooling consolidation or expansion decisions within the chartered scanner-stack budget; co-decider: {{TIER_2_TOOLING_CO_DECIDER}}.
- Programme-level metric definition changes (chartered outcomes in Section 10); co-decider: {{TIER_2_METRIC_CO_DECIDER}}.
- Material remediation campaign launch (organisation-wide, multi-month, cross-functional resourcing impact); co-decider: {{TIER_2_CAMPAIGN_CO_DECIDER}}.
- Third-party security review sign-off above {{TIER_1_VENDOR_SCOPE}} and below {{TIER_3_VENDOR_SCOPE}}; co-decider: {{TIER_2_VENDOR_CO_DECIDER}}.

Tier 3 (programme decisions escalated to the executive sponsor or the steering committee, recorded on the workspace activity log with the steering-committee minute reference):
- Risk acceptance above {{TIER_3_RISK_BAND}} (chartered ceiling above which no acceptance is granted without steering committee).
- SLA exception above {{TIER_3_SLA_DURATION_CEILING}}.
- Programme scope changes (in-scope asset class addition or removal, business unit addition or removal, geographic addition or removal).
- Resourcing changes that miss capability commitments (Section 11).
- Scanner-stack replacement decisions.
- Material control deficiencies the steering committee has to weigh against business risk.
- Programme cadence changes (governance cadence in Section 12).

Decision-tier reconciliation discipline:
- Every Tier 2 and Tier 3 decision carries the steering-committee or co-decider record paired to the finding record on the workspace activity log.
- The audit reads the chartered tier against the activity log entries to confirm decisions were taken at the chartered authority.
- A decision taken outside the chartered tier is treated as a control finding the audit reads against the charter.

Out-of-tier escalation:
- The accountable operator may escalate any Tier 1 or Tier 2 decision to the next tier when the decision merits steering-committee read.
- A Tier 1 decision taken under time pressure that would normally be Tier 2 is captured with the documented reasoning and re-reviewed at the next steering committee.

7. Governance structure

The governance section names the standing forums that exercise the chartered authority. The vulnerability management programme has its own steering committee distinct from the security programme steering committee, because the operating tempo, the engineering partners, and the chartered decisions sit at a different layer. A defensible governance section names the committee composition, the chartered authority, the meeting cadence, and the escalation path.

Standing forum 1: Vulnerability Management Steering Committee
- Chartered authority: oversight of the chartered programme against the chartered outcomes (Section 10) at quarterly cadence.
- Composition: {{VMSC_COMPOSITION_LIST}} typically including executive sponsor, accountable operator, head of platform engineering or named delegate, head of product engineering or named delegate, head of infrastructure or named delegate, head of AppSec, head of GRC and compliance, head of internal audit or named delegate, head of legal or named delegate, head of privacy or named delegate.
- Meeting cadence: quarterly with named calendar anchor; out-of-cycle on event-driven trigger (Section 12).
- Input artefact: vulnerability management programme scorecard plus quarterly steering committee read pack.
- Output artefact: steering committee minute paired to the workspace engagement record with named decisions.

Standing forum 2: Operating Committee
- Chartered authority: operational tempo of the chartered programme at monthly cadence.
- Composition: {{OPCOM_COMPOSITION_LIST}} typically including accountable operator, vulnerability management leads across the in-scope asset classes, platform engineering programme manager, product engineering programme manager.
- Meeting cadence: monthly.
- Input artefact: cycle metrics from the operating record (SLA compliance, backlog change, exception backlog, scanner coverage, audit-evidence freshness).
- Output artefact: operating committee minute paired to the workspace engagement record.

Standing forum 3: Triage Huddle
- Chartered authority: operational triage tempo across the in-scope asset classes at weekly cadence.
- Composition: {{TRIAGE_HUDDLE_COMPOSITION_LIST}} typically including triage leads across the in-scope asset classes.
- Meeting cadence: weekly.
- Input artefact: triage queue, exception expiry queue, mass-exploitation watch.
- Output artefact: triage huddle notes on the workspace engagement record.

Standing forum 4: Audit-Cycle Read
- Chartered authority: audit and assurance posture at audit-cycle cadence.
- Composition: {{AUDIT_CYCLE_READ_COMPOSITION_LIST}} typically including accountable operator, head of GRC and compliance, head of internal audit, external auditor as guest.
- Meeting cadence: per audit cycle; typically annually for external audit and quarterly for internal audit interim reads.
- Input artefact: audit-evidence pack from the operating record.
- Output artefact: audit-cycle read minute paired to the workspace engagement record.

Escalation path (the chain through which an out-of-cycle decision is escalated):
- Triage huddle to operating committee for operational disputes that exceed the triage authority.
- Operating committee to steering committee for chartered-authority disputes that exceed the operating tier.
- Steering committee to executive sponsor for decisions that exceed the chartered ceiling.
- Executive sponsor to {{GOVERNING_BODY}} for decisions that exceed the chartered authority at the organisational level.

Advisory roles (consulted but not voting):
- Legal advisory on regulatory-adjacent decisions.
- Privacy advisory on data-classification-affecting decisions.
- HR advisory on workforce-affecting decisions.
- Finance advisory on budget-affecting decisions.
- Internal audit advisory on assurance-affecting decisions.
- Cyber-insurance advisory on underwriter-relevant decisions.

Governance discipline:
- Each forum minute is paired to the workspace engagement record with named chair, named attendees, named decisions, and named follow-ups.
- A decision taken outside a chartered forum is captured ad hoc and ratified at the next chartered meeting.
- The chartered cadence is reviewed at the annual charter review and on a structural-reorganisation trigger.

8. Operating model and engineering interfaces

The operating model section names the chartered teams inside the programme and the chartered interfaces with the engineering organisation that performs the actual remediation work. The vulnerability management programme does not perform the remediation work end to end; it triages, prioritises, routes, verifies, and governs. The interface section makes the cross-functional contract enforceable rather than implicit.

Chartered internal teams (named with chartered scope and reporting line to the accountable operator):

Team A: Discover and Ingest
- Chartered scope: scanner orchestration, scanner-output ingestion, scanner-stack coverage management, scanner-credential lifecycle, third-party scanner-output import.
- Named role lead: {{DISCOVER_INGEST_LEAD_ROLE}}.

Team B: Triage and Prioritise
- Chartered scope: finding triage, CVSS validation, deduplication, asset-binding, severity calibration, prioritisation against the chartered prioritisation method.
- Named role lead: {{TRIAGE_PRIORITISE_LEAD_ROLE}}.

Team C: Route and Remediate-Track
- Chartered scope: finding routing to engineering owners, SLA tracking, remediation campaign coordination, exception lifecycle.
- Named role lead: {{ROUTE_REMEDIATE_LEAD_ROLE}}.

Team D: Verify and Close
- Chartered scope: retest scheduling, verification disposition, closure record, re-open handling.
- Named role lead: {{VERIFY_CLOSE_LEAD_ROLE}}.

Team E: Govern and Report
- Chartered scope: chartered cadence outputs, audit-evidence pack assembly, steering committee read pack, scorecard maintenance, regulatory-and-underwriter response.
- Named role lead: {{GOVERN_REPORT_LEAD_ROLE}}.

Engineering interface 1: Platform engineering and infrastructure
- The programme triages, prioritises, routes, and verifies; platform engineering performs the cloud-configuration, infrastructure-as-code, network-segmentation, identity-provider, and observability-side change.
- Joint discipline: SLA bands from the chartered SLA policy, finding-ownership rules from the chartered RACI, escalation rules from the chartered authority, audit-evidence rules from the chartered cadence.
- Interface owner pair: {{VM_SIDE_PLATFORM_INTERFACE_OWNER}} and {{PLATFORM_SIDE_VM_INTERFACE_OWNER}}.

Engineering interface 2: Product engineering and software development
- The programme triages SAST, SCA, secret-detection, and AppSec findings; product engineering performs the code, design, dependency, and release change.
- Joint discipline: per-product SLA bands from the chartered SLA policy, secure-coding feedback loop into the SDLC, exception process across deferred fixes.
- Interface owner pair: {{VM_SIDE_PRODUCT_INTERFACE_OWNER}} and {{PRODUCT_SIDE_VM_INTERFACE_OWNER}}.

Engineering interface 3: Operations and change management
- The programme triages and tracks remediation; operations performs the patch deployment, configuration change, change-window coordination, and rollback handling.
- Joint discipline: change-window awareness, emergency-patch coordination for mass-exploitation events, post-change verification trigger.
- Interface owner pair: {{VM_SIDE_OPS_INTERFACE_OWNER}} and {{OPS_SIDE_VM_INTERFACE_OWNER}}.

Engineering interface 4: Vendor and procurement
- The programme triages vendor-affected findings; vendor and procurement coordinate vendor patch availability, end-of-life replacement decisions, and contractual remediation obligations.
- Joint discipline: vendor risk tracking, vendor escalation pathway, end-of-life replacement budget.
- Interface owner pair: {{VM_SIDE_VENDOR_INTERFACE_OWNER}} and {{VENDOR_SIDE_VM_INTERFACE_OWNER}}.

Interface discipline:
- Each interface carries a named owner pair, an expected response posture, and a published service-level expectation against the chartered SLA bands.
- A material change to the interface contract is communicated to the partner function before it takes effect.
- Interfaces are reviewed at the annual charter review and on the named triggers in Section 13.

9. Roles, responsibilities, and accountability

The roles section names the chartered roles inside the programme and the durable accountabilities each role carries. Roles are named by title rather than by person so the chartered roles outlive personnel change; the named-person roster lives on the separate organisation chart that updates without forcing a charter amendment. Each role connects to the chartered outcomes in Section 10 and the operating record cadence in Section 12.

Role 1: Executive sponsor
- Title: {{EXECUTIVE_SPONSOR_TITLE}}.
- Durable accountability: executive accountability for the chartered programme to the executive committee, the {{GOVERNING_BODY}}, the audit committee, the board risk committee, the regulators, and the cyber-insurance underwriter.
- Decision authority: Tier 3 risk acceptance, Tier 3 SLA exception, chartered scope change, scanner-stack replacement, programme-level resourcing escalation.
- Cadence touchpoints: annual charter sign-off, quarterly steering committee chair, audit-cycle read.

Role 2: Accountable operator (head of vulnerability management)
- Title: {{ACCOUNTABLE_OPERATOR_TITLE}}.
- Durable accountability: operational accountability for the chartered programme outcomes.
- Decision authority: Tier 1 decisions across the programme, Tier 2 with named co-decider, Tier 3 escalation to sponsor or steering committee.
- Cadence touchpoints: monthly operating committee chair, quarterly steering committee co-chair, annual charter author.

Role 3: Discover and Ingest lead
- Durable accountability: scanner-stack coverage commitment, scanner-output ingestion completeness, scanner-credential lifecycle.
- Decision authority: scanner configuration within Tier 1, scanner-coverage gap registration, scanner-credential rotation triggering.

Role 4: Triage and Prioritise lead
- Durable accountability: triage queue health, prioritisation method application, severity calibration discipline, deduplication discipline.
- Decision authority: Tier 1 triage and prioritisation decisions, Tier 2 severity override above documented band with co-decider.

Role 5: Route and Remediate-Track lead
- Durable accountability: SLA compliance posture, remediation campaign coordination, exception lifecycle, engineering-interface health.
- Decision authority: Tier 1 routing and SLA tracking decisions, Tier 2 SLA exception with co-decider, Tier 2 campaign launch with co-decider.

Role 6: Verify and Close lead
- Durable accountability: verification rigour, closure record discipline, re-open rate.
- Decision authority: Tier 1 verification disposition, retest scheduling.

Role 7: Govern and Report lead
- Durable accountability: chartered cadence outputs, audit-evidence pack assembly, steering committee read pack quality, scorecard maintenance.
- Decision authority: Tier 1 cadence-output preparation, Tier 2 metric-definition change with co-decider.

Role 8: Vulnerability management engineering counterparts (per asset class)
- Title pattern: {{ENGINEERING_COUNTERPART_TITLE_PATTERN}} per in-scope asset class (cloud security engineering lead, identity engineering lead, AppSec engineering lead, infrastructure engineering lead, container engineering lead).
- Durable accountability: engineering-side delivery against the chartered SLA bands, engineering-side input to the cadence outputs.

Role 9: Steering committee members
- Durable accountability: chartered governance at quarterly cadence.
- Decision authority: Tier 3 chartered authority exercised through committee resolution.

Role 10: Custodian of the charter
- Title: {{CUSTODIAN_TITLE}}.
- Durable accountability: charter version control, amendment trigger tracking, annual review preparation, sign-off-chain integrity.

Role boundary discipline:
- Role definitions name the role by title; the organisation chart names the people currently occupying the roles and updates without requiring a chartered amendment.
- A role change (addition, removal, or material redefinition) runs the chartered amendment process (Section 13).
- A personnel change (hire, departure, internal move) updates the organisation chart without amending the charter.

10. Chartered outcomes and capability commitments

Chartered outcomes are the part of the charter the steering committee reads against at quarterly cadence and the audit committee reads against at annual cadence. Outcomes framed as aspirational language ("the programme will reduce vulnerability exposure") cannot be reconciled to evidence. Outcomes framed as capability commitments with named measurement methods, named reporting cadence, and named acceptable variance produce a chartered cadence the operating record can defend.

Outcome 1: Mean time to remediate by severity
- Measurement method: median and 90th-percentile time-to-remediate by severity (critical, high, medium, low) per asset class, cycle by cycle, against the chartered SLA bands in the vulnerability SLA policy.
- Reporting cadence: monthly to the operating committee, quarterly to the steering committee, annually to the audit committee.
- Acceptable variance band: {{OUTCOME_1_VARIANCE_BAND}} against the chartered SLA bands.
- Escalation trigger: variance band breach for two consecutive cycles.

Outcome 2: Exception backlog ceiling
- Measurement method: count and percentage of open findings under exception (SLA exception, risk acceptance, severity override, false-positive disposition under review) against the chartered ceiling.
- Reporting cadence: monthly to the operating committee, quarterly to the steering committee.
- Acceptable variance band: chartered ceiling +/- {{OUTCOME_2_VARIANCE_BAND}}.
- Escalation trigger: ceiling breach in the current cycle.

Outcome 3: SLA compliance rate by asset class
- Measurement method: percentage of findings closed within the chartered SLA per asset class per cycle.
- Reporting cadence: monthly to the operating committee, quarterly to the steering committee, annually to the audit committee.
- Acceptable variance band: {{OUTCOME_3_VARIANCE_BAND}} against the chartered target.
- Escalation trigger: asset-class SLA compliance below the variance band for two consecutive cycles.

Outcome 4: Scanner coverage by in-scope asset class
- Measurement method: chartered scanner coverage by in-scope asset class against the named scanner stack and named coverage commitment.
- Reporting cadence: quarterly to the steering committee, annually to the audit committee.
- Acceptable variance band: coverage drift above {{OUTCOME_4_VARIANCE_BAND}} from the chartered baseline.
- Escalation trigger: drift band breach or scanner-stack incident.

Outcome 5: Audit-evidence freshness
- Measurement method: age of the most recent evidence pack per chartered framework against the chartered freshness commitment.
- Reporting cadence: quarterly to the steering committee, per audit cycle to the audit committee.
- Acceptable variance band: freshness lag above {{OUTCOME_5_VARIANCE_BAND}}.
- Escalation trigger: lag band breach or audit-cycle read request the freshness cannot support.

Outcome 6: Re-open rate
- Measurement method: percentage of findings that re-appear after chartered closure within the chartered re-open window per cycle.
- Reporting cadence: quarterly to the steering committee.
- Acceptable variance band: re-open rate above {{OUTCOME_6_VARIANCE_BAND}}.
- Escalation trigger: rate band breach for two consecutive cycles.

Outcome 7: Cycle-on-cycle backlog change
- Measurement method: open finding population net change per cycle against the chartered acceptable trajectory.
- Reporting cadence: monthly to the operating committee, quarterly to the steering committee.
- Acceptable variance band: trajectory drift above {{OUTCOME_7_VARIANCE_BAND}}.
- Escalation trigger: trajectory drift for two consecutive cycles.

Chartered outcome discipline:
- Each outcome carries a named measurement method, a named reporting cadence, a named acceptable variance band, and a named escalation trigger; an outcome without all four is incomplete and is treated as a control finding the audit reads against the charter.
- The seven-outcome structure produces a steering committee read that is reconciliation rather than narrative.
- The audit reads the same seven outcomes against the same seven evidence trails.

11. Resourcing, capacity, and budget posture

The resourcing section is the part of the charter the steering committee reads against at quarterly cadence and the executive sponsor escalates from when chartered capability commitments are at risk. A defensible resourcing section names four resourcing layers (headcount, tooling, knowledge, capacity) each with current posture, chartered floor, and escalation pathway, rather than a single budget number.

Layer 1: Headcount posture
- Named role headcount commitment: {{HEADCOUNT_COMMITMENT_PER_ROLE_LIST}}.
- Named seniority distribution: {{SENIORITY_DISTRIBUTION_LIST}}.
- Named contractor capacity: {{CONTRACTOR_CAPACITY_LIST}}.
- Named succession depth for accountable-operator continuity: {{SUCCESSION_DEPTH_LIST}}.
- Chartered floor below which the steering committee is convened out-of-cycle: {{HEADCOUNT_FLOOR}}.
- Escalation pathway when the floor is at risk: accountable operator notifies executive sponsor and triggers out-of-cycle steering committee.

Layer 2: Tooling stack posture
- Named scanner categories committed (external attack surface, web and API, internal, identity, cloud control plane and workloads, container, SAST, SCA, secret detection, mobile, IoT or OT where applicable): {{SCANNER_CATEGORIES_LIST}}.
- Named scanner products in scope per category: {{SCANNER_PRODUCT_LIST}}.
- Named tooling renewal cycle: {{TOOLING_RENEWAL_CYCLE}}.
- Named tooling-coverage gaps known to the programme: {{TOOLING_COVERAGE_GAPS_LIST}}.
- Chartered floor below which the steering committee is convened out-of-cycle: {{TOOLING_FLOOR}}.
- Escalation pathway when a tooling floor is at risk: accountable operator notifies executive sponsor; scanner-stack replacement runs Tier 3 chartered authority.

Layer 3: Knowledge posture
- Named training commitment: {{TRAINING_COMMITMENT_LIST}}.
- Named certification posture: {{CERTIFICATION_POSTURE_LIST}}.
- Named cross-functional rotation discipline: {{CROSS_ROTATION_LIST}}.
- Named threat-intelligence subscription posture: {{THREAT_INTEL_POSTURE_LIST}}.
- Chartered floor: {{KNOWLEDGE_FLOOR}}.

Layer 4: Capacity posture
- Named triage capacity expressed in cycle-load terms: {{TRIAGE_CAPACITY}}.
- Named remediation tracking capacity: {{REMEDIATION_TRACKING_CAPACITY}}.
- Named verification capacity: {{VERIFICATION_CAPACITY}}.
- Named audit-evidence collection capacity: {{AUDIT_EVIDENCE_CAPACITY}}.
- Named governance reporting capacity: {{GOVERNANCE_REPORTING_CAPACITY}}.
- Chartered floor below which chartered outcomes are at risk: {{CAPACITY_FLOOR}}.

Budget posture (the chartered budget commitment paired to the layered resourcing posture):
- Current-year budget posture: {{CURRENT_YEAR_BUDGET_POSTURE}}.
- Multi-year budget trajectory: {{MULTI_YEAR_BUDGET_TRAJECTORY}}.
- Named budget contingency for mass-exploitation event response: {{MASS_EXPLOITATION_CONTINGENCY}}.
- Named budget contingency for scanner-stack incident response: {{SCANNER_STACK_INCIDENT_CONTINGENCY}}.

Resourcing review discipline:
- The resourcing section is reviewed at the annual charter review one to two months before the budget cycle so the chartered floors inform the next-year budget conversation.
- A material change in any layer mid-cycle triggers an out-of-cycle steering committee.
- A resourcing posture below a chartered floor is treated as a chartered capability at risk and is reported to the executive sponsor.

12. Programme cadence

The charter names the governance cadence rather than the operating cadence. The governance cadence is the disciplined rhythm at which the chartered authority, scope, posture, and outcomes are reviewed and signed. A defensible cadence layers five rhythms specific to vulnerability management and pairs each rhythm to a chartered forum and a chartered output.

Annual cadence: Charter review and audit-committee read
- Trigger: annual calendar anchor one to two months before the budget cycle.
- Output: charter reconfirmation or amendment package; annual report to the audit committee and where applicable the board risk committee; annual chartered-resourcing posture refresh.

Quarterly cadence: Vulnerability Management Steering Committee
- Trigger: quarterly calendar anchor.
- Output: chartered outcomes read against the chartered acceptable variance bands; quarterly risk acceptance reauthorisation across the exception backlog; quarterly read of scanner coverage and tooling posture; steering committee minute paired to the workspace engagement record.

Monthly cadence: Operating Committee
- Trigger: monthly calendar anchor.
- Output: cycle metrics read (SLA compliance by asset class, backlog change, exception backlog, scanner coverage, audit-evidence freshness); operating committee minute paired to the workspace engagement record.

Weekly cadence: Triage Huddle
- Trigger: weekly calendar anchor.
- Output: triage queue management; exception expiry queue management; mass-exploitation watch; triage huddle notes on the workspace engagement record.

Event-driven cadence: Out-of-cycle escalation
- Trigger: charter amendment trigger; material risk acceptance escalation; mass-exploitation event response; scanner-stack incident response; control finding response from audit, internal audit, or regulator; cyber-insurance underwriter assurance request; SLA exception above the chartered ceiling.
- Output: out-of-cycle steering committee or executive sponsor convening; named decision recorded on the workspace activity log.

Audit-cycle cadence: External audit, internal audit, regulator examination, underwriter assurance
- Trigger: audit cycle calendar set by the audit committee, the external assurance provider, the regulator, and the cyber-insurance underwriter.
- Output: audit-evidence pack derived from the operating record; named audit-cycle read minute.

Cadence discipline:
- Each cadence event carries a named chair, a named input artefact, a named output artefact, and a named follow-up routing.
- A scheduled cadence event missed is captured ad hoc and ratified at the next scheduled event.
- The cadence is reviewed at the annual charter review and on a structural-reorganisation trigger.

13. Sign-off, amendment, and version control

The sign-off section closes the charter by capturing the names, roles, signatures, and dates that give the chartered vulnerability management programme 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}}.

Co-sponsor (where applicable, typically CIO or CTO whose engineering organisation owns much of the remediation work):
- Role: {{CO_SPONSOR_ROLE}}.
- Named person: {{CO_SPONSOR_NAMED_PERSON}}.
- Signature: {{CO_SPONSOR_SIGNATURE}}.
- Sign-off date: {{CO_SPONSOR_SIGN_OFF_DATE}}.

Accountable operator (head of vulnerability management):
- Role: {{ACCOUNTABLE_OPERATOR_ROLE}}.
- Named person: {{ACCOUNTABLE_OPERATOR_NAMED_PERSON}}.
- Signature: {{ACCOUNTABLE_OPERATOR_SIGNATURE}}.
- Sign-off date: {{ACCOUNTABLE_OPERATOR_SIGN_OFF_DATE}}.

Chief Risk Officer acknowledgement (where risk acceptance ceilings cross into enterprise risk):
- Role: {{CRO_ROLE}}.
- Named person: {{CRO_NAMED_PERSON}}.
- Acknowledgement: I confirm that the chartered risk acceptance ceilings are consistent with the enterprise risk appetite.
- Acknowledgement date: {{CRO_ACKNOWLEDGEMENT_DATE}}.

Board risk committee or technology risk committee chair acknowledgement (where applicable):
- Role: chair, {{RISK_COMMITTEE_NAME}}.
- Named person: {{RISK_COMMITTEE_CHAIR_NAMED_PERSON}}.
- Acknowledgement: I confirm that the committee has read this charter as part of the annual programme assurance read.
- Acknowledgement date: {{RISK_COMMITTEE_ACKNOWLEDGEMENT_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 cyber assurance read.
- Acknowledgement date: {{AUDIT_COMMITTEE_ACKNOWLEDGEMENT_DATE}}.

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 cloud account population, new geography, new on-premise estate).
2. Change in the executive sponsor, the accountable operator, or the named signers.
3. Change in the regulatory environment that places new chartered obligations on the programme (NIS2 in scope, DORA in scope, sector-specific regulation activated, CISA Cyber Performance Goals expectation shift).
4. Material change in the threat environment (sector incident pattern, board-level risk reset, mass-exploitation event the chartered cadence has to absorb).
5. Structural reorganisation that changes the reporting line of the accountable operator.
6. Scanner-stack replacement that changes the operating capability commitments.
7. Control finding from an audit, internal audit independent review, regulator, or cyber-insurance underwriter 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 programme communication of the chartered amendment is dispatched to the standing committee, the engineering interface owners, and the audit and assurance partners.

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}}.

Charter acknowledgement statement (the closing block of the charter):
- This vulnerability management programme charter is the founding document of the vulnerability management 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.
- The vulnerability management policy, the vulnerability SLA policy, the vulnerability management RACI, and subordinate operating procedures derive their authority from this charter; where any subordinate document conflicts with this charter, this charter prevails until the subordinate is realigned.

Eight failure modes the charter has to design against

A vulnerability management 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 head of vulnerability management 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, regulators, and cyber-insurance underwriters expect. The fix is the named executive sponsor sign-off, the co-sponsor sign-off from the engineering executive whose teams perform the remediation work, the chief risk officer acknowledgement, and where applicable the board risk committee and audit committee acknowledgements.

The scope is written as aspirational language

A scope section that reads "the programme covers all assets" leaves the boundary implicit and forces the programme to defend boundary decisions case by case. The fix is the three-list structure (in-scope asset classes, out-of-scope, shared-responsibility) at asset-class granularity that maps to the scanner stack and the operating record.

The chartered scope outruns the scanner stack

An in-scope asset class with no scanner coverage commitment is a recognisable failure pattern audit reads as a control gap. The fix is pairing each in-scope asset class to a named scanner category, naming the scanner-coverage gaps known to the programme, and treating coverage drift above the chartered band as an escalation trigger.

The authority section names mandate but not decision tiers

A charter that says "the programme has authority to direct remediation work" without naming the decision tiers reads as posture rather than as enforceable rights. The fix is the three-tier decision framework (Tier 1 accountable operator, Tier 2 named co-decider, Tier 3 sponsor or steering committee) with explicit decision categories and ceilings for SLA exception duration, risk acceptance severity and exposure bands, scanner-tooling decisions, and remediation campaign launch.

The chartered outcomes are aspirational rather than reconcilable

Outcomes framed as "the programme will reduce vulnerability exposure" cannot be reconciled to evidence. The fix is naming each outcome with a measurement method, a reporting cadence, an acceptable variance band, and an escalation trigger, so the steering committee read is reconciliation rather than narrative.

The engineering interface is implicit

A charter that names the programme scope without naming the cross-functional contract with platform engineering, product engineering, operations, and vendor management leaves the routing dispute implicit. The fix is the four-interface section that names the work the programme owns, the work the engineering function owns, and the joint discipline that connects them at the chartered SLA bands.

The resourcing posture is a single budget number

A resourcing section written as a single budget number that the steering committee cannot reconcile to chartered outcomes leaves the chartered capability commitment indefensible. The fix is the four-layer structure (headcount, tooling, knowledge, capacity) each with current posture, chartered floor, and escalation pathway.

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 seven named amendment triggers between scheduled reviews, with the version history capturing every refresh.

Eleven questions the charter has to answer

A defensible vulnerability management charter answers each of these eleven 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 eleven questions are the operational floor of a chartered programme; richer programmes answer more, but the eleven below are the durable minimum.

1.Who sponsors the vulnerability management programme and who signs as the accountable operator, and how are the signatures evidenced on the workspace record.
2.What does the chartered programme exist to do across the discover, ingest, deduplicate, triage, prioritise, route, remediate, verify, govern lifecycle.
3.What asset classes are in-scope, what is out-of-scope, and where is the responsibility shared with a named counterparty.
4.What scanner coverage does the chartered scope commit to per asset class, and where are the known coverage gaps.
5.What authority does the programme carry over SLA exception, risk acceptance, scanner-tooling, and remediation-campaign decisions across three named decision tiers.
6.What standing forums (steering committee, operating committee, triage huddle, audit-cycle read) exercise the chartered authority, and how often do they meet.
7.Which chartered teams sit inside the programme, and which engineering interfaces translate chartered authority into the operational remediation work.
8.Which durable accountabilities sit with which chartered roles, and how do they connect to the chartered outcomes.
9.What seven chartered outcomes does the programme commit to, each with a named measurement method, named reporting cadence, named acceptable variance band, and named escalation trigger.
10.What resourcing posture does the sponsor commit to defend across headcount, tooling, knowledge, and capacity, and what chartered floors trigger out-of-cycle steering committee.
11.When is the charter reviewed, which seven events trigger out-of-cycle amendment, and how is each version recorded on the workspace activity log.

How the charter pairs with SecPortal

The template above is copy-ready as a standalone artefact. If your team already runs vulnerability management, remediation tracking, evidence collection, scanner-finding intake, exception governance, and audit-ready reporting 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 vulnerability management programme engagement record through engagement management, so the programme boundary, the sponsor, the accountable operator, the version history, the sign-off chain, and the amendment log live alongside the findings the chartered authority is exercised across 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 and 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 steering committee minutes 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 SLA bands in the linked SLA policy pair to the vulnerability SLA management workflow and the SLA breach escalation workflow.

The chartered outcomes in Section 10 read against the findings management record with CVSS 3.1 scoring and the compliance tracking feature where ISO 27001 Annex A 8.8, SOC 2 CC7.1 and CC7.2, NIST CSF 2.0, NIST SP 800-53 RA-5, NIST SP 800-40, PCI DSS 6.3 and 11.3, NIS2, DORA, and CISA Cyber Performance Goals 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 closure discipline pairs to the retesting workflows feature and the security finding fix verification workflow.

The AI report generation workflow drafts the executive summary, the mission paragraph, the outcomes summary, and the steering committee read pack 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, the SLA breach escalation, and the steering committee read invitations to the named signers and the standing committee with the same audit trail.

For the steering-committee read of the chartered outcomes, see the vulnerability management programme scorecard. For the operating discipline the chartered policy commits to, see the vulnerability management policy template. For the operating model the chartered RACI commits to, see the vulnerability management RACI template. For the SLA bands the chartered SLA policy commits to, see the vulnerability SLA policy template. For the cross-cadence security narrative, see the security leadership reporting workflow. For the framework anchors, see the framework pages for ISO 27001, SOC 2, NIST CSF 2.0, NIST SP 800-53, NIST SP 800-40, PCI DSS, and DORA. SecPortal does not replace the executive sponsor, the accountable operator, the steering committee, the engineering remediation function, or the audit. The sponsor signs the charter; the accountable operator runs the programme; the engineering organisation performs the remediation; SecPortal carries the durable workspace record the charter operates against and the audit reads after. SecPortal does not provide enterprise SSO, SCIM provisioning, native Jira or ServiceNow ticket synchronisation, SIEM or SOAR integration, automated approval routing, or built-in control libraries.

Buyer and operator pairing

The vulnerability management programme charter is the founding artefact CISOs, security operations leaders, vulnerability management teams, internal security teams, security programme managers, GRC and compliance teams, security engineering teams, cloud security teams, AppSec teams, and internal audit teams stand up when a board, an audit committee, a regulator, an enterprise customer, or a cyber-insurance underwriter asks for evidence that the vulnerability management programme is chartered with executive sponsorship rather than operating on implied authority. External advisors (virtual CISOs, compliance consultants, security consultants) use the same package to give client programmes a chartered foundation that meets framework expectations rather than a placeholder document drafted ad hoc on the eve of an audit.

Loading tool...

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Every action recorded across the workspace

Compliance tracking without a full GRC platform

Collaborate across your entire team

Role-based access control with least privilege by default

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Multi-factor authentication on every workspace

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Security testing program management

Security leadership reporting

Vulnerability acceptance and exception management

Vulnerability SLA management

Vulnerability SLA breach escalation

Vulnerability backlog management

Security debt portfolio management

Cross-framework control mapping

Audit fieldwork evidence request fulfillment

Compliance audits

Carry the chartered authority on the live workspace record, not on a static document drive

SecPortal pairs the signed vulnerability management programme charter to a programme engagement record so the sponsor sign-off, the steering committee acknowledgement, the chartered SLA bands, the risk acceptance ceilings, the scanner-coverage commitments, the annual reconfirmation, and the amendment history all live on one workspace alongside the findings the chartered authority is exercised across, with a named-actor activity log. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Vulnerability Management Program Charter Templatethirteen sections that authorise the programme, name the sponsor, set decision rights, and pair the outcomes to a workspace operating record

Thirteen sections that authorise the vulnerability management programme and connect the chartered authority to a workspace operating record

1. Document control and version history

2. Executive summary

3. Mission, purpose, and chartered outcomes statement

4. Programme scope

5. Operating principles

6. Authority and decision rights

7. Governance structure

8. Operating model and engineering interfaces

9. Roles, responsibilities, and accountability

10. Chartered outcomes and capability commitments

11. Resourcing, capacity, and budget posture

12. Programme cadence

13. Sign-off, amendment, and version control

Eight failure modes the charter has to design against

The charter is signed by the head of vulnerability management only

The scope is written as aspirational language

The chartered scope outruns the scanner stack

The authority section names mandate but not decision tiers

The chartered outcomes are aspirational rather than reconcilable

The engineering interface is implicit

The resourcing posture is a single budget number

The charter is treated as a one-off document

Eleven questions the charter has to answer

How the charter pairs with SecPortal

Buyer and operator pairing

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Every action recorded across the workspace

Compliance tracking without a full GRC platform

Collaborate across your entire team

Role-based access control with least privilege by default

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Multi-factor authentication on every workspace

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Security testing program management

Security leadership reporting

Vulnerability acceptance and exception management

Vulnerability SLA management

Vulnerability SLA breach escalation

Vulnerability backlog management

Security debt portfolio management

Cross-framework control mapping

Audit fieldwork evidence request fulfillment

Compliance audits

Carry the chartered authority on the live workspace record, not on a static document drive

Thirteen sections that authorise the vulnerability management programme and connect the chartered authority to a workspace operating record

1. Document control and version history

2. Executive summary

3. Mission, purpose, and chartered outcomes statement

4. Programme scope

5. Operating principles

6. Authority and decision rights

7. Governance structure

8. Operating model and engineering interfaces

9. Roles, responsibilities, and accountability

10. Chartered outcomes and capability commitments

11. Resourcing, capacity, and budget posture

12. Programme cadence

13. Sign-off, amendment, and version control

Eight failure modes the charter has to design against

The charter is signed by the head of vulnerability management only

The scope is written as aspirational language

The chartered scope outruns the scanner stack

The authority section names mandate but not decision tiers

The chartered outcomes are aspirational rather than reconcilable

The engineering interface is implicit

The resourcing posture is a single budget number

The charter is treated as a one-off document

Eleven questions the charter has to answer

How the charter pairs with SecPortal

Buyer and operator pairing

Vulnerability Management Program Charter Template
thirteen sections that authorise the programme, name the sponsor, set decision rights, and pair the outcomes to a workspace operating record