A city CIO wants a reusable definition for the risk that unpatched internet-facing civic apps can be exploited. What record should the risk team author first?
Select an answer to reveal the explanation.
Short Explanation
You need a reusable recipe card, not a one-time sticky note. Author the risk statement for that exploitation scenario so you can apply it across apps later.
Full Explanation
A city CIO who wants a reusable definition for the risk that unpatched internet-facing civic apps can be exploited needs a reusable risk statement describing that exploitation scenario. The statement is the reusable definition that can later be scoped to many applications. Opening an audit engagement for every application before defining risk language fails by concept because engagements are not the first artifact for reusable risk wording. A one-off incident ticket that disappears when closed fails by concept because incidents are ephemeral and do not define ongoing risk. A policy acknowledgment campaign with no risk wording fails by concept because acknowledgment tracks policy acceptance, not risk definition. Exam caveat: CIS-RC distinguishes reusable risk statements from incidents, audits, and acknowledgment campaigns. Operational check: author the reusable risk statement for unpatched internet-facing civic app exploitation in the risk framework, peer-review the wording, and confirm it can be scoped to multiple application entities without rewriting the definition each time. In civic IRM programs, retain configuration and decision evidence so examiners can reconstruct why this design supports public services.