FAQGlobalISO/IEC 27035

ISO/IEC 27035 FAQ CSIRT Roles

Assign ISO/IEC 27035 incident coordinator, IMT, IRT or CSIRT, point-of-contact, evidence, communications, and business decision roles.

ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Apply separate legal, contractual, regulatory, privacy, and evidence requirements where relevant.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

ISO/IEC 27035 distinguishes the (IMT), which leads incident management across the lifecycle, from (IRTs), which perform response work. Part 1 treats computer security incident response teams (CSIRTs) and CERTs as examples of IRTs, while Part 3 recommends establishing a CSIRT for ICT incident response operations.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

Which incident-management roles should be assigned?

Assign an (IMT) to maintain the capability and an to lead each case. Define internal or external (IRTs), points of contact, monitoring, business and asset owners, legal and privacy advisers, communications, continuity, HR, evidence specialists, and crisis management as the organization needs them.

ISO/IEC 27035-1 treats a as one possible IRT, while ISO/IEC 27035-3 recommends establishing a CSIRT for ICT incident response operations. Smaller organizations and outsourced environments can combine roles, but authority, availability, conflicts, supplier handoffs, and accountability should remain explicit. The plan should show who acts, who approves, who is informed, and who can accept residual risk.

  • Publish primary and backup contacts with secure out-of-band routes and availability expectations.
  • Pre-authorize urgent containment boundaries and define when executive, crisis, safety, legal, privacy, customer, supplier, or authority escalation is required.
  • Exercise internal and external relationships, including managed service providers and specialist responders, before relying on them.
Citations
NIST SP 800-61r3

Lists common incident response roles and responsibilities, including leadership, incident handlers, legal, public affairs and media relations, asset owners, and third parties.

Question 2

What should the role record contain?

Keep approved terms of reference, a responsibility matrix, contact and backup roster, on-call coverage, authority limits, skills and training records, supplier responsibilities, communication routes, and exercise results. Incident records should show that named roles accepted handoffs and used their authority in practice.

For outsourced response, map the provider's service description and escalation commitments to the organization's own decision rights. The provider can perform response work, but the organization still needs owners for business impact, legal duties, public communications, risk acceptance, and incident closure.

  • List the systems, services, regions, hours, and incident types each team covers.
  • Record which actions responders may take immediately and which need business, legal, finance, or executive approval.
  • Test primary and backup contacts, secure out-of-band communication, provider handoffs, and loss of normal collaboration tools.
Citations
Question 3

How should authority be divided during an incident?

The directs response activity and coordinates the IRTs, while the IMT maintains oversight, reporting, and the incident-management capability. Technical responders should have pre-approved authority for urgent actions within defined boundaries.

Actions with material financial, operational, safety, legal, privacy, or reputational effects should move to the specified business or management authority. The plan should state who can isolate systems, interrupt services, engage external support, communicate externally, accept residual risk, and close the incident.

  • Keep one accountable even when several specialist teams respond.
  • Require explicit acceptance when ownership transfers across shifts, providers, regions, or crisis teams.
  • Record decisions and approvals in the incident record, including emergency actions taken under delegated authority.
Citations
Question 4

When should incident roles be reviewed?

Review roles after incidents and exercises and whenever systems, services, suppliers, organization structure, working hours, contact routes, legal duties, or crisis arrangements change. Check both the written assignment and whether the people remain available, trained, and authorized.

Use exercise and incident evidence to find unclear authority, slow approvals, missing skills, overloaded individuals, and failed supplier handoffs. Assign corrective actions and retest the affected path.

  • Remove departed staff and expired supplier contacts promptly.
  • Review backups and succession for every role that can block containment, notification, recovery, or closure.
  • Update the plan, contracts, training, and contact register together so they do not conflict.
Citations
Primary sources

References and citations

iso.org
Referenced sections
  • Primary ISO listing for incident management principles and process.
"preparing for, detecting, reporting, assessing, and responding to incidents"
iso.org
Referenced sections
  • Primary ISO listing for planning, preparing, and lessons-learned guidance.
