Keep an incident decision log that people can use
Capture the reasoning behind response actions so technical and business teams can stay coordinated.
Read article : Keep an incident decision log that people can use
OUR APPROACH
A clearer route from risk to readiness.
Start with the work your business depends on. Find the gaps that matter. Turn the next decision into a practical action—and check that it works.
BEGIN WITH THE RIGHT QUESTION
What needs to keep working?
A long list of findings can leave a business unsure where to begin. The most useful starting point is the service you cannot afford to lose: processing an order, treating a patient, accessing client records or keeping a production line moving.
From there, we connect the people, systems and information behind that service. This gives security decisions a business context and helps separate immediate exposure from work that can be planned.
The result should be a clear sequence of decisions, with responsibilities and evidence attached. The scope and deliverables are agreed before an engagement begins.
THE WORKING CYCLE
Understand. Prioritise. Act. Validate.
A repeatable way to organise the work, adapted to your environment and the question you need to answer.
01
Understand
Map the service, its dependencies and the controls already in place.
02
Prioritise
Compare exposure with business impact and agree what needs attention first.
03
Act
Define the changes, owners and approvals needed to move forward.
04
Validate
Test within an agreed scope, record the evidence and revisit open issues.
The cycle continues when your systems, suppliers, people or business priorities change.
WHAT HAPPENS AT EACH STAGE
A process your team can follow.
01
UNDERSTAND THE ENVIRONMENT
See the service behind the system.
Technology inventories tell part of the story. We also need to know who uses the service, what information it handles, where access comes from and what happens when a dependency fails.
The conversation covers
- Critical workflows and the people who own them
- Identity, endpoints, email, cloud and supplier dependencies
- Current controls, known concerns and available evidence
A shared starting point
An agreed view of the service, its boundaries, dependencies and questions that still need investigation.
02
SET THE ORDER OF WORK
Give the highest-impact gaps a clear owner.
A finding becomes useful when people understand its significance. We consider the likely route to disruption, the effectiveness of current controls and the business consequences of a failure.
The decision considers
- What an attacker or an operational failure could affect
- Which gaps need immediate attention and which can be scheduled
- Dependencies, resources and practical constraints on remediation
A focused set of priorities
An ordered action list with the reason for each priority, an owner and the evidence needed to close it.
03
TURN DECISIONS INTO ACTION
Make the change deliberate.
Security improvements can affect how people work. Agree the implementation responsibilities, approval route and test conditions before changing production systems. Where your IT team or provider performs the work, the handover should be specific enough to act on.
The plan makes clear
- What will change and who is responsible for implementing it
- Which approvals, access and maintenance windows are required
- How the change will be checked and what happens if it causes problems
An actionable plan
Defined tasks, dependencies, acceptance criteria and a route for handling exceptions or unexpected results.
04
CHECK THE RESULT
Replace assumptions with useful evidence.
A completed task is not always a working control. Validation should answer the original question: does the change reduce the identified exposure, and can the business still perform the work it needs to do?
The review looks for
- Configuration and coverage evidence for the agreed controls
- Measured restoration or scenario results where in scope
- Unresolved issues, remaining limitations and follow-up owners
A documented next decision
A record of what was checked, what the evidence supports and what still needs action or a later review.
ILLUSTRATIVE WORKING EXAMPLE
“Our backups are working.” What does that tell us?
A successful backup report answers one question. A recovery decision needs a wider view. Here is how the same working cycle can uncover the next useful step.
STARTING ASSUMPTION
The files are saved. The business can recover.
The backup job completed, but the team has not yet restored the application and checked a complete customer order.
A MORE USEFUL TEST
Restore the workflow. Check the outcome.
- Choose the order-processing service and agree recovery objectives.
- Map identity, application, database and external dependencies.
- Restore in an agreed test environment with defined responsibilities.
- Check a representative order and record elapsed time, data loss and gaps.
Now the business has evidence to improve its recovery plan, rather than relying on the job status alone.
This is an illustrative scenario, not a customer case study or a promise of a particular recovery result.
ADAPT THE STARTING POINT
The right scope for the situation.
The method stays clear. The depth, pace and participants depend on what is happening in your business.
We need a focused security review.
Define the service or concern first, then agree the systems and evidence to include. The review can identify gaps, priorities and practical next steps. An assessment does not silently include implementation; responsibilities for follow-on work are agreed separately.
We are planning a technology or AI change.
Bring the proposed workflow, information involved, connected systems and intended users. Review access and data boundaries before the rollout, test difficult cases and agree a review date. Security decisions should be part of the implementation plan.
We need to rehearse response or recovery.
Agree the scenario, participants, safety limits and learning objectives. A tabletop exercise tests decisions and coordination; a technical recovery drill tests restoration activities. Record observations and assign improvements so the exercise leads to useful change.
We may have an active incident.
A suspected incident requires a focused conversation about immediate circumstances, safe communications and available evidence. Contact us through a trusted route. Availability, responsibilities and the scope of any response engagement must be confirmed directly.
WHAT GOOD HANDOVER LOOKS LIKE
Something your team can use after the conversation ends.
The priority
A clear statement of the risk or operational issue and why it matters to a business service.
The action
A practical task with an owner, dependencies and an agreed approval route.
The evidence
The record or test that will demonstrate whether the task achieved its intended purpose.
The review
A date or trigger for revisiting the decision, including changes that could make the evidence outdated.
These are examples of useful outputs. The engagement scope determines which documents, tests and implementation activities are included.
A SHARED RESPONSIBILITY
Keep the right people in the decisions.
Business owners explain the operational impact. Technical teams explain the environment and its constraints. Security work connects those views and gives the next action a clear purpose.
We can work alongside your existing IT team or service provider. Agree who provides evidence, who approves changes and who validates the result. Where suppliers or specialist advisers are involved, bring them into the relevant decisions early.
The aim is clarity your team can maintain: understandable priorities, usable records and a realistic way to review progress.
BEFORE WE BEGIN
Questions about working together.
Does every engagement follow all four stages?
The cycle describes how we organise the thinking. An engagement may focus on one stage, such as assessment or recovery testing. We agree the scope and expected outputs first, including what depends on your team or another provider.
How long does a review take?
The timing depends on the scope, number of systems, evidence available and access to the people involved. We discuss these dependencies before agreeing a schedule. A narrow review and a multi-system recovery exercise require different preparation.
Will you make changes to our live systems?
Only when implementation is part of the agreed scope and the relevant approvals are in place. A review can identify recommended actions without making production changes. Responsibilities, test conditions and change controls should be explicit.
Can you use evidence from our existing tools?
Yes. Existing inventories, configuration records, alerts, policies and test results can provide useful context. Their relevance and currency need to be assessed against the question being answered; having a report does not by itself establish that every control is effective.
What if we cannot fix everything immediately?
Prioritise around impact, exposure and dependencies. Record the outstanding issue, the accountable owner and any agreed interim measures. A practical plan makes the remaining risk visible rather than treating an unfinished task as resolved.
Is this a certification or a guarantee against incidents?
No. The work produces findings and evidence within an agreed scope. It does not guarantee that an incident cannot occur or automatically establish compliance, insurance eligibility or certification.
What should we prepare for the first conversation?
A brief description of the business service, the concern, your existing IT arrangements and any deadline is enough to start. Mention known constraints. Do not send credentials or confidential incident evidence through the general enquiry form.
CONTINUE THE CONVERSATION
Practical reading for the next decision.
A restore test should end with a business check
Plan a recovery rehearsal that checks data, dependencies and a useful workflow—not simply a successful backup console message.
Read article : A restore test should end with a business check
Cloud access reviews: follow the identity, not just the server
A practical way to connect people, service identities and integrations to the business information they can reach.
Read article : Cloud access reviews: follow the identity, not just the serverSTART WITH THE DECISION IN FRONT OF YOU
Bring the question. Let’s define the next step.
Tell us what needs to keep working, what concerns you and where you need a clearer view.