Change management

Assess a planned change for impact, decide the controls needed before and after it, and keep one set of records as the result.

Typical requirementsISO 27001 A.8.32DORANIS2 Art. 21

Stage 1 of 5
Triage
The change request is checked against trigger rules. Below the threshold it gets a short record; above it, a full assessment.
Documents Assets
Links used
1. Documents covers Assets
WINGMAN and AI support
Applies the trigger rules; the initiator can escalate but not downgrade.
Decides: The engineer and the security reviewer.
Stage 2 of 5
Impact
Affected assets and their dependants, existing risks and open vulnerabilities on them.
Assets Risks Vulnerabilities
Links used
1. Assets depends on Assets
2. Risks affects Assets
3. Vulnerabilities found on Assets
WINGMAN and AI support
Looks up existing risks first and proposes a new one only when nothing fits.
Decides: The reviewer confirms.
Stage 3 of 5
Controls before and after
Existing controls are looked up and reused; missing ones are proposed as pre-conditions or post-change checks.
Controls Risks Assets Requirements
Links used
1. Controls reduces Risks
2. Controls protects Assets
3. Requirements met by Controls
WINGMAN and AI support
Lists pre-required and post-required controls with their requirements.
Decides: Control owners agree.
Stage 4 of 5
Decision
The change board approves the assessment. Its decision leads to pre-condition tasks with owners and dates.
Roles Documents Tasks
Links used
1. Documents leads to Tasks
2. Roles defined in Documents
WINGMAN and AI support
Prepares the assessment for the board in plain language.
Decides: The change board decides.
Stage 5 of 5
After the change
Risk levels, controls and tasks are updated in the same records, so the next change starts from current data.
Controls Tasks Plans Risks
Links used
1. Controls improved by Tasks
2. Tasks part of Plans
3. Controls reduces Risks
WINGMAN and AI support
Records the agreed updates after approval.
Decides: Owners confirm each update.

Screens for this stage · Stage 5: After the change

Risks **A risk with an open review and a suggestion** On the risk itself: what changed since the last review (a linked incident, a training task, a parent risk), one suggested change (likelihood 4 → 2 with the reason), and Confirm & complete.

Risks · step 1 **Suggested change: likelihood 4 → 2** A single incident in July and no recent successful breaches suggest the likelihood is overstated.

Risks · step 2 **Accepted, with Undo** The suggestion is marked Accepted and the button becomes Apply 1 change & complete. Nothing is written until the review is completed.

Risks · step 3 **Review completed: score 16 → 8, Monitored** The score drops from 16 to 8, severity from Critical to High, status moves to Monitored, the position on the matrix shifts, and the brief regenerates.

Sector angles

What this use case looks like under specific regulations.

Financial sector

New products and material changes are assessed for risk before they go live.

ISO 27001 / SOC 2

Changes are assessed for security impact, and the change record is evidence for change management controls.

AI governance

A new model version or a new purpose is a change, assessed before it goes live.

CRA

Each release is assessed for security impact, and the record becomes part of the technical documentation.

GDPR

A new purpose, system or processor triggers privacy by design and a DPIA screening before go-live.

Other use cases

Incident handling

Support every stage of an incident, from the first signal to the risk review it should trigger.

Supplier evaluation

Evaluate a supplier for feasibility before onboarding, and keep watching it afterwards.

Regular reviews

Run the reviews good practice expects (assets, documents, risks, incidents, access) on a calendar instead of from memory.

Security operations control

Run security work through plans and tasks, with briefs, reminders and escalations, and ask "what needs to be done" against everything the model knows.

All use cases