IR-1 Policy and procedures: requirements and evidence

What IR-1 policy and procedures requires and why assessors start here

IR-1 asks the organization to have a written incident response policy and the procedures that put it into practice. The policy should state its purpose, scope, roles and responsibilities, management commitment, coordination among the parties involved in responding, and compliance expectations. The procedures turn those statements into steps people can follow. Both must be disseminated to the defined roles, owned by a designated official, and reviewed and updated at a defined frequency and after defined events. For a compliance lead or CISO, this is usually the first document an assessor opens, because every other IR control (training, testing, handling, reporting and the incident response plan) is judged against it. If the policy is missing, out of date or unknown to the people who must follow it, assessors have little reason to trust the rest of the family.

The control is harder to meet than it reads, for three recurring reasons. Documents drift from practice: the policy says reports go to one team while the on-call rota routes them elsewhere, and nobody notices until a test. Ownership is unclear: the policy was written by a project that ended, so no official is accountable for keeping it current. Review dates are missed: the document carries a review date that passed months ago, and the change log shows no update after the last incident or reorganization. Before engaging anyone, confirm the defined review frequency and the defined events in your own system security documentation, then check whether the named official still holds the role. Compare the policy against your last two exercises or real incidents and record every gap.

A practical first step is to collect the current policy, every procedure that implements it, the distribution list or acknowledgment records, and the review history, then mark each element the control names as present, dated and owned, or missing. Gaps usually sit in ownership and review evidence rather than in the prose itself. Self-hosted wiki and documentation platforms can keep version history and access records for these documents inside your own environment, which helps show when a change was made and by whom, although the organization still decides what the policy says and who approves it. An implementation partner can help structure documents, set the review workflow and prepare the evidence pack, but the organization owns the policy and an independent assessor decides whether the control is met.

Which systems, teams and baselines bring IR-1 into scope

IR-1 is allocated to the low, moderate and high baselines and to the privacy baseline, so it applies to nearly every system an agency or contractor authorizes. The cards below cover the decisions that change how much work the policy and procedures require: the level at which the policy is set, the systems and teams it governs, and the third parties that carry incident duties.

Baseline allocation across impact levels

SP 800-53B allocates IR-1 to the low, moderate and high baselines and to the privacy baseline, so the control applies whatever the system's impact level. A low-impact system still needs its own incident response policy and procedures, even though the enhancements that follow in the IR family differ by baseline. Check which baseline your authorization boundary uses before you decide how deep the procedures must go.

Organization, mission or system level

IR-1 lets the organization set the policy at the organization, mission or business process, or system level. A single enterprise policy with system-level procedures usually covers more systems with less duplicated text, while a system-level policy suits a boundary with its own operators and reporting chain. Record the chosen level in the policy itself so an assessor can see which systems it governs.

Systems and boundaries under the policy

List every system inside the authorization boundary, including development, test and backup environments that hold the same data, and confirm each one maps to a named policy owner. Systems left off the list tend to surface during an assessment as gaps. Shared services such as identity providers, logging platforms and self-hosted ticketing tools need explicit coverage too, because their incidents reach the systems that depend on them.

Teams with incident response roles

The policy must define roles and responsibilities for everyone who detects, triages, contains, communicates or reports incidents, which often includes help desk staff, system administrators, legal, privacy and executive decision makers. Map each role to a named position rather than a team alias where possible. Confirm the roles match the people an assessor will interview, since IR-1 assessment relies on interviews with personnel who hold these responsibilities.

Privacy baseline and personal data

The privacy baseline brings IR-1 into scope for systems that process personally identifiable information, even where the security impact level is low. Decide whether the incident policy addresses privacy incidents with a separate chain of notification and a privacy official as the designated reviewer. Confirm with your privacy office which breach notification duties apply to the data held in each system before writing those procedures.

Third parties with incident duties

