Mean Time to Tune Detection After Incident

The post-incident retrospective is a measurable input

The live detection plane carries the rule library, the routing rule library, the severity ladder, the suppression scope register, and the analyst procedure documentation. Each security incident reads against all five surfaces simultaneously: the rule that fired or did not fire, the routing rule that read the alert and produced the destination, the severity that allocated the triage time, the suppression scope that hid or did not hide the alert, and the analyst procedure that produced the response action. The retrospective record names which of the five surfaces produced the gap the incident exposed.

The platform stores the operating outcomes around each retrospective intervention; the security organisation maintains the detection content, the routing rules, the severity ladder, the suppression register, and the analyst procedures. Reading the retrospective record against the activity log gives the programme a closed-loop view: which incidents produced which gaps, which gaps closed inside the agreed bands, which gaps stayed open across quarters, and which rules appear in retrospectives more than once. The detection engineering tuning economics research covers the steady-state per-rule tuning labour; this research prices the retrospective-driven tuning labour that flows through the same library on a different cadence.²³

Programmes that argue retrospectives from anecdote produce a free-text lessons-learned section in the incident report and rarely revisit it. Programmes that argue retrospectives from a measured loop write the gap against a structured taxonomy, assign a named owner with a target date, validate the closure against the same metric the gap was opened against, and read the per-input distribution on a per-quarter cadence to identify themes. The two postures look identical inside a single incident retrospective and diverge sharply across multi-quarter windows.

Seven retrospective input classes

Retrospective findings are not a single category. Each input class points at a different surface of the detection plane, requires a different intervention discipline, and carries a different closure-band expectation. Naming the seven classes lets the retrospective record write against a structured taxonomy rather than against a free-text narrative.^1,2,11

A defensible retrospective record reads the input-class distribution per quarter and per programme. A record whose retrospective interventions are 70 percent missed-detection inputs against a single telemetry source is signalling a telemetry pipeline problem, not seven independent rule problems; a record whose interventions are evenly distributed across the seven classes is signalling a detection programme operating against a varied incident pattern. Reading the security finding routing rule economics research alongside the retrospective distribution lets the programme see whether routing failures are a retrospective input or a steady-state library problem.²⁶

Defensible closure bands per input class

Closure bands are not a target. They are what the per-input record produces when the retrospective assigns a named owner with a target date, the intervention writes against a clear hypothesis, the validation step happens against the same metric the gap was opened against, and the per-quarter theme review catches stalled work. Programmes whose distribution skews materially past these bands usually lack one of those four disciplines.^1,2,11,13

The bands compound against the incident volume. A programme that opens five retrospective interventions per incident across a ten-incident quarter is carrying fifty open work items; the steady-state closure rate against the bands determines whether the backlog stays bounded or grows. Reading the median and 90th percentile together prevents the long-tail outliers from masking the operational reading.

A four-track cadence keeps the retrospective surface bounded

The realistic cadence is four tracks. Each track has a different scope, a different participant set, and a different output. The four tracks together keep the retrospective work bounded, the closure-band distribution visible, the thematic patterns observable, and the audit evidence reproducible.^1,2,3,11

The cadence reads the activity log and the engagement chronology on each track. Without the activity log, none of the tracks can identify which retrospective interventions have changed state since the last review, which interventions have been applied without provenance, or which interventions have been archived without the chain back to the originating incident.

A defensible retrospective intervention artefact has eight fields

The artefact stays operational across audit windows when it carries eight fields per intervention. The artefact is not a tooling output; it is what the audit walkthrough reconciles against the live rule state, the override register, the routing rule library, the severity ladder, and the analyst procedure documentation.^{1,2,3,4,5,6,7}

