CISSP Domain 7 Revision: Security Operations

Domain 7 carries the second-highest exam weighting after Domain 1, and it earns that weighting through sheer breadth rather than any single difficult concept. Fifteen objectives cover investigations, monitoring, incident response, disaster recovery, physical security and personnel safety, and the challenge is holding that much ground in your head at once rather than mastering any one particularly hard idea. Grouping the objectives into a few operational clusters makes the domain far more manageable.

Investigations

Understanding investigations here builds directly on the investigation types from Domain 1, but shifts focus to how an investigation is actually carried out.

Evidence collection and handling depends on maintaining chain of custody throughout, documenting who held evidence, when, and what was done with it, since a break in that chain can render evidence unusable regardless of how compelling it looks. Reporting and documentation need to be contemporaneous and factual, avoiding speculation that could undermine credibility later. Investigative techniques cover interview methods, timeline reconstruction and correlation of evidence from multiple sources. Digital forensics tools, tactics and procedures require preserving the state of a system at the point of compromise, commonly through imaging a drive before any analysis touches the original media, so nothing is altered in a way that could be challenged later. Artefacts worth recognising as evidence types span data, computer, network and mobile device sources, each with different volatility: memory contents disappear the moment a machine powers off, while data on disk can persist for years, which is why the order of volatility matters when deciding what to collect first.

Logging and monitoring

This cluster is where most of Domain 7's technical detail sits.

Intrusion detection and prevention systems differ by function rather than just name: detection identifies and alerts, prevention actively blocks. Security Information and Event Management (SIEM) platforms aggregate log data from across an environment and apply correlation rules to surface events that wouldn't be obvious from any single log source alone. Continuous monitoring and tuning keeps detection rules relevant, since an untuned system tends to drift toward either alert fatigue from excessive false positives or blind spots from rules too narrowly configured. Egress monitoring watches data leaving the network, often the more revealing traffic direction for detecting exfiltration, compared with the more heavily scrutinised ingress side. Log management covers the practical discipline of collection, retention and secure storage of logs themselves, which need protection against tampering if they're ever going to hold up as evidence. Threat intelligence, drawing on threat feeds and active threat hunting, shifts monitoring from purely reactive to proactive, looking for indicators of compromise before an alert fires on its own. User and Entity Behaviour Analytics (UEBA) applies behavioural baselines to detect anomalies that signature-based tools miss entirely, an account suddenly accessing systems it's never touched before, for example.

Configuration management

Provisioning, baselining and automation sit together in a single objective because they represent the lifecycle of keeping systems in a known, secure state. A baseline defines what a properly configured system looks like, provisioning brings new systems up to that baseline, and automation reduces the drift that creeps in when configuration is left to manual, inconsistent human effort over time.

Foundational operations concepts

Need-to-know and least privilege reappear from earlier domains, applied here specifically to day-to-day operational access rather than architectural design. Separation of duties splits sensitive operational processes across multiple people, echoing the personnel security principle from Domain 1. Privileged account management controls and monitors the accounts capable of the most damage if compromised, often through dedicated privileged access management tooling rather than standard directory controls. Job rotation moves staff periodically between roles, both reducing single points of failure and making fraud or long-running misconduct harder to conceal. Service level agreements formalise expected performance and availability, giving operations teams a measurable standard to be held against.

Resource protection

Media management and media protection techniques extend the data destruction and classification principles from Domain 2 into the operational reality of handling physical and virtual media day to day. Data at rest and data in transit protection, encryption chiefly, needs to be applied consistently rather than only where convenient, since a gap in either state creates an obvious point of compromise.

Incident management

This objective follows a lifecycle worth memorising in order, since exam questions often describe a scenario partway through an incident and ask what phase comes next.

Detection identifies that an incident may be occurring. Response contains the immediate situation. Mitigation limits further damage while the underlying cause is addressed. Reporting communicates the incident to appropriate internal and, where required, external parties, tying back to the reporting distinctions from Domain 1. Recovery restores affected systems to normal operation. Remediation addresses the root cause so the same incident doesn't recur. Lessons learned closes the loop, feeding findings back into policy, training and technical controls, the same continuous improvement principle that runs through the risk management objective in Domain 1.

Detection and preventative measures

Firewalls, next generation, web application, and network firewalls specifically, filter traffic based on increasingly sophisticated criteria, next generation firewalls in particular combining traditional filtering with application awareness and intrusion prevention capability. Whitelisting and blacklisting take opposite default postures: whitelisting denies everything except what's explicitly permitted, generally the more secure but more operationally demanding approach, while blacklisting permits everything except what's explicitly denied. Third-party security services extend an organisation's detection capability beyond what internal resources alone could sustain, managed detection and response providers being a common example. Sandboxing isolates untrusted code or files in a controlled environment to observe behaviour without risking the production environment. Honeypots and honeynets deliberately expose decoy systems to attract and study attacker behaviour, providing early warning and threat intelligence rather than direct production protection. Anti-malware remains a baseline control, though signature-based detection alone is now widely understood to be insufficient against novel threats. Machine learning and AI-based tools increasingly supplement traditional signature and rule-based detection, identifying patterns that wouldn't trigger a conventional rule, though the exam expects awareness that these tools carry their own risk of false positives and require tuning just as much as traditional systems.

