What is the effect of the order completion entry?

The effect is high, while the probability is still unmeasured.

The team does not want to run the Restore test on production. What is the test step?

An isolated restorer with payment reconciliation in the next operating window. Duration and deviations are recorded at the risk entry.

Is it better to document and observe the risk, or to rehearse the restore immediately? Weigh in.

Documentation costs little, but does not reduce uncertainty. The sample costs effort in the operating window, but provides duration and deviations as documented data.

ActivityChapter III · Documentation · Building block 6 of 6

Communicate risks

A risk log records an uncertain development and its possible consequences. A concrete test method makes visible how the team reduces uncertainty.

By Michael Meierhoff · Meierhoff Systems

Cause, eventWhy and what happens.
Impactfollow-up for operation.
Test stepResponsible, concrete, terminated.

Context

Why this is important

Uncertainties that exist only in the head of individual persons become visible only in an emergency. A risk entry makes them concrete, assigns responsibility and plans a proof. The procedures themselves are in recovery.

This building block documents risks and subsequent steps. Architecture review generates findings; recovery provides recovery procedures that can be reviewed.

At a glance · From risk to check step

Each risk is recorded with its consequence, an owner and a scheduled check step.

Shop example · Filled working artifact

Risk Entry: Shop-Restore

The team knows that order backups exist, but has not yet tested the restore with payment reconciliation in practice.

This is how you read the picture

Cause, event Cause and Event fields: Restore not rehearsed, shop database failure requires recovery.
Impact Impact field: Orders and payment status could be time-different.
Test step Fields "Responsible" and "Test step and appointment": isolated restore in the next operating window.

EXAMPLE · COMPLETEDRisk Entry: Shop-Restore

Cause: Restore has not been rehearsed since the introduction of the new ordering scheme.
Event: A shop database failure requires recovery from backup.
Impact: Orders and payment status could be time-different.
Probability / Effect: Probability still unmeasured; effect high for order completion.
Responsible: Responsible person of the shop.
Test step and date: Isolated restore with payment reconciliation in the next operating window; record duration and discrepancies.

The entry separates occupied status, possible sequence and planned proof.

Benefits & limitations

Helps if:

Uncertain architecture assumptions can affect goals, releases and operational capability.
Migrations, recovery and external dependencies need visible mitigations, owners and reassessment dates.

Boundaries

Unsupported numbers create false precision; state the assessment basis and uncertainty, or use graded categories.
Every open risk needs an owner and next review step; close obsolete entries with a status and outcome.
The log records the risk; rehearse the restore through Recovery, and use findings from a Review.

In practice

Formulate cause, event and consequence. Describe a possible development and its affected goal in a traceable chain. Separate fact from assumption. The result is a testable risk entry instead of a general concern.
Justify the assessment and mitigation. Assess likelihood and impact using available evidence, and identify suitable prevention, detection or recovery measures. State uncertainty explicitly. This keeps priority understandable in business terms.
Assign ownership and reassessment. Name an owner, review date and required evidence. Reassess residual risk after implementation. This keeps mitigation and residual risk separately visible.

Read the detailed explanation

A risk entry describes a possible future event and its impact on a goal. A clear cause-and-effect chain connects uncertainty to potential consequences. Likelihood and impact support prioritisation but need a defensible basis. Risks may arise from an Architecture decision or inform Threat modelling.

A mitigation reduces likelihood or impact and receives an owner and review date. Once its effectiveness is verified, residual risk is reassessed. When an event occurs, it is handled as an incident or concrete remediation work; the risk log records status and resulting evidence. Regular updates keep the register useful for decisions. Long lists without owners or next steps lose their value for steering work. A closed risk receives a status and outcome evidence so it no longer remains an open concern. New findings can change likelihood, impact or mitigation.

A risk matrix positions risks by likelihood and severity; the risk log adds owners and verification steps.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What is the effect of the order completion entry?
View the solution with justification
The effect is high, while the probability is still unmeasured.
ApplyingTransferred to a new situation
The team does not want to run the Restore test on production. What is the test step?
View the solution with justification
An isolated restorer with payment reconciliation in the next operating window. Duration and deviations are recorded at the risk entry.
EvaluateWeighing an alternative
Is it better to document and observe the risk, or to rehearse the restore immediately? Weigh in.
View the solution with justification
Documentation costs little, but does not reduce uncertainty. The sample costs effort in the operating window, but provides duration and deviations as documented data.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

This is the last building block of the Atlas.

6 Building blocks