IA-1 Policy and procedures: requirements and evidence

What IA-1 policy and procedures require before any authentication control is tested

IA-1 asks an organization to have a documented identification and authentication policy, supported by procedures that show how the policy is carried out, with a named official who owns both, distribution to the roles that depend on them, and reviews at a defined frequency and after defined events. An assessor checks this governing layer first, because the technical controls in the IA family (user, device and service authentication, identifier and authenticator management) can only be judged against written rules. If the rules cannot be produced, the rest of the family has nothing to be measured against. The risk IA-1 addresses is simple to describe and common in practice: authentication rules that exist only in people's heads, in an old wiki page, or in a ticket template nobody maintains. When an administrator leaves, or a platform is replaced, the password length, MFA expectations or account-issuance steps can drift without anyone noticing. Three things usually make IA-1 hard to satisfy. Policies are written once and never revisited, owners have left the organization, and procedures describe the system as it was designed rather than as it runs today. Before testing any IA control, confirm who owns the policy, when it was last reviewed, which events trigger a review, and whether the procedures match the identity provider, directory and account lifecycle actually in use.

IA-1 has no control enhancements in SP 800-53 Rev. 5 Release 5.2.0, so the requirement is one set of expectations rather than a menu of add-ons. SP 800-53B selects IA-1 for the low, moderate and high baselines but not for the privacy baseline, so any system in scope for a low, moderate or high baseline needs this policy layer. Confirm the defined values for review frequency, triggering events and distribution roles in your own organization's control parameters, since those choices are yours to set and are what an assessor will test against. Assessors typically examine the policy and procedures, the events list used for review, the system security plan and interview the personnel who hold identification and authentication responsibilities.

Which systems, teams and third parties IA-1 policy and procedures cover

Before drafting an IA-1 policy, decide which systems it governs, which identity services it names, who receives it and how inherited controls are recorded. Each decision changes how much content the policy needs and who must approve it.

Impact baseline for each system

IA-1 is selected in the SP 800-53B low, moderate and high baselines, so the impact level of each system determines which systems the policy must cover and how much procedure detail it needs. Confirm with your authorizing official or system owner which categorization applies to each system in scope. Mixed-impact environments often need one policy with system-specific procedure annexes rather than separate documents.

Named authentication services and identity providers

The policy should name the directories, identity providers, single sign-on services, and authentication mechanisms that it governs, such as the enterprise directory, privileged access tooling, and any federated identity provider. An unnamed service is easy to leave out of reviews. Inventory these services from your own environment and confirm each owner before the policy is approved.

Roles that receive the policy

IA-1 requires distribution to defined roles, so the list must match the people who run identity operations, approve access, and handle authenticator issuance and reset. Typical recipients include identity administrators, help desk staff, system owners, and security operations. Record who received each version and when, because assessors commonly ask for distribution evidence.

Inherited controls from cloud and managed providers

Where a cloud or managed service provider operates part of the identity stack, the policy must state which authentication controls the provider performs and which remain with your organization. Obtain the provider's control responsibility documentation and map its entries to your procedures. Confirm with the provider how it documents inheritance, since the terms and artifacts vary by service.

Link to the system security and privacy plan

The IA-1 policy should be consistent with the system security and privacy plan for each in-scope system, which records how identification and authentication controls are implemented. Check that the plan references the current policy version and that any stated authenticator or identifier rule matches the policy text. Mismatches between the two documents are a common finding in assessments.

Link to the risk management strategy

The policy should trace its authentication requirements to the organization's risk management strategy and risk tolerance, so that stronger rules apply where risk is higher. Confirm with your risk owner which risk decisions the policy must reflect and how exceptions are approved. Related controls AC-1, PM-9, PS-8 and SI-12 usually share an owner and review cycle with IA-1, so confirm the combined scope with your own environment before setting review dates.

How an assessor tests IA-1 policy and procedures

This table maps each assessment focus for IA-1 to the examine and interview methods an assessor uses, the evidence to prepare and the findings that commonly appear. SP 800-53A Rev. 5 assesses IA-1 with 17 determination statements using only the examine and interview methods, so no test method applies. Read each row as a question the assessor will ask and the artifact that answers it.

