Build a risk register that changes decisions

A risk register earns its place when it changes priorities, resources, or implementation. It should help an engineering leader decide whether to delay a release, restrict a permission, fund recovery work, or accept an exposure for a defined period. A list of red, amber, and green entries is not enough.

Begin with scenarios the business can recognize rather than labels such as “cyber risk.” Then connect each scenario to the affected service, assessment evidence, controls, treatment work, and accountable decision-maker. The register becomes useful when someone can follow that chain and explain why the next action matters.

Define the decisions before designing the register

Start with one product, business process, or managed service. Identify its critical dependencies, important information, external providers, and operating constraints. A focused boundary makes it easier to test the method before applying it across the organization.

Ask the people who will use the register what decisions they need to make. A platform lead may need to choose between improving recovery and replacing a legacy component. A support manager may need to approve narrower access without disrupting customer service. A CTO may need to decide whether a launch can proceed with unfinished treatment work.

Define the assessment method and approval rules before collecting scores. As a practical recommendation, document:

• The assessment horizon, such as exposure over the next twelve months.
• Likelihood and impact definitions, including how conflicting impact dimensions are handled.
• Risk appetite and operational tolerance thresholds.
• Who can approve treatment and accept residual exposure.
• Review intervals and events that require reassessment.

Risk appetite expresses the kinds and levels of risk the organization is willing to pursue or retain. Tolerance translates that position into usable boundaries, such as a maximum acceptable outage or restrictions on uncontrolled customer-data exports.

For an ISMS aligned with ISO/IEC 27001, clauses 6.1.2 and 6.1.3 address risk assessment and treatment. Clause 8.2 calls for assessments at planned intervals and when significant changes occur or are proposed. The standard does not prescribe one universal annual schedule or scoring matrix. Your method must work within the actual ISMS scope.

Give every entry enough structure to support action

A register can begin in a spreadsheet. Its usefulness depends on relationships, ownership, and maintenance, not its file format. More connected tooling becomes valuable when manual reconciliation makes those relationships unreliable.

Use a stable identifier and a small set of fields that answer practical questions. Keep lengthy technical evidence in linked records rather than copying it into every row.

Distinguish risk status from task status. “Treatment in progress” does not mean exposure has decreased. “Accepted” does not mean the scenario has disappeared. Reserve closure for circumstances such as the affected activity ending or the scenario no longer applying, and retain the reasoning.

Likewise, a vulnerability, failed control, and risk are related but different records. A missing patch is a weakness. A failed deployment check is a control issue. The risk describes what could happen because of those conditions and why it matters. Link detailed findings to that scenario instead of creating a separate enterprise risk for every scanner result.

Discover scenarios from the way the service works

Use architecture and operational evidence to identify risks. Bring engineering, security, service owners, support, and relevant business functions into a focused discussion. Policies alone rarely reveal where permissions are broader than intended, recovery depends on one person, or a supplier has become a critical dependency.

Useful inputs include data-flow diagrams, access reviews, incident records, restore tests, supplier assessments, vulnerability findings, change proposals, and unresolved audit observations. Threat modeling can help teams examine trust boundaries and plausible failure paths.

A useful scenario follows this pattern: an event affects a particular service through an identifiable weakness, producing stated consequences.

For example: a compromised support account permits export of customer records because permissions are excessive, causing unauthorized disclosure and response work. This is more actionable than “account compromise.” It identifies both an attack path and controls that could interrupt it.

Look beyond confidentiality. Include outages, corrupted records, failed recovery, supplier disruption, administrative misuse, and unavailable expertise. For AI-enabled functions, consider incorrect outputs being acted on, sensitive information entering an unsuitable service, or an agent executing beyond its intended authority.

Deduplicate scenarios carefully. Two services may share an identity provider but have different consequences and treatment options. Conversely, several findings may contribute to one export scenario. Aggregate where the decision and owner are shared; separate where the business consequences or treatment decisions differ.

