diff --git a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx
index efa009a6..c836ede1 100644
--- a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx
+++ b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx
@@ -158,7 +158,7 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden
 **Goal:** Confirm the fix actually worked.
 
 - Verify immediately after deployment
-- Monitor for at least a week
+- Monitor based on residual risk, blast radius, and incident type
 - Consider adding new alerts or test cases
 - Document what monitoring is now in place
 
diff --git a/docs/pages/incident-management/incident-response-template/overview.mdx b/docs/pages/incident-management/incident-response-template/overview.mdx
index 99a817d3..3ea216fc 100644
--- a/docs/pages/incident-management/incident-response-template/overview.mdx
+++ b/docs/pages/incident-management/incident-response-template/overview.mdx
@@ -78,6 +78,17 @@ That's it to start. Add complexity only as you need it.
 
 Review and adapt these pages for your own internal incident response documentation.
 
+This section is different from the broader [Incident Management](/incident-management/overview) guidance:
+
+- **Incident Management pages** explain concepts and practices
+- **Incident Response Template pages** are meant to be copied, customized, and used internally
+
+Within this template section:
+
+- **Policy / roles / communications / contacts** define your operating model
+- **Templates** are blank working documents to fill out during or after incidents
+- **Runbooks** are scenario-specific response procedures
+
 ### What's Included
 
 | Document                                                | Purpose                                                         |
diff --git a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx
index 3db389b6..0efdf0d0 100644
--- a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx
+++ b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx
@@ -168,7 +168,7 @@ Regardless of team size, define who can make high-stakes decisions during P1 inc
 | | | |
 | | | |
 
-These people should be reachable 24/7 for critical incidents. Consider:
+There should be a 24/7 escalation path to these people for critical incidents. Consider:
 - Founders / C-level
 - Security Lead
 - Engineering Lead
diff --git a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx
index a3b5b29d..dcb659fc 100644
--- a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx
+++ b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Runbook: Build Pipeline Compromise | Security Alliance"
-description: "Stub runbook. Customize with your CI/CD platform and procedures."
+description: "Example runbook for CI/CD compromise. Review and customize for your platform, release process, and trust boundaries before use."
 tags:
   - Security Specialist
   - Operations & Strategy
@@ -21,7 +21,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-> **Stub runbook.** Customize with your CI/CD platform and procedures.
+> **This is an example runbook.** Review and customize for your CI/CD platform, artifact flow, deployment model, and approval process before use.
 
 ## Quick Reference
 
@@ -37,36 +37,150 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 
 ### Symptoms
 
-- [ ] Unexpected code in deployed artifacts
-- [ ] CI/CD configuration changed without approval
-- [ ] Secrets accessed or exfiltrated
-- [ ] Unauthorized workflow runs
+- [ ] Unexpected workflow runs or releases
+- [ ] CI/CD configuration changed without expected approval
+- [ ] Secrets accessed, exported, or rotated unexpectedly
+- [ ] Build artifacts differ from expected source or prior reproducible output
+- [ ] Deployments reference an unexpected commit, artifact, or builder identity
+
+### Likely Scope Questions
+
+- Is this limited to CI configuration, or were artifacts actually produced from a compromised pipeline?
+- Did the pipeline have deploy permissions, signing authority, or production credentials?
+- Were any releases, containers, frontend bundles, or packages published during the exposure window?
+
+### Differentiation
+
+- Unauthorized code merged without pipeline abuse may be a repository compromise first
+- Malicious package updates without CI tampering may be a dependency incident first
+- A bad deployment from a legitimate commit may be an operational failure rather than compromise
 
-### Confirm Compromise
 
-- Review CI/CD audit logs
-- Compare build artifacts to source
-- Check for config changes in CI/CD platform
 ## Immediate Actions
 
