Incident response readiness
Readiness is a week your team can already run.
A company is ready for an incident when a named owner can revoke access, the list of systems is believable, and the people who already work there can do those things without inventing a process in the middle of the night. A binder that has never been used is not readiness.
Where it breaks
The incident sits between IT, the person who built the workflow, and a vendor. Two people think they own the decision, or nobody does. That is the same finding as any other stalled handoff. The difference is that the week is shorter.
Companies search for incident response when they want a number: a hotline, a retainer, a promise that someone else will be awake. Those searches are real. This page is about the part you can put in place with the people you have, before that contract is the question. Ownership and cadence are the services underneath it.
Questions that show readiness
Answer them for a specific incident, not in general. A lost laptop, a vendor account, a payment system, a customer-data export.
- Who is called first, and who is allowed to decide?
- Who can disable an employee account, a key, and a vendor session, and how long does that take on a normal Friday?
- Where is the list of systems that hold customer data, and when was it last compared with what is actually running?
- Is offboarding current enough that the access list is worth trusting?
- Who speaks to customers, who speaks to the insurer or the auditor, and are they working from the same facts?
- The week after, can you show what you did? For SOC 2 or PCI, the evidence has to match the path you actually took.
If two of those have no name, you are not waiting on a better template. You are waiting on owners. Write the blanks down. That list is more useful than a completed policy that nobody has walked.
What to put in place
- One owner for the incident, and a second person who can act if the owner is unreachable.
- A current access list for the few systems that matter, and a way to revoke that access which someone has actually used.
- A single place the timeline is written while the work is happening, not reconstructed later.
- A cadence that already meets. An incident bridge that has no relation to how the week is run will not be remembered.
- A decision, made on a quiet day, about what you will not do in the first hour, so people do not freelance.
None of these require a new hire. They require the products and the processes to agree on the path. That is the same standard as the rest of the practice: no added headcount to make a rough flow look smooth.
What we will not do
We map how an incident would move through your operation, name one owner on each duty that can stop that path, join the access and the records, and leave the cadence with your team. The method is the same one used on the rest of the work: map, name, join, prove, leave.
We do not sell a 24-hour response retainer, and this page does not describe one. We do not quote a response time. If you need a firm to take the keyboard during an active breach, say that in the first note. We will tell you if this engagement is not the fit.
If the pressure is an audit or a questionnaire rather than an incident, start with SecOps consulting. The evidence problem and the readiness problem are neighbors. They are not the same afternoon.
Prove it on a quiet week
Run the questions as a tabletop on a real system you choose, with the people who would actually be called. Record what held, what slipped, and what changed. A diagram that was never used is not a result.
Pick one system. Give it an hour. If the hour produces a named owner and a revoke step someone demonstrated, you learned more than a binder would have taught you. If it produces an argument about who decides, that argument is the finding. Bring it to the conversation.
Contact
If the incident has no owner, start there.
Tell us which system you are worried about and who would be called today. We reply with a scoped visit, or we tell you if you need a response firm we are not.