Risk Identification, Monitoring and Analysis

3.1 Understand risk management

Core idea: risk treatment.

Scenario: A high CVSS finding is isolated in a lab, while a lower score affects an internet-facing payment service.

Practitioner response: Prioritize remediation using exploitability, exposure, business impact, compensating controls, and documented risk tolerance.

Concepts to Understand

• risk visibility and reporting: risk visibility and reporting is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• risk register: risk register is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• threat intelligence and indicators of compromise: threat intelligence and indicators of compromise is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• CVSS: CVSS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• MITRE ATT&CK: MITRE ATT&CK is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• impact assessments: impact assessments is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• threat modeling: threat modeling is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• risk frameworks: risk frameworks is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• risk appetite and tolerance: risk appetite and tolerance is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• risk treatment: risk treatment is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

3.2 Understand legal and regulatory concerns

Core idea: legal constraints.

Scenario: Monitoring can capture personal data from employees in several jurisdictions.

Practitioner response: Verify lawful basis, privacy notices, retention, access controls, and jurisdictional restrictions before expanding collection.

Concepts to Understand

• jurisdiction: jurisdiction is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• limitations: limitations is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• privacy: privacy is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

3.3 Perform security assessments and vulnerability management activities

Core idea: vulnerability management.

Scenario: A supplier's system connects to production but has not provided recent vulnerability remediation evidence.

Practitioner response: Perform supplier risk review, request evidence, document findings, and track remediation or acceptance through governance.

Concepts to Understand

• risk framework implementation: risk framework implementation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• security testing: security testing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• internal, supplier, and architecture review: internal, supplier, and architecture review is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• vulnerability scanning, reporting, analysis, and remediation: vulnerability scanning, reporting, analysis, and remediation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

3.4 Operate and monitor security platforms

Core idea: monitoring operations.

Scenario: A SIEM receives firewall logs but not identity-provider events for privileged access.

Practitioner response: Add identity, endpoint, network, and application sources needed to correlate privileged activity and protect log integrity.

Concepts to Understand

• continuous monitoring: continuous monitoring is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• source systems: source systems is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• events of interest: events of interest is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• log management: log management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• log integrity and preservation: log integrity and preservation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• SIEM monitoring, analysis, tracking, and audit: SIEM monitoring, analysis, tracking, and audit is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

3.5 Analyze monitoring results

Core idea: monitoring analysis.

Scenario: An alert fires thousands of times per day and analysts ignore the queue, but it sometimes catches real privilege abuse.

Practitioner response: Tune noise using baseline context while preserving high-risk signals and escalation paths.

Concepts to Understand

• baselines and anomalies: baselines and anomalies is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• correlation and noise reduction: correlation and noise reduction is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• visualizations, metrics, and trends: visualizations, metrics, and trends is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• event data analysis: event data analysis is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• documenting and communicating findings: documenting and communicating findings is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

vulnerability vs threat vs risk

This comparison is covered through the domain objectives above and the SSCP review sheet.

Risk Avoidance vs Mitigation vs Transfer vs Acceptance

Exam clue: Acceptance must be explicit and authorized; informal tolerance is not governance.

SIEM alert vs incident

This comparison is covered through the domain objectives above and the SSCP review sheet.

baseline vs anomaly

This comparison is covered through the domain objectives above and the SSCP review sheet.