Incident Response Process: How to Tell If Your IT Firm Has Actually Practiced – or Will Be Improvising When It Counts

Every IT firm will tell you they have an incident response process. Almost none can prove it. When ransomware locks your files at 2 a.m. on a Tuesday, the difference between a firm with a written, tested, documented process and one making it up as they go is the difference between a recoverable disruption and a business-ending event. This post gives you a specific, practical checklist to tell those two types of firms apart – before you sign a contract, not after the alarm goes off.

1. Why Verbal Assurances Fail Under Pressure
2. What a Real Incident Response Process Looks Like
3. The Checklist: Specific Questions to Ask Any IT Firm
4. Red Flags That Tell You Everything
5. What Good Actually Looks Like in Practice
6. How to Use This to Make a Decision
7. How the NIST Framework Applies to IT Firm Evaluation

Why Verbal Assurances Collapse When You Actually Need Them

Most IT vendor conversations go the same way: you ask “what happens if we get hit by ransomware?” and the salesperson says “don’t worry, we have a process for that.” Reassuring in a conference room. Useless in a crisis.

A verbal assurance is not a process. A process is a documented sequence of steps, assigned to named roles, with defined decision points, practiced on a calendar schedule, and updated after every real or simulated event. Anything short of that is a hope dressed up as a plan.

The stakes are not abstract. According to CISA’s incident response guidance, organizations that contain breaches fastest are the ones with pre-defined playbooks – not the ones with the smartest engineers improvising under pressure. Speed of containment is directly tied to how much was written down before the incident started.

Your job as a buyer is not to test an IT firm’s intentions. Their intentions are fine. Your job is to test their preparation.

What a Real Incident Response Process Looks Like

Before you can evaluate a vendor, you need a baseline. A mature incident response process has six distinct phases. You do not need to memorize the technical names – you just need to know that all six must exist in writing.

• Preparation: Everything done before an incident occurs – the written plan, defined roles, communication trees, and pre-staged recovery tools.
• Identification: The process for detecting that something is wrong and confirming it is a real incident, not a false alarm. This should be automatic where possible.
• Containment: Stopping the spread. Isolating affected systems without destroying evidence needed for later analysis.
• Eradication: Removing the threat completely – not just visible symptoms, but the root cause and any persistence mechanisms left behind.
• Recovery: Restoring systems to a verified clean state, testing them, and returning to normal operations in a controlled sequence.
• Post-Incident Review: A documented analysis of what happened, what worked, what failed, and what changes are being made to prevent recurrence.

A firm that cannot walk you through all six phases by name – and show documentation for each – does not have a process. They have a general awareness that incidents exist.

The Checklist: Specific Questions to Ask Any IT Firm About Their Incident Response Process

These questions are designed to surface the difference between rehearsed capability and a verbal promise. Ask them in any vendor evaluation. Listen for specificity, not confidence. Confident vagueness is the most common answer you will get.

About the Written Plan

• Can you show me your incident response plan document, or describe its structure in detail?
• How long is the document? (A real plan is not a one-pager.)
• When was it last updated, and what triggered that update?
• Does the plan include specific playbooks for different incident types – ransomware, business email compromise, data exfiltration – or is it a single generic document?

About Roles and Accountability

• Who is the named incident commander on your team when something happens?
• Is that a primary contact or a backup? Who covers if they are unavailable?
• Who on your team is responsible for client communication during an active incident, and on what cadence?
• Does your plan define a clear escalation path from first responder to senior decision-maker?

About Testing and Practice

• How often do you run tabletop exercises to rehearse your incident response process?
• When was the last tabletop exercise? What scenario did you practice?
• Do you run simulated breach drills against your own monitoring environment?
• After a real incident or a drill, do you produce a written after-action report? Describe what one looks like.

About Your Environment Specifically

• If we become a client, how do you customize your incident response plan to our specific environment?
• What information do you need from us – network diagrams, critical asset inventory, data classification?
• How do you document our recovery priority order so your team knows which systems to restore first?

About Recovery Capability

• What is your target recovery time for a full ransomware scenario in an environment like ours?
• How do you verify that backups are actually clean before restoring from them?
• Have you ever executed a full recovery for a client? Walk me through what that looked like. (Do not accept a hypothetical answer. You want a real example.)

Red Flags That Tell You Everything

Some answers give you immediate clarity. These are the responses that should end the conversation.

