docs(incident-management): normalize structure and wording

docs/pages/incident-management/communication-strategies.mdx

@@ -1,9 +1,16 @@
 ---
 title: "Incident Communication Strategies | SEAL"
-description: "Establish secure communication channels for incident response. Appoint spokespersons, develop pre-approved notification templates, and provide regular stakeholder updates during security incidents."
+description: "Establish secure incident channels, appoint primary and backup spokespersons, and use pre-approved templates to update stakeholders on a fixed cadence."
 tags:
   - Security Specialist
   - Operations & Strategy
+contributors:
+  - role: wrote
+    users: []
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
 ---
 
 import { TagList, AttributionList, ContributeFooter } from '../../../components'
@@ -13,14 +20,18 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components'
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
+> 🔑 **Key Takeaway**: Designate a single spokesperson and fixed update cadence before
+> chaos starts. Ship only confirmed facts; "no new information" is a valid status update
+> that reduces speculation damage.
+
 Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless,
 from a team member’s, outsider’s, or observer’s point of view, communication is very important to be able to understand
 what's happening, and it also provides some time to reflect and think about what is going on. With that said, providing
 information before confirming that it's accurate, can often be very negative and cause uncertainty. It is recommended to
 have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and
 it can often be that the update is that there is currently no new information available.
 
-## Best Practices
+## Best practices
 
 1. Define and establish secure communication channels for incident response teams.
 Use [encrypted messaging apps](/encryption/communication-encryption)
@@ -37,6 +48,13 @@ Avoid speculation and provide factual information.
 For message templates and example public updates, see
 [Incident Response Template: Communications](/incident-management/incident-response-template/communications).
 
+## Further reading
+
+- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together
+- [Communications template](/incident-management/incident-response-template/communications): ready-to-adapt holding statements and updates
+- [Community Management](/community-management/overview): the channels these messages go out on
+- [Incident Detection and Response](/incident-management/incident-detection-and-response): what triggers a communication
+
 ---
 
 <ContributeFooter />

docs/pages/incident-management/forensic-readiness.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Forensic Readiness | Security Alliance"
-description: "Forensic readiness: prepare your organization to preserve, collect, and present trustworthy evidence before an incident occurs. Design evidence collection into architecture, maintain chain of custody, and meet regulatory disclosure requirements."
+description: "Forensic readiness: prepare your organization to preserve, collect, and present trustworthy evidence before an incident occurs. Design evidence collection into..."
 tags:
   - Security Specialist
   - Operations & Strategy

docs/pages/incident-management/incident-detection-and-response.mdx

@@ -1,9 +1,16 @@
 ---
 title: "Incident Detection And Response | SEAL"
-description: "Detect security incidents early with continuous on-chain monitoring and logging. Build an Incident Response Team (IRT) with clear roles for containment, recovery, and post-incident review."
+description: "Detect security incidents early with continuous on-chain monitoring and logging. Build an Incident Response Team (IRT) with clear roles for containment"
 tags:
   - Security Specialist
   - Operations & Strategy
+contributors:
+  - role: wrote
+    users: []
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
 ---
 
 import { TagList, AttributionList, ContributeFooter } from '../../../components'
@@ -13,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components'
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
+> 🔑 **Key Takeaway**: Detect on-chain and off-chain anomalies early, then execute a
+> prepared response cycle: IRT roles, containment, recovery, and post-incident review.
+> Delay multiplies irreversible Web3 losses.
+
 You don't want to be the project that has funds stolen and then doesn't notice it for multiple days. Early detection
 and effective response to security incidents will help minimize damage.
 
@@ -41,6 +52,13 @@ For a complete incident response policy template covering roles, severity, docum
 and
 [Incident Response Template: Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing).
 
+## Further reading
+
+- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together
+- [Monitoring overview](/monitoring/overview): the signals detection depends on
+- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation
+- [Lessons Learned](/incident-management/lessons-learned): turning each incident into a change
+
 ---
 
 <ContributeFooter />