"plan and prepare for incident response and to learn lessons"
iso.org
Referenced sections
  • Primary ISO listing for ICT incident response operations guidance.
"information security incident response in ICT security operations"
csrc.nist.gov
Referenced sections
  • Lists common incident response roles and responsibilities, including leadership, incident handlers, legal, public affairs and media relations, asset owners, and third parties.
"Roles and responsibilities will differ for each organization and may also differ within an organization based on the nature of a particular incident."
Related guides

Explore more topics

ISO/IEC 27035 Compliance Guide
Understand what the ISO/IEC 27035 series covers, how its three published parts fit together, and how to adopt the guidance without mistaking it for a law or certification scheme.
ISO/IEC 27035 Escalation FAQ
Define ISO/IEC 27035 escalation and elevation triggers, authorities, handoff evidence, and reassessment rules before incidents occur.
ISO/IEC 27035 Event vs Incident FAQ
Distinguish an information security event from an incident under ISO/IEC 27035 and record the assessment without discarding useful event evidence.
ISO/IEC 27035 Evidence Log Template
Use an ISO/IEC 27035-aligned incident log to preserve facts, decisions, actions, communications, evidence references, and chain-of-custody information.
ISO/IEC 27035 Incident Lifecycle Guide
Follow the ISO/IEC 27035 five-phase incident-management process and understand how the detailed ICT response loop fits inside it.
ISO/IEC 27035 Incident Lifecycle Workflow
Turn the ISO/IEC 27035 lifecycle into an operational workflow with explicit decisions, handoffs, owners, evidence, and reopening triggers.
ISO/IEC 27035 Incident Management FAQ
Plain-language ISO/IEC 27035 answers on events, incidents, roles, severity, escalation, evidence, notification, retention, review, and lessons learned.
ISO/IEC 27035 Incident Response Playbook
Build ISO/IEC 27035-aligned playbooks that guide detection, triage, analysis, containment, eradication, recovery, reporting, and evidence preservation.
ISO/IEC 27035 Incident Severity and Escalation Matrix
Design an ISO/IEC 27035-aligned severity and escalation matrix using impact, priority, damage, urgency, recoverability, and reporting triggers.
ISO/IEC 27035 Incident Timer Workflow
Create an incident clock that tracks operational checkpoints and separate legal or contractual deadlines without inventing ISO/IEC 27035 time limits.
ISO/IEC 27035 Lessons Learned FAQ
Apply ISO/IEC 27035 lessons learned to plans, controls, risk decisions, training, relationships, metrics, and future response capability.
ISO/IEC 27035 Notification Evidence FAQ
Preserve evidence for internal and external incident notifications without attributing legal deadlines or reporting duties to ISO/IEC 27035.
ISO/IEC 27035 Notification Threshold Mapping Guide
Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.
ISO/IEC 27035 Post Incident Review FAQ
Run an ISO/IEC 27035 post-incident review after stabilization and recovery, then assign measurable improvements without losing accountability.
ISO/IEC 27035 Retained Logs FAQ
Retain ISO/IEC 27035 incident logs and digital evidence according to purpose, investigation needs, law, contracts, privacy, and organizational policy.
ISO/IEC 27035 Severity Classification FAQ
Classify incident severity under ISO/IEC 27035 using organization-specific criteria and reassess it as facts, impact, and recoverability change.
ISO/IEC 27035 vs ISO 22301 Comparison
Compare ISO/IEC 27035 incident-management guidance with ISO 22301 business continuity management-system requirements and certification scope.
ISO/IEC 27035 vs NIS2 Comparison
Compare voluntary ISO/IEC 27035 incident-management guidance with binding NIS2 duties for in-scope EU entities and national implementation.
ISO/IEC 27035 vs NIST SP 800-61 Comparison
Compare ISO/IEC 27035 with the current NIST SP 800-61 Rev. 3 while preserving this legacy route for visitors using the older publication name.
ISO/IEC 27035 vs NIST SP 800-61 Rev. 3 Comparison
Compare the ISO/IEC 27035 series with NIST SP 800-61 Rev. 3 incident-response guidance and show how organizations can use both.