IA-1: Policy and Procedures

To meet the ia-1: policy and procedures requirement, you must publish an Identity and Authentication (IA) policy and supporting procedures, assign ownership, and distribute them to the right internal audiences so the organization can implement IA controls consistently and prove it during assessment. Treat IA-1 as your “control plane” for identity: it defines who does what, when, and what evidence exists.

Key takeaways:

• IA-1 is about documented, disseminated governance for identity and authentication, not a technical configuration.
• Auditors will look for ownership, version control, distribution, and operational procedures that map to implemented controls.
• Your fastest path is a one-page policy + runbook-style procedures + evidence map tied to your system boundary and assessment scope.

IA-1 sits in the NIST SP 800-53 Identity and Authentication family and acts as the foundation for every other IA control you will implement. If your MFA, account lifecycle, and authenticator management are working but you cannot show a current policy, procedures that reflect reality, and proof the documents were issued to the right teams, assessments stall. IA-1 closes that gap by forcing clarity: who owns identity governance, what standards apply, how exceptions work, and what teams must do day to day.

For a CCO, GRC lead, or Compliance Officer, the practical objective is assessment-ready documentation that matches operations. That means: (1) a policy that sets rules and accountability, (2) procedures that engineers and IT can execute without interpretation, and (3) evidence that you distributed and maintain both. IA-1 is also a forcing function for aligning identity practices across internal teams and third parties that touch authentication flows (for example, managed service providers or identity platform administrators).

This page gives requirement-level guidance you can implement quickly, with step-by-step actions, required artifacts, audit questions to prep for, and a pragmatic execution plan. Sources: NIST SP 800-53 Rev. 5 and the NIST SP 800-53 Rev. 5 OSCAL catalog. ¹

Regulatory text

Excerpt (IA-1): “Develop, document, and disseminate to {{ insert: param, ia-1_prm_1 }}:” ²

What the operator must do with that text

• Develop: Create an IA policy and IA procedures that cover how your organization manages identity and authentication for the in-scope system(s).
• Document: Put the policy and procedures under formal document control (owner, version, approval, effective date, review cadence you define).
• Disseminate: Distribute them to the right audiences (the placeholder in the excerpt represents the organization-defined recipients). In practice, this means everyone who designs, administers, approves, or audits identity and authentication, plus any third party admins where contractually possible.
• Make it provable: Keep evidence of publication, distribution, and maintenance. This is where most teams fail IA-1. ²

Plain-English interpretation (what IA-1 really requires)

IA-1 requires you to standardize identity and authentication expectations in writing, then push those expectations to the people who must execute them. The assessor expectation is straightforward: your organization should be able to show consistent decision-making for identity (account provisioning, authentication strength, exceptions) and consistent execution (tickets, approvals, system settings) because the policy and procedures exist, are current, and are known to relevant personnel.

A workable mental model:

• The policy answers “what must be true” (principles, minimum requirements, governance, enforcement).
• The procedures answer “how we do it here” (step-by-step operational runbooks tied to your tools and workflows).

Who it applies to (entity and operational context)

IA-1 applies anywhere you have adopted NIST SP 800-53 controls for a system boundary, including:

• Federal information systems and programs aligning to NIST SP 800-53. ³
• Contractor systems handling federal data, where NIST 800-53 controls are flowed down or used as the control baseline in contracts and security requirements. ³

Operationally, it applies to:

• The in-scope information system(s) in your authorization or assessment boundary (cloud environments, SaaS, on-prem, hybrid).
• Teams who touch identity: IAM engineers, IT service desk, security operations, application owners, HR (joiner/mover/leaver inputs), and GRC/audit.
• Third parties with administrative access or identity integration responsibilities (IdP implementers, MSPs). Treat them as part of your “dissemination” plan even if you can only distribute excerpts or contractually required procedures.

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

Step 1: Define scope and recipients (so “disseminate” is defensible)