Assessment focus	Examine and interview methods	Evidence requested	Common findings
Policy document	Examine the identification and authentication policy for scope, purpose, roles, coverage and management commitment. Interview the designated official about how the policy was approved.	Signed or approved policy with version, approval date and named owner; evidence of distribution to defined roles	Policy names no owner, has no approval record, or covers only part of the organization's identification and authentication scope
Implementing procedures	Examine procedures for accounts, identifiers and authenticators against the policy. Interview operators to confirm they follow the documented steps.	Procedure documents mapped to policy statements; runbooks or tickets showing the procedure in use	Procedures describe a retired system, a former directory or a decommissioned tool, while staff work from undocumented steps
Review and update triggers	Examine the list of events that require review, such as audit findings, incidents, system changes and organizational changes. Examine records showing reviews occurred.	Defined review frequency and event list; dated review records; change log showing updates after triggering events	Review frequency is defined but no review is recorded; an audit finding or incident did not lead to a policy update
System security plan	Examine whether the system security plan references the identification and authentication policy and the procedures that implement it.	System security plan sections on identification and authentication, cross-referenced to policy and procedure identifiers	Plan describes authentication controls that do not match the procedures, or it cites a policy version that no longer exists
Privacy plan and risk management strategy	Examine whether the privacy plan and risk management strategy documentation reflect the identification and authentication policy and its risk decisions.	Privacy plan entries and risk strategy text that reference the policy; risk decisions linked to authentication	Risk strategy is silent on authentication risk, or privacy plan and policy describe different identity data handling
Personnel with identification and authentication responsibilities	Interview the personnel who assign identifiers, issue authenticators and approve access to confirm their roles and their knowledge of the policy.	Named role assignments; training or briefing records; responsibility matrix	Staff cannot name the policy owner or locate the current version, and responsibilities are assumed rather than assigned
Version control and access to documents	Interview document owners and examine where the current policy and procedures are stored and who can change them.	Repository location, access list, version history and rollback record for each document	Staff find several conflicting copies on shared drives, and no one can show which copy was approved

How to write, approve and distribute the IA-1 policy and procedures

This sequence turns IA-1 from a control statement into a policy and procedure set that has a named owner, an approval record, distribution to the right roles and a defined review cycle. Each step closes with an artifact an assessor can examine.

Confirm the baseline and system scope
Start by confirming which SP 800-53B baseline applies to the systems in scope. IA-1 is selected for the low, moderate and high baselines but not for the privacy baseline, so the impact level of each system determines whether the control applies in its full form. Record the systems, services and user populations that the policy will cover, including cloud identity services, directories, privileged access tooling and any non-person identities. Check the system security plan so the policy scope matches the documented boundary. The output is a scope statement that lists covered systems, the baseline selected for each and the authorizing official's acknowledgment of that scope.
Name the designated official and policy owner
Assign a designated official who manages the identification and authentication policy and procedures, and a policy owner who maintains the document day to day. In many organizations these are different people, such as a CISO as official and an identity engineering lead as owner. Write both roles into a short appointment record that states their responsibilities for drafting, updating and answering questions about the policy. The output is a signed appointment record that an assessor can match against the policy's ownership statement, along with a named contact for each authentication service.
Draft the policy statement and its scope
Draft the top-level policy covering its purpose, the scope of identification and authentication it governs, the roles and responsibilities it assigns, and the organizational commitment to comply. Keep the statement at policy level so that technical detail sits in the procedures. Align terms with the risk management strategy and privacy plan referenced in the assessment objects, so that the policy does not contradict other governance documents. The output is a draft policy with a version number, document history and a cross-reference table that links each section to the related controls, including AC-1, PM-9, PS-8 and SI-12 as related controls for IA-1.
Write procedures for each authentication service
Write one procedure set per authentication service, such as workforce single sign-on, privileged access, directory services, service accounts and external user access. Each procedure should name the step owner, the systems involved and the expected evidence, such as enrollment records, access review outputs or directory change logs. Where a procedure depends on a control in another family, reference that control by ID rather than restating it. Map each procedure to its owner so that gaps appear early. The output is a procedure set with an owner and an evidence location for every service in scope, held in the same repository as the policy.
Obtain formal approval of policy and procedures
Route the policy and procedures to the management level that the organization's governance model requires for approval. Record who approved each version, the date and any conditions attached to approval. Resolve comments from security, legal, privacy and operations before the approval step, and keep the comment log, since assessors commonly ask how dissent was handled. Confirm that the approved version is the one published in the repository. The output is a signed approval record for each version, with the approved document ID and the approver's name and role.
Distribute to defined roles with acknowledgment
Distribute the approved policy and relevant procedures to the roles that the organization defined, such as identity administrators, service desk staff, system owners and application developers. Ask each recipient to acknowledge receipt, and track acknowledgments against the role list. Follow up on missing acknowledgments through the governance channel. Where a self-hosted wiki or documentation platform is used, its version history and permission model can show who had access to each version and when it changed, which supports the distribution record. The output is a distribution record that lists each defined role, its recipients, acknowledgment dates and any open items.
Set review frequency and triggering events
Set the review frequency and the events that trigger an unscheduled review. Both are organization-defined values in IA-1, so the organization must choose them based on its risk, its change rate and its regulatory obligations rather than copying figures from another organization or template. Typical triggers include audit findings, incidents involving authentication, major changes to identity providers and changes in applicable law. Record the chosen values in the policy itself and add them to the review calendar. The output is a review schedule with defined frequency, named triggering events and a log of completed reviews, which proves the review cycle is operating.

