GuideGlobalISO/IEC 27035

ISO/IEC 27035 Notification Threshold Mapping

Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.

ISO/IEC 27035 provides voluntary incident-management guidance; it does not set legal or contractual notification duties. Apply each controlling law, authority instruction, contract, insurance term, and ISO/IEC 27001 requirement separately.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

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

Use to route and record notifications about an . Take every external trigger, clock, recipient, and required report from its controlling source because the series does not decide whether a regulator, affected person, customer, supplier, insurer, or law-enforcement body must be notified. Assign each decision to an authorized owner and reassess it as the facts change.

Section 1

How should notification thresholds be mapped?

has three parts with different jobs. Part 1:2023 covers the principles and five-phase process for information security incidents, including incidents that do not involve information and communication technology. Part 2:2023 covers planning and preparation. Part 3:2020 covers ICT incident response operations only, including notification and internal and external reporting. Use the Part 3 reporting model for ICT incidents without extending its operational scope to non-ICT cases.

Create one row for each distinct reporting route. Record the controlling law, regulation, authority instruction, contract, insurance term, policy, or voluntary arrangement; the covered entity, jurisdiction, service, data, and incident type; the trigger test; the event that starts the clock; the decision owner; deadline; recipient; channel; required content; approval; update or final-report duties; confidentiality limits; and proof of submission.

Keep three decisions separate. Event notification sends a suspected event to the . Internal incident reporting informs the response team, management, and other assigned functions. External reporting sends information outside the organization when a controlling source or an authorized voluntary decision requires it. One incident can follow several routes with different definitions and clocks.

  • Link each row to the current controlling source and name the owner responsible for checking changes.
  • Define the clock start precisely; detection, awareness, confirmation, classification, service disruption, and receipt of sufficient facts are not interchangeable.
  • Record both report and no-report decisions with the facts considered, interpretation, approver, time, and reassessment trigger.
  • Prepare contacts, credentials, secure channels, forms, approval routes, and out-of-hours cover during planning.
  • Label facts as confirmed, provisional, estimated, or unknown so an early report does not present assumptions as findings.
Section 2

What should the live decision record contain?

Start the notification review when the facts could meet a mapped trigger, not only after the incident receives its final severity. Link the decision to the incident identifier and preserve the source version, covered entity and service, known facts, missing facts, trigger analysis, clock start, deadline, owner, approver, decision time, and next reassessment.

For a submitted report, retain the approved content, recipient, channel, transmission time, acknowledgement or case number, later updates, and final report where required. Protect sensitive content under the applicable handling rules. For a no-report decision, retain the reason and the fact or time that will reopen the analysis.

  • Scope: legal entity, jurisdiction, service, data, customers, suppliers, and other affected parties.
  • Source: exact instrument, clause or authority instruction, version or retrieval date, trigger, clock rule, and reporting route.
  • Facts: discovery and awareness times, incident chronology, impact, duration, affected parties, containment, recovery, uncertainty, and information still being gathered.
  • Decision: report, do not report, or defer pending named facts; owner, approver, legal or specialist input, rationale, timestamp, and reassessment.
  • Submission: approved report, secure channel, recipient, sent time, acknowledgement, reference number, updates, corrections, and final-report status.
Section 3

How should the notification workflow run?

At intake, record when the organization received the event and notify the incident coordinator. During assessment, identify the affected entities, services, systems, data, jurisdictions, contracts, and parties, then open every potentially relevant threshold row. The assigned owner decides each route against its own source and clock while the response team continues to contain and recover.

If the source permits or requires staged reporting, send the required initial information by the applicable deadline and update it through the defined route. Do not delay an initial report solely because cause, scope, or affected numbers remain uncertain unless the controlling source allows that delay. Correct material errors through the same approved process and keep the earlier submission.

  • Open: capture event time, receipt time, identifier, affected scope, known facts, and immediate internal notifications.
  • Screen: select every potentially applicable row based on entity, jurisdiction, service, data, contract, and incident type.
  • Decide: apply each source's trigger and clock, record uncertainty, assign missing facts, and obtain the required approval.
  • Submit: use the approved recipient, channel, content, and confidentiality controls; retain proof of transmission.
  • Update and close: meet follow-up duties, correct errors, document no-report decisions, and close each route only when its own requirements are complete.
Section 4

Which distinctions prevent reporting errors?

Severity, external reportability, and urgency are related but separate. A low operational severity can still meet a legal or contractual trigger, while a critical incident may fall outside a particular reporting regime. Evaluate every mapped row independently and record how the incident facts meet or fail its test.

The reporter may also differ by route. The ICT response team can supply technical facts, but legal, privacy, regulatory, customer, supplier, insurer, law-enforcement, or public communications may belong to another authorized role. The map should name both the fact provider and the person allowed to decide or send.

  • Do not copy a deadline without its trigger, scope, calculation rule, time zone, recipient, and follow-up requirements.
  • Do not assume the incident-classification time starts every external clock.
  • Do not use one customer notice as proof that regulators, affected persons, suppliers, insurers, or other customers were addressed.
  • Do not send sensitive technical or personal data through a channel that the source or organizational handling rules do not permit.
  • Do not treat silence from a recipient as proof that the report was complete or accepted; retain the acknowledgement and manage requests for more information.
Section 5

How should the map be tested and maintained?

Assign an owner and review date to every row. Review sooner when a law, authority instruction, contract, insurance term, service, legal entity, jurisdiction, supplier, customer, reporting portal, contact, or internal authority changes. Archive superseded rows so past decisions can be evaluated against the source in force at the time.

Exercise cases with overlapping routes, uncertain clock starts, incomplete facts, out-of-hours approval, unavailable portals, confidential evidence, and later corrections. Measure whether the team identified every relevant route, reached the correct owner, sent the required content through the proper channel, and retained proof.

  • Verify contacts, credentials, forms, secure channels, and backup submission methods.
  • Test handoffs between responders and legal, privacy, continuity, supplier, customer, insurer, and communications owners.
  • Compare incident decisions with the current map and correct stale sources, unclear triggers, missing routes, or unsupported clock assumptions.
  • Retest material changes and record the result, owner, unresolved gap, and due date.
Primary sources

References and citations

iso.org
Referenced sections
  • Part 1 connects incident documentation and lessons learned to planning, risk assessment, contacts, communications, and process improvement.
iso.org
Referenced sections
  • Part 2 covers external relationships, legal and regulatory planning, training, exercises, capability monitoring, and lessons-learned improvements.
iso.org
Referenced sections
  • Part 3 distinguishes event notification, internal reporting, and external reporting, and notes that external authorities and stakeholders can require different criteria, time frames, roles, and taxonomies.
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 CSIRT Roles FAQ
Assign ISO/IEC 27035 incident coordinator, IMT, IRT or CSIRT, point-of-contact, evidence, communications, and business decision roles.
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 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.