CISSP Domain 7, Security Operations, is one of the largest domains on the exam (13%) and the one that most closely mirrors the day job of a working security professional. It is the domain of incident response, SOC operations, vulnerability management, change management, BCP/DR execution, and the dozens of recurring activities that keep a security program functioning week to week. Domain 7 rewards candidates who can think operationally - prioritise under uncertainty, run process at scale, and decide what to escalate and when.
This guide collects the 14 in-depth Domain 7 articles on Threat on the Wire into one structured reference. Use it as a study path or a topic index. Every article assumes you already know the fundamentals and want clarity on how the (ISC)² CBK frames operational security at the manager level.
What Domain 7 is really testing
CISSP lens: the right answer balances rigour with sustainability. Operations is run by humans; pick options that produce repeatable outcomes without burning out the team.
Domain 7 covers the operational rhythms of a security program: detection, response, monitoring, vulnerability and patch management, change control, third-party operations, BCP/DR execution, physical security operations, and the people processes that hold it all together. Almost every Domain 7 question can be reframed as "given normal operating conditions plus this incident or change, what is the right response?"
You will be tested on:
- Foundational security operations: prioritisation, sustainability, escalation.
- Logging and monitoring that produces actionable detection.
- Incident detection and triage: turning alerts into cases.
- Incident response plans and execution.
- Change and configuration management.
- Vulnerability management and patch operations.
- Insider threat detection and user behaviour monitoring.
- Data loss prevention in operations.
- Operationalising IAM (the day-to-day of access control).
- Physical and environmental security operations.
- BCP and DR execution (the operational counterpart to Domain 6 testing).
- Cloud and hybrid security operations.
- Managing third-party and outsourced security operations.
How Domain 7 fits into the rest of the CBK
Domain 7 is the operational layer of every other domain. The risk decisions in Domain 1 get executed here. The classification work in Domain 2 gets enforced here. The architectural choices in Domain 3 get sustained here. The network designs in Domain 4 get monitored here. The IAM systems in Domain 5 get operated here. The testing programs in Domain 6 get acted upon here.
If a Domain 1 risk question feels like it is asking "and then what does the team actually do?", you are in Domain 7 territory.
Core concepts at a glance
| Concept | What it is | Why it matters on the exam |
|---|---|---|
| Incident | An event that causes harm or threatens to | Domain 7's most-tested vocabulary |
| Event vs incident | Event = anything observed; incident = a harmful event | Tested directly with definitional questions |
| SIEM | Security Information and Event Management | Aggregates logs; correlates; alerts |
| SOAR | Security Orchestration, Automation, and Response | Workflow automation on top of SIEM |
| MTTR | Mean Time to Respond / Remediate | Key operational metric |
| MTTD | Mean Time to Detect | Lower MTTD = better detection |
| RTO | Recovery Time Objective | How fast must we recover? |
| RPO | Recovery Point Objective | How much data can we lose? |
| RPO < RTO | Convention: data freshness target stricter than time to recover | Tested with backup-window scenarios |
| Forensic chain of custody | Documented handling of evidence | One break breaks the case |
| DLP | Data Loss Prevention | Endpoint, network, and cloud variants |
| UEBA | User and Entity Behaviour Analytics | Detects anomalies that signature rules miss |
| Change Advisory Board | Reviews and approves significant changes | Tested in change-control scenarios |
Security operations foundations
Operations is judged by sustainability over time, not by heroics on any single day. Security Operations Foundations: Running Day-to-Day Security Without Burning Out Your Team covers the rhythms - shift handovers, queue management, escalation paths, on-call rotations - that turn an inbox of alerts into a functioning operation.
Logging, monitoring, and detection
Detection is what separates a security team from a compliance team. Logging and Monitoring That Actually Helps You Detect Incidents covers what to log, how to centralise it, and how to tune signal versus noise.
Once an alert fires, the work shifts to triage. Incident Detection and Triage: Turning Alerts into Actionable Cases covers severity scoring, evidence preservation, and the decisions that determine whether an alert becomes a case or gets closed.
Incident response
Incident response plans only work if they have been written, exercised, and operated by people who know their roles. Incident Response Plans That Actually Work on Your Worst Day covers the lifecycle (preparation, identification, containment, eradication, recovery, lessons learned), the role definitions, and the communication plan that keeps the response coherent.
The incident response lifecycle
- Preparation: have plans, tools, and trained people before anything happens.
- Identification: detect that an incident is occurring.
- Containment: stop the bleeding without destroying evidence.
- Eradication: remove the threat from the environment.
- Recovery: return systems to normal operation.
- Lessons learned: capture and act on what went well or badly.
The exam tests this order specifically. Containment before eradication. Recovery before lessons learned. Skipping the lessons-learned phase is a wrong answer in scenario questions.
Change and configuration management
Most security incidents trace back to a change that was not properly reviewed. Change and Configuration Management: Keeping Security Controls Stable When Everything Keeps Changing covers the change types (standard, normal, emergency), the Change Advisory Board, configuration drift detection, and the rollback discipline that prevents a small change from becoming a big incident.
Vulnerability and patch management
Vulnerability management is a continuous program; patching is one of its most visible operations. Vulnerability Management and Patch Operations: Staying Ahead Without Breaking the Business covers prioritisation (CVSS, EPSS, exploit availability), patch windows, and the trade-offs between speed of patching and stability of operations.
Insider threat and behaviour monitoring
The insider is the threat that is already inside your perimeter. Insider Threats and User Behavior Monitoring: Watching for Risk Without Becoming Big Brother covers the operational mechanics of UEBA, the legal and ethical considerations, and the program design that distinguishes legitimate monitoring from over-reach.
DLP and IAM operations
Data leaks are a continuous operational problem. Data Loss Prevention in Operations: Keeping Sensitive Data From Walking Out the Door covers endpoint, network, and cloud DLP, the false-positive management discipline, and the integration with classification (Domain 2) and IAM.
Identity is operationalised every day. Operationalizing Identity and Access Management: Least Privilege in Daily Practice covers the day-to-day work of IAM - access reviews, joiner/mover/leaver execution, privileged-session monitoring, and the operational metrics that prove the program is working.
BCP, DR, and operational continuity
BCP and DR are tested in Domain 6 and executed in Domain 7. Business Continuity, Disaster Recovery, and Security Operations: Keeping the Lights On covers the run-time mechanics: invocation criteria, command structure, technical failover, and the security-operations role inside the broader business response.
Physical and environmental security operations
The physical layer of security operations is often forgotten until something goes wrong. Physical and Environmental Security in Daily Operations covers the controls that protect facilities and the environmental factors (HVAC, fire, flood, power) that determine whether the data centre survives a bad day.
Cloud and hybrid operations
Cloud changes the operational model. Security Operations in Cloud and Hybrid Environments: Adapting Your Practices covers the operational shifts - shared responsibility, native logging vs. third-party SIEM ingest, cloud-native incident response - that distinguish cloud security operations from on-premise practice.
Managing third-party security operations
Outsourced operations and managed services bring their own challenges. Managing Third-Party and Outsourced Security Operations Without Losing Control covers the governance, contractual, and operational mechanisms that keep an outsourced SOC or managed security service from becoming a black box.
Real-world SOC scenarios
A SOC manager sees an alert at 3am: a privileged service account is logging in from a country the company does not operate in. The technical instinct is to disable the account. The SOC manager instinct is layered. First, validate - is this a known maintenance window or false positive? Second, contain - block the source IP, force MFA challenge, suspend the account if validated as malicious. Third, gather evidence - capture session details, command history, any data accessed. Fourth, escalate - notify the on-call IR lead and account owner. Fifth, document - the timeline matters more than the speed. Sixth, run the post-incident review and feed the lessons into UEBA tuning. Domain 7 questions reward this structured, evidence-aware response sequence.
A second example: a CISO is told the patching team has fallen 60 days behind on a critical vulnerability. The technical instinct is to push for emergency patching. The operational instinct is broader. First, understand why patching is behind - capacity, change windows, business resistance? Second, prioritise - which 10% of unpatched systems carry 90% of risk? Third, deploy compensating controls (segmentation, additional monitoring) for the remaining systems while the patch backlog clears. Fourth, document the residual risk and get senior management to formally accept it. Fifth, fix the underlying program problem so this does not repeat. Domain 7 expects this risk-based, sustainable approach.
Common exam traps in Domain 7
- Skipping containment. Eradication before containment is wrong. The order is preparation, identification, containment, eradication, recovery, lessons learned.
- Treating event and incident as synonyms. An event is anything observed; an incident is a harmful event or imminent threat of one. The exam tests the distinction.
- Picking the most aggressive response. "Disable the account" is not always the right answer. Sometimes "monitor for further behaviour" is right because aggressive containment destroys evidence or causes downtime.
- Confusing RTO and RPO. RTO is how fast you must recover; RPO is how much data you can afford to lose. They are different objectives, often expressed in different units.
- Forgetting the lessons-learned phase. Many candidates choose recovery as the last step. The exam favours lessons learned as the closing phase.
- Ignoring chain of custody. Evidence integrity matters even when the incident is internal-only. The exam tests this with scenario questions about evidence handling.
- Treating cloud operations as identical to on-premise. Shared responsibility, native services, and cloud-specific incident-response models all change the operational picture. The exam tests the differences.
The full Domain 7 reading order
Operations foundations
Logging, monitoring, and detection
Incident response
Change and vulnerability management
Insider threat and DLP
IAM operations
BCP/DR and physical operations
- Business Continuity, Disaster Recovery, and Security Operations
- Physical and Environmental Security in Daily Operations
Cloud and third-party operations
- Security Operations in Cloud and Hybrid Environments
- Managing Third-Party and Outsourced Security Operations
Exam scenario practice
Related CISSP domains
Threat on the Wire publishes a long-form pillar for every CISSP domain. The eight domains are interlocked - mastering any one of them is easier when you can see how it connects to the others. Here's how this domain relates to the other seven, with a one-line summary of the relationship and a link to the pillar.
| Pillar | How it relates to this domain |
|---|---|
| Domain 1: Security and Risk Management | Domain 1 sets governance and BCP plans; Domain 7 executes them day to day. |
| Domain 2: Asset Security | Retention, DLP, and asset operations from Domain 2 are run here. |
| Domain 3: Security Architecture and Engineering | Hardened systems designed in Domain 3 get sustained in operations. |
| Domain 4: Communication and Network Security | Network monitoring telemetry feeds the detection covered in Domain 7. |
| Domain 5: Identity and Access Management | IAM from Domain 5 is operated daily as part of security operations. |
| Domain 6: Security Assessment and Testing | Domain 6 testing finds weaknesses; Domain 7 operations remediate them. |
| Domain 8: Software Development Security | Application-level operations (deployment, patching, monitoring) bridge to Domain 8. |
For the full CISSP overview, exam structure, and 12-week study plan, see the CISSP Study Hub.
Frequently asked questions
How much of the CISSP exam covers Domain 7?
Domain 7 is weighted at 13% of the exam. Out of roughly 100-150 items, expect 13-20 from Domain 7. The operational reasoning bleeds into Domain 4 networking questions, Domain 5 IAM questions, and Domain 6 testing questions.
What is the difference between RTO and RPO?
RTO (Recovery Time Objective) is how quickly a system must be restored after a disruption. RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time - how far back the recovery point can be. A four-hour RTO and a one-hour RPO together mean: when something fails, we must be running again within four hours, and the recovered system must reflect data no more than one hour old.
Is every alert an incident?
No. An event is anything observed - a login, a process start, a network connection. An incident is a harmful event or the imminent threat of one. SOC operations spend most of their time triaging events to decide which become incidents. The exam tests this distinction directly.
Why does the order of incident response phases matter?
Because acting out of order destroys evidence or makes the response worse. Containing before identifying may stop the wrong thing. Eradicating before containing leaves the threat actor in the environment. Recovering before lessons learned wastes the most valuable artefact of the response: the data about what just happened. The exam tests order explicitly.
What are the standard, normal, and emergency change categories?
Standard changes are pre-approved, low-risk, and follow a documented procedure (no CAB review needed). Normal changes go through the Change Advisory Board for review and approval. Emergency changes happen outside normal windows when the risk of waiting exceeds the risk of changing - typically requiring an emergency CAB and full post-change review.
Key takeaways
- Domain 7 is the operational rhythm of the security program. Sustainability matters as much as rigour.
- Event vs incident is testable vocabulary. An event is observed; an incident is a harmful event.
- The IR lifecycle has six phases in this order: preparation, identification, containment, eradication, recovery, lessons learned.
- RTO is recovery time; RPO is recovery point. They are different objectives.
- Change management has three categories - standard, normal, emergency - each with its own approval path.
- Vulnerability management is continuous and risk-based, not list-driven. Prioritise by exploitability and exposure, not by scanner severity alone.
- Cloud operations need cloud-native thinking. Shared responsibility, native services, and cloud-specific IR all change the playbook.
If you take one thing away from Domain 7, take this: operations is what turns plans into outcomes. A documented IR plan that has never been exercised is not a security control; a half-finished patch program with the wrong priorities is worse than no patch program at all. Run security operations the way you would run any production system - with rigour, repeatability, and continuous improvement.