The SOC Charter

One document, one source of truth

The SOC charter is the master operational document. It's not a strategy paper or a vision statement. It's the authoritative reference that defines what the SOC does, how it does it, who does what, and how effectiveness is measured. When the CISO asks "what are our response SLAs?" the answer is in the charter. When a new analyst asks "when do I escalate?" the answer is in the charter. When the auditor asks "how do you measure detection effectiveness?" the answer is in the charter.

Organizations without a charter answer these questions from memory, from fragmented documents, or from the last person who was asked. The answers drift. The CISO describes strategic objectives. The SOC lead describes operational procedures. The analyst describes the alert queue. Nobody describes the same function because nobody defined it in one place.

Estimated time: 40 minutes.

Question 1: What does the SOC do?

Mission statement

The charter opens with a mission statement — two or three sentences that define the SOC's purpose in terms the CISO, the board, and the team all understand. This is not a marketing statement. It's a scoping document.

NE's mission statement: "The Northgate Engineering Security Operations Center monitors, detects, investigates, and responds to security threats across the Microsoft 365 environment. The SOC operates a hybrid model with internal business-hours coverage and managed after-hours triage through BlueVoyant. The SOC measures its effectiveness through detection quality metrics (MTTD, false positive rate, external discovery rate) and reports quarterly to the CISO."

Three sentences. What the SOC does (monitor, detect, investigate, respond). What environment it covers (Microsoft 365). How it's staffed (hybrid). How it's measured (quality metrics). How it reports (quarterly to CISO). Every subsequent section of the charter elaborates on one of these.

This is the document your SOC builds by the end of Module 1. Sections 1-4 draw from the operational artifacts in Sections 1.1-1.5. Section 5 draws from Section 1.10 (Incident Classification). Section 6 draws from Section 1.6 (Operational Metrics). Section 7 is the most important — every known gap documented with a status and a mitigation plan.

Scope — in and out

The scope section defines what the SOC monitors and — critically — what it doesn't. This prevents scope creep, the gradual expansion of the SOC's responsibilities beyond its capacity. Scope creep is the mechanism by which SOC teams become responsible for vulnerability management, IT helpdesk escalations, compliance questionnaire responses, and physical security monitoring — none of which are SOC functions, all of which consume analyst time that should go to detection and response.

Scope creep happens gradually and often through reasonable-sounding requests. "Can you also check this compliance report while you're in Sentinel?" "Since you already monitor sign-ins, can you also handle password reset requests?" "The IT team is busy — can you triage these helpdesk tickets that look security-related?" Each request is small. Together they consume hours per week of analyst time that should go to the SOC's core mission. The charter's out-of-scope section is the organizational boundary that prevents this accumulation.

NE's in-scope: identity threats (credential compromise, AiTM, token theft, device code phishing), email threats (BEC, phishing, inbox manipulation, external forwarding), endpoint threats (malware, lateral movement, living-off-the-land techniques), cloud application threats (OAuth abuse, consent grants, data exfiltration), and infrastructure threats (Azure resource manipulation, privilege escalation). Each domain maps to specific Sentinel data sources and detection rules built in Modules 3-6.