Evidence that passes IA-1 and how to keep it current between audits

An assessor testing IA-1 looks for a policy and procedures set that exists, is distributed to the right people, has an accountable owner and is reviewed on schedule and after events that matter. The six artifacts below connect those checks, and most of them can be kept current through routine work instead of a pre-audit rebuild.

Approved policy with version record

The identification and authentication policy itself, with a version number, an effective date, the name of the approving official and a short change summary. The assessor checks that the policy names its purpose, scope, roles and the organizational entities it covers, and that the approved version matches what staff can actually find. Keep the policy in a controlled wiki or document system so every edit is versioned. Confirm with your own environment which tool holds the authoritative copy and who can approve changes.

Implementing procedures for authenticators

Procedures are the step-by-step work behind the policy: how accounts are requested, how identifiers are issued and retired, how credentials are reset and how exceptions are approved. An assessor compares each procedure against the policy and asks a staff member to walk through one real example. Write procedures as owned runbooks linked to the systems they operate, and review them whenever a platform, identity provider or workflow changes so they describe the current system.

Distribution and acknowledgment records

Evidence that the policy reached the defined roles, such as system administrators, help desk staff and application owners, and that those people acknowledged it. The assessor samples individuals and checks whether they received the current version. Use role-based access in your documentation platform so that each role sees the policy, and export the access and acknowledgment logs at each review cycle. Ask your identity team which roles were defined as recipients in the policy itself.

Review log for scheduled and event-driven reviews

A dated record of each review of the policy and procedures, showing the reviewer, the outcome and any updates made. IA-1 expects reviews at a defined frequency and after defined events, so the log must show both kinds. Keep the schedule as a calendar entry or ticket with an owner, and record every review even when nothing changes. Confirm your defined review frequency with the policy owner, since the frequency is set by the organization and not by the control text.

Triggering events and resulting updates

A register of the events your policy names as triggers, such as audit findings, security incidents, new identity platforms or significant regulatory changes, with the policy update each event produced. Assessors often use audit findings as the example they test, so link each finding to the revision it caused. Maintain the register as findings close, not at audit time. Keep the incident and finding identifiers so the trail can be followed without manual reconstruction.

Cross-references to the SSP and risk strategy

Evidence that the identification and authentication policy aligns with the system security and privacy plan and the risk management strategy. The assessor checks that the SSP describes the same authentication approach the policy requires and that the risk strategy accounts for authentication risk. Update these references whenever the policy changes, and record the revision of each linked document so mismatches are visible. Ask your compliance lead which plan and strategy documents are the official ones for your system boundary.

