The Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-13-1 requires an approved Incident & Threat Management Policy that defines how an organization identifies, classifies, responds to, and reports security incidents and threats; this post gives a practical, audit-ready template and an approval workflow tailored to the Compliance Framework so small businesses can implement the control quickly and consistently.
What Control 2-13-1 requires and key objectives
Control 2-13-1 expects the organization to maintain a documented and approved policy that: (1) defines incident and threat categories and severity levels; (2) assigns roles and responsibilities (including escalation points); (3) specifies detection, containment, eradication, recovery and reporting requirements; (4) mandates evidence preservation and chain-of-custody; and (5) provides timelines for internal and external notifications. Key objectives are consistent detection/response, timely reporting to stakeholders, defensible evidence handling for investigations and regulatory notification, and measurable performance (MTTD/MTTR) that auditors can verify against defined metrics.
Practical policy template (how to structure your document)
Use a clear, modular layout so auditors and staff can find elements quickly. At minimum include: Purpose & Scope (systems, locations, data classes covered), Definitions (incident, near miss, threat actor, data breach), Roles & Responsibilities (CISO, Incident Response Lead, IT Ops, Legal, HR, PR), Incident Lifecycle (Detection, Triage & Classification, Containment, Eradication, Recovery, Lessons Learned), Reporting & Notification (internal timelines, regulator breach notification triggers), Evidence Preservation (hashing, imaging, chain-of-custody), Tools & Integrations (SIEM/EDR/ticketing/forensics), Training & Exercises, Metrics & Review (MTTD, MTTR, exercises per year), and Document Control (versioning, review cadence, approval list). Example short snippet you can drop into your policy: "Incidents classified as High/Severe must be reported to the CISO within 1 hour and to external regulators per statutory timelines; forensic imaging must be performed before systems are remediated where feasible."
Sample sections — specifics to include
In the Evidence Preservation section specify technical steps: collect volatile memory via approved tools (e.g., dump using Belkasoft or OS-specific tools), create forensic disk images with hashes (SHA-256), store images in an encrypted evidence repository, log actions in a tamper-evident chain-of-custody record, and maintain logs for at least 12 months (or longer if your Compliance Framework or sector requires). Under Detection, list log sources and retention: firewall NGFW logs (90 days online, 1 year archived), proxy and web gateway (90 days), Active Directory auth logs (12 months), EDR telemetry (90 days hot, 12 months cold), and syslog forwarding to SIEM with timezone normalization to UTC for consistency during investigations.
Approval workflow — role-based, auditable, and lightweight for small businesses
Design an approval workflow that is clear but not bureaucratic. Suggested workflow: Draft by IT Security Owner → Technical review by IT Ops & EDR/SIEM lead (3 business days) → Legal & Privacy review for notification obligations (3 business days) → Executive review (CISO/CEO) for risk acceptance (5 business days) → Formal sign-off by CISO and archived copy stored in a policy repository with signed email evidence. Use version control naming like vYYYY.MM.DD-# and record approver name, role, date, and rationale for changes. For small businesses the total approval cycle can be targeted to 10 business days; include an emergency fast-track approval path for immediate policy changes after a major incident (documented post-facto review required).
Workflow artifacts to maintain for compliance evidence
Keep an approvals log (PDF of the signed policy plus timestamped sign-off emails), change control tickets (e.g., Jira or ServiceNow change request with ID), meeting minutes from the review committee, tabletop exercise reports demonstrating the policy in action, and training completion records. Auditors will look for these items: the signed policy, version history, evidence of distribution (intranet, email), training rosters, and at least one exercise or incident report that showed the policy was followed.
Technical integration and implementation notes specific to Compliance Framework
Integrate the policy into your toolchain: map incident categories to SIEM correlation rules and EDR playbooks so that the policy's classification levels trigger the correct automation (e.g., High severity → isolate host via EDR, create high-priority ticket, notify IR lead). Define retention and access controls consistent with the Compliance Framework — logs must be immutable for the minimum period defined by the framework (commonly 12 months); use WORM storage when long-term retention is required. Implement automated evidence collection scripts that capture relevant artifacts (system logs, process lists, network connections) into a secure bucket with write-once permissions and record the SHA-256 hash to the investigation ticket.
Real-world small business scenarios and actionable steps
Scenario A — Phishing that leads to credential compromise: Triage the event as Moderate if only credentials suspected, High if lateral movement is detected. Actions: force password reset for affected accounts, enable MFA if not already present, run EDR scans on logged-in endpoints, preserve mailbox logs (export PST), and review authentication logs in AD/RADIUS. Collect screenshots, email headers, and message trace as evidence. Scenario B — Suspected ransomware: Immediately isolate impacted hosts via EDR, capture memory and disk images, collect network flow logs to identify exfiltration, check backups for integrity and recovery readiness, and notify legal if regulated data is involved. Document each step in the ticket and preserve hashes for later forensic validation. Both scenarios should be exercised in a tabletop at least annually; small businesses should do focused tabletop exercises every 6 months for high-risk scenarios.
Compliance tips, best practices, and risk if not implemented
Best practices: keep the policy concise (2–6 pages ideal for small teams), map each policy requirement to a control in the Compliance Framework, automate evidence capture where possible, and tie training to performance objectives. Track KPIs (MTTD < 24 hours, MTTR target based on business impact) and report them quarterly to executives. Risks of not implementing Control 2-13-1 include delayed detection and containment leading to larger breaches, inability to demonstrate due diligence during regulatory investigations, higher forensic costs, loss of customer trust, and potential fines. For example, failing to preserve evidence can invalidate an insurance claim or impede law enforcement involvement after a ransomware attack.
Summary: Build the Incident & Threat Management Policy with clear scope, classification, roles, technical requirements (SIEM/EDR/log retention/evidence handling), and a lean but auditable approval workflow that includes technical, legal, and executive sign-off; maintain artifacts (signed policy, approvals log, change tickets, tabletop reports) and integrate policy actions into automated detection and response playbooks. Following this template and workflow will help small businesses meet ECC – 2 : 2024 Control 2-13-1, reduce incident impact, and provide the documentation auditors and regulators expect.
