How we work
Our Response Process
Seven steps from intake to follow-up: what we do, what we need from you, and what gets delivered at each stage, plus typical timelines and the information to prepare.
Our process
A standard process with a deliverable at every step
The process is transparent. You get the assessment first and decide whether to continue.
Intake & containment
We answer 24/7 and immediately walk you through isolating systems and preserving evidence so the encryption stops spreading.
Sample analysis & family identification
We analyze encrypted samples and the ransom note to confirm the family, the variant and the encryption characteristics.
Recoverability assessment & quote
Weighing decryptors, backups, snapshots and database structure, we document what can realistically be recovered and quote a firm price.
Recovery & business validation
We recover in business-priority order, verify data integrity item by item and validate the systems together with your teams.
Attribution & hardening
We reconstruct the intrusion path, deliver a forensic report, close the entry point and harden accounts and backups against reinfection.
Step 1 — Intake and initial assessment
What we do: respond quickly after intake and use a call or remote session to establish the incident type, when it was noticed, the affected scope, and whether encryption is still spreading — then issue containment instructions immediately.
What we need from you
- when it was discovered, how many hosts and business systems are affected, and the current state of operations;
- what has already been done — any reboot, reinstall, antivirus run or recovery software;
- isolation of affected hosts as instructed: disconnect the network but keep the power on; do not reboot, reinstall or format;
- pausing automated backup and sync jobs that could overwrite data, and preserving the original ransom note.
What you get: a containment instruction list and a first read — the likely family direction and what material to collect next.
Step 2 — Isolation and evidence preservation
What we do: fix the evidence before the environment is altered — disk and memory images from key hosts, domain controller and server logs, firewall and VPN logs, virtualization and backup platform logs, each hashed and registered. In parallel we shrink the exposed surface and disable suspicious accounts to cut the attacker's live channel.
What we need from you
- the necessary administrative access, or an operations engineer with those rights available online;
- network topology and an asset inventory: how many servers, which public mappings, how backups run;
- confirmation of which systems may be imaged and which data must not leave the premises — tell us in advance about classified environments;
- holding off on virus cleanup and on deleting suspicious accounts or scheduled tasks until acquisition is complete.
What you get: the evidence inventory (source, time, hash) and the containment checklist.
Step 3 — Family identification and encryption analysis
What we do: determine the family and variant from the appended extension, the ransom note and the contact patterns inside it, file header and footer structure, encrypted block distribution and sample characteristics — then establish whether a public decryptor exists for that build, whether encryption was intermittent, and whether shadow copies are typically destroyed.
What we need from you
- the original ransom note, as text or a screenshot;
- two or three encrypted sample files — ordinary documents are fine; do not include customer records, financial data or personal information;
- if possible, an unencrypted version of the same file, which helps materially for some families;
- the quarantine record for any sample your antivirus has already isolated.
What you get: the family and variant identification with the evidence behind it, and a description of that build's known encryption behaviour.
Step 4 — Recoverability assessment and quote
What we do: assess the current data state on read-only copies — how much is encrypted, whether database files are repairable, what backups and snapshots survive, which directories were untouched — and pilot each recovery path on small samples to produce quantified expectations. The output is a tiered plan with a quote and a time estimate.
What we need from you
- data volume, the list of business systems, and the recovery priority — which systems must come back first;
- the state of backups: backup server condition, last successful run, whether any offline or off-site copy exists;
- the available downtime window and who will sign off on acceptance;
- confirmation of the plan and the fee before execution begins.
What you get: the recoverability assessment report (recoverable scope, available paths, expected outcome and risks), the tiered implementation plan, and a firm quote.
Step 5 — Recovery execution
What we do: all work happens on copies, in business-priority order — first the minimum dataset core production needs, then historical and archived data. Databases get file-level repair and data extraction; virtualized workloads get business data extracted from the virtual disks. Progress and the actually achieved ratio are reported at checkpoints, and if a path underperforms we change the plan rather than push it through.
What we need from you
- target storage for the recovered data, normally with free capacity no smaller than the original dataset;
- operations staff to prepare the environment, start and stop services, and work through application-side checks;
- keeping original disks read-only — no continued work or new writes on affected hosts;
- a business-side contact to take part in interim sampling confirmation.
What you get: interim progress reports and a manifest of recovered data annotated by system and point in time.
Step 6 — Verification and handover
What we do: complete verification before handover — sampled bulk file-open checks, database mount and consistency checks, row counts on key business tables, and application-level business sampling — and issue the verification checklist together with a statement of what is confirmed unrecoverable.
What we need from you
- business-side sampling against real scenarios: queries, reports, document cross-checks;
- agreed acceptance criteria and a named signatory;
- cooperation on the pre-go-live security check and credential rotation before restored systems rejoin the production network.
What you get: the verification checklist and recovery report, a statement of permanently lost data with re-entry advice, and the pre-go-live checklist.
Step 7 — Forensics, hardening and follow-up
What we do: reconstruct the attack timeline and entry point from the preserved evidence, assess the likelihood of exfiltration, and issue the forensic report for police filing and compliance records. Hardening then targets the actual intrusion path: remove unnecessary public mappings, enable MFA on remote access, patch flaws under active exploitation, reduce privilege and segment the network, and rebuild an offline or immutable backup with restore testing. A follow-up review within the agreed interval confirms nothing has regressed.
What we need from you
- confirmation of the forensic scope and the report's purpose — police filing, compliance, internal accountability, insurance;
- named owners for remediation and agreed change windows, with cooperation on item-by-item verification;
- details of third-party administrator and vendor access, so external channel risk can be assessed.
What you get: the forensic report and IOC list, the hardening checklist with verification results, backup design and restore verification records, recommended ransomware alert rules, and the follow-up review record.
Information to prepare before you call
Having these details ready on the first call materially speeds up the assessment. Call us anyway if you do not have all of them — we can fill the gaps as we talk.
| Category | What to describe |
|---|---|
| Incident basics | When and how it was discovered, whether it is still spreading |
| Affected scope | Number of hosts, business systems involved (ERP, OA, HIS, MES, file servers), whether virtualization platforms or NAS units are affected |
| Encryption traits | The appended file extension, ransom note filename and contents, whether the desktop wallpaper changed |
| Actions already taken | Any reboot, reinstall, antivirus or recovery software run, whether anyone has paid or contacted the attacker |
| Backup status | Backup method, last successful run, whether the backup server was also encrypted, any offline or off-site copy |
| Environment | OS and database versions, total data volume, which ports are exposed, how VPN and remote desktop are used |
| Business needs | Which systems must be restored first, the acceptable downtime window, whether a police filing or compliance report is required |
Worth sending with your enquiry: the original ransom note as text, plus two or three encrypted sample files with no sensitive content. Do not send files containing customer records, financial data or personal information.
Typical timelines
The figures below are typical references. Actual timing depends on data volume, environment complexity, backup condition and how quickly information flows; the assessment report gives a specific range for your environment.
| Stage | Typical range |
|---|---|
| Intake to containment instructions | Within the first call |
| Initial family and version identification | Usually hours, depending on how fast samples arrive |
| Full recoverability assessment | Generally one to several business days; longer for large or complex environments |
| Recovery of a single file server | Generally one to several days |
| File-level database repair | Several days depending on database size and encryption coverage; longer for very large instances |
| Multiple VMs or a whole virtualization platform | Typically several days to a week or two, depending on VM count and disk capacity |
| Forensic report delivery | Several business days when evidence is complete |
| Hardening implementation | Rolled out in batches by scope, typically days to weeks |
Two things worth stating. Earlier containment usually means a larger recoverable scope — reboots, reinstalls and disk operations sharply reduce the available paths. And we do not skip assessment or verification to save time, because putting unverified data into production usually causes longer downtime than doing the checks.
Updated