IR-1: Policy and Procedures

IR-1 requires you to create and maintain incident response (IR) policy and procedures, then distribute them to the people who must follow them. To operationalize it fast, assign an IR policy owner, publish a procedures runbook tied to your incident lifecycle, define who receives what, and keep evidence that the documents are current, approved, and actually disseminated. ¹

Key takeaways:

• You need two things: an IR policy (management intent) and IR procedures (operator runbooks), with defined audiences and distribution.
• Auditors will test “documented and disseminated” through approvals, version control, access logs/attestations, and training or acknowledgment records.
• A control card + evidence bundle turns IR-1 from a static document into an auditable, repeatable control operation.

IR-1: Policy and Procedures is the “paper-to-practice” gate for incident response: if you can’t show a maintained IR policy, a usable procedures set, and proof that the right people received them, you will struggle to defend the rest of your incident response program in an assessment.

Most organizations fail IR-1 in predictable ways. They have a PDF policy that reads well but doesn’t map to how the SOC, IT, Legal, Privacy, and business teams actually work. Or they have a great runbook in a wiki, but no formal approval, no versioning, and no record of dissemination. Another common gap is scope confusion: a corporate policy exists, but the system or environment in scope for the assessment (for example, a federal system boundary or a contractor enclave handling federal data) is not clearly covered.

This page explains what IR-1 expects at “requirement level,” who it applies to, and how to implement it as an operating control with clean evidence. The aim is speed: get to an approvable policy, an executable set of procedures, and a repeatable mechanism to distribute and prove currency.

Regulatory text

Requirement excerpt: “Develop, document, and disseminate to [organization-defined personnel or roles]:” ¹

What the operator must do with that text

IR-1 is a documentation-and-communication requirement with three verbs you must satisfy:

1. Develop: Create IR policy and IR procedures that fit your environment, roles, and incident risks.
2. Document: Put them under document control (ownership, versioning, approval, review cadence, and retention).
3. Disseminate: Distribute the policy and procedures to the specific roles that need them, and be able to prove it happened.

The bracketed phrase (“organization-defined personnel or roles”) is not optional. You must explicitly define the audiences. If you leave audiences implicit (“all employees”), expect an auditor to ask: which roles respond, which roles approve, which roles escalate, and where is that defined?

Citations: NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI

Plain-English interpretation (what IR-1 really means)

• Policy is the management statement of intent: scope, objectives, governance, definitions, and high-level requirements.
• Procedures are the “how”: step-by-step actions for detection, analysis, containment, eradication, recovery, communications, evidence handling, and post-incident review.

IR-1 is satisfied when a reasonable operator can pick up your procedures and execute the incident lifecycle, and you can show that the people expected to do that work were given the current version.

Who it applies to

Entity types

• Federal information systems implementing NIST SP 800-53 controls.
• Contractor systems handling federal data where NIST SP 800-53 is flowed down by contract or used to satisfy program requirements. ¹

Operational context (where this becomes real)

IR-1 matters most in these situations:

• You run a SOC or on-call incident response function (internal or through a third party).
• You operate regulated or contract-bound environments with defined system boundaries (enclaves, segregated cloud accounts, dedicated tenants).
• You rely on multiple teams for response (IT Ops, Security, Legal, HR, Privacy, Comms, Product, Customer Support).

If incident response crosses organizational lines, IR-1 should also address how you coordinate with third parties (forensics firms, MSSPs, cloud providers, critical SaaS vendors), even if those parties sit outside your internal policy repository.

What you actually need to do (step-by-step)

Step 1: Define scope and roles (make the bracket concrete)

Create a one-page “IR-1 scope sheet” that answers:

• Which systems/environments are in scope (system boundary, business unit, or contract scope).
• Which incident types are covered (security incidents, privacy incidents, availability events with security impact, etc.).
• The personnel/roles who must receive policy and/or procedures.

Minimum role list to consider

• CISO/Head of Security, IR Manager, SOC analysts
• IT Operations / SRE / Cloud Ops on-call
• Legal, Privacy, HR (as applicable)
• Executive incident sponsor (often CIO/COO) for major incidents
• Communications/PR lead (if you have external comms obligations)
• Third-party management/procurement contact for vendor coordination