-1. [ ] Disable compromised pipelines
-2. [ ] Rotate all secrets and tokens
-3. [ ] Take down potentially compromised deployments
-4. [ ] Audit recent builds and deployments
-## Mitigation
-
-1. [ ] Audit CI/CD configuration for unauthorized changes
-2. [ ] Rebuild from trusted commit using clean pipeline
-3. [ ] Implement additional approval requirements
-4. [ ] Review and restrict pipeline permissions
-## Prevention
-
-- [ ] Require approval for CI/CD config changes
-- [ ] Use short-lived credentials
-- [ ] Implement branch protection
-- [ ] Audit pipeline access regularly
-- [ ] Use signed commits
-- [ ] Separate build and deploy permissions
+### Step 1: Freeze the pipeline
+
+**Why:** Stop additional malicious builds, releases, or secret access.
+
+- [ ] Disable affected workflows/pipelines
+- [ ] Revoke or pause auto-deploy jobs
+- [ ] Block manual approvals until scope is understood
+
+### Step 2: Preserve evidence
+
+**Why:** CI audit logs, workflow definitions, artifact metadata, and deployment history are easy to overwrite.
+
+- [ ] Export CI audit logs
+- [ ] Save workflow/job history for the exposure window
+- [ ] Record affected commits, workflow files, artifact digests, release IDs, and deployment targets
+- [ ] Preserve runner details if self-hosted runners were involved
+
+### Step 3: Rotate credentials by blast radius
+
+**Why:** Pipeline compromise often becomes credential compromise.
+
+Prioritize rotation of:
+- [ ] CI platform tokens
+- [ ] cloud deploy credentials
+- [ ] package registry tokens
+- [ ] artifact signing keys or release credentials
+- [ ] secrets available to self-hosted runners
+
+### Step 4: Stop trust in recent outputs
+
+**Why:** Do not assume recent artifacts or deployments are clean.
+
+- [ ] Identify all artifacts built during the exposure window
+- [ ] Identify all deployments and releases from those artifacts
+- [ ] Quarantine or withdraw suspicious outputs where possible
+
+
+## Investigation
+
+### Key Questions
+
+- [ ] What was the initial access path: CI platform, repository permissions, runner compromise, or stolen token?
+- [ ] What permissions did the compromised pipeline actually have?
+- [ ] Were secrets exposed only to logs/runtime, or used to publish or deploy?
+- [ ] Which environments were reachable: build only, staging, production?
+- [ ] Which outputs must now be treated as untrusted?
+
+### Information to Gather
+
+| Data | Source |
+|------|--------|
+| CI audit logs | CI/CD platform |
+| workflow/config diffs | repository history |
+| release/deployment history | CI/CD platform, cloud provider, registry |
+| artifact digests / provenance | registry, signing system, artifact store |
+| runner access and execution logs | runner host / CI platform |
+
+
+## Containment and Recovery
+
+### Option A: Rebuild from a known-good commit using a clean pipeline
+
+**When:** You can identify a trusted commit and re-establish a trusted build path.
+**Impact:** Release cadence slows, but trust is restored more safely.
+
+1. Stand up a clean pipeline or isolated builder
+2. Re-verify repository state and workflow definitions
+3. Rebuild from a known-good commit
+4. Compare output metadata against expected source and release intent
+5. Redeploy only from the rebuilt trusted output
+
+### Option B: Roll back to last known-good release
+
+**When:** A trusted prior release exists and rollback is operationally safe.
+**Impact:** Feature loss or temporary service degradation may occur.
+
+1. Identify the last trusted artifact and deployment
+2. Roll back affected services
+3. Verify rollback success in production
+4. Continue investigation before resuming normal release flow
+
+### Option C: Keep service paused until trust is re-established
+
+**When:** You cannot distinguish clean from compromised outputs.
+**Impact:** Operational disruption, but lower risk of serving malicious artifacts.
+
+1. Pause releases/deployments
+2. Communicate impact internally and externally as needed
+3. Rebuild trust in source, pipeline, credentials, and artifacts before resuming
+
+
+## Verification Before Resuming
+
+Do not resume normal delivery until you can answer these clearly:
+
+- [ ] The initial access path is understood well enough to prevent immediate recurrence
+- [ ] Compromised credentials have been rotated or invalidated
+- [ ] Untrusted artifacts and releases have been identified and handled
+- [ ] Build and deploy permissions are re-scoped appropriately
+- [ ] A known-good artifact has been rebuilt or a known-good release has been restored
+
+
+## Hardening After the Incident
+
+- [ ] Separate build permissions from deploy permissions
+- [ ] Require stronger approval controls for workflow and release changes
+- [ ] Use short-lived credentials where possible
+- [ ] Reduce secret exposure to only the jobs that need them
+- [ ] Restrict or harden self-hosted runners if used
+- [ ] Improve artifact provenance, signing, and release verification
+
+
+## Escalation
+
+Escalate immediately if:
+- [ ] production deployments may have been modified
+- [ ] signing keys or release credentials may be exposed
+- [ ] user-facing artifacts may have been maliciously published
+- [ ] the pipeline had access to broader cloud or infrastructure credentials
+
+See [Contacts](../contacts) and [Incident Response Policy](../incident-response-policy).
+
+
 ## Related
 
 - [Frontend Compromise](./frontend-compromise)