Managed service providers, cloud operators, outsourced security monitoring firms and implementation partners may detect or contain incidents on your behalf. The policy should state which third-party duties are inherited under contract, how their reporting reaches your internal capability, and who approves their actions. Review the agreements that assign these duties, because an assessor will ask whether the policy and the contracts describe the same responsibilities.

How to build an IR-1 policy and procedure set that holds up

This sequence moves an IR-1 policy from an unowned idea to an approved, distributed and scheduled document set that an assessor can examine and trace to named roles. Each step produces a record that the next step depends on.

Assign an accountable official
Name one senior person who owns the incident response policy and procedures, and record that appointment in writing. This person approves changes, answers assessor questions and keeps the review schedule. Name a delegate as well, so the policy has an owner when the primary official is unavailable. The output is a signed appointment or charter entry that states the official's role, authority and reporting line. You know the step is done when the official can explain the policy's scope without looking it up.
Inventory the systems and organizations in scope
Before drafting, decide whether the policy applies at the organization, mission or business process, or system level, and write that choice down. List the business units, systems and third parties the policy covers, and confirm which SP 800-53B baseline applies to the systems in scope. The output is a scope statement that the policy will cite. Assessors look for a clear match between what the policy says it covers and what the organization actually runs.
Draft the policy against each required element
Write the policy so that each required element has a named section: purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. Take the element list from the control in SP 800-53A and check the draft against it line by line, rather than working from memory. Ask legal, HR and the security office to review the coordination and compliance sections. The output is a draft policy with a traceability table that maps each section to an element. The step is complete when every element has a section that a reviewer can point to.
Write procedures that implement the policy
Write the procedures that show how the policy is carried out, such as how incidents are reported internally, who is paged, how roles hand off and how the policy is reviewed. Each procedure should name the role that performs each action and the record it creates. Keep procedures separate from the policy so that operational detail can change without a full policy approval. The output is a procedure set with an index that links each procedure to the policy section it implements. A reader who has never worked in the organization should be able to follow the procedure to the end.
Define the dissemination list and review triggers
Identify the defined roles that must receive the policy and procedures, such as incident responders, system owners, help desk staff and executives, and record how each role gets the document. Define the review frequency and the events that force an earlier review, such as a significant change in the organization, a material incident or a change in applicable law. Set these values in the policy itself. The output is a distribution list and a trigger table. Assessors ask for both, so they should match the policy text exactly.
Approve and publish the document set
Route the policy and procedures to the approving authority, record the approval date, version and approver, and publish them in the location that the distribution list names. Keep a version history so that any earlier version can be produced for an assessor. The output is an approved document set with a version record and a publication record showing where it was posted and when. Confirm that the published copy matches the approved copy, since assessors often compare them.
Record acknowledgment and set the first review cycle
Collect acknowledgments from the people on the distribution list, and follow up with anyone who has not confirmed receipt. Put the next review date and the trigger events on a calendar owned by the accountable official. The output is an acknowledgment log and a review calendar with the next scheduled review. The step is done when the calendar exists, the review date is in the record and the log can be exported for an assessment. Organizations that use a document platform with version control and role-based permissions can keep these records in one place, but the organization still owns them.

How an assessor tests IR-1 and which evidence they request

This table sets out how an assessor tests IR-1 under SP 800-53A Rev. 5, which evidence they ask for, and the findings they most often raise. Read each row as a test step: the examine method checks the written policy and procedures, the interview method checks whether responders know and use them, and the findings column shows where the program usually falls short.

