The First Hour of a Security Incident: A Decision Log for Small Teams
Incident readiness guide · Calculated Ventures, LLC. When a suspected cyber incident is reported, the first hour is about protecting people and operations, preserving reliable evidence, and making clear decisions. It is not about immediately choosing a dramatic technical action to prove progress.
CISA’s Incident Response Plan Basics emphasizes defined responsibilities, communications, and preparation before an event. A small organization may not have an incident response department, but it can still establish a usable command structure and a shared decision log.
Before the incident: write down who can decide
Identify a response lead, technical investigator, system owner, executive decision-maker, and communications/legal contacts. Provide alternate names and out-of-band contact information in case identity systems or normal email are unavailable. Define who may authorize isolation, third-party assistance, customer communication, and restoration.
Store a controlled copy of the response plan somewhere accessible during a service outage. Test contact methods during a tabletop exercise. If the organization operates safety-critical or operational technology environments, establish coordination with the safety and operations owners before recommending shutdown or isolation.
Minutes 0–10: Verify the report and start the incident clock
Capture who observed the event, what was seen, the affected service, the time zone and timestamp, and how the observation was obtained. Is the event ongoing? Are people, critical services, or regulated data at immediate risk? Name an incident lead and assign someone to maintain the log.
Do not confuse a single security alert with proof of compromise. Record preliminary classifications such as “suspected,” “confirmed,” and “ruled out” with the evidence supporting changes in status.
Minutes 10–25: Protect essential operations and preserve evidence
Decide whether containment is necessary to prevent further harm. It may involve disabling a compromised account, restricting access, isolating a device, or engaging a cloud/service provider. Each option has operational and forensic consequences; follow the organization’s incident response and evidence-preservation procedures.
Before altering logs or restarting equipment, capture relevant volatile and persistent evidence according to authorized collection procedures. Identify systems likely to contain audit records, endpoint events, authentication histories, network telemetry, and application logs. Use restricted storage with controlled access and consistent timestamps.
Do not erase a suspected infection, reboot a critical system, or run unapproved remediation simply because an alert is alarming. Coordinate containment with qualified responders, especially where public safety, essential services, or legal preservation obligations may be involved.
Minutes 25–45: Establish what is known and what remains uncertain
Build an evidence list with source, timestamp, owner, reliability, and next collection step. Compare what endpoint, identity, network, and application tools show. Look for contradictory observations, such as an account that appears disabled in one console but active in another.
Keep hypotheses separate from findings. “Possible unauthorized access” is a valid working hypothesis; “data exfiltration confirmed” requires evidence. Management should see both the current factual position and the decisions requested of them.
Minutes 45–60: Escalate, communicate, and assign next decisions
Determine which notifications are required by law, contract, insurance conditions, internal policy, or customer agreement. Different rules have different triggers and clocks; consult the responsible legal or compliance authority rather than assuming a universal notification deadline.
Choose an update cadence and approved communications channel. Document who will provide the next situation report, when it will arrive, and which evidence gaps are blocking containment or recovery decisions. External statements should be approved through the organization’s established process.
A usable incident decision-log format
- Event ID: unique identifier and opened-at timestamp with time zone.
- Observation: what was directly observed, by whom, and through which tool or report.
- Evidence: immutable or controlled storage reference and collector.
- Decision: action considered, justification, approving authority, and operational consequences.
- Action: owner, time executed, change or ticket reference, and outcome.
- Next checkpoint: unresolved question, responsible person, and target follow-up time.
Example (fictional): 14:06 EDT—multiple failed administrator logins reported. 14:12—identity analyst reviewing authoritative sign-in records; compromise not confirmed. 14:19—security lead approves temporary conditional access restriction after operations review; reevaluate at 14:45. This demonstrates how to distinguish observations, analysis, and approved actions.
After the first hour: verify recovery and learn
Once the event is contained, restore services only using the approved plan. Verify normal operations with the application owner, preserve the incident timeline, record costs and impacts accurately, and capture lessons learned. Update detection rules, backups, access controls, supplier contacts, and tabletop scenarios based on evidence rather than speculation.
One simple readiness drill is to provide the team with a scenario involving a suspicious privileged login and unavailable email. Time how long it takes to contact the response lead, identify the system owner, and make one documented containment decision. The gaps are the action plan.
Resources and authoritative guidance
Threat intelligence may inform whether a current vulnerability is relevant to the investigation. Use Threat Pulse’s CISA-sourced updates for leads, then verify them against authoritative sources and local evidence. For assistance structuring security operations and compliance artifacts, visit Calculated Ventures capabilities.
- CISA Incident Response Plan Basics
- CISA Cybersecurity Performance Goals
- NIST SP 800-37 Rev. 2: Risk Management Framework
This is preparation and process guidance. For an active high-impact incident, engage the organization’s designated responders, leadership, legal counsel, and appropriate authorities.
