DailyWF / Policies
Incident Notification
Define who must be notified when incidents affect service, data, obligations, or reputation.
Policy intent
Incident notification policy should define when silence is no longer acceptable. It should identify who needs to know, how fast, and what level of certainty is required.
Minimum content
- Define who and what the policy covers, including systems, data, tools, users, vendors, and exceptions.
- Impact categories and notification thresholds.
- Internal and external notification paths.
- Message owner and approval constraints.
- Update cadence until closure or downgrade.
Expected output
A policy page that states expectations clearly enough to guide approval, exception, and review decisions.
Common failure mode
Waiting for certainty before communicating impact and next update time.
Use notes
| Authority | Identify who can approve, deny, and grant exceptions. |
|---|---|
| Exception handling | Give exceptions an owner, reason, expiration, and review date. |
| Review point | Review when law, tools, contracts, ownership, or operational risk changes. |
Related pages
- Change vs IncidentDistinguish planned change from unplanned service disruption.
- Access ReviewDefine how access is reviewed, changed, approved, and removed.
- Change ManagementDefine when changes require review, approval, notice, or rollback planning.
- Change Request ReviewReview a proposed change before it affects production work.
- Change Review ChecklistReview planned changes before execution.
Use this with a tool
Find related documents, copy a checklist, or request a missing workflow.