• Retrospective intervention identifier. Immutable reference the activity log writes against; preserved across the rule, routing, or procedure version chain.
• Source incident identifier. The originating incident retrospective record, with the named retrospective lead and the retrospective date preserved; the chain back to the incident chronology stays intact.
• Retrospective input class. One of the seven recognised input classes (missed detection, low-fidelity detection, late detection, suppressed detection, routing failure, severity miscall, downstream triage failure).
• Target rule or procedure identifier. The live rule, routing rule, severity ladder entry, suppression scope, or analyst procedure the intervention modified, with the version history preserved alongside the intervention chain.
• Hypothesis. The change the intervention expected to produce, written against the precision, recall, severity-match, routing-match, or triage-match metric the intervention was meant to move.
• Validation method. How the intervention was confirmed to produce the intended change, with the named reviewer and the validation evidence pointer (synthetic execution, replayed trace, purple-team confirmation, live operating window observation).
• Time-to-tune readings. Calendar days from retrospective open through intervention close and validation close, recorded as three distinct timestamps; the per-cycle breakdown lets the median and the 90th percentile read cleanly across the input-class distribution.
• Outcome record. The post-intervention reading against the target metric, the named reviewer who confirmed the reading, and the next-action field (continue, refine, or revert if the change did not pay back).

Interventions missing any of the eight fields are not reconcilable at audit walkthrough. The audit walkthrough reads each retrospective intervention back through the intervention identifier on the activity log, confirms the source incident through the engagement chronology, confirms the intervention existed at the time the rule or procedure was modified through the version history, and confirms the outcome record matches the metric trend the operating record shows. Reading the detection validation cycle economics research alongside the retrospective artefact gives the validation method the structure the eight-field record reads against.²⁴

Six failure modes on the retrospective ledger

The six failure modes are predictable and observable on the live record. Each shows in the retrospective ledger, the activity log, or the per-quarter theme review well before it shows in the headline time-to-tune number. Reading the six failure modes as a named checklist on a cadence is what catches retrospective decay before it shows at audit walkthrough.^1,2,3,6

1. Retrospective ticket open without owner. The retrospective produces a named gap but no named owner-with-target-date; the work stalls inside the backlog and the time-to-tune reading skews silently as the unowned interventions accumulate.
2. Retrospective ticket open without intervention class. The retrospective records the gap as free text rather than against the seven-input taxonomy; the per-input distribution cannot be read and the per-quarter theme review cannot identify patterns.
3. Validation deferred to next cycle. The intervention ships into the live library without a named validation method; the rule is assumed to work because it was authored, and the next incident retrospective discovers the rule does not fire on the target behaviour.
4. Time-to-tune averaged across the heavy tail. The programme publishes a single mean across a distribution whose tail is several quarters long; the median behaviour is hidden by the long-tail outliers and the audit committee receives a dashboard number that does not match the operational reality.
5. Retrospective backlog growth without prioritisation. The retrospective record accumulates open interventions across quarters; the backlog grows linearly with incident volume, the time-to-tune distribution shifts upward, and the underlying cause stays unnamed.
6. Retrospective archive without provenance link. The retrospective ticket is archived after closure but the link back to the source incident, the source telemetry, and the original retrospective decision is not preserved; the audit walkthrough cannot reconstruct why the intervention was applied.

Each failure mode is recoverable through review. None is recoverable through more interventions. The defensible response to each failure mode is the per-quarter theme review and the per-audit-cycle evidence read rather than additional retrospective volume. Programmes that name and read the six failure modes against the live record on a cadence catch the decay inside one or two cycles. Programmes that read only the headline time-to-tune mean catch the decay two to four quarters after it has compounded.

Five numbers for the leadership post-incident tuning report

Five numbers communicate the post-incident tuning health to leadership without requiring operational depth. The numbers pair against the incident volume curve and the median time-to-detect reading; reading any one number on its own usually overstates the surface and understates the depth.^1,2,4

Reporting the five numbers on a per-quarter rhythm alongside the incident volume curve and the median time-to-detect reading gives leadership the closed-loop view from incident detection through detection improvement on one record. Reading the mean time to detect vs remediate research alongside the post-incident tuning numbers lets the programme see whether the operating-time levers and the learning-time levers are improving on parallel cadences.²⁷

Framework citations read the retrospective surface at three points

Enterprise frameworks do not name post-incident detection tuning directly. They name the underlying expectations the retrospective ledger implements: documented post-incident analysis, documented improvement action based on lessons learned, and periodic review of the analysis-to-improvement chain. Mean time to tune detection after incident prices the labour and the elapsed time that keep all three observable on a cadence; without the discipline, the framework citations are aspirational rather than operational.^{1,2,3,4,5,6,7}

