The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
Proposal
The risk assessment of the continuity discipline, which asks a different question from an IT risk assessment. We map the scenarios that interrupt each critical process, the single points of failure, the supplier and key person dependencies, and prioritise by likelihood and impact. It is the input that makes the BIA and the recovery plans point at the real risk rather than at whatever sounds most frightening.
No price appears on this page. Scope does: what we do, how we run it, who runs it and what is not included. The people who read your request are the ones who will look after you, and they come back with the proposal and with time to talk it through.
What stops the business, how likely it is and for how long.
This is the risk assessment from the continuity discipline, and it answers a different question than an IT risk assessment: not what can be breached, but what makes the operation stop, how likely that is, and for how long. We map the scenarios that interrupt each critical process, the single points of failure, and the dependencies on vendors and on individual people.
The work starts by closing the scope in writing and mapping the processes, then moves into interviews: documents say what should happen, the conversation says what actually happens and where the single-person dependency lives. The result is a matrix prioritized by likelihood and impact, along with an action plan with owners and sequence, pointing to the mitigations that actually move the risk.
On your side, we need time on the calendar with the people accountable for the processes and access to whoever knows the vendors and contracts. The cycle format adds treatment tracking and periodic reassessment, because the matrix ages fast: a new vendor or a migration changes the whole picture. It is the input that makes the BIA and the recovery plans start out pointing at the right risk.
Scope definition
We agree in writing what is in and what is out, and why. A badly defined scope is the most common cause of a project running over.
Process mapping
We map which processes exist, who answers for each one and what it depends on to work: systems, people, suppliers and other processes. That picture defines where to go deeper and what can stay out.
Interviews
We talk to IT, to security and to the business areas. Documents say what should happen; interviews say what does.
Report
We consolidate the findings into a report where every item comes with severity, evidence and the path to fix it. We write to be read by the people who will act, not to fatten pages.
Remediation follow-through
We chase the queue until each item closes, with a date and an owner. Finding things is the easy part.
Periodic reassessment
The critical ones come back to the table on a calendar, and a new supplier arrives assessed instead of arriving and being assessed after the incident.
Usually comes together with
Not a bundle, and it changes nothing you have already chosen. It is what tends to come up next, in the experience of companies that have been through this.