Technology Risk Assessment and Acceptance

Consider a fictional technology risk register entry added three years before an outage. Primary order database runs in a single cloud region; a regional failure would stop order-taking. Likelihood: low. Impact: high. Rating: amber. Owner: Head of Infrastructure. Mitigation: multi-region deployment planned. It was reviewed every quarter, and every quarter it stayed amber.

When the region failed in this scenario, order-taking stopped for eleven hours. The post-incident review found that the multi-region project had been deferred twice and that the register still referred to a former Head of Infrastructure who had left eighteen months earlier, with no recorded handover. It contained no authorized acceptance of the remaining exposure. It had identified a failure scenario without resolving who would decide how to handle it.

Assessing technology risk should lead to a response, but a newly identified risk may still need analysis before a decision is possible. Record that uncertainty and assign the next action. A complete-looking list is useful only if readers can distinguish decisions made from decisions still due.

A risk is a scenario with two estimates

Technology risk assessment considers a potential event, the harm it could cause, and how likely that harm is over a stated period. NIST’s risk definition links likelihood and impact; neither a probability nor a severity label alone describes the exposure.

The event is where most register entries are weakest. Database risk or cloud dependency cannot be estimated, because there is no event to attach a likelihood to. A usable statement names a cause, an event, and a consequence: a regional outage takes the only replica offline, and orders stop for the duration. That form makes both estimates possible and makes controls assignable, since each control addresses one part of the chain. The method of building such statements is covered in risk assessment; for security scenarios, the same chain is what a threat model records as a path.

Make the basis of a likelihood estimate visible

Likelihood estimates can combine incident data, models, and expert judgment. For a regional outage, distinguish the chance of the event from the chance that it interrupts this workload despite its controls. State the evidence and uncertainty so that a reviewer can challenge the estimate, rather than treating a label as an observed frequency.

Some risk matrices multiply ordinal scores such as 1–5. Equal products then suggest comparability that the scale does not establish: a rare catastrophe and a frequent nuisance may need different responses. Other matrices use an explicit lookup table or escalate severe consequences without multiplication. Whether a low-likelihood, high-impact event becomes amber depends on those rules. Any coarse classification can hide ranges and uncertainty, so retain the underlying scenario and estimates alongside the color.

State the time horizon, because low over a quarter and low over five years are different claims. State the basis: past incidents, provider history, or explicit judgment, so that the estimate can be challenged. And for high-impact scenarios, estimate the consequence in the terms the business uses — hours without orders, customers affected, regulatory exposure — rather than on a five-point scale, since those are the numbers a decision-maker will actually weigh. The general reasoning about weighing likelihood against cost is set out in risk-based decisions.

The register is a record of decisions

A risk register preserves current risk information and its history. Include newly identified risks, assessments in progress, decisions awaiting approval, and the status of selected responses. A pending decision needs an owner, a next action, and a due date. Keep it visible until resolved; removing undecided entries would hide exposure rather than manage it.

The fields and maintenance practices are set out in risk register. Keep the risk rating, chosen response, approval status, and implementation status distinct. Record who decided, under which authority and conditions, when to review, and any expiry. A color cannot answer those questions, but adding a decision field does not remove the need to retain the estimate.

Selecting a response and tracking its implementation

NIST describes acceptance, avoidance, mitigation, sharing, and transfer, including combinations over time. Risk response explains what each requires. Selecting a response and achieving its intended effect are separate events.

A planned additional control has not yet earned a reduction in the estimate. Assess current residual risk using the controls already operating and any completed, verified stages; record the expected reduction from future work separately. Carrying that exposure does not establish authorized acceptance. Link the mitigation plan, milestones, and current acceptance decision—or a pending decision and interim restrictions—to the same risk ID. A delay triggers reassessment of exposure and approval conditions. It requires renewed approval when it changes the authorized scope, period, or conditions; an expired approval without renewal leaves unapproved exposure. Risk control and security control explain the evidence needed to count a control as operating.

Sharing and transfer allocate specified consequences and responsibilities through an arrangement with another party. Insurance may cover financial loss without restoring customer service; a provider contract may allocate operational duties while leaving important obligations with the customer organization. Check what actually moves and what remains. If a provider’s controls reduce likelihood or impact, assess that mitigation separately. The organization still needs to understand recovery dependencies, replicated data, restore paths, and timing, as described in Replication Is Not Recovery.

Who may accept what