diff --git a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx
index 99beadb3..863a4395 100644
--- a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx
+++ b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Runbook: Dependency Attack | Security Alliance"
-description: "Stub runbook. Customize with your package management and build procedures."
+description: "Example runbook for dependency compromise. Review and customize for your package manager, build flow, and release process before use."
 tags:
   - Security Specialist
   - Operations & Strategy
@@ -21,7 +21,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-> **Stub runbook.** Customize with your package management and build procedures.
+> **This is an example runbook.** Review and customize for your package manager, dependency policy, and build procedures before use.
 
 ## Quick Reference
 
@@ -39,44 +39,131 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 
 - [ ] Unexpected behavior after dependency update
 - [ ] Security advisory for a package you use
-- [ ] Malicious code found in node_modules or similar
-- [ ] Lockfile changes you didn't make
+- [ ] Malicious code found in installed dependencies or build output
+- [ ] Lockfile changes you did not expect
+- [ ] Frontend bundle or released artifact changed more than the source diff would explain
 
-### Confirm Dependency Attack
+### Scope Questions
 
-```
-npm audit
-# or
-yarn audit
-```
+- Did the malicious dependency reach production, or is this still limited to source/build environments?
+- Was the dependency executed only during build time, or also in user-facing runtime code?
+- Did the dependency have access to CI secrets, registry tokens, or signing material?
+- Were any artifacts published or deployed during the exposure window?
 
-Check for recent lockfile changes in git history.
+### Differentiation
+
+- If the compromised package was only introduced through your CI/build path, also review [Build Pipeline Compromise](./build-pipeline-compromise)
+- If the issue is malicious code being served to users, also review [Frontend Compromise](./frontend-compromise)
+- If this is only an advisory on an unused code path, severity may differ from an actively weaponized package
 
 
 ## Immediate Actions
 
-1. [ ] Take down site to stop serving malicious code
-2. [ ] Identify the malicious package
-3. [ ] Pin dependencies to last known good version
-4. [ ] Rebuild from clean environment
+### Step 1: Freeze releases that rely on the affected dependency
+
+**Why:** Prevent additional malicious artifacts from being built or published.
+
+- [ ] Pause affected builds and deployments
+- [ ] Stop package publishing if your pipeline republishes downstream artifacts
+- [ ] Block dependency auto-update jobs until scope is understood
+
+### Step 2: Identify the exact bad package/version path
+
+**Why:** You need a precise package, version, and introduction path before you can cleanly contain it.
+
+- [ ] Record package name and version
+- [ ] Identify whether it is direct or transitive
+- [ ] Identify which commits or lockfile changes introduced it
+- [ ] Determine whether multiple repos or services consume it
+
+### Step 3: Stop trusting recent outputs
+
+**Why:** If malicious code ran during build or packaging, recent artifacts may be untrusted even if source looks clean.
+
+- [ ] Identify builds created during the exposure window
+- [ ] Identify deployed versions and published packages that include the dependency
+- [ ] Quarantine or withdraw suspicious outputs where possible
+
+### Step 4: Preserve evidence
+
+**Why:** Registry state, lockfiles, and CI evidence can change quickly.
+
+- [ ] Save lockfile and manifest versions from affected builds
+- [ ] Save CI logs and artifact metadata
+- [ ] Record package tarball hashes, integrity values, and registry metadata where available
+
+
+## Investigation
+
+### Key Questions
+
+- [ ] Was the package actually malicious, or just vulnerable?
+- [ ] Was the malicious code executed in your environment?
+- [ ] Did it affect build-time systems, runtime users, or both?
+- [ ] Were secrets, signing credentials, or deploy tokens exposed?
+- [ ] Which artifacts or releases must now be treated as untrusted?
+
+### Information to Gather
+
+| Data | Source |
+|------|--------|
+| package/version metadata | registry, lockfile, manifest |
+| introduction point | git history, dependency bot PRs |
+| build logs | CI/CD platform |
+| deployed artifacts using bad dependency | release history, artifact store |
+| advisories / upstream incident details | package registry, maintainer advisories |
+
+
+## Containment and Recovery
+
+### Option A: Revert to the last known-good dependency state
+
+**When:** A trusted prior lockfile/package set exists.
+**Impact:** Fastest path in many cases.
+
+1. Revert the dependency or lockfile to a known-good state
+2. Rebuild from a clean environment
+3. Verify the bad package is no longer present in the output
+4. Redeploy only after validating the resulting artifact
+
+### Option B: Replace or remove the affected package
+
+**When:** A clean replacement exists, or the package is non-essential.
+**Impact:** May require code changes or degraded functionality.
+
+1. Remove or replace the affected package
+2. Regenerate lockfile carefully
+3. Rebuild from a clean environment
+4. Validate both functionality and resulting dependency tree
+
+### Option C: Keep service paused until trust is re-established
+
+**When:** You cannot clearly determine which artifacts are clean.
+**Impact:** Operational disruption, but lower chance of serving malicious code.
+
+1. Pause affected deployments
+2. Reconstruct a trusted dependency set
+3. Rebuild from a clean environment
+4. Resume only after verifying outputs and rotation of any exposed credentials
 
 
-## Mitigation
+## Verification Before Resuming
 