• ISO 27001:2022 Annex A 5.27. Learning from information security incidents with documented evidence; the retrospective intervention record reads against the named-learning expectation, and the per-quarter theme review reads against the periodic-review expectation.
• ISO 27001:2022 Annex A 8.16. Monitoring activities with documented evidence and periodic review; retrospective interventions that target the monitoring control read against the periodic-review surface.
• NIST CSF 2.0 RS.AN. Adverse event analysis with documented evaluation; the per-incident retrospective record reads against the analysis evidence surface.
• NIST CSF 2.0 RS.IM. Incident response improvements based on lessons learned; the retrospective intervention record carries the chain from analysis through improvement.
• NIST CSF 2.0 ID.IM. Improvement of the cybersecurity programme based on lessons; the per-quarter theme review reads against this surface as a programme-level improvement track.
• NIST SP 800-61 Revision 2 Section 3.4. Post-incident activity including lessons-learned meetings with documented evidence; the retrospective intervention record reads against the named-improvement-action expectation.
• NIST SP 800-53 Revision 5 IR-4 and IR-8. Incident handling and incident response plan with documented update on lessons learned; the retrospective ledger reads against both surfaces.
• SOC 2 CC7.4 and CC4.1. Incident response activities and monitoring evaluation; both criteria read against the documented retrospective record and the per-audit-cycle evidence track.
• PCI DSS v4.0 Requirement 12.10. Incident response plans with documented exercises and updates; the retrospective intervention record that updates the live detection or routing library reads against this surface where the CDE is in scope.
• DORA Article 17 and Article 18. ICT-related incident management and classification and reporting; the retrospective record that closes detection gaps surfaced by classified incidents reads against both articles for in-scope financial entities.
• CIS Critical Security Controls v8.1 Control 17 and Control 8. Incident response management and audit log management; the retrospective ledger and the activity log together read against the documentation surface of both controls.

The pattern across frameworks is consistent: documented post-incident analysis, documented improvement action, periodic review of the analysis-to-improvement chain. Mean time to tune detection after incident prices the labour and the elapsed time that keep all three observable on a cadence.

How SecPortal supports the post-incident detection tuning surface

SecPortal keeps the per-incident engagement record, the per-finding state machine, the activity log, the override register, the retesting workflow, and the named-owner field on one workspace so the retrospective record reads against the same data the operating cadence runs against. The platform stores the operating outcomes around each retrospective intervention; the security organisation maintains the detection content, the routing rules, the severity ladder, the suppression register, and the analyst procedures.^{15,16,17,18,19,20,21,22}

• Engagement management binds each incident retrospective to a chartered engagement record with named scope, named timeline, and named owner; the per-incident retrospective stays reproducible against the same record across audit windows.
• Findings management holds the named-owner field, the severity record, the engagement reference, the evidence pointer, and the eight-field artefact a retrospective intervention writes against when the intervention modifies the live finding state.
• Finding overrides hold the eight-field exception decision chain that the suppression-scope reconciliation traverses, with named approver, rationale, effective period, and named expiry; the override register stays auditable across multi-quarter retrospective cycles.
• Activity log with CSV export captures the timestamped chain of every retrospective state change, every owner reassignment, and every closure decision with 30, 90, or 365 day retention depending on plan; the log supplies the time-to-tune readings, the per-input distribution, the recurrence rate, and the retrospective backlog open count the leadership report reads.
• Retesting workflows hold the re-verification step as a first-class state and pair the rescan output, the manual validation evidence, or the synthetic-execution evidence to the original retrospective intervention; the closure evidence carries through to administrative closure.
• Continuous monitoring runs recurring detection-validation and tuning cycles on a documented cadence with daily, weekly, biweekly, or monthly schedules; the cadence pairs with the per-environment-change retrospective trigger.
• Compliance tracking maps the retrospective-related framework citations (ISO 27001 A.5.27 and A.8.16, NIST CSF 2.0 RS.AN and RS.IM and ID.IM, NIST SP 800-61 Section 3.4, NIST SP 800-53 IR-4 and IR-8, SOC 2 CC7.4 and CC4.1, PCI DSS 12.10, DORA Articles 17 and 18, CIS Controls v8.1 Controls 17 and 8) so the retrospective review reads against the same crosswalk the audit interface uses.
• AI reports can summarise the retrospective backlog open count, the median and 90th percentile time-to-tune, the per-input distribution, the recurrence rate, and the per-incident retrospective narrative for the leadership post-incident tuning read.
• Team management with RBAC supplies the workspace user catalogue (owner, admin, member, viewer, billing roles) that the named-owner field on each retrospective intervention references; the role assignments support the documented-allocation surface frameworks read against.
• Bulk finding import accepts Nessus, Burp Suite, and CSV so detection-derived findings from external testing tools and external alert-triage systems join the same lifecycle the workspace-native findings traverse.

