Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 27035-3:2020 — Incident Management — Response and Operation
Practical guidance for detecting, analyzing, containing, and recovering from security incidents
The operational phase of incident management is where preparation meets
reality. ISO/IEC 27035-3:2020 provides detailed procedural guidance for
the detection, analysis, containment, eradication, and recovery phases of
incident response. This standard is the operational core of the 27035
series, translating strategic plans into tactical actions that security
teams execute during live incidents.
Time is the most critical resource during incident response. According to
industry data, the average dwell time (the period between compromise and
detection) is still measured in days or weeks. ISO/IEC 27035-3 provides
the structured approach needed to compress this timeline and minimize
damage.
industry data, the average dwell time (the period between compromise and
detection) is still measured in days or weeks. ISO/IEC 27035-3 provides
the structured approach needed to compress this timeline and minimize
damage.
Incident Detection and Initial Assessment
Effective detection requires a multi-layered strategy. The standard
covers detection from multiple sources: automated security controls (SIEM,
EDR, IDS/IPS), user reports (phishing, unusual behavior), external threat
intelligence feeds, and third-party notifications. Each detection source
must have defined procedures for initial triage — determining whether an
event is a false positive, a non-malicious anomaly, or a genuine security
incident requiring escalation.
Initial assessment is the bridge between detection and full response.
ISO/IEC 27035-3 defines a structured triage process that evaluates the
technical scope (affected systems, indicators of compromise), business
impact (data sensitivity, service criticality, regulatory exposure), and
urgency (active threat, propagation risk, time sensitivity). The assessment
feeds into a decision matrix that determines the incident severity level,
the response team composition, and the escalation path.
| Severity Level | Definition | Response Time Target | Team Composition |
|---|---|---|---|
| Low | Isolated, no data breach, low business impact | Within 1 business day | L1 analyst |
| Medium | Limited scope, potential minor data exposure | Within 4 hours | L2 analyst + team lead |
| High | Significant data breach, critical system impact | Within 1 hour | Full incident team + management |
| Critical | Ongoing active threat, regulatory breach likely | Immediate (15 min) | Full team + executive + legal + PR |
Well-defined triage criteria prevent two common problems: alert fatigue
(where teams become desensitized to alerts) and the “cry wolf” effect
(where false positives erode confidence in detection systems).
(where teams become desensitized to alerts) and the “cry wolf” effect
(where false positives erode confidence in detection systems).
Containment, Eradication, and Recovery Strategies
The standard presents a structured approach to containment that balances
speed with forensic preservation. Short-term containment (e.g., isolating
affected systems, blocking IP addresses, disabling compromised accounts)
aims to stop the immediate threat from spreading. Long-term containment
applies more durable measures such as network segmentation changes, access
control updates, and temporary system reconfigurations while eradication
activities are planned.
Eradication removes the root cause of the incident. This may involve
removing malware, patching vulnerabilities, revoking compromised credentials,
or rebuilding affected systems from known-good images. The standard
emphasizes that eradication must be thorough — partial eradication leads
to re-infection or persistence. Recovery involves restoring normal operations
in a phased manner, with careful monitoring to ensure that the threat is
fully neutralized before production traffic is restored. The standard
recommends a formal “return to operations” checklist and sign-off process.
A common operational mistake is rushing to recovery before completing
thorough forensic analysis and eradication. This can leave backdoors or
persistent threats in the environment, leading to repeated incidents.
ISO/IEC 27035-3 emphasizes methodical progression through each phase.
thorough forensic analysis and eradication. This can leave backdoors or
persistent threats in the environment, leading to repeated incidents.
ISO/IEC 27035-3 emphasizes methodical progression through each phase.
Post-Incident Review and Lessons Learned
The post-incident phase is where the organization captures the knowledge
gained from the incident and translates it into improved defensive posture.
ISO/IEC 27035-3 recommends a structured post-incident review (PIR) process
that addresses: what happened, what went well, what went wrong, what could
be improved, and what changes are needed to prevent recurrence. The review
should produce a formal report with actionable recommendations, assigned
owners, and target completion dates.
The standard also highlights the value of incident metrics aggregation.
By analyzing patterns across multiple incidents — common attack vectors,
affected asset classes, detection gaps, response bottlenecks —
organizations can identify systemic weaknesses and prioritize improvement
initiatives. Trend reporting to management reinforces the business case
for continued investment in incident management capabilities.
Frequently Asked Questions
Q: When should containment begin versus completing assessment first?
A: In active threat scenarios (e.g., ransomware encryption in progress),
immediate containment takes precedence. The standard supports parallel
activities — one team initiates containment while another continues
assessment. The decision depends on the nature and velocity of the threat.
A: In active threat scenarios (e.g., ransomware encryption in progress),
immediate containment takes precedence. The standard supports parallel
activities — one team initiates containment while another continues
assessment. The decision depends on the nature and velocity of the threat.
Q: How does forensic evidence collection fit into response?
A: Forensic considerations must be integrated into response procedures
from the beginning. The standard recommends that containment actions
preserve evidence where possible (e.g., memory capture before system
shutdown, network flow logs before blocking). Organizations should have
pre-defined chain-of-custody procedures and, where needed, work with legal
counsel to protect privilege.
A: Forensic considerations must be integrated into response procedures
from the beginning. The standard recommends that containment actions
preserve evidence where possible (e.g., memory capture before system
shutdown, network flow logs before blocking). Organizations should have
pre-defined chain-of-custody procedures and, where needed, work with legal
counsel to protect privilege.
Q: What is the recommended approach for ransomware incidents?
A: The standard advises against paying ransoms as a policy. Response should
focus on containment (isolating affected systems), preservation of evidence,
engagement with law enforcement, activation of backup-based recovery
procedures, and communication with stakeholders according to regulatory
obligations.
A: The standard advises against paying ransoms as a policy. Response should
focus on containment (isolating affected systems), preservation of evidence,
engagement with law enforcement, activation of backup-based recovery
procedures, and communication with stakeholders according to regulatory
obligations.
Q: How should cloud-native incidents be handled differently?
A: Cloud incidents require specific considerations: ephemeral resources
may complicate forensics, shared responsibility models affect response
boundaries, and API-based attacks require different detection and
containment approaches. The standard recommends cloud-specific playbooks
and pre-established coordination procedures with cloud service providers.
A: Cloud incidents require specific considerations: ephemeral resources
may complicate forensics, shared responsibility models affect response
boundaries, and API-based attacks require different detection and
containment approaches. The standard recommends cloud-specific playbooks
and pre-established coordination procedures with cloud service providers.