What meeting IA-1 costs in staff time, tooling and external review

This table lists the cost components behind IA-1 Policy and procedures, who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so the table shows where effort goes rather than how much it costs, and the main takeaway is that staff time, not software licensing, is the largest and most persistent component.

Cost component	One-time or recurring	What drives it	How to keep it down
Staff time to draft the IA policy and procedures	One-time, then recurring on revision	Number of system types, user populations and authenticator methods the policy must cover	Scope the policy to defined roles and systems, and reuse existing identity standards as source text
Legal, privacy and security approval time	Recurring at each revision	Number of approvers, and whether privacy and risk management documents must be aligned	Set an approval matrix in advance and pre-agree which changes need full review
Document tooling and licenses	Recurring license fees for commercial platforms	Seat counts, editing and version history features, and access controls on the policy library	Self-hosted open-source wikis can remove license spend, though hosting and admin time remain
Distribution and acknowledgment effort	Recurring, tied to each policy version	Number of defined roles that must receive and acknowledge the policy and procedures	Automate distribution and acknowledgment tracking through the document platform or identity workflows
Periodic and event-driven review cycles	Recurring	Defined review frequency, number of triggering events such as audit findings, and procedure dependencies	Track review dates in a shared calendar and link review triggers to the issue tracker
External review by an implementation partner	One-time for gap review, optional recurring support	Written scope, number of systems and documents reviewed, and whether evidence is also prepared	Ask for a fixed-scope written quote that names deliverables and the documents covered
Auditor or assessor sampling effort	Recurring at each assessment cycle	Number of policy versions, review records and interview candidates the assessor selects	Keep dated version history, approval records and review logs ready for sampling

How XWiki and BookStack keep policy versions, approvals and role access

IA-1 asks for a documented identification and authentication policy and procedures that are owned, distributed and reviewed. Two self-hosted open-source wikis can hold those documents and their history, and the cards below explain what each one records and how its permissions can be set. The tools hold the record, but the approval workflow and review schedule are decisions the organization must design and confirm.

XWiki version history for policy pages

XWiki keeps every change to a page under version control, recording what changed, when and by whom. For IA-1, this gives an assessor a trail showing when the identification and authentication policy was first issued and when each review updated it. Users can compare any two versions and roll back to an earlier one, so a change that weakened a password requirement can be traced and reversed. Check that your deployment retains this history under your own backup and retention settings, and confirm the behavior against the current XWiki release in your environment.

XWiki license and self-hosting

XWiki is licensed under LGPL-2.1-or-later, which governs how the software may be used, modified and redistributed. Hosting it inside the organization's own infrastructure keeps the policy repository under its control, including the audit trail and any retained copies of prior versions. Ask whether your legal team needs to review the license terms for your use case. Confirm your hosting, backup and access arrangements in writing before relying on the wiki as the system of record for IA-1 documents.

BookStack roles for policy owners

BookStack determines what each user can do from the roles assigned to them. For IA-1, this lets the organization give edit rights on the identification and authentication policy to the designated policy owner only, while other staff keep view rights. Assign roles according to your documented ownership model, and record who holds each role so the access list can be shown to an assessor. Confirm the role names and default abilities in your current BookStack release before writing your access procedure.

BookStack per-level permission overrides

BookStack allows permissions to be overridden per role at the shelf, book, chapter or page level. An organization can hold the authentication policy in a restricted book, so that only the defined roles can read or edit it, while a general security book stays broader. This matches the need to limit edit rights to the policy owner and read rights to the roles that must follow the procedures. Test the override on a sample page with a non-administrator account to confirm that the effective access matches your written rules.

Approvals and acknowledgments remain organizational

Neither tool, as described here, establishes a formal approval step, a review schedule or a record that each staff member acknowledged the policy. IA-1 expects the organization to define who reviews and approves the policy, how often it is reviewed and after which events, and how acknowledgments are retained. Design these processes in a procedure, and decide whether approvals happen in the wiki, in a ticketing system or in a signed document. Confirm each step with your assessor before relying on it.