What the platform does not do is also part of the design. SecPortal does not author detection rules, does not execute attack simulations against live systems, does not ingest live SIEM telemetry, does not integrate with SIEM, SOAR, EDR, NDR, ticket, or workforce-management platforms, does not push to Jira, ServiceNow, Slack, Teams, or PagerDuty, and does not automate retrospective decision-making. The retrospective authoring, the rule editing, the live detection plane, the routing rule library, the severity ladder, and the analyst procedure documentation belong to the security organisation. The platform keeps the retrospective outcome record, the activity log, the engagement chronology, and the override register on one workspace so the post-incident detection tuning question is reproducible at any moment between cycles.

Read against the rest of the SecPortal research library, post-incident detection tuning is the retrospective-driven layer of a wider detection operating discipline. The detection engineering tuning economics research covers the steady-state per-rule tuning labour the live library absorbs across operating cycles; the detection validation cycle economics research covers the five lifecycle states each rule traverses; the validation method mix economics research covers the budget split across validation methods; the security finding routing rule economics research covers the routing rule library the detection-derived findings traverse; the control validation vs detection validation pairing research covers the cross-register pairing the audit chain reads. The retrospective discipline ties the five surfaces together at the moment an incident produces a named gap.^23,24,25,26

For the operational workflow side that runs the retrospective record across the security organisation, the post-incident lessons learned workflow use case documents how the chartered engagement record holds the retrospective output, the named-owner intervention list, and the closure evidence on one trail. The incident response use case covers the upstream incident chronology the retrospective reads against, and the security leadership reporting use case covers how the five leadership numbers feed the per-quarter board-cybersecurity briefing without rebuilding the deck each cycle.

Frequently asked questions

Sources and further reading

1. NIST, SP 800-61 Revision 2 Computer Security Incident Handling Guide (Section 3.4 Post-Incident Activity)
2. NIST, SP 800-53 Revision 5 (IR-4 Incident Handling, IR-8 Incident Response Plan, SI-4 System Monitoring)
3. NIST, Cybersecurity Framework (CSF) 2.0 (RS.AN Adverse Event Analysis, RS.IM Incident Response Improvements, ID.IM Improvement)
4. ISO/IEC 27001:2022 Annex A 5.27 Learning from Information Security Incidents and 8.16 Monitoring Activities
5. AICPA, SOC 2 Trust Services Criteria (CC7.4 Incident Response Activities, CC4.1 Monitoring Evaluation)
6. PCI Security Standards Council, PCI DSS v4.0 Requirement 12.10 Incident Response Plan
7. European Union, Digital Operational Resilience Act (DORA) Article 17 ICT-Related Incident Management and Article 18 Classification
8. CIS, Critical Security Controls v8.1 (Control 17 Incident Response Management, Control 8 Audit Log Management)
9. NIST, SP 800-137 Information Security Continuous Monitoring (ISCM)
10. MITRE ATT&CK Framework, Enterprise Matrix
11. FIRST, Computer Security Incident Response Team (CSIRT) Services Framework
12. NCSC, Incident Response and Detection Engineering Guidance
13. SANS, Incident Handler's Handbook
14. ENISA, Good Practice Guide for Incident Management
15. SecPortal, Findings Management
16. SecPortal, Finding Overrides
17. SecPortal, Activity Log
18. SecPortal, Engagement Management
19. SecPortal, Retesting Workflows
20. SecPortal, Continuous Monitoring
21. SecPortal, Compliance Tracking
22. SecPortal, AI Reports
23. SecPortal Research, Detection Engineering Tuning Economics
24. SecPortal Research, Detection Validation Cycle Economics
25. SecPortal Research, Validation Method Mix Economics
26. SecPortal Research, Security Finding Routing Rule Economics
27. SecPortal Research, Mean Time to Detect vs Remediate