Security incident response for a small team: a minimum procedure

Goal

Handle a suspected compromise (leaked credential, exploited dependency, unexpected administrator login, defaced page) so that damage is limited, evidence survives and the team learns from it, without a dedicated security function.

Prerequisites

NIST SP 800-61 Rev. 3 (April 2025) places incident response inside an organisation's ongoing cybersecurity risk management under the Cybersecurity Framework 2.0: prepared beforehand, not improvised. The OWASP Secure Product Design cheat sheet lists a practised security incident response plan among its configuration recommendations. Prepare: a contact list (who decides, who can revoke credentials, hosting provider, registrar, payment provider), an inventory of secrets with their rotation steps, logs shipped off the hosts they describe, and a written evidence rule.

Steps

1. Declare: one person names it an incident, opens a timeline document and records every action with a timestamp from then on. Two roles at most: responder and communicator.
2. Scope: which credentials, hosts and data could the attacker have reached? Assume the worst plausible case until evidence narrows it.
3. Contain before eradicating: revoke or rotate exposed credentials, cut the attacker's path (disable the account, remove the key, take the endpoint offline) and rotate every secret the compromised component could read. Prefer reversible actions.
4. Preserve evidence before destroying state: snapshot disks or containers, export logs, record running processes and connections; then rebuild rather than clean in place.
5. Eradicate and recover: rebuild affected systems from known-good images and source, apply the fix, restore data from backups taken before the compromise where integrity is in doubt, and confirm that every rotated credential is in use.
6. Communicate factually with affected users and partners; which notification obligations apply depends on jurisdiction and contracts and should be checked with someone qualified to say.
7. Close with a blameless postmortem: timeline, root cause, what detection would have caught it earlier, actions with owners.

Expected result

The first hour follows a checklist rather than a debate; the postmortem has evidence to work from; every credential the attacker could have seen has been rotated; the incident produces concrete changes to detection and configuration.

Limits and test basis

This is a synthesis of the cited guidance scaled down to a small team, not a legal or regulatory procedure; obligations are not stated here. Rehearse it once with a fictitious leaked key: a plan that has never been run is a document, not a capability.