1.6 The SOC Charter
The SOC Charter
Introduction
The SOC charter is the authoritative document that defines what the SOC does, who does it, what authority they have, and how performance is measured. It is the single reference that answers every organizational question: “What is the SOC responsible for?” “Who can disable a user account during an incident?” “What is the expected response time for a Critical alert?” “Who does the SOC report to?”
Without a charter, these answers live in people’s heads and vary depending on who you ask. With a charter, the answers are documented, approved by leadership, and reviewable.
SOC charter template
SECURITY OPERATIONS CENTER CHARTER
======================================================
1. MISSION
The SOC provides continuous monitoring, detection,
investigation, and response for security threats
targeting [Organization Name]'s information systems,
with a focus on the Microsoft 365 and Azure environment.
2. SCOPE
The SOC is responsible for:
- Monitoring the Sentinel incident queue and Defender
XDR alert queue
- Triaging and investigating security alerts
- Executing containment and remediation actions for
confirmed incidents
- Developing and maintaining detection rules
- Maintaining investigation playbooks
- Producing incident reports and conducting post-
incident reviews
- Tracking and reporting operational metrics
- Coordinating with external providers (MDR, IR,
legal, regulatory)
The SOC is NOT responsible for:
- [List exclusions: vulnerability management,
penetration testing, security architecture,
compliance reporting — whatever is handled by
other teams]
3. OPERATING MODEL
[Model selected from subsection 1.1: Dedicated /
Managed / Hybrid / Virtual]
Coverage hours: [24×7 / 8×5 + MDR / etc.]
External provider: [Provider name, contract reference]
4. ROLES AND RESPONSIBILITIES
[Table from subsection 1.2: T1, T2, T3, SOC Manager
with names of current role holders]
5. ESCALATION MATRIX
[Matrix from subsection 1.4: business hours and
after hours, with contact details]
6. AUTHORITY
The SOC is authorized to take the following actions
without prior approval from outside the SOC:
- Revoke user refresh tokens
- Force password reset for compromised accounts
- Remove inbox rules and mailbox forwarding
- Revoke OAuth application consent
- Quarantine/purge phishing email from mailboxes
- Block IP addresses and domains in Defender
Tenant Allow/Block List
The following actions require CISO or delegate
approval:
- Disable user accounts
- Isolate devices via Defender for Endpoint
- Modify conditional access policies
- Disable or modify transport rules
- Communicate externally about incidents
- Engage external IR providers
- Submit regulatory notifications
7. METRICS AND TARGETS
[Table from subsection 1.5 with specific targets]
8. REPORTING
- Monthly SOC dashboard to CISO
- Quarterly SOC maturity assessment to CISO
- Incident reports per Module S8 framework
- PIR action register reviewed weekly
9. REVIEW SCHEDULE
This charter is reviewed:
- Annually (scheduled review)
- After any significant incident (ad hoc review)
- When the operating model changes
- When the organizational structure changes
Approved by: [CISO name, date]
Next review: [date]
======================================================
Why the authority section matters most
The authority section is the charter’s operational core. During a live incident at 02:00, the analyst does not have time to seek approval for routine containment actions. The charter pre-authorizes these actions so the analyst can act within defined bounds without delay.
Equally important: the charter defines what requires external approval. An analyst who disables the CEO’s account without CISO approval because “it seemed urgent” has created a business disruption without authorization. The charter prevents both under-response (analyst hesitates because they are unsure of their authority) and over-response (analyst takes drastic action without appropriate oversight).
The approval requirements should match the containment framework from Module S7 (subsection 7.3). If the playbook says “T2 analyst or SOC manager approval,” the charter should confirm that T2 analysts have this authority.
Get the charter signed by the CISO
A charter that the SOC wrote and the SOC approved is an internal document with no organizational authority. A charter signed by the CISO (or whoever the SOC reports to) carries the weight of leadership endorsement. When the analyst revokes tokens at 02:00, they are acting under authority granted by the CISO through the charter — not acting on their own initiative. This distinction matters when the action is later questioned.
Try it yourself
Draft the Authority section of a SOC charter for your organization. List every containment action your SOC might take and classify it as either "pre-authorized" (SOC can execute without external approval) or "requires approval" (needs CISO or delegate sign-off). Then answer: are there any actions currently ambiguous — where your team is unsure whether they have authority? Those ambiguities should be resolved in the charter.
Check your understanding
1. An analyst revokes a user's refresh tokens during an incident at 23:00. The next morning, the user's manager complains to the CISO: "Your team locked my employee out of their account without telling anyone." The CISO asks the SOC manager to explain. How does the SOC charter protect the analyst?
You're reading the free modules of SOC Operations
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.