AU-1: Policy and Procedures

Quick-reference card

What this control requires

AU-01 requires organizations to develop, document, and disseminate policies and procedures governing the entire audit and accountability (AU) control family. That means defining why audit and accountability matters to the organization, who’s responsible for it, and how the rest of the AU controls will be implemented in practice.

In practice, that means the policy must address purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. It also needs to align with applicable laws, executive orders, directives, regulations, and standards. Alongside the policy, organizations must produce procedures that describe how each AU family control is carried out at the operational level.

Specifically, an official must be designated to own the development, documentation, and dissemination of both the policy and its supporting procedures. That designated official is also accountable for reviewing and updating these documents at organization-defined frequencies and in response to specific triggering events, such as audit findings, security incidents, or changes in regulatory requirements.

Why it matters

Most organizations treat AU-01 as a documentation checkbox, drafting a policy once and filing it away. That approach creates a gap between what the policy states and how the organization actually handles logging, monitoring, and audit trail management. When that gap surfaces during an assessment, it undermines the credibility of the entire AU control family.

Failure to maintain this control introduces audit risk and may result in certification withdrawal, regulatory findings, or failed authorization-to-operate (ATO) decisions. Because AU-01 sits at the foundation of every other audit and accountability control, assessors treat it as a bellwether for organizational maturity. A stale or incomplete policy signals that downstream controls like log management, session auditing, and event correlation likely lack governance too.

Without documented procedures, security teams operate on institutional knowledge rather than repeatable processes. That makes personnel transitions, incident response, and cross-team coordination unreliable. Organizations preparing for cybersecurity audits should recognize that assessors will look for evidence that policies and procedures are living documents, not artifacts produced solely for the audit.

What weak AU-01 governance exposes

• Audit findings triggered by policies that restate NIST control language verbatim instead of reflecting organizational context and risk appetite
• Certification withdrawal or failed ATO decisions when review dates are missing or outdated, with no evidence the policy was revisited after triggering events
• Regulatory scrutiny when no designated official is accountable for policy development, documentation, and dissemination
• Downstream AU control failures when procedures describe what controls exist but not how they’re implemented
• Compliance gaps when the policy doesn’t align with applicable laws, regulations, or organizational directives

How to implement

For your organization

The most common implementation challenge with AU-01 isn’t writing the initial policy. It’s keeping the policy aligned with how audit and accountability actually works across the organization. Teams draft a policy during their first compliance cycle, then treat it as finished. Over time, the technology stack evolves, regulatory requirements shift, and the policy quietly becomes fiction.

In practice, the most effective starting point is mapping the scope of your audit and accountability program to the controls in the NIST SP 800-53 AU family. The policy should describe why these controls matter to your organization specifically, not just restate what the standard requires. Reference your risk management strategy, because that strategy should directly inform the thresholds, frequencies, and roles your AU policy establishes.

Where most organizations fall short is ownership. Designate a specific individual, not a team or role title, as the official accountable for the policy lifecycle. That person owns development, documentation, dissemination, and review. They don’t need to write every procedure themselves, but they need authority to enforce review timelines and update cycles.

Specifically, procedures must go beyond describing what controls exist. They need to specify how each AU control is implemented, who executes each step, what tools are used, and how exceptions are handled. For organizations building or maturing their compliance monitoring programs, linking procedures to specific AU controls creates traceability that assessors value.

The result is that review triggers need to be defined explicitly. At minimum, include post-assessment findings, security incidents affecting audit infrastructure, changes to applicable laws or regulations, and major system architecture changes. Avoid vague language like “as needed,” which assessors will challenge.

Common mistakes:

• Writing a standalone AU policy disconnected from the broader security and privacy policy framework
• Assigning policy ownership to a committee rather than a named individual
• Treating the policy review cycle as calendar-based only, ignoring event-driven triggers
• Producing procedures that describe outcomes without specifying operational steps

For your vendors

When evaluating a vendor’s compliance with AU-01, the challenge shifts from writing policy to verifying that one exists and functions as described. You can’t audit a vendor’s internal documentation the same way you audit your own, so the focus becomes evidence collection and consistency checks.