1. Write down the system boundary and identity stack in scope (IdP, SSO, MFA, PAM, HRIS feeds, directory services).
2. Identify the recipient groups for IA policy and procedures (example groups below). The requirement leaves this organization-defined, but you must be explicit. ²

Suggested recipient groups (edit to fit your org):

• IAM/Directory Services team
• Security Engineering (auth standards)
• IT Service Desk (account lifecycle execution)
• Application owners (app-level auth settings)
• GRC/Internal Audit (oversight and testing)
• HR operations (authoritative joiner/mover/leaver signals)
• Third party administrators (where applicable)

Step 2: Draft the IA policy (one document, high signal)

Your policy should include, at minimum:

• Purpose & scope: which systems and identities it covers (workforce, privileged, service accounts, API keys if applicable).
• Roles and responsibilities: control owner, system owners, approvers for exceptions.
• Minimum authentication requirements: MFA expectations, password rules if you still use passwords, authenticator types allowed, reauthentication triggers.
• Identity proofing / account issuance principles: how you validate a user is who they claim to be (even if handled by HR or a third party).
• Privileged access requirements: separation, approvals, logging expectations at a policy level.
• Exceptions: who can grant, how long they last, and what compensating controls are required.
• Enforcement & noncompliance handling: what happens if a team cannot meet the policy.

Keep it short. The more detail you put here, the faster it goes stale. Put operational detail in procedures.

Step 3: Write procedures that match real operations (runbook format)

Create procedures that an auditor can trace to tickets, system settings, and logs. Common procedure modules:

• Joiner / mover / leaver workflow: request intake, approvals, provisioning, deprovisioning, validation steps.
• Access request and approval: how requests are submitted, who approves, what must be captured.
• Authenticator management: MFA enrollment/reset, lost device, recovery, re-verification steps.
• Privileged access elevation: just-in-time workflows, break-glass process, emergency access review.
• Service account lifecycle (if applicable): issuance, ownership, rotation, monitoring, decommissioning.
• Periodic access review support: what evidence is produced and by whom.

Write procedures in “if-this-then-that” language. Avoid aspirational statements that your tooling cannot support.

Step 4: Assign ownership, approvals, and review triggers

• Name a control owner for IA-1 (often IAM lead or Security GRC with IAM engineering sign-off).
• Define approvers (CISO, CIO, Security leadership, or delegated authority).
• Set a review cadence you can meet and tie reviews to events: IdP migration, MFA policy change, major incident, acquisition, or new regulated customer requirements. ³

Step 5: Disseminate and prove dissemination

Dissemination fails when it is informal. Use a controlled mechanism:

• Publish in your policy repository (GRC tool, intranet, document management system).
• Distribute via targeted communications to recipient groups (email, ticketing announcement, change management bulletin).
• Require attestation for key operator groups (IAM admins, service desk leads, app owners) where feasible.

Evidence matters more than the email itself. Capture artifacts that demonstrate who received what and when.

Step 6: Map IA-1 to your control stack and recurring evidence

Operationalize IA-1 by mapping:

• IA-1 → control owner → policy doc → procedure docs → recurring evidence (publication record, review record, training/attestation record). A practical approach is to maintain a simple “evidence map” that your team updates as part of normal control operations. Daydream is useful here because it can track the control-to-evidence chain and keep recurring requests from becoming ad hoc scrambles, especially across multiple systems and third parties.

Required evidence and artifacts to retain

Maintain these artifacts in an assessor-friendly folder structure (by system boundary):

1. IA Policy (PDF or controlled doc export) with version, owner, approval, effective date. ²
2. IA Procedures (runbooks/SOPs) referenced by the policy and aligned to actual tools.
3. Approval records (GRC approval workflow, e-signature, or meeting minutes showing formal adoption).
4. Dissemination evidence:
   • distribution list or recipient groups,
   • announcement artifacts,
   • attestations or training completion for operator roles (if used).
5. Review and change history:
   • revision log,
   • periodic review evidence,
   • triggers tied to major identity changes (tickets/CHG records).