Record discovery gaps as work. If nobody knows which customers use an export feature, that uncertainty should produce an investigation task, not an invented impact estimate.

Assess exposure without manufacturing precision

Establish a common scoring language

Likelihood and impact need definitions that assessors can apply consistently. For likelihood, distinguish threat activity from the probability that the whole scenario succeeds. Frequent phishing attempts do not automatically mean frequent bulk disclosure: authentication, privileges, session controls, and export restrictions affect the path.

Impact should reflect the business outcome. Consider service interruption, disclosure, integrity loss, response costs, contractual consequences, and harm to affected people where relevant. Document the aggregation rule. If the method uses the highest material impact dimension, say so; an average can otherwise hide a severe confidentiality consequence behind smaller operational effects.

A simple ordinal matrix can support triage. However, multiplying two category numbers produces an index, not a measured probability or monetary loss. Do not add those scores across services and call the result total enterprise exposure. Use the rating alongside rationale, urgency, uncertainty, and treatment dependencies.

Calibrate assessments together. Have owners score a few representative scenarios independently, compare their reasoning, and resolve differences against the definitions. This is more useful than allowing each department to develop its own interpretation of “high.”

Separate inherent, current residual, and target residual risk

Define the inherent-risk baseline explicitly. It might describe the scenario without the selected security controls, but it should still state the service architecture and business activity assumed. Otherwise, assessors may imagine incompatible versions of “no controls.”

Current residual risk reflects controls that are implemented and supported by relevant effectiveness evidence. Target residual risk is the expected exposure after proposed treatment. Keep both visible: a planned access restriction must not lower today's rating.

Not every control changes both dimensions. Stronger authentication may reduce likelihood. Narrower export permissions may limit the volume exposed. Tested response procedures may contain consequences after detection. Describe the mechanism rather than applying a blanket percentage reduction because a control exists.

Preserve uncertainty and use quantitative analysis selectively

Record assumptions, evidence dates, coverage gaps, and confidence. “No previous incidents” is weak evidence when logging cannot detect the event. Low confidence should trigger investigation; it should not automatically force the highest score.

For expensive treatment decisions, supplement qualitative assessment with scenario-based financial analysis. Use ranges for event frequency and consequences, identify major cost drivers, and test how the decision changes under different assumptions. Simulation can help explore those ranges, but cannot repair unsupported inputs.

As an illustrative calculation, assume an event frequency of 0.05 to 0.2 per year and losses of €100,000 to €400,000 per event. Multiplying the endpoints gives a rough annualized range of €5,000 to €80,000. This is an input to discussion, not a forecast or justification for ignoring rare severe outcomes. Explain what additional evidence would narrow the range.

Connect controls to the failure path

Control mapping should explain causality. For the support-account scenario, authentication addresses account takeover, authorization constrains accessible records, export restrictions limit extraction, and monitoring supports detection. A policy acknowledging access responsibilities is relevant, but does not prove those technical restrictions operate.

Maintain many-to-many relationships: one identity control may support several risks, and one risk may depend on multiple controls. Include scope and dependencies. An authentication control covering employees but excluding supplier accounts cannot support the same conclusion for both populations.

Evaluate three separate questions:

• Design: Would the control interrupt or contain the scenario if it worked as intended?
• Implementation: Is it deployed across the relevant systems, identities, and workflows?
• Operation: Does current evidence show that it continues to work?

For access restrictions, evidence might include role definitions, actual assignments, negative authorization tests, and completed removals. For recovery, a backup configuration proves less than a restore test with integrity checks and a measured recovery result. For export monitoring, demonstrate that the event is captured, the alert reaches a responder, and the responder can investigate it.

Keep provenance with evidence: source, collection time, scope, reviewer, and limitations. Evidence age is contextual. A configuration export may become stale after a deployment; an exercise result may remain useful until architecture or responsibilities change.