-1. [ ] Remove or replace malicious package
-2. [ ] Update lockfile with known good versions
-3. [ ] Rebuild using `npm ci` or `yarn --frozen-lockfile`
-4. [ ] Redeploy verified build
+- [ ] The malicious or suspect dependency is removed from the build
+- [ ] A clean rebuild has been produced from a trusted environment
+- [ ] Any exposed credentials have been rotated
+- [ ] Suspicious builds, releases, or packages have been identified and handled
+- [ ] The resulting artifact has been checked against expected changes
 
 
 ## Prevention
 
 - [ ] Use lockfiles and commit them
-- [ ] Use `npm ci` / `yarn --frozen-lockfile` in CI
-- [ ] Regularly audit dependencies
-- [ ] Consider using a private registry
-- [ ] Pin exact versions for critical packages
-- [ ] Review dependency changes in PRs
+- [ ] Use deterministic install commands in CI (`npm ci`, `pnpm install --frozen-lockfile`, etc.)
+- [ ] Review dependency and lockfile changes in PRs
+- [ ] Restrict who can approve dependency update automation
+- [ ] Audit critical dependencies and minimize unnecessary package surface area
+- [ ] Treat build-time dependencies as part of the production attack surface
 
 
 ## Related
diff --git a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx
index fe8ffd4e..95be4248 100644
--- a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx
+++ b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx
@@ -38,59 +38,77 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 ### Symptoms
 
 - [ ] Users report unexpected transaction requests
-- [ ] UI behaving differently than expected
-- [ ] Wallet drainer detected
-- [ ] Injected scripts in page source
-- [ ] DNS/domain issues
-- [ ] Community reports of phishing via official domain
+- [ ] UI behaves differently than expected
+- [ ] Wallet drainer behavior detected
+- [ ] Injected scripts or unexpected external resources appear in page source
+- [ ] Official domain or subdomain resolves unexpectedly
+- [ ] Community reports phishing or malicious prompts on the official frontend
 
 ### Attack Vectors
 
 | Vector | Signs |
 |--------|-------|
-| DNS hijack | Domain pointing to wrong IP |
-| CDN compromise | Malicious files served |
-| Dependency attack | npm/yarn package compromised |
-| Build pipeline | CI/CD compromise |
-| Hosting compromise | Files modified on server |
+| DNS hijack | Domain pointing to wrong IP or nameserver changes |
+| CDN compromise | Malicious files served from trusted edge path |
+| Dependency attack | Malicious npm/package dependency in built frontend |
+| Build pipeline compromise | CI/CD workflow or build output tampered with |
+| Hosting compromise | Files modified directly on origin or hosting platform |
+
+### Immediate Scope Questions
+
+- Is the compromise limited to the frontend, or does it indicate deeper CI/CD or hosting compromise?
+- Are users being asked to sign malicious transactions, approvals, or messages?
+- Which domains, subdomains, and static assets are affected?
+- How long may the compromised content have been served?
 
 
 ## Immediate Actions
 
-### Step 1: Take Down or Redirect
+### Step 1: Stop serving the compromised frontend
 
-**Why:** Stop users from interacting with compromised site
+**Why:** The first priority is preventing new user interactions with a malicious interface.
 
 Options:
-- [ ] Point DNS to maintenance page
+- [ ] Point DNS to a controlled maintenance page
 - [ ] Disable CDN distribution
-- [ ] Remove site from hosting
-- [ ] Add banner/warning if partial control
+- [ ] Remove or disable the affected site on hosting
+- [ ] Block or disable the specific route/app if compromise is scoped and partial control is retained
 
-### Step 2: Warn Users
+### Step 2: Warn users quickly and clearly
 