6. Control mapping: an internal mapping showing how IA-1 supports other IA controls and where procedures live.

Common exam/audit questions and hangups

Assessors commonly press on these points:

• “Who exactly received the policy and procedures?” Have a defined recipient list and evidence of distribution. ²
• “Do procedures match reality?” If your SOP says approvals happen in a tool you no longer use, you fail on credibility.
• “Where is the exception process?” Many teams have exceptions in practice but not in writing, or exceptions with no expiry.
• “Show me the last review.” If you cannot show a review record, the control looks abandoned.
• “Who owns IA-1?” Shared ownership with no clear accountable owner creates audit drift.

Frequent implementation mistakes (and how to avoid them)

Mistake	What it looks like in an audit	Fix
Policy is too broad	Reads like generic security policy; no system scope	Add system applicability statements and identity scope boundaries
Procedures are aspirational	Steps don’t match tickets or tool capabilities	Rewrite procedures from actual workflows, then improve workflows later
No dissemination proof	“It’s on SharePoint” with no targeted distribution	Track announcements, recipient groups, and operator attestations
Ownership is unclear	Multiple teams claim partial control	Assign one accountable owner; list supporting roles
Docs aren’t maintained	Old versions conflict with current MFA/SSO setup	Add review triggers tied to identity changes and incidents

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Operational risk still matters: weak IA documentation creates inconsistent access decisions, slow incident response (unclear break-glass rules), and assessment findings that can block authorizations or customer security reviews. The primary IA-1 risk factor to manage is missing implementation evidence. ²

Practical 30/60/90-day execution plan

Use phases to avoid fake precision and keep momentum.

Immediate (stabilize and scope)

• Confirm the in-scope systems and identity components.
• Assign IA-1 owner and approvers.
• Inventory existing identity docs and find gaps (policy missing, SOPs outdated, no review trail).
• Define dissemination recipients and the mechanism you will use (policy portal + targeted announcements).

Near-term (publish and operationalize)

• Draft and approve the IA policy (short, enforceable).
• Write procedures for the highest-risk workflows first: privileged access and joiner/mover/leaver.
• Build the evidence map: what you will retain every cycle and where it lives.
• Perform the first dissemination push and collect proof.

Ongoing (make it repeatable)

• Tie doc review to identity change management (IdP config changes, MFA rollouts, directory migrations).
• Run a lightweight quarterly control check (sample tickets + confirm procedures still match operations).
• Use Daydream or your GRC system to track owners, evidence due dates, and auditor-ready exports.

Frequently Asked Questions

Who should be listed as the “dissemination” recipients for IA-1?

List the roles that design, approve, administer, or audit identity and authentication for the in-scope systems. Include third parties with admin responsibility where contractually feasible, or distribute relevant excerpts and require acknowledgment.

Can IA-1 be satisfied with one policy document and no procedures?

IA-1 explicitly calls for policy and procedures. In practice, audits fail when procedures are missing because teams cannot prove repeatable execution, even if the technology is configured correctly. ²

How technical should the procedures be?

Make them executable. Reference your actual tools (IdP, ticketing system, PAM), include required approvals and evidence outputs, and avoid copying generic language that doesn’t match how work is done.

We have an enterprise security policy. Do we still need an IA-specific policy?

If the enterprise policy clearly governs identity and authentication requirements for the assessed system boundary and is paired with IA procedures, it may be sufficient. Most teams still publish an IA addendum to remove ambiguity and reduce assessment friction.

What evidence is the most common missing piece for IA-1?

Dissemination and maintenance records. Teams often have a document but cannot show who received it, who approved it, or when it was last reviewed. ²

How does IA-1 relate to other identity controls in NIST 800-53?

IA-1 is the governance layer that tells operators how to implement and sustain the rest of the IA family. Your procedures should cross-reference related IA controls so assessors can trace policy intent to technical and operational implementation. ³

Footnotes

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

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

3. NIST SP 800-53 Rev. 5