Do not lower residual risk in direct proportion to completed tasks. Three completed tickets out of four do not imply a 75% reduction. The missing ticket may implement the only control that limits disclosure. Review the scenario after verified changes, then record why the conclusion changed.

Select treatment and make the trade-off explicit

The usual treatment options are to avoid, reduce, share or transfer, and accept risk. They can be combined, but each needs a stated purpose.

Avoidance ends or changes the activity creating the exposure. It does not necessarily eliminate every related risk. Removing a feature may introduce manual processes that need their own assessment.

Reduction should consider preventive controls and consequence-limiting measures. Compare engineering effort, operational friction, dependencies, expected benefit, and time to effect. An immediate restriction may be preferable to a stronger architectural change that cannot be delivered for several months; the register should capture both stages.

Contractual transfer and insurance do not remove every operational consequence. A supplier indemnity will not restore your service, and insurance does not reverse disclosure. Where personal data processing is involved, outsourcing also leaves role-specific obligations under the GDPR; Articles 28 and 32 remain relevant to processor arrangements and security measures.

Acceptance is an affirmative decision, not the absence of budget or an overdue ticket. Record the business rationale, current evidence, retained exposure, approval authority, duration, and conditions requiring review. Cost is relevant, but not the only criterion: legal obligations, customer commitments, and consequences may rule out an otherwise convenient option.

Give each treatment action an implementation owner, resource commitment, target date, dependency, and completion test. The risk owner remains accountable for the overall assessment and response; task owners deliver individual changes. An authorized reviewer approves the treatment decision and any retained exposure under the organization's rules.

Define escalation before work stalls. For example, a missed milestone affecting an imminent launch should trigger a launch decision, not simply move the due date. Record rejected alternatives too, especially when they explain why a temporary treatment was chosen.

Worked example: a support-account export risk

The following example is illustrative. Assume a software service has twenty support users, customer records accessible through a support console, and a bulk-export function inherited from an earlier operating model. Single sign-on is implemented, but bulk-export privileges are broadly assigned. Existing logs capture exports, although no alert has been tested.

The scenario is: an attacker compromises a support session and uses excessive privileges to export customer records, causing unauthorized disclosure and customer-response work.

The service owner is accountable for the risk. The identity lead owns authentication changes, the application team owns authorization, and security operations owns detection testing.

Using this hypothetical organization's five-level method, the inherent rating is likelihood 4 and impact 4. The current residual assessment is likelihood 3 and impact 4: existing authentication provides some protection, but broad privileges leave a substantial disclosure path. Confidence is moderate because session safeguards and the maximum export volume have not yet been tested. These numbers are illustrative category ratings, not probabilities.

The team compares three options: remove bulk exports, restrict them to approved users, or preserve existing access with stronger monitoring. Support demonstrates a legitimate need for limited exports. The owner chooses reduction through restricted access, stronger authentication for the remaining privileged users, and tested export alerts.

Assume delivery requires twelve engineering days over four weeks. Those figures are planning assumptions, not market benchmarks. The register links the work to the delivery plan and records interim restrictions while implementation is incomplete.

The target residual rating is likelihood 2 and impact 3, subject to verification. It remains a target until tests pass. After deployment, the reviewer discovers that an older endpoint bypasses the new volume restriction. The impact rating therefore remains 4, and the bypass becomes a blocking treatment task.

Once corrected and retested, the owner reassesses the complete path. Any remaining exposure receives explicit approval and a review date. A new export integration, failed access review, or material increase in accessible records triggers earlier reassessment. The register has now changed implementation, sequencing, and approval—not merely documented concern.

Build a monitoring loop that produces decisions

Scheduled reviews remain useful, but changes between reviews must reach the owner. Connect operational signals to the scenarios they affect. Relevant triggers include failed access removals, new suppliers, architectural changes, incidents, control-test failures, and new threat information.

For each trigger, define its source, affected scope, routing, expected response time, and reviewer. As a practical recommendation, distinguish an urgent exposure requiring immediate operational action from a routine evidence refresh. Do not wait for a risk meeting to contain an active incident.