Test element	What the assessor does	Evidence requested	Common findings
Policy content (examine)	Reads the incident response policy and checks it covers purpose, scope, roles, responsibilities, management commitment, coordination and compliance, against the 17 determination statements for IR-1.	Current signed IR policy, version history, scope statement naming systems and business processes covered	Policy omits a required element such as management commitment or coordination with other functions
Procedures (examine)	Checks that procedures exist to implement the policy and that each procedure names the steps, owners and records it produces.	Written incident response procedures, linked runbooks, record templates	Procedures are high-level statements with no owners, or they point to documents that no longer exist
Currency of review (examine)	Compares the review and update dates against the organization's defined frequency and defined triggering events, such as major incidents or changes in structure.	Review log, approval records, change history showing dates and reviewers	Reviews are overdue, or no event-driven update was made after a significant incident or organizational change
Dissemination (examine and interview)	Confirms the policy and procedures reached the defined roles, and asks personnel how they received them.	Distribution list, acknowledgment records, intranet publication logs, access records for the document repository	No proof of dissemination to some defined roles, or distribution went only to the policy owner
Designated official (examine)	Verifies that a named official manages the policy and procedures and has the authority to approve changes.	Appointment memo or role description, approval signatures, governance meeting minutes	The owner named in the policy has left the role, or no one is named
Practice match (interview)	Interviews personnel with incident response responsibilities and asks them to walk through a recent event, comparing what they did with the written procedures.	Interview notes, a sample of recent incident records, responder checklists in use	Policy describes a process the team does not follow, so the document reflects an earlier practice
Role awareness (interview)	Asks responders to name their duties, escalation contacts and decision authority under the policy.	Roster of responders with assigned roles, on-call schedule, escalation matrix	Responders cannot identify who approves containment decisions or who contacts legal and communications
Privacy and alignment checks	Where the system processes personal data or falls under a privacy baseline, confirms the policy addresses privacy-related incident duties.	Mapping of policy sections to privacy requirements, sign-off by the privacy function	Privacy roles are absent from the policy, so the privacy function is not involved in incident decisions

Evidence that shows IR-1 is current and disseminated

IR-1 is tested on documents and on people. An assessor wants to see a policy and procedures that are approved, owned, dated and reviewed, and then wants proof that the right roles received them and know what they cover. The five artifacts below connect those two halves and each needs a routine that keeps it true between assessments.

Approved policy with version history

The incident response policy should carry an owner, an approver, an effective date and a version number. Assessors check that the version they examine is the one in force and that the policy addresses purpose, scope, roles, management commitment, coordination and compliance. Keep prior versions retrievable so you can show what changed. In a wiki such as XWiki, page history records what changed, when and by whom, which covers this need without a separate register. Confirm with your own change process how approvals are recorded.

Procedures that implement the policy

Procedures translate the policy into steps: who triages a report, who declares an incident, how evidence is preserved and who is notified. Assessors compare procedures against the policy to find gaps, such as a policy duty with no procedure behind it. Each procedure should name its owner and the policy section it implements. Review procedures alongside the policy so the two never drift apart, and record which systems or teams the procedures currently cover.

Dissemination records and acknowledgments

IR-1 requires both documents to reach defined roles. Keep a distribution list tied to roles, not names alone, and record when each version was published and to whom. Staff acknowledgments show receipt for the current version. Access settings in a documentation platform such as BookStack, where permissions can be set per role at the shelf, book, chapter or page level, help limit who can edit the policy while letting responders read it. Confirm how your platform logs views and acknowledgments before relying on it.

Review log with dates and change reasons

The policy and procedures must be reviewed and updated at a frequency you define and after events you define. Your organization sets those values, so write them into the policy and confirm them with your auditor. The review log records each review date, the reviewer, whether changes were made and why, such as a lessons-learned trigger or a regulatory update. A log showing no reviews when one was due is a common finding, so set calendar reminders tied to the defined schedule.

Current register of IR duty holders

Interviews are part of the IR-1 assessment, and assessors ask personnel with incident response responsibilities what they do and which document governs it. Maintain a register that maps each role to its duties, its named holders and its deputies, and update it when staff change. Confirm that the people interviewed have the current policy and procedures. A register that lags behind staff turnover makes interview answers inconsistent with the documents.

What meeting IR-1 costs in money and effort

This table breaks down the cost and effort components of writing, approving, disseminating and reviewing IR-1 policy and procedures, and marks which ones are one-time and which recur. Use it to see who is paid for each component and what to request in a quote. No prices or durations are stated because none are published in the research supplied for this topic.

