Protect / Incident Response

Incident Response.

When something goes wrong, how fast you respond determines how bad it gets.

By Brian Gagne, CTO · March 14, 2026 · Updated March 19, 2026

The 3am phone call

Here is what separates organizations that survive security incidents from those that do not: the ones that survive had a plan before the phone rang. Incident response is a predefined process for handling security events -- detection, containment, eradication, recovery, and lessons learned. The organizations that scramble are the ones that never wrote down who to call, where the logs are, or how to isolate a compromised system. The organizations that execute are the ones that practiced it before it mattered.

Preparation is 90% of the work

Most incident response work happens before an incident occurs. Defining escalation paths. Establishing communication channels that work when email is compromised. Documenting system architectures so you know what connects to what when you need to isolate something fast. Running tabletop exercises so the first time your team works through a scenario is not during a real event. When an incident hits, you do not have time to figure out where the logs are stored. You do not have time to track down who has admin access to the compromised system. You do not have time to debate whether to pull the network cable. All of that needs to be decided, documented, and rehearsed before anything goes wrong.

Containment first. Investigation second.

When a security event is detected, the first priority is stopping the spread. Isolate affected systems. Revoke compromised credentials. Block known indicators of compromise. Investigation happens in parallel, but containment cannot wait for a complete understanding of what happened. Every minute of delay is more systems exposed.

What a real incident response capability looks like

It is not a binder on a shelf. A real incident response capability includes monitoring that detects anomalies before they become full-blown incidents. Documented playbooks for the scenarios most likely to affect your environment. Escalation paths that reach actual humans who can make decisions, not a ticket queue. Our threat detection work feeds directly into incident response. The monitoring surfaces the signal. The playbook tells you what to do with it. The people on the other end have the access and authority to act. Those three pieces have to work together.

13+
years of zero security incidents on managed infrastructure

Our longest client relationships go back to 2012. Across those 13+ years of managed infrastructure: zero security incidents. That track record is not luck. It is the result of hardened infrastructure, continuous monitoring, and incident response capability that was ready before it was needed.

Remediation as response: closing active vulnerabilities

Problem

A northeast MSP serving HIPAA and PCI-DSS compliance clients had active penetration testing findings -- IPv6 DNS spoofing, NetBIOS spoofing, SMB null session authentication, SMB signing issues -- with no clear remediation path or timeline.

Solution

We treated the unresolved findings as an active incident posture. Each finding was triaged by real-world exploitability, not report order. Remediation was scoped to budget constraints with verification testing after each fix. The response included documenting the full remediation path so the MSP had evidence for compliance auditors.

Outcome

All critical findings remediated and verified. The MSP had documented evidence of detection, response, and resolution -- the exact lifecycle that compliance frameworks require.

Incident response is not just about breaches. Unresolved vulnerabilities sitting in a report are incidents waiting to happen. The response is the same: triage, prioritize, fix, verify.

How we build response into every engagement

We build incident response capability into every managed services engagement. That means documented playbooks for common scenarios, defined escalation paths that reach us directly, and monitoring through our security operations platform that detects anomalies before they become full-blown incidents. When something happens at 3am, Brian or Meelie pick up the phone. Not a helpdesk. Not a ticket queue. That is what our SLA response time commitments actually mean. First conversation is free. Reach us at kief.studio/contact.

Frequently asked questions

What happens if something breaks at 3am?

You call us and we pick up. Brian or Meelie. Not a helpdesk, not a voicemail. Our managed services engagements include defined escalation paths with real response time commitments. The monitoring is already running, so in many cases we know about the issue before you do.

Do we need an incident response plan if we are a small business?

Yes. Small businesses are targeted precisely because attackers assume they lack response capability. Your plan does not need to be a 200-page document. It needs to answer four questions: how do we detect something is wrong, who do we call, how do we contain it, and how do we recover. We build these plans as part of our managed services engagements.

Can you help if we are already dealing with an active incident?

Yes. We can assist with containment, investigation, and recovery. The priority is always stopping the spread first, then understanding what happened. If you are in the middle of something right now, reach us at kief.studio/contact.

Need help with this?

First conversation is free. Talk directly to the founders.

Get in Touch