Incident Response Readiness

A red team breaks in. This rehearses what you do once someone has. The red-team leaf in this practice area emulates an adversary against your live defences to test whether you detect and respond to a genuine intrusion, and a ransomware scenario sits inside that engagement rather than being sold separately. Readiness work does not attack anything. We run the scenario as an exercise, so the whole leadership group can be in the room and the conversation can stop while someone finds an answer, which is exactly what cannot happen during a live test. The two are complementary and the order usually matters: rehearse first, then test under real conditions, because a red team that lands in an organisation which has never exercised its response mostly proves that it had not.

Half a day, and more of the business than people expect. The technical group alone will rehearse containment competently and then discover that every decision which actually stalls an incident belongs to somebody else: who approves taking a revenue system offline, who talks to a customer whose data is involved, who signs a regulatory notification, who refuses to pay. Those answers are not technical, and an exercise that excludes the people holding them measures the wrong thing. We ask for the security and IT owners, an executive who can authorise a shutdown, and whoever owns legal and communications, even if they only attend the second half. The decision log records who decided what and how long it took, and that timing is usually the finding leadership reacts to.

Yes, into an isolated environment, on agreed systems. A backup job reporting success is not evidence of recovery, and the gap between the recovery objective in a policy and the restore time measured in practice is the single most common finding in this work. We also test something most backup reviews skip: whether your backups survive compromise of the account that manages them, because ransomware operators go for the backup system first. From you we need a restore target we are allowed to build, credentials scoped to that environment, and a named owner for each system in scope. The Restore Test Record carries the measured time rather than the intended one. If your architecture makes a real restore impossible within the engagement, we say so and scope what can be proven instead.

Readiness as numbers and gaps, not as a maturity colour. It states the measured restore time against your stated objective, which scenarios have been exercised and when, how many gaps the exercise opened and how many are closed, and the decisions still waiting to be pre-authorised. It also says plainly which scenarios remain unrehearsed, because a report that omits them reads as broader assurance than the work supports. What it will not contain is a readiness score. A single number invites a board to treat an exercise against two scenarios as coverage of all of them, and the honest version of that claim is a list. Where a gap needs money or a decision only the board can make, it is written that way rather than left as a technical recommendation nobody can act on. How often it lands is yours to set at scoping, against your board calendar rather than ours.

With a scoping call. You describe the environment, who would be involved and what you have exercised before, and we come back with scenarios, scope and a fixed price in writing. Not included: this is not incident response itself. If you are in a live incident now, the relevant work is Digital and Cyber Forensics, and the honest advice is to call about that instead. If what you need is a certifiable continuity management system rather than a rehearsal, that is ISO 22301 in our compliance practice, which carries its own exercise programme built for an audit. We do not give legal advice, make regulatory filings or rebuild your environment. CERT-In directions require certain incidents to be reported within six hours of noticing them and the DPDP Act carries its own duties. SecureRoot is not a CERT-In empanelled auditing organisation. We rehearse those clocks; the filing is yours and your counsel's. SecureRoot is ISO/IEC 27001:2022 certified, certificate IN60432E.