Deliverable: a role-to-document matrix (policy vs procedures) that you can defend in an audit.

Step 2: Write (or refresh) the IR policy (management level)

Keep policy short and testable. Include:

• Purpose, scope, and definitions (what counts as an incident)
• Governance: who owns IR, who approves exceptions, who declares severity
• Mandatory requirements: logging, reporting, evidence preservation, post-incident review expectations
• References to supporting documents (procedures/runbooks, contact lists, escalation paths)

Operator tip: If the policy includes requirements you can’t evidence (for example, “all incidents are reviewed within X days”), remove the number or move it to a target in procedures where you can manage it.

Step 3: Build procedures as runbooks tied to the incident lifecycle

Your procedures should be usable under stress. Common procedure modules:

• Intake & triage: sources, ticketing, initial validation, severity criteria
• Containment: account disablement, network isolation, endpoint actions, cloud key rotation
• Eradication & recovery: patching, rebuilds, credential resets, service restoration checks
• Communications: internal notification tree, executive updates, customer notifications (if applicable), regulator/contracting officer pathways (if applicable)
• Evidence handling: chain of custody, log preservation, forensics handoff
• Post-incident review: root cause, corrective actions, lessons learned, backlog tracking

Deliverable: an IR procedures set with clear “who does what” per step. Avoid prose-only documents; checklists win audits.

Step 4: Put documents under control (approval, versioning, review triggers)

Auditors need to see governance, not just content.

• Assign an owner (role, not a person-only dependency)
• Define approvers (security leadership plus cross-functional sign-off where needed)
• Set a review trigger: material changes (org restructure, tooling changes, major incident learnings, contract changes)
• Use version control (document history, change log)

This is where a simple control card helps: objective, owner, cadence/trigger, steps, evidence, exceptions.

Step 5: Disseminate to defined roles, and make it provable

Pick a dissemination method you can evidence:

• GRC tool policy portal with required acknowledgment
• LMS assignment for IR policy awareness (for roles in scope)
• Access-controlled wiki plus quarterly attestation by role owners
• Email distribution lists plus read/ack tracking (weaker, but workable if controlled)

Match dissemination depth to audience:

• Everyone gets the IR policy (if your org policy says so).
• Responders get procedures, contact rosters, and on-call instructions.

Step 6: Run control health checks (prove it’s operating)

IR-1 can become stale fast. Add lightweight checks:

• Confirm current versions are published
• Confirm acknowledgments/attestations for in-scope roles
• Sample test: pick one responder and have them locate the current runbook and escalation contact list during a tabletop

Practical implementation note: This is where teams get caught. They can show a policy, but can’t prove dissemination to the defined roles.

Required evidence and artifacts to retain

Use an “evidence bundle” approach so you can answer audits fast.

Evidence category	What to retain	What it proves
Policy	IR policy document, version history, approval record	“Develop” and “Document”
Procedures	IR procedures/runbooks, checklists, playbooks, contact/escalation roster	Operational “how” exists
Dissemination	Distribution list, access control list, acknowledgments, LMS completion, attestation records	“Disseminate” to defined roles
Governance	Role definitions, RACI, exception process, review triggers	Ownership and accountability
Ongoing operation	Control health check logs, remediation tickets, change log entries tied to incidents	Sustained maintenance

If you use Daydream, map IR-1 to a control card and attach the minimum evidence bundle per cycle so the team stops rebuilding audit packets from scratch.

Common exam/audit questions and hangups

