Control 2-13-2 of ECC – 2 : 2024 requires organizations to establish measurable KPIs and consistent reporting for incident and threat management so the Compliance Framework can validate that detection, response and remediation processes are effective, auditable and continually improving.
What the requirement means in practice
At its core this control asks you to define what “good” looks like for incident and threat handling, instrument the environment to capture objective data, and publish reports that demonstrate performance against those definitions. For Compliance Framework compliance you must show documented KPI definitions, data sources, collection methods, dashboards/reports, thresholds/targets, and evidence of review and improvement actions.
Step-by-step implementation approach
Start by mapping your incident lifecycle to measurable events: detection, triage, containment, eradication, recovery and post-incident review. For each stage define the single-source-of-truth fields that you will use in KPI calculations (for example: incident_id, detection_timestamp, containment_timestamp, remediation_timestamp, severity, affected_asset_id, root_cause). Store these fields in a centralized repository: SIEM/ELK/Cloud logs, EDR alerts, or your ticketing/IR platform (TheHive, ServiceNow, Jira Service Management).
Selecting practical KPIs (examples and formulas)
Choose a focused set of KPIs that align to business risk and are feasible for a small business to collect. Start with 6–10 core metrics such as: Mean Time to Detect (MTTD) = avg(detection_timestamp - event_start_timestamp), Mean Time to Respond/Contain (MTTR) = avg(containment_timestamp - detection_timestamp), Incidents by severity per month, % Incidents closed within SLA, Recurrence rate (repeat incidents per asset), False positive rate (alerts dismissed / total alerts). For small teams, limit to MTTD, MTTR, incidents-by-severity and % closed-in-SLA to keep reporting actionable.
Data sources, instrumentation and technical details
Ensure each detection source emits standardized fields. Recommended minimum event schema: timestamp, event_id, incident_id, detection_source, detection_rule_id, severity (mapped to ECC severity levels), host_id, user_id, src_ip, dst_ip, disposition, and timestamps for containment and remediation. For calculation you can use SQL on an event-store or aggregations in Elastic/Kibana, Splunk, or cloud-native tools (AWS GuardDuty + Security Hub + CloudWatch Metrics). Sample query (pseudo-SQL) to compute MTTR: SELECT avg(extract_epoch(containment_timestamp) - extract_epoch(detection_timestamp)) AS MTTR_hours FROM incidents WHERE severity = 'critical' AND containment_timestamp IS NOT NULL AND detection_timestamp IS NOT NULL AND time_range = 'last_30_days'.
Small business example scenario
Example: a 50-person SaaS startup runs production on AWS and uses GuardDuty for detection, GitHub for code, and Jira for incident tickets. Implementation steps: forward GuardDuty findings to an S3 bucket and Security Hub, normalize alerts into a small DynamoDB incidents table with fields above, use Lambda functions to enrich events (geo-IP, asset owner), and run scheduled Glue/Athena queries to compute MTTD/MTTR and generate a weekly PDF report for the CTO and a monthly dashboard for the board. Targets: MTTD ≤ 1 hour for critical, MTTR ≤ 8 hours for critical, and ≥ 90% of incidents closed within SLA.
Reporting cadence, audiences and evidence for auditors
Define report formats and rhythms: operational (daily or weekly) for SOC/tech teams, management (monthly) with trend lines and root-cause summaries, and board-level (quarterly) with high-level KPIs, significant incidents, and remediation plans. For Compliance Framework audits retain evidence: raw log extracts, KPI calculation queries, dashboard snapshots, meeting minutes where KPI reviews occurred, and action tracker entries tying KPIs to remediation tasks. Retain 12 months of KPI datasets by default (longer if the framework or local law requires).
Automation, quality control and continuous improvement
Automate data pipelines and KPI calculations to minimize manual error: use SOAR playbooks to tag incidents with standardized fields and to mark containment/remediation timestamps. Implement data quality checks (e.g., percentage of incidents with missing containment timestamps) as meta-KPIs. Run quarterly reviews to validate KPI definitions against emerging threats and business changes, and revise thresholds based on trend analysis and risk appetite.
Compliance tips, best practices and common pitfalls
Tips: (1) Start small—report a minimal, reliable KPI set; expand as maturity increases. (2) Map KPIs back to business impact so executives understand meaning (e.g., MTTR reduction equates to X fewer hours of downtime). (3) Use consistent severity mappings and SLAs; inconsistent severity coding breaks KPI accuracy. (4) Instrument incident tickets with automated timestamps—manual entries introduce bias. Pitfalls: over-measuring leads to noise; poorly defined metrics (e.g., counting alerts instead of incidents) produce misleading trends. For evidence, keep documented SOPs showing how each KPI is computed and who owns the metric.
Risk of not implementing the requirement
Failing to implement KPIs and reporting under Control 2-13-2 leaves your organization blind to detector and responder effectiveness, increasing the risk of prolonged compromises, repeated incidents, regulatory nonconformance and reputational damage. Without objective metrics you cannot prove to auditors or leadership that incidents are being detected and resolved within acceptable timeframes—this can lead to fines, failed audits, missed insurance claims and avoidable downtime.
Summary: Implementing KPIs and reporting for incident and threat management under ECC 2:2024 Control 2-13-2 requires a practical, phased approach: map your incident lifecycle, standardize event schema, select focused KPIs (MTTD, MTTR, incidents-by-severity, SLA compliance), automate collection and calculation, build audience-specific reports, retain audit evidence, and institute continuous improvement cycles. For small businesses the emphasis should be on reliable, lightweight instrumentation and clear tie-ins to business impact so the Compliance Framework can be demonstrably satisfied.
