Input: the relevant event or risk scenarios with their risk sources, the business processes and objectives, the consequence criteria, and the controls already in place with how effective, implemented and used they are. Action: identify and assess the consequences of failing to preserve confidentiality, integrity or availability. Trigger: not done before; the identified risk list changes; risk owners or interested parties change the units they want consequences in; or scope or context changes affect consequences. Output: potential consequences per risk scenario, tied to assets or events according to the approach. Losing confidentiality, integrity or availability may cause knock-on effects on the organisation and its objectives, and the analysis can work upward from those losses; typically the risk owner estimates the consequence, taking into account the time or data lost through interrupted or disturbed operations, the perceived severity (for example in money), and recovery costs depending on whether recovery is internal or needs an outside party.
This control maps to 1 controls across 1 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.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.