-**Why:** Prevent further damage
+**Why:** A compromised frontend often becomes a user-signing incident within minutes.
 
 - [ ] Post on Twitter/X
 - [ ] Post in Discord/Telegram
-- [ ] Update status page
+- [ ] Update status page or incident page
+- [ ] Pin the warning in primary community channels
 
 Message template:
-> Our website may be compromised. Do NOT interact with [domain] or approve any transactions until further notice. Your funds in the protocol are safe if you don't sign new transactions.
+> Our website may be compromised. Do NOT interact with [domain] or approve any transactions until further notice. If you have not signed new transactions, your funds in the protocol remain unaffected.
+
+### Step 3: Preserve evidence before cleanup
+
+**Why:** The malicious content, served assets, and resolver state may change quickly.
 
-### Step 3: Assess Scope
+- [ ] Save page source and served JavaScript bundles
+- [ ] Record affected URLs, file hashes, and timestamps
+- [ ] Capture DNS state, CDN config, and hosting/deploy history
+- [ ] Preserve CI/CD and deployment logs if relevant
 
-- [ ] What was changed?
-- [ ] How long was it compromised?
-- [ ] How many users potentially affected?
-- [ ] Were any transactions signed?
+### Step 4: Determine the trust boundary failure
+
+**Why:** You need to know whether to treat this as DNS, hosting, dependency, or pipeline compromise.
+
+- [ ] Identify how the malicious content was introduced
+- [ ] Identify what credentials or systems may also be exposed
+- [ ] Identify whether backend, admin, or deployment systems should also be treated as untrusted
 
 
 ## Investigation
 
 ### Priority: Identify Attack Vector
 
-The first priority is understanding how the attacker gained access so you can close that vector:
+The first priority is understanding how the attacker gained access so you can close that vector.
 
 - [ ] **How did attacker gain access?** (DNS, CDN, dependencies, CI/CD, hosting)
 
@@ -100,23 +118,22 @@ Once identified, go to the specific runbook:
 - Dependency attack → [Dependency Attack](./dependency-attack)
 - Build pipeline compromise → [Build Pipeline Compromise](./build-pipeline-compromise)
 
-### Post-Mitigation Investigation
-
-After the threat is contained, investigate impact:
+### Impact Questions After Containment
 
-- [ ] What was injected/changed?
-- [ ] Which users interacted during compromise window?
-- [ ] What were users tricked into signing?
+- [ ] What exactly was changed or injected?
+- [ ] What user actions were being induced? (approval, signature, transfer, login, seed phrase theft)
+- [ ] Which users interacted during the compromise window?
+- [ ] Did the incident affect only the frontend, or also the underlying protocol or admin systems?
 
 ### Check These
 
 | Component | How to Check |
 |-----------|--------------|
-| DNS records | `dig` or DNS provider console |
-| CDN files | Compare to known good |
-| Build artifacts | Check CI/CD logs |
-| Dependencies | `npm audit`, lockfile changes |
-| Hosting files | Compare to repo |
+| DNS records | `dig`, registrar, DNS provider console |
+| CDN files and config | compare to known-good state |
+| Build artifacts | CI/CD logs, artifact store |
+| Dependencies | lockfile, registry metadata, package diffs |
+| Hosting files | compare deployed content to repo / known-good release |
 
 
 ## Mitigation
@@ -133,29 +150,30 @@ See the specific runbook for detailed mitigation steps:
 
 ### Before Restoring Service
 
-- [ ] Root cause identified
-- [ ] Vulnerability fixed
-- [ ] Fresh deployment from verified source
-- [ ] All credentials rotated
-- [ ] Additional security measures in place
+- [ ] Root cause identified well enough to prevent immediate recurrence
+- [ ] Access path closed
+- [ ] Fresh deployment produced from verified source and trusted build path
+- [ ] Relevant credentials rotated
+- [ ] Critical user flows manually checked before reopening
 
 ### Restoring Service
 
 1. Deploy verified build
-2. Verify deployment matches expected
-3. Test critical user flows
-4. Monitor for anomalies
+2. Verify served assets match expected release
+3. Test critical wallet and transaction flows
+4. Monitor for unexpected asset changes, approvals, or user reports
 5. Announce service restored
 
 
 ## Affected User Support
 
-If users signed malicious transactions:
+If users may have signed malicious transactions or approvals:
 