docs/pages/incident-management/incident-response-template/communications.mdx

@@ -1,13 +1,16 @@
 ---
 title: "Communication Templates | Security Alliance"
-description: "Templates and building blocks for incident communications. Adapt these to your situation and tone."
+description: "Templates and building blocks for incident communications. Adapt these to your situation and tone. Adapt pre-built internal and public message blocks"
 tags:
   - Security Specialist
   - Operations & Strategy
 contributors:
   - role: wrote
     users: [hexnickk4997, n0guest]
-
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
 ---
 
 import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
@@ -17,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
+> 🔑 **Key Takeaway**: Adapt pre-built internal and public message blocks so spokespeople
+> ship factual updates under pressure. Avoid root-cause speculation, blame, and
+> excessive apologies until facts are confirmed.
+
 Templates and building blocks for incident communications. Adapt these to your situation and tone.
 
 ## Before You Post
@@ -201,6 +208,15 @@ Use these as modular pieces. Combine as needed for your situation.
 - Acknowledge impact on users
 - Avoid excessive apologies (one is enough)
 
-*See [Incident Response Policy](./incident-response-policy) for the overall response process.*
+*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) for the overall response process.*
+
+## Further reading
+
+- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together
+- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation
+- [Communication Strategies](/incident-management/communication-strategies): the principles behind these templates
+- [Community Management](/community-management/overview): the channels these messages go out on
+
+---
 
 <ContributeFooter />

docs/pages/incident-management/incident-response-template/contacts.mdx

@@ -1,13 +1,16 @@
 ---
 title: "Critical Contacts | Security Alliance"
-description: "Keep this updated. Stale contacts during an incident waste critical time."
+description: "Keep this updated. Stale contacts during an incident waste critical time. Keep emergency internal, partner, vendor, legal, and PR contacts verified"
 tags:
   - Security Specialist
   - Operations & Strategy
 contributors:
   - role: wrote
     users: [hexnickk4997, n0guest]
-
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
 ---
 
 import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
@@ -17,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
+> 🔑 **Key Takeaway**: Keep emergency internal, partner, vendor, legal, and PR contacts
+> verified and owned. Stale phone trees waste the minutes that matter most during
+> containment.
+
 Keep this updated. Stale contacts during an incident waste critical time.
 
 **Last verified:** [DATE]
@@ -119,7 +126,7 @@ Protocols, exchanges, or other partners to notify during major incidents.
 | Public updates | | |
 | Team alerts | | |
 
-## Quick Reference - P1 Escalation
+### Quick Reference - P1 Escalation
 
 For P1 (critical) incidents, contact in this order:
 
@@ -130,7 +137,7 @@ For P1 (critical) incidents, contact in this order:
 4. [ ] Legal (if fund loss or regulatory implications)
 </Checklist>
 
-## Maintenance
+### Maintenance
 
 <Checklist id="maintenance">
 - [ ] Review and update quarterly
@@ -140,7 +147,16 @@ For P1 (critical) incidents, contact in this order:
 
 **Owner:** [Assign someone to maintain this document]
 
-*See [Incident Response Policy](./incident-response-policy) and [Roles and Staffing](./roles-and-staffing) for how
+*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) and [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing) for how
 these contacts fit into the response process.*
 
+## Further reading
+
+- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together
+- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation
+- [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): the roles these contacts fill
+- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast
+
+---
+
 <ContributeFooter />

docs/pages/incident-management/incident-response-template/incident-response-policy.mdx

@@ -1,14 +1,17 @@
 ---
 title: "Incident Response Policy | Security Alliance"
-description: "This policy defines how we respond to security and operational incidents. It covers roles, severity classification, and the steps from detection through post-incident review."
+description: "This policy defines how we respond to security and operational incidents. It covers roles, severity classification. Define severity, decision makers"
 tags:
   - Security Specialist
   - Operations & Strategy
   - DevOps
 contributors:
   - role: wrote
     users: [hexnickk4997, n0guest]
