The entity must keep a complete, current assessment of its operational risk profile. To support that it must: (a) run adequate information systems that monitor operational risk, gather and analyse risk data and support reporting upward to senior management and the Board; (b) record, for each critical operation, the processes and resources it depends on (staff, facilities, technology, information and service providers), how they depend on each other, and the risks, obligations, controls and key data attached; and (c) use scenario analysis to gauge how badly severe operational risk events could hit, test resilience and find where controls or other mitigations need to be added or changed.
This control maps to 2 controls across 2 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
APRA CPS 230 Operational Risk Management 26 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of APRA CPS 230 Operational Risk Management your existing evidence covers. Hold NIST Cybersecurity Framework 2.0 and 30 of 87 APRA CPS 230 Operational Risk Management controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 4 were rejected on the NIST Cybersecurity Framework 2.0 pair alone.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.