Acceptance concerns residual risk under current controls. Risk appetite expresses the kinds and amount of risk the organization is willing to take for its objectives; tolerance makes that direction applicable to particular outcomes and decisions. They need not be two nested numerical thresholds. For service reliability, risk tolerance can inform several requirements. An error budget measures allowance under an SLO for a defined population and window; a recovery-time objective limits recovery duration for a specified event. Meeting one does not establish the other, and neither grants acceptance authority.

The following is an example of how an approved delegation and exception policy could route decisions. Local mandates must define the actual holders, scope, review rules, and constraints. Escalation requests a decision; it does not guarantee approval.

Situation	Decision route	Required condition
Within applicable limits and delegated scope	The explicitly authorized risk acceptor, who may be the system owner	Record the evidence, scope, conditions, review date, and any expiry
Outside the local delegation, with an exception route available	The designated business or technology authority	Confirm its mandate and approve any exception before relying on it
Outside organizational direction, or no valid exception authority	Escalate for an authorized policy decision; restrict, avoid, or mitigate the activity as needed	A short duration does not waive a binding constraint; any permissible change to policy requires its own approval

This applies decision rights to risk. A governance body may resolve trade-offs only within its mandate. In the fictional opening, the actual eleven-hour loss is a result to compare with the organization’s requirements and the estimates available before the outage. The story supplies no appetite limit from which to conclude that eleven hours necessarily exceeded it. The demonstrated failure is the missing decision and handover record.

For individual findings and temporary departures from standards, an approved exception may have an expiry; enduring approved alternatives need their own scope and review rules; see vulnerability exception, and its use in Twelve Thousand Findings and A Standard Nobody Could Deviate From. Maintenance deferrals may create lifecycle or delivery risk. Where a design or implementation constraint also increases future change effort, record the related technical debt. A maintenance backlog alone does not establish that additional effort.

Keep ownership current and define review triggers

The distinction between doing the work and answering for it is explained in responsibility and accountability. Record the accountable role and its current holder, their mandate, and any deputy or vacancy route. A role can provide continuity if that mapping is maintained; a person’s name alone can also become stale. Make transfer explicit when people move, and distinguish ownership of the risk from authority to accept it.

Schedule reviews for accepted risks and unresolved decisions, and define what brings them forward. Relevant events include a related incident, a change to the system, a supplier change, or a regulatory change. Also monitor indicators — measurable signals that the estimate may be wrong, such as rising error rates on the dependency concerned, repeated near misses, or a slipped milestone on the mitigation. A risk whose indicator moves should not wait for the next committee meeting.

Each decision to accept, renew, or close is itself a decision worth recording with its reasoning, in the form described in decision record; the register holds the current state and the record explains how it got there.

Judging a risk process

• Decision coverage and overdue actions. Track selected responses separately from pending assessments or approvals, including the age and owner of each overdue action.
• Valid ownership. Check that each accountable role maps to a current holder or an explicit deputy/vacancy arrangement with the required authority.
• Acceptance within authority. Check the approval scope, applicable limits and exception rules, conditions, and expiry where one applies.
• Missed mitigation milestones. Record the effect on current exposure and approval conditions, the reassessment outcome, and any required renewal. A delay alone is not an unrecorded renewal.
• Assessment currency. Track the last substantive review and its evidence. An unchanged estimate can be valid when its assumptions were checked.
• Incident comparison. Compare the pre-incident scenario, decisions, and actions with what happened. Coverage alone does not show that the register influenced decisions.

A heat map and an entry count describe the record, but do not demonstrate that responses were authorized or implemented. An unchanged quarterly assessment can be justified; retain the evidence and reasoning that distinguish a review from a copied status.

The sentence each entry should support

For every significant technology risk, the register should explain what could happen, the estimated harm and its basis, the current response and its authority, and when to review. If a decision is pending, it should instead name the decision needed, its owner and due date, and the interim measures governing continued exposure.

At the first deferral in the fictional example, the team should have reassessed the scenario using the recovery estimate, uncertainty, and constraints known then. An authorized decision could have accepted the current residual exposure, required temporary controls, or restricted the activity. The later eleven-hour outage would test that earlier assessment; it was not an exact duration the decision-maker could be assumed to know. Another deferral would prompt a further check of the estimate and approval conditions.

References

• NIST CSRC Glossary — risk
• NIST CSRC Glossary — likelihood of occurrence
• NIST CSRC Glossary — risk register
• NIST CSRC Glossary — risk response
• NIST CSRC Glossary — risk appetite
• NIST CSRC Glossary — risk tolerance
• NIST IR 8286 Rev. 1 — Integrating Cybersecurity and Enterprise Risk Management (2025)
• NIST SP 800-39 — Managing Information Security Risk (2011)
• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments (2012)