-
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
 ---
 
 import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
@@ -18,12 +21,16 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-## Overview
+> 🔑 **Key Takeaway**: Define severity, decision makers, and the detect-to-review flow in
+> writing before an incident. Policy that exists only in heads fails when minutes matter
+> and funds can leave forever.
 
-This policy defines how we respond to security and operational incidents. It covers roles, severity classification,
-and the steps from detection through post-incident review.
+This policy defines how we respond to security and operational incidents. It covers roles,
+severity classification, and the steps from detection through post-incident review. For role
+structures and on-call options, see
+[Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing).
 
-For role structures and on-call options, see [Roles and Staffing](./roles-and-staffing).
+## Overview
 
 ## Roles
 
@@ -40,7 +47,9 @@ Makers when needed.
 
 ### Scribe
 
-Documents everything in the [Incident Log](./templates/incident-log-template). Maintains timestamps (UTC), captures
+Documents everything in the [Incident
+  Log](/incident-management/incident-response-template/templates/incident-log-template). Maintains
+  timestamps (UTC), captures
 decisions and rationale. This is a focused role. Don't also assign the Scribe to fix things.
 
 ### Communication Manager
@@ -134,7 +143,7 @@ The Detector's job: get the right people involved, fast.
 **Incident Leader responsibilities:**
 
 1. Pull in relevant SMEs
-2. Assign a Scribe → they create an [Incident Log](./templates/incident-log-template)
+2. Assign a Scribe → they create an [Incident Log](/incident-management/incident-response-template/templates/incident-log-template)
 3. Assign Communication Manager(s)
 
 ### Step 3: Investigation
@@ -163,7 +172,8 @@ If a temporary fix (rollback, pause, disable feature) is faster than a full fix
 - [ ] Plan permanent fix with owner and timeline
 </Checklist>
 
-See [Runbooks](./runbooks/overview) for step-by-step guides for specific incident types.
+See [Runbooks](/incident-management/incident-response-template/runbooks/overview) for step-by-step
+  guides for specific incident types.
 
 ### Step 5: Monitoring
 
@@ -179,7 +189,7 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden
 **Goal:** Learn and prevent recurrence.
 
 1. Incident Leader schedules post-mortem (within a week of resolution)
-2. Scribe prepares [Post-Mortem](./templates/post-mortem-template) draft
+2. Scribe prepares [Post-Mortem](/incident-management/incident-response-template/templates/post-mortem-template) draft
 3. Team reviews timeline, identifies root causes, captures lessons
 4. Define action items with owners and deadlines
 5. Share with team (and community if appropriate)
@@ -189,19 +199,11 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden
 ## Communication Guidelines
 
 - **Internal:** Regular updates in the incident channel. Frequency depends on severity.
-- **External:** Communication Manager drafts, gets approval before posting. See [Communications](./communications) for
+- **External:** Communication Manager drafts, gets approval before posting. See
+  [Communications](/incident-management/incident-response-template/communications) for
   examples.
 - **Transparency:** Default to sharing post-mortems publicly (redacting sensitive details).
 
-## Related Documents
-
-- [Roles and Staffing](./roles-and-staffing) - Team structure options
-- [Communications](./communications) - Public announcement guidance
-- [Incident Log Template](./templates/incident-log-template) - Fill out during incidents
-- [Post-Mortem Template](./templates/post-mortem-template) - Complete after incidents
-- [Contacts](./contacts) - Critical contacts
-- [Runbooks](./runbooks/overview) - Step-by-step incident guides
-
 ## Document Control
 
 | Version | Date | Author | Changes |
@@ -210,4 +212,13 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden
 
 *Customize this policy for your protocol's tools, team structure, and communication channels.*
 
+## Further reading
+
+- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together
+- [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): team structure options
+- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together
+- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together
+
+---
+
 <ContributeFooter />