Monitoring frequency should reflect how quickly a control changes and how consequential failure would be. Automated configuration checks may run frequently; a recovery exercise or supplier review needs a different rhythm. “Continuous” should describe an ongoing operating process, not imply that every control is tested every second.

Build failure handling for the monitoring itself. A disconnected source or stale inventory should appear as unknown coverage, not a passing control. Deduplicate repeated alerts and group shared failures so owners receive actionable context rather than dozens of identical notifications.

When a signal arrives, record what changed, which scenarios were considered, the immediate action, and whether reassessment altered the treatment decision. A failed access review may warrant investigation without automatically changing every linked score. Conversely, confirmed excessive access to sensitive records may invalidate the existing residual assessment immediately.

Continuous controls monitoring is most valuable when its results reach both control operators and the owners responsible for the associated exposure.

Use AI to prepare assessments, not approve them

AI can help draft scenarios, reconcile evidence, summarize changes, identify possible control mappings, and propose priorities. Its output should remain reviewable draft work.

Start with a narrow workflow whose results can be checked. Require source references and distinguish extracted facts from inferred conclusions. Check missing coverage, contradictory records, outdated documents, and unsupported assumptions. A polished summary is not evidence that the underlying sources agree.

For vulnerability prioritization, use business context alongside external signals. Severity describes potential technical consequences; exploitation likelihood and confirmed exploitation indicate different aspects of threat activity. Neither tells you whether the affected component is deployed, reachable, privileged, or part of a critical service. AI can assist correlation, but the inventory and exposure checks remain essential.

Supplier intelligence needs similar discipline: distinguish facts about your contracted provider and service from speculation about an affiliated company. Behavioral analytics also require care because unusual activity is not automatically malicious, and employee monitoring can raise privacy and employment-law considerations.

Govern the AI workflow itself. Apply least privilege, limit sensitive inputs, retain reviewable output history, and define when a model or prompt change requires retesting. Historical incident data can encode blind spots: poorly monitored services may appear safer simply because fewer events were recorded.

Predictive outputs should be hypotheses with owners and validation tasks. A generated score should remain a proposal until checked against the agreed method. The responsible owner approves the assessment and treatment.

Using AI for risk work does not automatically make the system high-risk under the EU AI Act. Classification depends on use case and role; Article 9's risk-management requirements concern high-risk systems. Consult the Commission's current overview for applicability and timing. The NIST AI RMF offers voluntary governance guidance, not a compliance guarantee.

Report the decision trail and test whether the register works

Engineering needs affected systems, blocking dependencies, verification criteria, and upcoming decisions. Leadership needs material exposure, treatment options, resource requests, and changes since the previous review. Both views should come from the same underlying assessment.

Retain assessment history rather than overwriting it. Preserve the previous conclusion, new evidence, changed assumptions, reviewer, approval, and date. Keep accepted risks visible, including approaching expiry dates and conditions that no longer hold.

Useful operating metrics include the age of risks awaiting a decision, overdue treatment milestones, time from material change to reassessment, and the share of significant scenarios supported by current control evidence. Compare measures against your own baseline. Counts of entries or generated recommendations mainly describe activity, not improved decisions. ISMS metrics should help expose stalled ownership and unsupported conclusions.

Secani connects risks, requirements, controls, and evidence in an ISMS workspace. For a focused first scope, model the supporting systems and providers, attach existing evidence to the controls or decisions it supports, and turn gaps into owned tasks. Review AI-assisted suggestions against their sources and preserve human approvals, comments, and timestamps. The documentation describes that evidence-centered workflow.

Start with five significant scenarios. For each, confirm the owner, current assessment rationale, treatment decision, verification evidence, and next review trigger. Then take one into a real planning meeting and ask what should change. If the answer is a permission boundary, delivery sequence, funded task, or explicit acceptance decision, the register is doing useful work.