Incident response for engineering teams

The first hour of a security incident is decided months earlier. A practical plan for teams that ship software, not a template for a binder.

Engineering teams already do incident response: a bad deploy, a database at 100% CPU, a queue that stopped draining. A security incident uses the same muscles with three differences — someone may be actively working against you, what you say outside the company has consequences, and the evidence matters after the fire is out. The plan below assumes you have an on-call rotation and a chat tool, and adds only what security needs.

Before: the preparation that decides the first hour

Know what "normal" looks like

You cannot spot an attacker's session if you do not know what your own traffic looks like. Centralised logs for authentication, administrative actions and outbound connections, kept long enough to look back a month, are the minimum. Most intrusions are discovered weeks after they begin.

Decide who can pull which lever

Revoking every session, rotating a signing key, taking a service offline: each is a one-line command and a large business decision. Write down, in advance, who may take each action without asking. The on-call engineer at 03:00 should not be guessing whether they are allowed to disable logins.

Keep the contact list outside the system

If the identity provider is what got compromised, the runbook in the wiki behind single sign-on is unreachable. Legal, the executive on call, the cloud provider's abuse contact and your cyber-insurance line belong somewhere that still works when everything else does not.

During: contain, then understand

1. Stop the bleeding first. Rotate the exposed credential, block the address, revoke the token. Investigation can wait; exfiltration cannot.
2. Preserve before you fix. Snapshot the disk, export the logs, note the time. A rebuilt server is a clean server with no memory of what happened.
3. One channel, one scribe. A dedicated incident channel and a person whose only job is writing down what was done and when. That timeline is what every later conversation — customers, regulators, insurers — will be built on.
4. Assume the first finding is not the whole story. A leaked key is often how the attacker got in, not everything they did once inside. Check what the credential could reach, and whether it did.

After: the part that makes the next one shorter

A blameless review within a week, while memories are fresh. Two outputs: the gap that let it happen (a control to add) and the gap that let it last (a detection to add). Then put the regulatory clock in the record — many jurisdictions require notification of affected people within fixed days of discovery, and "discovery" is the timestamp from your scribe.

The plan is not the document. The plan is the decisions you no longer have to make at 03:00.

Where EagleWise fits

Most of what the first hour needs is knowing what you have and who owns it: which service the leaked key belonged to, which hosts are exposed, which dependency the advisory is about. EagleWise keeps that map current — assets, exposure, code findings, owners — so an incident starts from an inventory rather than a search. EagleWise alerts your team when exposure or device posture changes; Alameda does not staff, contain or recover the incident — that stays with you.