Who writes, approves and reviews IA-1: in-house teams, partners and the auditor

Your organization owns IA-1. The identification and authentication policy and its procedures are management decisions about who gets an identity, how users prove who they are and who may change those rules, so the accountable people sit inside the organization even when outside help drafts the text. Start by naming a designated official who is responsible for the policy and procedures and who can be reached by the assessor. Then decide who approves the policy at the level of authority that fits your governance model, and record that approval.

Policy ownership: A named owner keeps the policy current, answers questions about it and tracks open changes.
Designated official: Name the role, not only a person, so coverage survives staff changes.
Approval record: Keep the signed or otherwise recorded approval with its date and version.
Review schedule: Set the review frequency and the events that trigger an early review, such as audit findings or significant system changes, then run those reviews and keep the minutes.
Distribution: Confirm that the defined roles actually receive and acknowledge the policy.

Check that your own staff can explain the policy without the consultant present, because interviews are part of how an assessor tests IA-1.

Where IA-1 policies fail in assessments and how to close each gap

IA-1 is assessed on paper, but assessors also test whether the policy and procedures are owned, distributed, current and consistent with the system they describe. The gaps below recur across assessments, and each one has a specific fix and a specific piece of evidence that shows it is closed.

No named owner or official

A policy that sits in a shared drive with no designated official leaves assessors unable to tell who maintains it or who answers questions about it. IA-1 expects the organization to assign a responsible official for the identification and authentication policy and the procedures that implement it. Check that the owner is named by role and by person, that the appointment is recorded in a management document, and that the owner's contact details are current. Evidence: a signed appointment or role description and the policy's owner field.

Procedures describe a past system

Procedures written for an earlier directory, identity provider or MFA method often name tools and steps that no longer exist. An assessor who follows a procedure step by step and finds it does not match the running system will question the whole policy set. Compare each procedure against the current configuration, including account onboarding, password resets and privileged access. Evidence: a dated walkthrough record showing each step matches the live environment, with changes logged.

No record of distribution

Publishing a policy is not the same as distributing it to the roles that must follow it. Assessors look for evidence that the policy and procedures reached the people with identification and authentication responsibilities, such as help desk staff, system administrators and application owners. Define the distribution list by role and keep a record of who received each version. Evidence: distribution logs, acknowledgment forms or LMS completion records tied to the current version.

Reviews only on a calendar

Many policies are reviewed on a fixed date and nowhere else. IA-1 also expects review and update after defined events, such as audit findings, security incidents, changes to the identity provider or new regulatory requirements. Define the triggering events in the policy itself and record how each one was handled. Evidence: a review log that lists both scheduled and event-driven reviews, with the trigger and the outcome for each.

Versions that cannot be traced

When a policy changes without a traceable approval, assessors cannot confirm which version was in force on a given date. Keep each version under version control with the change author, the date and the approver, and make the approved version the only one users can read. Compare versions before each review to confirm what changed. Evidence: a version history showing each revision, its approval and the effective date, with the superseded copy retained.

Policy out of step with the SSP

A policy that describes different authentication requirements from those in the system security plan creates a finding even when both documents are individually sound. Check that the policy scope, the selected baseline and the authenticator rules match what the SSP states for the system. Where they differ, correct the document that is wrong and record why. Evidence: a traceability table linking each policy statement to its SSP entry, with a reviewer sign-off.

What buyers ask about IA-1 cost, effort, timing and outside help

How much effort does IA-1 take to meet?

IA-1 is a documentation and governance control, so its effort is mostly in writing, agreeing and maintaining the policy and procedures, not in building technology. The work scales with how many systems share the identification and authentication model, how many teams run authentication (identity, cloud, application and network teams), and how mature the existing policy set already is. An organization with a current access control policy and a named identity owner usually has less to draft than one with scattered, undocumented practices. Ask any partner to break the effort into drafting, review and approval, distribution and training, and the first and recurring review cycles, so you can see which parts repeat each year.

