Security Charter

A Security Charter is the foundational governance document that establishes the purpose, authority, and scope of your Information Security Program. It serves as the strategic foundation that authorizes and guides all security initiatives, policies, and strategies within your organization.

Charter overview

Navigate to Control Model → Security Charter to view all charters. The list view shows each charter’s name, version, status, steering committee, sponsor, CISO, and review dates.

Core components

Every charter is built around three foundational sections, each with both a plain-text summary and a rich-text (Lexical editor) content field for detailed documentation:

Purpose — Why the security program exists and its mission. Defines the rationale, business context, and objectives that the program is designed to address.

Authority — Who authorized the program and the governance structure. Identifies executive sponsorship, reporting lines, and the scope of decision-making authority granted to the security function.

Scope — What the program covers and its boundaries. Specifies the organizational units, information assets, systems, and processes that fall under the security program’s purview.

Governance roles

Each charter assigns three governance roles:

Creating a charter

Charter lifecycle

Charters follow a defined status lifecycle that tracks their progression from creation to retirement:

The typical flow is: Draft → Under Review → Approved → Active → Archived.

Enriched content

Beyond the core Purpose, Authority, and Scope sections, charters support enriched content fields that provide comprehensive governance context:

Vision — The long-term security vision for the organization.

Mission — The security program’s mission statement.

Risk tolerance statement — The organization’s declared risk appetite and tolerance thresholds.

Governing regulations — Applicable laws, regulations, and industry requirements (e.g., GDPR, HIPAA, SOX).

Standards and certifications — Standards and certifications the program aligns to or pursues (e.g., ISO 27001, SOC 2, NIST CSF).

Framework pillars — The strategic pillars or domains that structure the security program (e.g., Governance, Risk Management, Compliance, Operations).

Roles and responsibilities — Detailed role definitions beyond the core governance roles, documenting who is responsible for what across the security organization.

Review triggers — Conditions that should prompt an out-of-cycle charter review (e.g., major organizational changes, significant incidents, regulatory changes).

Approval workflow

Charters use configurable approval workflows to manage the review and approval process. When a charter is submitted for approval, it moves to Under Review status and creates a workflow instance.

The workflow can include stages such as Initial Review, Legal Review, CISO Approval, and Steering Committee Approval. Each stage can have designated approvers, and the workflow tracks progress, decisions, and comments at every stage.

Approval decisions are recorded as CharterApproval records linked to both the charter and the Steering Committee. Each record captures the approver, decision (Approved, Rejected, or Pending), decision date, and comments.

See Charter Workflows for details on configuring approval workflows, and Settings for setting the tenant-level default workflow.

Version control

Every significant update to a charter creates a new version record. Versions capture:

Version label — A human-readable label (e.g., “v1.0”, “v2.1”) identifying the revision.

Snapshot — A complete JSON snapshot of the charter at the time the version was created, preserving the exact state for audit and comparison.

Change reason — A description of why the update was made, providing context for reviewers and auditors.

Created by — The user who created the version.

Version history is accessible on the charter detail page, allowing you to review how the charter has evolved over time and compare versions.

Strategy alignment

Charters serve as the strategic foundation for security strategies. Multiple strategies can be linked to a single charter, creating a hierarchy where the charter defines the program’s purpose and boundaries, and strategies provide the tactical execution plans.

Linked strategies appear on the charter detail page. When linking or unlinking a strategy, the action is recorded as a charter activity for audit purposes.

See Security Direction for details on creating and managing strategies.

Cross-references

Charters can reference related governance artifacts to establish a connected governance model:

Frameworks — Link to compliance frameworks that the charter aligns with.

Policies — Reference security policies that implement the charter’s directives.

Controls — Connect to security controls that enforce the charter’s requirements.

Risks — Associate organizational risks that the charter addresses.

These cross-references are stored as ID arrays and provide navigational context — they help users understand how the charter connects to the broader security program.

Activity tracking

Every significant action on a charter is recorded as a charter activity. Activity types include:

Activities include a message, description, metadata, and links to the associated workflow instance and stage when applicable.

Permissions

Managing Security Charters requires the security-charter:manage permission. Users with this permission can create charters, edit content, submit for approval, and manage the charter lifecycle. Users without this permission can view charter information in read-only mode.