Cost component	One-time or recurring	What drives it up or down
Policy drafting and approval effort	One-time, then recurring on revision	Number of organizational levels covered (organization, mission or business process, system), and how many approvers sign off
Procedure writing for each IR-1 procedure	One-time, then recurring on revision	Number of systems and business processes in scope, and whether procedures reuse existing IR-4 and IR-8 content
Documentation tooling or licenses	Recurring (subscription) or one-time (perpetual)	Seat count, hosting model and whether the organization already runs a wiki; self-hosted open-source wikis can remove license spend but still need hosting and administration
Dissemination and acknowledgment effort	Recurring, each time policy changes	Number of defined roles that must receive the policy, and whether acknowledgments are tracked in a system of record
Recurring review and update effort	Recurring at the defined frequency and after defined events	Frequency set by the organization, number of trigger events defined, and how much change follows incidents or system changes
External review of the policy	One-time per cycle, if purchased	Scope of the review, whether counsel or an outside assessor reviews wording, and how many rounds of comments occur
Assessor sampling and interviews	Recurring at each assessment cycle	Assessor's sample of policy versions, interviews with IR-responsible staff, and how quickly evidence can be retrieved
Version history and change records	Recurring, low effort if automated	Whether the documentation platform keeps version history and approvals natively; manual tracking adds effort at each review

How self-hosted wiki and permission tools hold IR-1 evidence

IR-1 is tested largely through documents: whether the incident response policy and procedures exist, are current, and reach the people who must follow them. A self-hosted wiki records how those documents change, and a permission model shows who may edit and read them. The two tools below cover different parts of that evidence, and the organization still owns the policy content and approval.

Version history for policy pages

XWiki keeps every change to a page under version control, recording what changed, when and by whom. An assessor testing whether IR-1 procedures are reviewed and updated at the defined frequency can compare any two versions and see the review trail directly. Check that the wiki is configured so page history cannot be purged by routine clean-up jobs, and that the retention of old versions matches your records policy. XWiki is licensed under LGPL-2.1-or-later, so confirm with counsel that this license fits how you plan to deploy and modify it.

Role-based ownership of the policy

BookStack assigns user abilities through roles, so the official who manages the incident response policy can be the only role able to approve edits, while responders hold read access. Permissions can be overridden per role at the shelf, book, chapter or page level, which lets you separate the IR policy from general documentation. Assessors look for a designated owner and controlled dissemination, so document the role mapping alongside the policy. Confirm the license terms, which are MIT, against your internal open-source policy before adoption.

Dissemination records outside the wiki

A wiki shows that a document exists and who can read it, but IR-1 also expects the policy to reach defined roles. Pair the wiki with a dated acknowledgement step, such as a sign-off form or a training attendance list, held in a system that records who confirmed receipt. Decide in advance which roles must acknowledge the policy and how new joiners are included. Confirm with your assessor which dissemination evidence they accept, because the wiki alone may not show that personnel received the document.

Access reviews for IR documents

Permissions drift over time as staff change roles, so the access list for the IR policy needs a periodic review. Export the role assignments and page-level overrides from each tool on a schedule and compare them with the current responder roster. Keep those exports with the review record so the assessor can see that editing rights match the designated official. Record who performed each review and what changed as a result.

Hosting and backup responsibilities

Both tools run inside your own infrastructure, which means the organization owns hosting, patching, backups and restore testing for the wiki that holds the policy. A restore test should confirm that page history and role assignments come back intact, not just the current page text. Ask your implementation partner to document the backup schedule, the restore procedure and the people responsible for each step. The partner can prepare these records, but the organization must perform and retain them.

Who owns the policy, who prepares it and who assesses it

