A permit-system risk workshop lists 'hackers' as the only entry without linking specific weaknesses in the application or its environment. What is missing for sound risk identification?
Select an answer to reveal the explanation.
Short Explanation
'Hackers' without a vulnerable door is a scary word, not a risk statement. Risk ID needs the who/what that might attack and the crack they could use—old plugins, weak auth, open admin ports. Pair the threat with the weakness or you're just brainstorming villains.
Full Explanation
Sound risk identification pairs threats with the vulnerabilities those threats could exploit in a specific system and environment. Listing only a generic label such as 'hackers' for a permit system names an actor class without linking weak authentication, unpatched components, exposed APIs, or misconfigured hosting that would make exploitation plausible. Without that pairing, the risk register cannot support meaningful likelihood, impact, or treatment decisions. Marketing claims of being 'unhackable,' replacing analysis with an insurance quote alone, or deleting the register because generic names feel sufficient all abandon structured identification. Municipal permit systems handle identity, payment, and approval workflows; identifying concrete weaknesses turns vague fear into actionable risk entries. Exam caveat: CISSP risk management expects identification of threats, vulnerabilities, likelihood, and impact—not slogan-level threat lists. Operational check: for each critical application, workshop threats against architecture diagrams, dependency lists, and known weakness categories; record linked threat-vulnerability pairs in the register; and refresh when the application or its hosting changes. Use those pairs to drive prioritized remediation rather than endless generic 'cyber' entries.