GuideGlobalISO/IEC 27035

ISO/IEC 27035 Notification Threshold Mapping

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

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
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.org5 citations
Referenced sections
  • ISO's current listing identifies Part 1:2023, Edition 2, as the published foundation for reporting, assessment, response, communications, documentation, and lessons learned.
  • Part 1 covers the generic incident-management principles and process, including non-ICT incidents, event reporting, assessment and decision, communications, documentation, and organization-defined or legally required notification intervals.
  • Part 1 grounds complete-at-the-time incident records, decision rationales, communications, secure evidence handling, and an up-to-date incident register.
Show 2 more
  • Part 1 separates event reporting, incident assessment, response, communications, documentation, and external relationships within the management process.
  • Part 1 connects incident documentation and lessons learned to planning, risk assessment, contacts, communications, and process improvement.
iso.org5 citations
Referenced sections
  • ISO's current listing identifies Part 2:2023, Edition 2, as the published guidance for planning external requirements, relationships, roles, training, testing, and improvement.
  • Part 2 covers planning and preparation, including decision criteria, roles, contacts, legal and regulatory considerations, reporting procedures, exercises, and improvement.
  • Part 2 grounds advance planning for legal and regulatory requirements, external relationships, contacts, forms, roles, communications, testing, and lessons learned.
Show 2 more
  • Part 2 grounds preparation of external requirements, contacts, reporting procedures, support relationships, training, and exercises before an incident.
  • Part 2 covers external relationships, legal and regulatory planning, training, exercises, capability monitoring, and lessons-learned improvements.
iso.org4 citations
Referenced sections
  • ISO's current listing identifies Part 3:2020, Edition 1, as published at the close-of-review stage; it covers ICT notification and internal and external reporting operations.
  • Part 3 is limited to ICT incident response operations. It distinguishes event notification, internal incident reporting, and external reporting and calls for planned reporting roles, channels, formats, and criteria.
  • Part 3 grounds the sequence from event notification through internal reporting and external reporting, including pre-established roles, formats, channels, criteria, and records.
Show 1 more
  • 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.
Show all related guides (20)

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 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 NIST SP 800-61 Rev. 3, including lifecycle differences, shared incident records, and migration from Rev. 2.

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.

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 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.