Residual calculation should reflect controls that mitigate a payment-outage risk. What must be configured?
Select an answer to reveal the explanation.
Short Explanation
Controls are the seatbelts on the risk. Link them to the payment-outage risk so residual math (or judgment) can see what is already buckling in—and what is not.
Full Explanation
Residual evaluation for a payment-outage risk should consider mitigating controls, which requires mapping or linking those controls to the risk so effectiveness informs residual judgment or calculation. Control linkage is how IRM connects second-line safeguards to first-line residual posture for civic payment services. Without links, residual ignores existing protective design.
Listing controls only in a slide appendix with no record links fails traceability and residual logic. Increasing inherent scores automatically whenever a control is attested confuses attestation success with inherent (pre-control) severity. Marking the risk Closed when any related knowledge article exists mistakes documentation presence for treated residual risk.
Exam caveat: inherent versus residual and control effectiveness are distinct. Attestation or knowledge articles do not by themselves close risk records.
Operational check: link mitigating controls to the payment-outage risk; review residual with control effectiveness visible; ensure attestation of a control does not auto-inflate inherent score or auto-close the risk.
When controls are linked, residual discussions for payment outages should reference recent control-test or attestation results so residual judgment reflects actual effectiveness, not merely the existence of a control record. Broken or missing links are a configuration defect: if finance cannot see which encryption, failover, or reconciliation controls mitigate the outage risk, fix mapping before debating scores. Exclude slide-deck control lists from the operating model; only linked IRM controls count for residual evaluation.