Can our own team write IA-1 without outside help?

Yes, an organization can write and own its IA-1 policy and procedures in-house, and NIST places that responsibility on the organization itself. Outside help is most useful when the team lacks someone who can map existing authentication practices into clear procedures, or when the policy must line up with several frameworks at once. An implementation partner can draft the documents, align them with the system security plan and the related controls, and prepare the evidence folder. Only an independent assessor can test the control and issue a report, so the partner's role ends at preparation.

What does the work need from our team?

The work needs a named policy owner with authority over identification and authentication, an approver at a level that can accept the risk, and interviewees who run the authentication processes day to day. Typical participants include security leadership, identity and access administrators, system owners and the personnel who handle account issuance and authenticator management. Ask a partner to list each role, the hours expected from each, and the meetings or review rounds planned, so the operational teams can plan their time before drafting starts.

How long does IA-1 take, and what sets the timeline?

NIST does not set implementation timelines for SP 800-53 controls, and it leaves timing decisions to the agency or program that imposes the requirement, including OMB Circular A-130 for federal systems. The duration of IA-1 depends on how fast decisions are made, how many existing documents must be reconciled, how many systems the policy covers, and whether a contract or assessment deadline applies. Ask for a timeline tied to written milestones and client review dates, and confirm which dependencies (approvals, system inventory, identity provider changes) sit outside the partner's control.

Is IA-1 selected at the privacy baseline too?

No, IA-1 is not selected at the privacy baseline. According to SP 800-53B Release 5.2.0, IA-1 is selected for the low, moderate and high security control baselines, but not for the privacy baseline. If your obligations also cover privacy, confirm with your privacy office which privacy controls apply, since the privacy baseline is a separate selection that applies regardless of impact level. Check the baseline profiles in NIST's OSCAL content before you finalize your control selection, and document the reason for any tailoring.

Can one authentication policy cover other related controls?

Partly. The IA-1 policy can be the anchor for identification and authentication requirements, and NIST relates IA-1 to controls such as AC-1, PM-9, PS-8 and SI-12, and SP 800-53 Release 5.2.0 updated the related controls of every -1 policy control. However, each related control still needs its own policy coverage, procedures and evidence where its assessment procedure asks for them. Ask a partner to produce a traceability table that shows which section of the shared policy answers each related control, and where a separate document is required.

Can a partner issue a compliance certificate for IA-1?

No. A partner can prepare the policy, procedures, roles and evidence for IA-1, but only an independent auditor, assessor or certification body issues a report or certificate. For federal and FedRAMP-style work, the assessor tests the control against the SP 800-53A procedures, and the authorizing official makes the risk decision. Before signing any statement of work, confirm in writing that the partner's deliverables are preparation outputs and that the independent assessment is a separate engagement that you arrange.

How DeployOpen scopes, documents and prepares IA-1 evidence

DeployOpen helps organizations prepare the identification and authentication policy, procedures and supporting evidence that IA-1 asks for, working inside the client's own infrastructure. Engagements are fixed-scope, and the organization keeps ownership of the policy, its approval and every control decision.

How we scope

Confirm which systems fall under the IA family and the impact baseline the organization selected for them.
List the roles that must receive the policy and procedures, and the official who will own them.
Agree in writing the review frequency and the events that trigger an update, before any drafting starts.

How we build

Draft the identification and authentication policy and procedures with the organization's security and compliance leads.
Map existing documents, such as the system security plan and risk management strategy, to the policy statements.
Configure documentation tooling such as XWiki or BookStack with role-based permissions so each document has a clear owner.

How we hand over

Deliver the approved policy, procedures and a revision history showing who changed what and when.
Provide a list of interview participants with identification and authentication responsibilities and a briefing on their roles.
Document the evidence locations and review calendar so an independent assessor can examine the materials directly.

How we support

Offer ongoing support as a retainer for periodic policy reviews and updates after defined triggering events.
Update procedures when SP 800-53 releases or the organization's system boundary changes, as agreed in the written scope.
Keep the organization's assessor-facing evidence current, while the independent auditor or assessor issues any assessment result.