Search every question across sub-FAQs

Assign an incident management team (IMT) to maintain the capability and an incident coordinator to lead each case. Define internal or external incident response teams (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 computer security incident response team 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.

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.

The incident coordinator 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.

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.

Escalate when the incident is not under control, can cause severe adverse impact, exceeds the current coordinator's authority, needs more or different responders, or approaches an organization-defined time or impact limit. Route the relevant decision when legal, contractual, safety, privacy, insurance, supplier, continuity, or communications criteria may apply. Examples include seeking approval to isolate a critical production service, activating crisis management after core services stop, asking privacy counsel to assess an affected-person notice, or calling a supplier whose evidence or recovery action is required.

The handoff should state current facts and uncertainty, severity and scope, affected information, systems and services, actions taken, outstanding decisions, evidence location, time constraints, required authority, and the next checkpoint. A named recipient must acknowledge the request and either accept ownership or redirect it to a named alternate; copying a mailbox or manager does not complete the handoff.

The record should prove that the trigger was recognized, the right authority received enough information, ownership was accepted, and the response changed. Keep the trigger, timestamp, initiator, recipient, acknowledgement, requested decision or resource, decision, revised priority, and next checkpoint.

Record failed and delayed routes too. They show where contact lists, on-call coverage, authority limits, supplier commitments, or crisis activation rules need correction.

Route operational escalation to the incident coordinator or another incident response team when the need remains within delegated response authority. Route decisions beyond that authority to the named management, crisis, business, finance, legal, privacy, safety, communications, or supplier authority.

The recipient must be able to decide the requested issue. Seniority alone is not enough if the person cannot authorize service interruption, external spending, public communication, risk acceptance, or another required action.

Reassess during the incident whenever impact, spread, recoverability, evidence risk, affected services, supplier involvement, or time pressure changes. Escalation is not a one-time severity label; the response can move up, across to a specialist team, or back to normal ownership when defined exit criteria are met.

Review the standing path after incidents, exercises, reorganizations, supplier changes, and changes to critical services or authority limits.

ISO/IEC 27035 is global, voluntary guidance for organizations of any type, size, or nature, including external incident-management service providers. Part 1:2023 defines the process and roles, Part 2:2023 covers planning and preparation, and Part 3:2020 covers ICT response operations. The series does not create a universal severity threshold, escalation deadline, regulator-notification clock, or legal power to interrupt a service.

The organization should set internal triggers, response targets, delegated authority, backups, and hand-back criteria from its risk and operating context. Binding laws, regulator rules, contracts, insurance terms, employment rules, and customer commitments can impose separate recipients, deadlines, or approvals. Apply those controlling requirements independently; an internal escalation level does not prove that an external reporting threshold is met.

Detection creates an information security event report, not an automatic incident declaration. The incident coordinator evaluates the report against criteria prepared in advance, including the event type, affected assets or services, actual or projected adverse consequences, and the organization's classification scale.

Classify the record as an information security incident when one or more related and identified events can harm the organization's assets or compromise its operations. Representative examples include ransomware that makes a service unavailable, accidental disclosure of protected information, unauthorized modification of data, theft of a device containing organizational information, or fire that damages an information system. These examples are informative, not automatic classifications; the specific facts and prepared criteria control. If the incident test is not met, retain the assessment and route a false alarm, vulnerability, routine service issue, or other event through the appropriate process.

Keep the original event report, source alert or observation, timestamps, affected assets or services, validation steps, correlated events, available impact evidence, criteria applied, assessor, decision time, status, rationale, and next action. Log later changes instead of rewriting the first assessment.

A false alarm means the reported event was found not to be real or to have any impact. A real event that does not meet incident criteria can still require vulnerability handling, service management, monitoring, or another follow-up process.

The incident coordinator evaluates the event report and declares the incident using criteria defined during planning. Security and non-security personnel should supply the asset, service, business, privacy, safety, supplier, and legal facts needed for the decision.

The policy should permit a possible or provisional incident status when facts are incomplete. If the criteria are met, establish the required incident response teams and start the response process without waiting for certainty about every detail.

Reopen the decision when new related events, affected assets, business impact, threat intelligence, supplier facts, or evidence changes the original test. An event closed as benign or routine can later become part of an incident after correlation.

During response, continue reassessing the incident's type, scope, priority, and severity. Keep each status change, timestamp, reason, and decision maker in the incident register.

ISO/IEC 27035-1:2023 provides the definitions and the generic process for organizations of any type, size, or nature, including external incident-management providers. ISO/IEC 27035-2:2023 covers the policy, plan, classification scale, forms, roles, exercises, and lessons learned. ISO/IEC 27035-3:2020 gives ICT operational guidance for detection, notification, triage, analysis, response, and reporting.

The series is voluntary guidance, not a law or a standalone certification. It does not set a universal number of affected users, duration, financial loss, severity label, or notification deadline that turns every event into an incident. An adopted policy or contract can make the organization's procedure mandatory internally, while applicable law or regulation can define a different reportable-incident test. Apply and record each test separately.

Analyse patterns across events and incidents as well as the individual case. Identify improvements to the incident plan, incident management team and incident response team performance, security controls, risk assessment, management review inputs, awareness, training, external relationships, tools, and metrics.

Prioritize improvements by risk, recurrence, and feasibility. A recommendation remains open until an accountable owner implements it and verifies effectiveness, or an authorized decision maker records why it was rejected, deferred, or accepted as residual risk, meaning the risk that remains after current controls and the approved decision.