Cyber Risk Identification
What the domain tests
Cyber Risk Identification tests whether you can build a defensible inventory of cyber risk before anyone quantifies it. The exam expects a lifecycle view: establish context, identify assets and business processes, map threats and vulnerabilities, assess existing controls, and record risks in a structured register. NIST CSF 2.0's Identify function and ISO/IEC 27005 both frame this as context-driven, not a one-off scan.
Core rules
- Start from business services and information assets, then trace dependencies: applications, data stores, identity providers, cloud services, vendors, and OT/IoT.
- Separate threat (who or what can cause harm), vulnerability (a weakness), and risk (the effect of uncertainty on objectives). A vulnerability alone is not a risk.
- Use multiple sources: asset inventory/CMDB, data-flow diagrams, threat intelligence, vulnerability scans, penetration tests, control assessments, incident lessons, and third-party inventories.
- Write risk statements as cause → event → impact, tied to a business objective. Example: "Because admin access lacks phishing-resistant MFA, a credential-stuffing campaign could take over the payment console, causing fraud losses and regulatory notification."
- Record owner, affected asset/process, threat, vulnerability, existing controls, potential impact, and identification date in the risk register.
Worked example
An online retailer exposes a payment API. Identification finds: customer PII and tokenized card data; threats include credential stuffing and a SaaS provider breach; vulnerabilities include an unpatched logging library and no MFA on the admin portal; existing controls include WAF and tokenization. The risk is not "unpatched library." It is: "Because the logging library is unpatched and admin MFA is absent, an attacker could exploit the API and reach payment tokens, causing fraud loss and breach notification." That statement links cause, event, and business impact and can be assessed later.
Traps
Treating a scanner output as the risk register; missing third parties and identity providers; writing vague scenarios ("cyber attack"); ignoring business-process criticality; and failing to distinguish existing controls from planned controls.