NIST SP 800-61 Rev. 3 How should teams handle reporting clocks under NIST SP 800-61 Rev. 3 incident response

Start by identifying the instrument that creates the duty. Determine its covered organization, sector, geographic and customer locations, incident or breach category, jurisdiction, trigger, deadline, calculation rule, recipient, content, update requirements, exceptions, and submission route. Do not copy a headline deadline into the plan without its conditions and exclusions.

Assess each instrument separately. One incident may require internal status updates, a supplier or customer notice under contract, notification to affected people, a regulator filing, or contact with law enforcement, and each may use a different definition and starting fact. A NIST incident declaration can be relevant evidence without being the legal trigger.

Build the resulting clocks into the incident-response plan and notification procedure. Assign an assessment owner, an authorized reporter, an approval path, and backup coverage. Prepare recipient details, portal access, required templates, secure communication methods, and an out-of-hours path before an incident occurs.

Incident coordination covers operational communication among parties with response roles. Incident notification formally informs affected customers, employees, partners, regulators, or others. NIST separately identifies public communication and usually voluntary incident information sharing. Label these paths so a status update, press statement, or threat-information exchange is not mistaken for a required notice.

NIST recommends notifying affected third parties under regulatory, legal, and contractual requirements and contacting law enforcement or regulators using plan criteria, management approval, applicable law, and organizational procedures. Designated individuals should make those contacts. Rev. 3 does not decide that a report is required or authorize a particular disclosure.

When facts remain uncertain, record the uncertainty and apply the controlling instrument's rules for preliminary, phased, corrected, or final reports. Do not delay merely to complete the technical investigation unless the instrument permits it, and do not invent a preliminary-report duty that the instrument does not contain.

Keep a clock register that identifies the instrument and provision, covered actor and incident type, jurisdiction, trigger, calculation method, deadline, recipient, required content, submission route, approval authority, and update or final-report duties.

Link the register to the technical incident record without treating detection, triage, declaration, scope confirmation, or rule-specific awareness as interchangeable. The responsible legal, compliance, privacy, contractual, or regulatory owner should confirm any interpretation that depends on case-specific facts.

For every live clock, retain the trigger analysis, source facts, timestamps and time zone, calculation, owner, approvals, submitted content, transmission result, acknowledgment, corrections, and later reports. If the team concludes that no notice is required, retain the provision, facts, analysis, decision owner, and reassessment condition.

Exercise the clock register with technical responders, legal and privacy owners, communications staff, leadership, and relevant suppliers. Test recipient data, portal credentials, approval coverage, secure sharing, and the ability to assemble the required facts under uncertainty. Record and close any gap found.

Reassess a live decision when scope, affected people or systems, data impact, incident category, jurisdiction, customer location, provider facts, or a controlling rule changes. Periodic register review does not replace incident-specific reassessment.