After a cloud migration, a residual risk remains that is within the organization's documented risk appetite, and further controls would cost more than the expected loss. Who should formally accept this risk, and how?
Select an answer to reveal the explanation.
Short Explanation
Accepting a risk is a business decision, so it belongs to the person who owns the business outcome and has the authority to sign off. You write it down in the risk register and set a review date so it doesn't quietly rot there. Analysts find risks, auditors check them, and neither of them gets to accept them.
Full Explanation
Risk acceptance is a legitimate treatment when residual risk falls within the organization's appetite and further treatment would cost more than it saves. Because accepting risk commits the organization to bearing potential losses, it must be done by a risk owner, typically the business or system owner with the delegated authority to make that commitment, not by whoever happened to find the issue. The decision is documented in the risk register with the rationale, the residual risk rating, any conditions, and a review or expiry date so it is reassessed as the threat landscape or business changes. A provider's account manager signing an indemnity addendum would represent risk transfer to the provider, not acceptance by the customer, and an account manager is not a party to the customer's internal governance. A security analyst identifies and reports risks but lacks authority to commit the organization to absorbing losses; closing a ticket hides the risk rather than accepting it. Internal audit provides independent assurance and must not make management decisions, because approving risks would impair its independence. Exam caveat: risk acceptance is never permanent and never implicit. Operational check: confirm each accepted risk in the register names an owner with appropriate authority and has a current review date.