• “We have a process, but it’s proprietary.” A legitimate firm will describe the structure of their plan without disclosing internal tooling. A blanket refusal means there is nothing to show.
• “We handle incidents all the time.” Frequency of activity is not evidence of documented capability. This is a non-answer.
• Hesitation followed by “we do that informally.” Informal means undocumented. Undocumented means unpredictable – exactly what you cannot afford when systems are down.
• A recovery time commitment with no explanation of how it was derived. A real number comes from a specific backup architecture and a specific testing history. A made-up number comes from a salesperson who wants to win the deal.
• No written after-action process. Firms that do not learn from incidents in writing repeat the same mistakes. This is one of the clearest signals separating a mature operation from a reactive one.
• Confusion about the difference between containment and eradication. These are distinct phases. Confusing them means an incident gets declared over before the threat is actually gone.

What Good Actually Looks Like in Practice

A firm with a genuine incident response process will answer your checklist questions without hesitation, and the answers will be consistent and specific. The incident commander is a named person, not “the team.” The last tabletop exercise has a date and a scenario. The recovery time estimate comes with an explanation of what assumptions it rests on.

Good firms will also tell you what they do not cover. An honest answer about scope limitations is a trust signal. A firm that claims to handle everything without caveats either has not thought carefully about it or is not being straight with you.

Ask whether their incident response capability has been independently verified. There is a real difference between a firm that says “we follow best practices” and one that can point to an external audit. At Xact IT, our security posture is audited annually by Versprite, a CREST-accredited assessor, against CIS Critical Security Controls. That kind of third-party verification is not standard in this industry – when it exists, it matters.

The posture you want is not a firm that treats incidents as emergencies to be reacted to. You want a firm that has rehearsed the scenarios until the response is nearly automatic. The preparation that happens long before anything goes wrong is exactly what makes the response quiet and controlled when it does.

For context on how protection, detection, and response fit together as a system, see our cybersecurity services overview. You can also explore our managed IT services to understand how ongoing support integrates with a documented incident response plan.

How to Use This to Make a Decision

You are not looking for a perfect score on every question. You are looking for a pattern. Firms with real capability will answer specifically across most of the checklist. Firms without it will be vague on most items even if they nail one or two.

Weight the testing questions heavily. A written plan that has never been practiced is a document, not a capability. Firms that run regular tabletop exercises build organizational muscle memory. Firms that skip testing are hoping the real event goes smoothly – and hope is not a strategy.

Weight the after-action process questions equally. Continuous improvement after incidents is the clearest long-term differentiator between firms that get better over time and firms that stay static. A firm that does not write down what went wrong will make the same wrong call next time.

Finally, pay attention to how they talk about your environment specifically. A generic incident response process applied to every client equally is better than nothing – but it is not the standard you should accept. The plan for your business should reflect your systems, your data, your recovery priorities, and your tolerance for downtime. A firm that cannot explain how they would adapt their process for you has not thought carefully about your business. That gap will show up at the worst possible time.

The goal of this checklist is not to trip up vendors on technicalities. It is to find the firm that has done the hard, unglamorous work of preparing for scenarios nobody wants to face. That work is exactly what separates an IT firm that reacts to incidents from one that has already rehearsed the answer.

How the NIST Framework Applies to IT Firm Evaluation

One additional benchmark worth using when evaluating any IT firm’s incident response process is the NIST Cybersecurity Framework. Published by the National Institute of Standards and Technology, it is one of the most widely adopted standards for structuring cybersecurity programs – including incident response – across industries.

The NIST framework organizes cybersecurity activity into five core functions: Identify, Protect, Detect, Respond, and Recover. The Respond and Recover functions map directly to what a mature incident response process must cover. Ask any vendor whether their incident response documentation is structured around a recognized standard like NIST or CIS Controls. A firm whose process aligns with an established framework is far more likely to have a complete, tested, auditable capability than one operating from an internal checklist with no external reference point.

This matters practically because frameworks create accountability. When a process is mapped to a standard, gaps become visible and measurable. When a process exists only in internal documentation with no external benchmark, there is no objective way to know if anything critical is missing. Asking “what framework does your incident response plan align with?” is a single question that surfaces an enormous amount of information about how seriously a firm takes this discipline.

Understanding the full picture – from the written plan through to framework alignment and third-party verification – is what separates a confident, informed vendor decision from one based on marketing language and gut feel. Use this checklist alongside the NIST standard as your dual reference point, and you will ask better questions than most buyers ever do.

If you want to pressure-test your current IT firm’s answers – or evaluate what a documented, practiced, independently verified incident response process actually looks like – Book a Free Cybersecurity Strategy Call. It is a 20-minute conversation, no obligation, and you will leave with a clearer picture of where you actually stand.