NE's out-of-scope: vulnerability management (owned by IT Security — the SOC uses vulnerability data for investigation context but doesn't own the scanning or remediation workflow), IT helpdesk (owned by IT Operations — "I can't log in" goes to helpdesk, not the SOC, unless the analyst suspects the access issue is security-related), compliance audit and questionnaire completion (owned by GRC — the SOC provides metrics data for compliance reporting but doesn't own the compliance framework), physical security (owned by Facilities), network operations monitoring (owned by Network Engineering). Each out-of-scope item names the owning team and the handoff procedure — so when someone asks the SOC to handle a vulnerability scan result, the charter directs them to IT Security and specifies that the SOC will consume the scan data for investigation enrichment but will not own the remediation tracking.

Operating model reference

The charter references the operating model ADR from Section 1.1 — summarizing the model choice (hybrid), the rationale, and the known gaps. The full ADR is an appendix to the charter. This gives the charter reader the operating model context without duplicating the full ADR analysis.

Question 2: Who does the work?

Tier definitions

The charter includes the tier definitions from Section 1.2 — condensed into a reference format. For each tier: the scope boundary, the escalation trigger, and the expected output. The full tier analysis stays in Section 1.2. The charter provides the operational reference: L1 has 15 minutes to classify or escalate. L2 has 2 hours to scope and recommend. L3 has protected time for feedback loop work.

RACI matrix

The charter includes a Responsibility Assignment Matrix that maps SOC activities to roles. For each activity (triage, investigation, containment, detection development, metrics reporting, MSSP management), the matrix assigns: Responsible (who does the work), Accountable (who owns the outcome), Consulted (who provides input), Informed (who needs to know).

At NE, the RACI looks like: Triage — Responsible: L1 analyst on shift; Accountable: SOC lead; Consulted: none; Informed: none. Investigation — Responsible: L2 analyst; Accountable: SOC lead; Consulted: L3 for complex cases; Informed: CISO for Severity 1. Containment — Responsible: SOC lead; Accountable: CISO; Consulted: IT Operations (for service impact); Informed: Legal (for regulatory assessment). Detection development — Responsible: L3/SOC lead; Accountable: SOC lead; Consulted: threat intel, IT Security; Informed: CISO (quarterly report).

The RACI prevents two common problems: activities that nobody owns (the detection feedback loop has no responsible party, so it doesn't happen) and activities that everyone informally owns (three people think they're responsible for containment, so containment is either duplicated or delayed while they coordinate).

Managed SOC integration

For hybrid models, the charter defines the managed SOC's role, responsibilities, and boundaries. NE's charter specifies: BlueVoyant is responsible for after-hours L1 triage using custom NE-specific runbooks. Escalations from BlueVoyant go to the on-call internal analyst for Severity 1 only and to the queue for Severity 2-4. BlueVoyant does not perform L2 investigation on ongoing internal investigations. Weekly review of BlueVoyant's closure patterns is the SOC lead's responsibility.

Question 3: How does work flow?

Alert lifecycle

The charter defines the end-to-end path of an alert: alert fires in Sentinel → incident created → assigned to L1 → triage framework (enrichment, classification) → disposition (TP → L2 investigation → containment → remediation → post-incident review; FP → close with rationale; BTP → close with rationale + exclusion assessment; UND → escalate per capability trigger). This lifecycle is a reference diagram in the charter — the single-page visualization that shows how any alert progresses from creation to resolution.

Escalation reference

The charter includes the three escalation triggers from Section 1.4 in a one-page reference format: capability trigger (15-minute boundary), pattern trigger (cross-alert correlation), instinct trigger (analyst judgment, never penalized). Plus the four-field escalation format: trigger type, entity, evidence checked, question for L2.

Handover reference

The charter includes the shift handover checklist from Section 1.3: four fields (active incidents, investigation findings, next step, urgency and context), 10-minute maximum, structured format. Plus the MSSP-specific handover elements (VIP list, scheduled process document, custom runbook reference).

Question 4: How do we measure?

Metrics definitions

The charter defines each metric the SOC tracks: what it measures, how it's calculated, what data source feeds it, and what the target is. The speed metrics (MTTT, SLA compliance, throughput) and quality metrics (MTTD, false positive rate, classification accuracy, external discovery rate, escalation accuracy) from Section 1.6 are included as a reference table.

Reporting cadence

Weekly (SOC lead internal review), monthly (SOC lead to CISO), quarterly (CISO to board). Each cadence has a defined format and audience. The quarterly board report is the document that demonstrates SOC effectiveness with data — and the charter specifies what that report contains.

Response SLAs

The charter defines response time targets by severity: Severity 1 (critical confirmed compromise) — initial response within 15 minutes, containment within 1 hour, CISO notification within 30 minutes. Severity 2 (high-confidence probable compromise) — initial response within 30 minutes, investigation within 2 hours. Severity 3 (medium-confidence possible compromise) — initial response within 1 hour, investigation within 4 hours. Severity 4 (low-confidence, informational) — initial response within 4 hours.

These SLAs are defined in the charter, not in the MSSP contract. The MSSP contract aligns to the charter's SLAs, not the other way around. This ensures the SLAs reflect the organization's risk tolerance rather than the MSSP's service tier.

The charter review cadence

A charter without a review cadence is a snapshot that becomes stale. The review cadence ensures the charter stays current as the SOC, the threat landscape, and the organization evolve.

Quarterly review

Every quarter, the SOC lead reviews the charter against the current operational state. Has the operating model changed? Have the tier definitions shifted? Has the MSSP contract changed? Are the metrics targets still appropriate? The quarterly review takes 1-2 hours and produces either "no changes" or a versioned update with a change log.

Trigger-based review

Outside the quarterly cadence, specific events trigger an immediate charter review: a Severity 1 incident that exposed an operational gap, a change in the managed SOC contract, a significant change in the detection library (new domain coverage, major rule deployment), a change in SOC staffing (new hire, departure, restructure), or a change in organizational risk posture (acquisition, new regulation, new crown jewels).

NE's charter has been through four versions since INC-NE-2026-0227-001. Version 1 was the post-incident baseline. Version 2 added the instinct escalation trigger after INC-NE-2026-0342. Version 3 updated the MSSP integration section when BlueVoyant's custom runbooks were finalized. Version 4 adjusted the metrics targets based on six months of quality data. Each version has a change log that documents what changed and why.

CISO signature

The charter is authoritative because it has executive approval. The CISO signs the charter — confirming that the SOC's mission, scope, staffing, and metrics targets align with the organization's security strategy. The signature converts the charter from "the SOC lead's document" to "the organization's document." When scope creep pressure arrives ("can the SOC also handle these compliance questionnaires?"), the charter provides the documented, CISO-approved answer: that's out of scope.

Building your charter

Start with the four-question framework. Write one paragraph for each question based on the artifacts you've built in Sections 1.1-1.6. Then expand each paragraph into the full section. The charter should be 8-12 pages — comprehensive enough to be authoritative, short enough to be readable.

Use NE's charter structure as a template: mission and scope (2 pages), roles and responsibilities including RACI (2 pages), operational procedures — escalation, triage, handover (3 pages), metrics and reporting (2 pages), appendices — operating model ADR, MSSP contract summary, glossary (1-2 pages).

Getting stakeholder buy-in

The charter requires input from three stakeholders: the SOC team (who will operate under it), the CISO (who will approve it), and IT Operations (who share responsibility boundaries with it). Draft the charter with the SOC team, review it with IT Operations for scope boundary agreement (the out-of-scope items should match IT's understanding of who owns what), and present it to the CISO for approval.

The CISO review is the most important step. Rachel's review of NE's first charter draft produced two changes: she expanded the scope to include cloud infrastructure threats (originally omitted because the SOC hadn't built detection rules for Azure yet — but the charter should define the target scope, with gaps documented as known limitations) and she adjusted the quarterly reporting format to align with the board's risk reporting template. Both changes improved the charter. Neither would have happened without executive review.

Version control and change management

The charter is a versioned document. Every change produces a new version with a date, a change description, and an approval signature. The version history is part of the charter itself — an appendix that shows how the SOC's operational foundation has evolved.

NE uses a simple versioning scheme: v1.0 (initial post-incident charter), v1.1 (instinct trigger addition), v1.2 (MSSP runbook integration), v1.3 (metrics target adjustment). Minor changes (wording clarification, contact information updates) increment the minor version. Structural changes (new escalation trigger, new scope item, new metric) increment the major version.

The first version will have gaps. That's expected and documented. The charter includes a "known gaps" section — the same concept as the ADR's known gaps from Section 1.1. Each gap has a mitigation plan or an acceptance rationale. Gaps are closed progressively as the SOC matures through the course modules. The charter evolves with the SOC.

Where the charter lives

The charter lives where the SOC works. At NE, the charter is a pinned document in the SOC Teams channel, with a printed copy on the SOC lead's desk. The digital version is the authoritative source — the printed copy is a quick reference that analysts flip to during shift for the escalation triggers or the triage enrichment steps.

The charter is not in a SharePoint library that requires three clicks to find. It's not buried in a compliance documentation hierarchy. It's on the desk, in the channel, and in the new analyst's onboarding packet. Accessibility determines usage. A charter nobody can find is a charter nobody uses.