-- [ ] Compile list of affected addresses (from chain data)
-- [ ] Provide guidance on revoking approvals
-- [ ] Consider compensation if protocol at fault
-- [ ] Document for post-mortem
+- [ ] Compile likely affected addresses from chain and telemetry data where possible
+- [ ] Provide approval revocation guidance
+- [ ] Provide transaction/contract indicators users should review
+- [ ] Preserve evidence for later root-cause and impact analysis
+- [ ] Consider remediation or compensation separately from immediate containment
 
 
 ## Escalation
@@ -169,12 +187,12 @@ If users signed malicious transactions:
 
 After resolving, review:
 
-- [ ] DNS provider security (2FA, lock)
-- [ ] Hosting access controls
+- [ ] DNS provider security and registrar controls
+- [ ] Hosting/CDN access controls
 - [ ] CI/CD security
-- [ ] Dependency management
-- [ ] Subresource integrity
-- [ ] Content Security Policy
+- [ ] Dependency management discipline
+- [ ] Frontend integrity controls (where applicable)
+- [ ] User-facing monitoring for unexpected asset changes
 
 
 ## Related
diff --git a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx
index dfab55a2..e9372884 100644
--- a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx
+++ b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx
@@ -23,6 +23,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 
 Step-by-step guides for specific incident types. Use these during active incidents to reduce cognitive load and ensure consistent response.
 
+These runbooks are operational procedures. They are different from:
+
+- **Playbooks** elsewhere in the framework, which are reference guidance
+- **Templates**, which are blank working documents to fill out during or after an incident
+
 > **These runbooks are examples and starting points.** They contain generic guidance that must be adapted to your specific protocol, infrastructure, and team. Review each runbook carefully and customize the commands, contacts, and procedures before relying on them during an actual incident. Untested runbooks can be worse than no runbook at all.
 
 ## Available Runbooks
diff --git a/docs/pages/incident-management/incident-response-template/templates/overview.mdx b/docs/pages/incident-management/incident-response-template/templates/overview.mdx
index 666c3f74..5321a2e1 100644
--- a/docs/pages/incident-management/incident-response-template/templates/overview.mdx
+++ b/docs/pages/incident-management/incident-response-template/templates/overview.mdx
@@ -23,6 +23,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 
 Templates for incident response documentation. Copy these when needed.
 
+These are working documents, not reference reading:
+
+- use a template when you need to create a new incident record or post-mortem
+- use a runbook when you need scenario-specific response steps
+- use the policy pages when you need process, roles, or communication expectations
+
 > **Review these templates before your first incident.** Familiarize yourself with the structure so you're not learning the format during an emergency. Consider running a tabletop exercise to practice filling them out.
 
 ## Available Templates
diff --git a/docs/pages/incident-management/overview.mdx b/docs/pages/incident-management/overview.mdx
index 65f4ee6f..0572cf5e 100644
--- a/docs/pages/incident-management/overview.mdx
+++ b/docs/pages/incident-management/overview.mdx
@@ -25,6 +25,14 @@ Incident management involves preparing for, detecting, responding to, and recove
 thinking about incident management prior to actually experiencing an incident, you can help increase the likelihood of a
 timely recovery.
 
+This section contains two different kinds of content:
+
+- **Framework guidance**: explanatory pages on communication, detection/response, lessons learned, and reference playbooks
+- **Operational templates**: copy-and-adapt incident response documents, templates, and runbooks for internal team use
+
+Use the framework guidance to understand the discipline. Use the incident response template section to build your own
+operational documentation.
+
 ## Contents
 
 1. [Communication Strategies](/incident-management/communication-strategies)
diff --git a/docs/pages/incident-management/playbooks/overview.mdx b/docs/pages/incident-management/playbooks/overview.mdx
index 16bf8d7f..fb050c23 100644
--- a/docs/pages/incident-management/playbooks/overview.mdx
+++ b/docs/pages/incident-management/playbooks/overview.mdx
@@ -19,9 +19,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-Generally speaking, incident response playbooks aim to provide detailed, step-by-step procedures for handling specific
-types of security incidents. Obviously, it's not possible to have thought about every possible scenario ahead of time,
-but one could create documentation for the most likely or devastating scenarios.
+These playbooks are reference material: they help teams think through common incident types, decision points, and
+response patterns. They are not drop-in internal operating procedures.
+
+For copy-and-adapt operational documentation, see
+[Incident Response Template: Templates](/incident-management/incident-response-template/templates/overview)
+and
+[Incident Response Template: Runbooks](/incident-management/incident-response-template/runbooks/overview).
 
 ## Best Practices