Ransomware readiness and resilience
Readiness is the part that happens before, and it is almost entirely unglamorous: privilege that was never trimmed, a flat network nobody has had time to segment, a backup job that has run green for four years and has never once been restored from.
The short version: readiness, not response
If an incident is in progress, stop reading this page and call your counsel and an appropriately licensed incident responder. This practice does readiness work, not live response. The two are different disciplines, bought at different times, and conflating them is how organizations end up with neither.
What this engagement does is measure, control by control, how far an intrusion would travel and how quickly you could come back — and then write down what to change, in the order that makes each subsequent change easier.
Control-by-control readiness review
Five areas, assessed against what is actually configured rather than what policy says.
Endpoint hardening
What runs on a workstation and what cannot: application control, macro and script policy, removable media, local administrator rights, and whether the endpoint tooling is in a mode that blocks or a mode that watches. A detection-only deployment is a legitimate choice and a very common accident.
Privilege
Destructive incidents are privilege stories. The review looks at how many accounts can reach how much, whether administrative credentials are used on ordinary workstations, whether one compromised identity reaches the backup system, and whether service accounts have accumulated rights nobody has reviewed. The workplace half of this is on identity and workplace security.
Segmentation
Whether a compromise in one place reaches everywhere. Most networks that describe themselves as segmented are segmented for performance, not for containment, and the difference only becomes visible under an attack.
Backup immutability
Whether the backups can be deleted or encrypted by the same identity that can reach production. Immutable or write-once storage, credentials that are not reused from the production domain, and an offline or logically separated copy are the controls that decide whether you have a choice to make at all.
Restore testing
Whether anyone has done it, on which services, how recently, and how long it took. This is the control with the widest gap between belief and evidence.
Why an untested backup is not a control
Backups become a control only once a restore has been performed and timed. Until then they are an intention, and the failure modes that matter show up during a restore rather than during a backup. The list of things a first real restore uncovers is consistent: an encryption key held only in the system being restored, a database that backs up consistently but restores into a schema the current application will not start against, a virtual machine image that needs a licence server that is also down, a retention window shorter than the time between compromise and discovery, and a restore throughput that turns an eight-hour expectation into four days.
None of those appear in a backup report. All of them appear in a drill.
Recovery objectives, per service rather than per organization
A single organization-wide recovery time objective is a number that nobody believes and nobody funds. Objectives are defined service by service: how long this service can be down before the consequence changes in kind, and how much data it can afford to lose.
The definitions used are the standard ones. Recovery time objective is the period within which a service must be restored; recovery point objective is the maximum acceptable data loss, expressed as a point in time before the disruption. Both are set out, with the wider planning process around them, in NIST’s SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, which is the most usable public reference for organizations that are not federal.
The useful output is not the numbers themselves. It is the gap between the objective the business states and the objective the current architecture can actually deliver, written down so the difference is a funded decision rather than an assumption. Setting those objectives from the business side, process by process, is a business impact analysis.
Backup architecture review
The review covers what is backed up and what is quietly not — the file share added last year, the software-as-a-service platform everyone assumes the vendor protects, the configuration that lives only in a console. It covers where copies live and how independent they are, whether immutability is enforced by the platform or by policy, and separation of duties: whether the person or process that can delete production can also delete the backups.
Where the estate is in public cloud, the configuration half of this overlaps with cloud security configuration review, and the two are often scoped together.
Restore-drill design
A restore drill takes a real service, rebuilds it in a clean environment from the backups you actually hold, and records how long it took and what turned out to be missing. Drills are designed and facilitated remotely: your engineers perform the restore, which is the point — the capability has to live with the people who would have to use it at three in the morning.
Each drill has a written scenario, a defined success condition, a timekeeper, and a record. The record is the deliverable: elapsed time per stage, what was missing, what had to be improvised, and what would have been different if the production environment had also been unavailable.
Continuity and recovery documents somebody could follow at 2am
Most continuity documents are written to satisfy a requirement and are unreadable under stress: long, structured by department, full of policy language, and silent on the specific question the reader has. The ones written here are structured by scenario, open with the first five actions, name roles rather than individuals, and state who may decide what.
They pair with the incident plan itself, which is the other half of the same problem: the technical ability to recover and the organizational ability to run the recovery are separate capabilities and both have to exist. See incident response readiness for the plan, the playbooks and the tabletop exercise, and the first 24 hours of an incident for what that period actually demands.
What you receive
| Deliverable | What it is for |
|---|---|
| Gap register | Control by control, what exists and what does not, with evidence |
| Prioritized plan | Sequenced so each change makes the next one cheaper |
| Drill findings | Timed results from a real restore, with what was missing |
| Continuity and recovery plans | Scenario-structured, written to be followed under pressure |
Recovery objectives are recorded per service alongside the objective the architecture can currently meet, so the two are never confused again.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
We have backups — is that not enough?
The question worth asking internally is not whether backups exist but who last restored from them, when, and how long it took.
What does a restore drill involve?
A first drill is usually scoped to one service and deliberately kept small, because the first one is where the process problems surface and a large scope buries them.
Does our insurer ask for this?
Cyber insurance applications and renewals ask about backup immutability, privileged access, endpoint controls and whether restores are tested, so this work produces the evidence behind those answers. Answering an application accurately is easier when the evidence already exists, and harder to correct afterwards.
What if we are hit right now?
Legal questions, including any notification obligation, rest with your counsel. Nothing on this page is legal advice, and no readiness engagement substitutes for counsel at that moment.
Find out what would actually happen
Describe the estate, what would have to keep running and what your backups cover today. The reply says what a readiness review would cover and what you would receive — see also all security services.