In practice, the first step is requesting the vendor’s audit and accountability policy and procedures as part of your third-party risk assessment. Review whether the policy addresses the required elements: purpose, scope, roles, management commitment, coordination, and compliance with applicable regulations. A policy that reads like a generic template, with no reference to the vendor’s specific operating environment, is a red flag.

Beyond the policy document, ask for evidence of the designated official responsible for its lifecycle. This is a specific NIST requirement, and vendors who can’t identify that person likely haven’t formalized their governance structure. Look for documented review history showing that the policy and procedures have been updated in response to defined triggers, not just on an annual calendar cycle.

Where inconsistencies often surface is in the relationship between documents. Cross-reference the vendor’s policy against their system security plan and privacy plan. These documents should be consistent. If the system security plan references logging and audit capabilities that the AU policy doesn’t address, the vendor may have a documentation gap that extends to operational controls. Organizations managing vendor ecosystems at scale can use UpGuard Vendor Risk to streamline evidence collection and identify inconsistencies across their third-party portfolio.

Common mistakes:

• Accepting a vendor’s AU policy at face value without checking for organization-specific context
• Failing to verify that a designated official is named and accountable
• Not requesting evidence of event-driven policy reviews, such as updates following audit findings or regulatory changes
• Overlooking inconsistencies between the vendor’s policy, procedures, and system security plan

Evidence examples

Cross-framework mapping

Related controls

• PM-09 — Risk Management Strategy: Directly informs the risk-based foundation of audit and accountability policy. The risk management strategy shapes thresholds, roles, and review triggers within AU-01.
• PS-08 — Personnel Sanctions: Supports enforcement of audit and accountability requirements. Personnel sanctions provide the consequence framework when individuals violate AU policies or procedures.
• SI-12 — Information Management and Retention: Governs how audit records and related documentation are retained and disposed of. Retention policies for audit data must align with the governance established in AU-01.
• AU-02 — Event Logging: Defines which events the system must log. AU-01 establishes the governance framework that determines how event logging requirements are scoped and maintained.
• AU-06 — Audit Record Review, Analysis, and Reporting: Specifies how audit records are reviewed and analyzed. The procedures established under AU-01 should describe the cadence and responsibilities for audit record review.

Frequently asked questions

What is NIST SP 800-53 AU-01

AU-01 requires organizations to create, maintain, and regularly update the policies and procedures that govern audit and accountability controls. It sits at the governance layer of the NIST SP 800-53 framework, establishing the foundation for every other control in the AU family. The policy must cover purpose, scope, roles, responsibilities, management commitment, coordination across entities, and alignment with applicable laws. A designated official must be named to own the full lifecycle of these documents.

What happens if AU-01 is not implemented

Organizations without a documented audit and accountability policy face audit findings, failed authorization-to-operate decisions, and potential regulatory action. Assessors treat AU-01 as a governance prerequisite for the entire AU family. Without it, there’s no documented basis for how logging, monitoring, event correlation, or audit trail management should function. That gap cascades downstream, because controls like AU-02 (Event Logging), AU-06 (Audit Record Review), and AU-12 (Audit Record Generation) all depend on the governance framework AU-01 establishes.

How do you audit AU-01

Auditors verify that the audit and accountability policy and procedures exist, address all required elements, and show evidence of active management. Assessors check whether the policy covers purpose, scope, roles, responsibilities, management commitment, coordination, and compliance with applicable laws. They confirm that a designated official is named, that review records show updates at defined frequencies and in response to triggering events, and that both documents have been disseminated to relevant personnel.

How often should audit and accountability policies be reviewed

Organizations should review audit and accountability policies at least annually, but calendar-based reviews alone aren’t sufficient. NIST SP 800-53 requires reviews at organization-defined frequencies and following organization-defined events. Common triggers include post-assessment findings, security incidents that affect audit infrastructure, changes to applicable laws or regulations, significant system architecture changes, and changes to the organization’s risk management strategy. Defining these triggers explicitly in the policy itself helps organizations avoid the “as needed” ambiguity that assessors routinely challenge during ongoing compliance oversight assessments.