Control tests, risk responses, and audit fieldwork all surface remediation work for the same utility. How should the IRM design treat those remediation items?
Select an answer to reveal the explanation.
Short Explanation
Picture one city work-order desk for potholes, whether a citizen, inspector, or auditor reported them. IRM’s shared issue process is that desk—one remediation lifecycle no matter if the gap came from a control test, a risk, or an audit finding. Separate tables just make the same leak look like three different problems.
Full Explanation
Control tests, risk responses, and audit fieldwork that all surface remediation for the same utility should feed a shared IRM issue process and table so remediation follows one lifecycle regardless of source. One work-order desk for civic gaps prevents the same encryption or access failure from appearing as three unrelated problems with three owners and three due-date schemes. Shared issues are a common IRM foundation across Policy, Risk, and Audit.
Creating a separate issue table for each source app so control, risk, and audit never share records multiplies status chaos and blinds executives. Routing every remediation item only through Incident Management and retiring the IRM issue object collapses compliance remediation into ITSM incident semantics. Storing remediation notes only on the parent risk statement and never opening an issue leaves no assignable remediation object.
Exam caveat: shared issue lifecycle across sources is intentional architecture. Parallel issue tables and incident-only remediation are common wrong turns on CIS-RC.
Operational check: open issues from a failed control test, a risk response, and an audit finding into the same issue process; confirm common fields, reporting, and aging; show leadership one remediation backlog for the utility rather than three siloed lists.