1. “Show me the IR policy and procedures.” Expect requests for the latest version and prior version history.
2. “Who are the defined personnel/roles?” If you can’t produce a clear list, the bracketed requirement is unmet.
3. “How do you know the right people received these?” Be ready with acknowledgment logs or access attestations.
4. “When were they last reviewed, and what triggered changes?” Tie updates to incidents, tooling changes, org changes.
5. “Do procedures match how you actually respond?” Misalignment between documents and real workflows is a red flag.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only compliance. A policy without procedures fails operational intent. Fix: publish runbooks with role-based steps.
• Mistake: Procedures exist but aren’t controlled documents. Wikis without versioning/approval create audit gaps. Fix: add document control, approvals, and change logs.
• Mistake: Dissemination is assumed. “It’s in SharePoint” is not proof. Fix: acknowledgments, role attestations, or controlled access logs.
• Mistake: Wrong audience definition. Over-broad (“all staff”) or under-broad (SOC only) scopes cause contradictions. Fix: define roles and map documents to roles.
• Mistake: Stale contact trees and escalation paths. During incidents, people call the wrong numbers. Fix: ownership and periodic verification tied to on-call rotation changes.

Enforcement context and risk implications

No public enforcement case references were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Operational risk is still straightforward: weak IR-1 evidence usually correlates with weak incident execution. During assessments, the immediate impact is control failure risk because you cannot prove “documented and disseminated.” During real incidents, the impact shows up as delayed escalation, inconsistent decision-making, and gaps in evidence preservation.

Practical 30/60/90-day execution plan

You asked for speed, so this plan focuses on producing auditable artifacts quickly without inventing time-to-implement claims.

First 30 days (stabilize and publish)

• Name an IR-1 owner and approvers.
• Draft or refresh IR policy (scope, governance, definitions, references).
• Compile current procedures into a single runbook set (even if imperfect).
• Define “personnel/roles” and build the policy/procedure distribution matrix.
• Choose dissemination mechanism you can evidence (GRC portal, LMS, attestation).

Deliverable: approved policy + procedures v1, with defined audiences and a dissemination record.

Days 31–60 (make it executable and testable)

• Convert prose procedures into checklists and decision trees (severity, containment options, comms).
• Align procedures to actual tools (ticketing, SIEM, EDR, cloud consoles).
• Add evidence handling instructions (log preservation and forensics handoff).
• Run one tabletop and feed outcomes into document updates (change log entry).

Deliverable: procedures that match reality, plus a test artifact (tabletop record) and resulting updates.

Days 61–90 (operationalize as a control)

• Start a recurring control health check: currency, access, acknowledgments, contact list validation.
• Track remediation items to closure (document gaps, role coverage gaps, missing acknowledgments).
• Package the evidence bundle in a single audit-ready location (GRC system or controlled repository).
• If using Daydream, automate evidence requests and store artifacts against IR-1 so audits become a pull, not a scramble.

Deliverable: repeatable operation with traceable evidence and a remediation backlog with owners and due dates.

Frequently Asked Questions

Do we need both an IR policy and IR procedures to satisfy IR-1?

Yes. IR-1 explicitly expects policy and procedures to be developed, documented, and disseminated; policy alone usually fails the “how-to-operate” test in audits. Keep the policy stable and push operational detail into procedures. ¹

Who counts as “[organization-defined personnel or roles]”?

The roles are your decision, but you must define them explicitly and be able to defend why they are in scope. Include responders and decision-makers, and consider supporting functions like Legal and Privacy where they participate in incidents. ¹

What is acceptable proof that we “disseminated” the documents?

Auditors generally accept evidence such as acknowledgment records, LMS assignment completion, or role-owner attestations plus controlled access records to the current versions. Pick one method and standardize it for the defined roles.

Our procedures are in a wiki. Is that a problem?

A wiki can work if it has document control: clear ownership, version history or change log, approval workflow, and access governance. Without those, you’ll struggle to prove “document” and “disseminate” in a repeatable way.

How often must we review IR policy and procedures?

NIST’s excerpt here does not specify a review frequency, so set a review trigger model you can operate: periodic review plus event-driven updates after major incidents, tooling changes, or org changes. Document the trigger rules and keep change logs. ¹

How do we connect IR-1 to third-party incident response support (MSSP, forensics firm)?

Treat third parties as part of the procedures: define engagement triggers, contacts, access prerequisites, and evidence handoff steps. Keep contracts/SOW references and a current contact roster in the controlled procedures set.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON