Risk Tolerance Statement
The board-level declaration of how much of each risk type the organisation will accept, which is what tells an architect which risks may be accepted without escalation.
Architecture decisions accept risk continuously — a single region, a dependency on one vendor, a known vulnerability with no patch, a manual control where automation is not funded. Without a stated tolerance, each acceptance is either escalated, which does not scale, or made silently at whatever level noticed it.
A useful tolerance statement is specific enough to be applied. "We accept no unmitigated critical vulnerabilities in internet-facing systems beyond seven days." "We accept up to four hours of unavailability for non-critical internal services." "We do not accept any single point of failure for payment processing." Those are decidable. "We have a low appetite for operational risk" is not.
What it gives an architect is the boundary between a decision they may take and one they must escalate — which speeds up the ordinary cases and directs attention to the genuine exceptions.
The corresponding obligation is that acceptances within tolerance are still recorded, in a register with an owner and a review date. An organisation that cannot enumerate the risks it has accepted has no way to know whether the aggregate is still within tolerance, which is the question a board actually needs answered.