Your organization owns IR-1. The policy and procedures are the organization's own statements of how it handles incidents, so a named senior official must approve them, assign the designated official who manages them, and decide who receives them. Assessors look for evidence that these decisions were made by the organization and not delegated silently to a vendor. The IR-1 policy must address purpose, scope, roles, responsibilities, management commitment, coordination among entities and compliance. Those statements only carry weight if the people named in them recognize and accept them.

Policy approval: A senior official signs the policy and records the date, so the approval can be shown during an interview.
Designated official: One named role maintains the document, tracks review dates and handles change requests.
Defined review cycle: Your team sets the review frequency and the events that trigger an earlier review, such as a major incident or a change in reporting law.
Dissemination records: Distribution lists, acknowledgments and repository access logs show the policy reached the defined roles.
Interview readiness: Staff with incident response responsibilities must be able to explain the policy in their own words.

Before engaging any partner, confirm internally who will sign, who will be the designated official and how review dates will be tracked.

Common IR-1 gaps and how to close them

Most IR-1 findings are not about missing policy text. They come from policies with no accountable owner, procedures that drifted from the tools in use, and review cycles that stopped running. Each card names one gap, why an assessor flags it, and the action that closes it.

Policy with no named owner

IR-1 requires the incident response policy and procedures to be managed by a designated official. When the document lists a team instead of a person, an assessor cannot tell who approves changes or answers questions. Close the gap by naming one role, such as the CISO or head of security operations, in the policy header and the document control record. Confirm the owner signed the approval in the document history.

Procedures that name retired tools

Procedures often reference a ticketing system, SIEM or chat channel that has since been replaced. An assessor interviewing responders will notice the mismatch quickly. Walk each procedure step by step with the people who run it, replace retired tool names, and record the date of the walk-through. Where the platform is self-hosted, confirm that the tool named in the procedure is the one actually deployed in your environment.

No record of dissemination

IR-1 expects both the policy and the procedures to reach the defined roles. A document sitting on a shared drive does not show that anyone received it. Keep a distribution list tied to roles, an acknowledgment record for each person, and a log of when each version was sent. Check that the list still matches current staff after reorganizations and contractor changes.

Review dates that have lapsed

Organizations define a review frequency and triggering events for IR-1, then stop checking them. Assessors compare the stated review date with the document history and look for gaps. Put the next review date and the trigger events, such as a major incident, a new reporting obligation or a platform change, in the document metadata. Set a recurring reminder to the named owner rather than relying on memory.

Policy out of step with the IR-8 plan

The incident response policy sets direction, while the incident response plan described in IR-8 sets roles, reportable incidents and information sharing. When the two use different severity levels, contact lists or escalation paths, responders cannot follow both. Compare the policy's roles and responsibilities section with the plan line by line, align the terms, and note the cross-reference in each document so a future change to one prompts a check of the other.

How much effort IR-1 takes and what buyers ask before hiring help

How much effort does IR-1 take to implement?

The effort depends less on the control text than on how many systems and business processes the policy must cover, and how many documents already exist. IR-1 asks for an incident response policy and the procedures that implement it, both disseminated to defined roles, owned by a designated official, and reviewed on a defined schedule. A small organization with one system and an existing security policy may need a focused revision. A larger one usually needs to reconcile policy, procedures and the incident response plan so they do not contradict each other. Ask any provider to break the effort into drafting, stakeholder review, approval, dissemination and the first review cycle, and to state which of those steps your staff must attend.

Can we write the IR-1 policy ourselves?

Yes, many organizations draft it internally, and NIST does not require an outside author. The policy must address purpose, scope, roles, responsibilities, management commitment, coordination and compliance, and the procedures must show how those statements are carried out. Your organization owns the policy and the decisions in it, so the people who will be accountable for incident response must agree to it. Where internal drafting usually stalls is in consistency: the policy, procedures, IR-8 plan and training materials must name the same roles and the same review triggers. Confirm internally whether you have someone who can maintain that consistency over time.

What does an implementation partner change in IR-1 work?

