A risk coordinator uses the word risk for both a generic threat statement library entry and a scored register item for the water treatment plant. How should IRM terminology separate those ideas?
Select an answer to reveal the explanation.
Short Explanation
One is the recipe card, the other is tonight’s dinner at that plant. The statement defines the threat idea; the risk record applies and scores it for a real entity.
Full Explanation
IRM separates a risk statement—the reusable definition of a risk concept—from a risk, which is the scoped, assessed instance tied to an entity such as a water treatment plant. When a risk coordinator uses “risk” for both the library blurb and the scored plant register item, ownership, scoring, and reporting blur. Clear terminology keeps the recipe card distinct from tonight’s dinner at that plant so assessments attach to real civic assets. Saying both uses are identical and that ServiceNow stores only one undifferentiated risk text field erases the definition-versus-instance pattern taught throughout IRM. Calling a risk statement always an audit finding and a risk always a security incident remaps GRC objects into Audit and SIR case types incorrectly. Claiming scoped plant risks belong only in Vulnerability Response denies IRM Risk ownership of entity-scoped risk records. Exam caveat: expect parallel pairs—risk statement versus risk, control objective versus control—on terminology items. Operational check for the coordinator: open a risk statement in the content library, then open a risk record for the treatment plant entity and confirm the plant risk shows entity scope and assessment fields that the statement alone does not carry.