Patch and vulnerability management

Implementing and supporting this discipline means balancing the urgency of closing known vulnerabilities against the operational risk of deploying untested patches into production, which is why most organisations run a staged patch process, testing before broad deployment, rather than patching everything immediately on release.

Change management

Participating in change management processes connects security back to IT operations more broadly. A formal change process, with review, approval and rollback planning, prevents well-intentioned operational changes from introducing unreviewed security risk, and the exam expects recognition that security should have a seat in that approval process rather than being informed after a change has already gone live.

Recovery strategies

Backup storage strategies span cloud, onsite and offsite options, each with different trade-offs between recovery speed and resilience against a site-wide disaster. Recovery site strategies, cold, warm and hot sites, differ mainly in how quickly they can become operational and how much that readiness costs to maintain: a cold site has infrastructure but no live data or systems ready to go, a hot site is fully operational and near-instantly available, and resource capacity agreements formalise access to shared infrastructure in advance of ever actually needing it. Multiple processing sites reduce reliance on any single location, and system resilience concepts, high availability, quality of service and fault tolerance, describe the technical mechanisms that keep systems running through component failure rather than depending entirely on a full site failover.

Disaster recovery

Implementing DR processes covers response, the personnel involved, communication methods used during an event, assessment of actual impact, restoration of systems, and training and awareness so that staff know their role before a real disaster forces them to improvise it. Lessons learned closes this cycle exactly as it does for incident management.

Testing DR plans follows an increasing order of realism and disruption worth memorising precisely: read-through and tabletop exercises talk through the plan without touching live systems, walkthroughs go a step further in detail, simulation tests specific scenarios in a controlled way, parallel testing runs recovery systems alongside live production without cutting over, and full interruption actually takes live systems offline to test genuine failover, the most realistic test but also the riskiest. Communication with stakeholders, test status reporting and regulators needs planning at every stage of this testing spectrum, not just during a genuine disaster.

Business continuity

Participating in BC planning and exercises closes the loop from Domain 1's business impact analysis, moving from planning documents into practised, tested capability, since a continuity plan that has never been exercised carries a level of unverified assumption an organisation can't afford to discover during an actual disruption.

Physical security

Perimeter security controls, fencing, lighting, security personnel among them, form the outermost layer, while internal security controls, badge access, CCTV, mantraps, extend that layered protection inward, echoing the same defence-in-depth logic applied to physical space rather than networks.

Personnel safety and security

Travel security addresses the elevated risk employees face when moving through unfamiliar or higher-risk jurisdictions, particularly for staff carrying sensitive devices or credentials. Security training and awareness in this context extends specifically to insider threat recognition, the impact of social media disclosure on personal and organisational security, and newer concerns like MFA fatigue, where attackers exploit the sheer volume of authentication prompts a user receives to trick them into approving a fraudulent login. Emergency management covers organisational response to events threatening staff safety directly, beyond the purely technical scope of disaster recovery. Duress procedures give personnel a covert way to signal they're acting under coercion, a specific duress code during a forced access attempt, for instance, distinct from any of the incident response mechanisms covered earlier because the threat here is to a person rather than a system.

Where AI now sits in Domain 7

Security operations is arguably where AI has the most immediate, practical presence, sitting inside the SIEM and SOAR platforms this domain already covers rather than as something bolted on separately. Correlating events across a high volume of alerts and surfacing the ones that actually matter is exactly the alert fatigue problem the logging and monitoring objective raises, and AI is now a standard part of how that problem gets managed at scale.

There's an operational flip side worth remembering too: once AI is running in production, it needs monitoring in its own right. Model drift, where a model's performance degrades gradually as the real-world data it encounters diverges from what it was trained on, is a genuinely new category of operational risk that doesn't map cleanly onto the incident lifecycle covered earlier, since drift is a slow decline rather than a discrete event with a clear point of detection. Treat it as security operations extending its remit to cover the model as an operational asset, not just the infrastructure the model runs on.

Final thought for revision

Domain 7 is less about mastering any single hard concept and more about holding a working operational picture of an entire security function at once: detection feeding into response, response feeding into recovery, recovery tested against disaster scenarios, all wrapped in the physical and personnel controls that keep the people running it safe. Study it in the operational clusters above rather than as fifteen disconnected objectives, and the volume becomes far less intimidating.