An implementation partner prepares the documents, the place where they live and the evidence trail, but it does not own the policy or certify that it works. In practice, a partner may map the control to your existing policy set, draft or restructure the policy and procedures, configure a document platform so versions, approvals and access are recorded, and assemble the evidence an assessor will ask for. Under a fixed scope, the deliverables and the review cycle are agreed in writing before work starts. Ask for the exact list of documents, the systems that host them, and who signs off on each.

How long does IR-1 take to put in place?

No supplied source gives a duration for IR-1, and NIST states it does not set implementation timelines for organizations. Time is driven by the number of approvers, the state of existing documents, how many business units or systems the policy must cover, and how quickly leadership agrees on roles. Organizations with a current policy set that needs only a control-level revision often move faster than those writing from scratch. Ask for a schedule in the written scope with named milestones, and confirm which dependencies, such as executive approval meetings, sit on your side.

What does the IR-1 work need from our staff?

The work needs named people who can make decisions, not just review drafts. Typically this includes the designated official who will own the policy, the leaders of security operations, IT, legal and privacy functions, and anyone who will carry out the procedures during an incident. Interviews are part of how assessors test this control, so the people named in the policy should be able to explain their role in their own words. Plan time for review cycles, for approval at the level your governance requires, and for a dissemination step that records who received the policy and when.

How does the auditor's role differ from the partner's role?

The partner prepares systems, documents and evidence, while the auditor or assessor independently tests whether the control is in place. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For IR-1, an assessor typically examines the policy and procedures and interviews personnel with incident response responsibilities, using the methods in SP 800-53A. Ask your assessor which evidence they expect, how they want the documents dated and approved, and whether they will accept a document platform's version history as proof of currency.

Which parts of IR-1 can be outsourced and which must stay in-house?

Drafting support, document structure, version control setup and evidence packaging can be outsourced. Accountability cannot. The organization must decide its incident response roles, approve the policy, appoint the designated official and keep the procedures current with real operations. Review triggers, such as organizational changes or lessons learned from incidents, are events only your staff can observe, so they need an internal owner. Before engaging anyone, write down which decisions stay internal and confirm that the provider's scope excludes them.

Can open-source document tools keep IR-1 evidence current?

Self-hosted wiki and documentation platforms can keep the policy and procedures under version control, which supports the currency and dissemination evidence assessors look for. XWiki keeps every change under version control with the author and timestamp, and lets users compare versions and roll back. BookStack assigns abilities through roles that can be overridden at the shelf, book, chapter or page level, which helps limit who can edit approved policy. Confirm in your environment that the chosen tool meets your approval workflow and retention requirements, because neither product replaces the governance steps your organization must record.

How DeployOpen scopes and prepares IR-1 evidence

DeployOpen prepares the systems, documents and evidence behind IR-1 Policy and procedures inside your own infrastructure, without issuing any assessment result. Your organization owns the incident response policy and procedures, and an independent assessor decides whether they meet the control.

How we scope

Agree in writing which systems, business processes and organizational levels the incident response policy and procedures will cover.
Confirm the named official who manages the policy and the roles the policy must reach for dissemination.
Set the review frequency and triggering events with your team before any drafting begins, so the scope is fixed and testable.

How we build

Draft an incident response policy covering purpose, scope, roles, responsibilities, management commitment, coordination and compliance.
Write the supporting incident response procedures and map each one to the policy statements it implements.
Configure version-controlled document repositories so every change to the policy and procedures is recorded with its author and date.

How we hand over

Deliver the approved policy, procedures, dissemination records and review log in a form your assessor can examine directly.
Prepare a short evidence index that points each IR-1 determination statement to the document or record that addresses it.
Walk your incident response personnel through the documents so the interviews an assessor runs match what is written.

How we support

Offer ongoing support as a retainer to keep the policy and procedures current after organizational or system changes.
Review updates to the policy after lessons learned, reorganizations or changes to the controls it depends on.
Confirm with your assessor which evidence formats and interview records they expect before the assessment begins.