AU-1: Policy and Procedures

AU-1 requires you to create, document, and share an audit and accountability (AU) policy and supporting procedures with the right stakeholders, then keep them current and provably in use. To operationalize it fast, assign an owner, publish a short AU policy plus runbooks for key AU controls, and build an evidence trail that shows staff received, followed, and reviewed them. ¹

Key takeaways:

• AU-1 is a documentation-and-dissemination control: policy + procedures + proof they were shared and maintained. ²
• Treat AU-1 as the “control plane” for the AU family: it should point to specific implementations, owners, and recurring evidence. ¹
• The fastest path to audit readiness is a mapped package: AU policy, AU procedures/runbooks, dissemination records, and a review log tied to system scope. ¹

AU-1: Policy and Procedures is the control that auditors use to check whether your audit logging program is governed, repeatable, and assessable. Most teams think of AU as “turn on logs.” AU-1 is the part that makes logging defensible: written expectations, documented steps, and distribution to the people who must follow them. Without AU-1, even strong technical logging can fail an assessment because you cannot show who is responsible, what “good” looks like, or how the organization ensures consistency across systems.

For a Compliance Officer, CCO, or GRC lead, AU-1 is also a practical forcing function. It pushes you to set boundaries (which systems are in scope), roles (who reviews logs and who maintains tooling), and operational cadence (how you keep policies and procedures current). If you build AU-1 well, you can reuse its structure to accelerate the rest of the AU control family by turning requirements into owner-mapped procedures and recurring evidence artifacts. ¹

Regulatory text

Requirement excerpt (as provided): “Develop, document, and disseminate to {{ insert: param, au-1_prm_1 }}:” ²

Operator interpretation of the excerpt: AU-1 expects you to (1) develop your AU policy and AU procedures, (2) document them in a form that is reviewable and version-controlled, and (3) disseminate them to the defined audience (typically the personnel and roles responsible for implementing, operating, and overseeing audit logging). Your implementation must be specific enough that an assessor can trace from written policy → procedure/runbook → technical implementation → recurring evidence. ¹

Plain-English interpretation (what AU-1 is really asking)

AU-1 is asking: “Do you have written rules for audit logging, written instructions for how to carry them out, and proof that the right people received and follow them?”

That means:

• A policy statement that sets organizational intent and minimum expectations for audit logging and audit record handling.
• Procedures that translate policy into operational steps (configuration, monitoring, review, escalation, retention, and exceptions).
• A dissemination mechanism (publishing location, targeted distribution, training attestation, or ticketed acknowledgment) tied to roles.
• A maintenance loop that keeps documents current as systems, tools, and responsibilities change. ¹

Who it applies to (entity and operational context)

AU-1 applies broadly anywhere NIST SP 800-53 is required or adopted, including:

• Federal information systems and the programs that govern them. ¹
• Contractor systems handling federal data, where NIST controls are flowed down contractually or used as the security control baseline. ¹

Operationally, AU-1 touches multiple teams:

• Security engineering / platform: logging infrastructure, agents, forwarders, SIEM, storage.
• IT operations / cloud operations: system configurations and access.
• Incident response: using logs as evidence and triggers.
• Compliance / GRC: documenting, mapping, reviewing, and demonstrating control operation.

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

1) Define scope and control ownership

• Identify the system boundary or boundaries where AU controls apply (systems that process, store, or transmit covered data).
• Assign an AU policy owner (often the CISO org) and procedure owners for key operational pieces (SIEM owner, platform logging owner, incident response owner).
• Document RACI at least to the level of: “who writes,” “who approves,” “who operates,” “who reviews.”
  Deliverable: AU-1 ownership and scope statement referenced from the policy package.

2) Draft and approve an AU policy (short, enforceable, testable)

Keep policy tight. It should read like enforceable requirements, not a narrative. Include:

• Purpose and scope (systems, environments, and major platforms).
• Roles and responsibilities (who collects, who reviews, who investigates, who administers).
• Minimum audit event categories (high-level) and requirement to enable audit logging for covered systems.
• Protection of audit records (integrity and access controls at the policy level).
• Retention and availability requirements (state the organization’s retention standard; if it varies by system, require system-specific standards in procedures).
• Exceptions process (who can approve deviations and how they are documented).
  Deliverable: Versioned “Audit and Accountability Policy” approved by the right authority.

3) Write AU procedures/runbooks that map to real operations

Procedures must be executable. Build them as runbooks aligned to how work happens:

• Logging onboarding procedure: steps to ensure new systems forward logs, apply standard parsing, and tag to ownership.
• Logging configuration baseline procedure: configuration management approach and change control for logging settings.
• Log review procedure: who reviews which alerts/log sources, how findings are recorded, and how escalations occur.
• Audit record access procedure: who can access raw logs, approval path, and periodic access review tie-in.
• Incident evidence handling procedure: how logs are preserved for investigations and legal holds if applicable.
• Exception procedure: how to request/approve temporary disablement or reduced logging, with compensating controls.
  Deliverable: Procedure set that points to tooling (SIEM, cloud-native logging, ticketing) and produces repeatable evidence.

Practical tip: each procedure should end with “Evidence produced,” listing exactly what artifacts the operator must generate (ticket numbers, reports, screenshots, export files, or system logs).

4) Disseminate to the right audience and record it

AU-1 is explicit about dissemination. Build a dissemination method you can prove:

• Publish policy and procedures in a controlled repository (GRC system, policy portal, or version-controlled documentation system).
• Send targeted distribution to required roles (security operations, system administrators, service owners).
• Collect acknowledgment (training completion, e-sign, or ticketed acknowledgment) and store it centrally.
  Deliverable: Dissemination records tied to document version.

5) Map AU-1 to control implementation and recurring evidence

This is the fastest way to make AU-1 audit-friendly:

• Create a control mapping entry that links AU-1 → policy document → procedures → tool configurations → evidence cadence.
• Define recurring evidence artifacts (examples: log review tickets, SIEM alert triage records, access review outputs).
• Assign each evidence item an owner and a storage location. ¹

Daydream fit (earned, not decorative): if you manage many systems or third parties that must follow your AU rules, Daydream can track AU-1 ownership, tie procedures to systems, and standardize recurring evidence requests so you are not rebuilding the same audit package each assessment cycle.

Required evidence and artifacts to retain

Use an “AU-1 evidence bundle” approach. Minimum artifacts:

• AU policy (version-controlled, approved, effective date).
• AU procedures/runbooks (version-controlled, approved or formally accepted).
• Scope statement: in-scope systems/services and owners.
• Dissemination proof: distribution list, acknowledgment records, training logs, or attestation tickets.
• Review/maintenance record: change log, periodic review sign-off, and rationale for material changes.
• Control mapping: AU-1 mapped to implementing controls and evidence artifacts (who, what, where). ²

Common exam/audit questions and hangups

Assessors tend to ask AU-1 questions that expose gaps between documents and reality:

• “Show me the AU policy and the procedures that implement it. Who approved them?”
• “Who received this policy? How do you know the right roles got it?”
• “Point to the procedure your admins follow to onboard a new system into logging.”
• “Show evidence that log review happens as described.”
• “How do you handle exceptions when a system can’t log required events?”
• “How do you keep these documents current after tool changes or reorgs?” ¹

Hangup to plan for: teams often have a policy, but procedures live as tribal knowledge in chat messages or personal notebooks. AU-1 expects controlled documentation and dissemination, not “ask Bob.”

Frequent implementation mistakes (and how to avoid them)

1. Policy without executable procedures.
   Fix: require each policy section to reference a procedure or standard operating step.

2. Procedures that don’t name tools, owners, or outputs.
   Fix: add “Owner,” “Systems covered,” “Steps,” and “Evidence produced” to every runbook.

3. Dissemination that can’t be proven.
   Fix: use a mechanism that generates durable records (policy portal acknowledgment, LMS completion, or ticket-based attestation).

4. Scope mismatch.
   Fix: explicitly state what systems are in scope and how new systems are added; reconcile with your asset inventory process.

5. No maintenance loop.
   Fix: tie AU document updates to change management triggers (SIEM migration, cloud logging changes, org role changes). ¹

Enforcement context and risk implications

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

Operational risk is still real: weak AU-1 documentation commonly leads to inconsistent logging, gaps in detection and investigation, and assessment findings that delay authorizations or contract outcomes in federal contexts. AU-1 is also a dependency control: if your policy and procedures are unclear, downstream AU controls become harder to defend during testing. ¹

Practical execution plan (30/60/90)

First 30 days (stabilize and publish)

• Assign AU-1 owner and procedure owners; document RACI.
• Confirm in-scope systems and logging platforms.
• Publish AU policy v1 and the minimum set of runbooks (onboarding, review, access).
• Stand up dissemination and acknowledgment tracking for the initial audience.

By 60 days (make it testable)

• Add evidence outputs to each procedure and validate you can collect them from real operations.
• Run a tabletop walk-through: take one in-scope system from “new” to “logging onboarded” using your procedure, and retain the artifacts.
• Create AU-1 control mapping that links documents to implementations and evidence.

By 90 days (make it sustainable)

• Integrate AU doc updates with change management triggers.
• Formalize exception handling and ensure exceptions generate time-bounded approvals and compensating controls.
• Do an internal control test: sample a few systems, verify procedures were followed, and record results as assessment-ready evidence. ¹

Frequently Asked Questions

What does “disseminate” mean for AU-1 in practice?

It means you must share the AU policy and procedures with the roles responsible for implementing and overseeing audit logging, and keep proof of that distribution. A wiki link alone is weak unless you can prove required personnel were directed to it and acknowledged it. ¹

Can AU-1 be satisfied with one document?

You can combine policy and procedures into one controlled document, but it still needs two layers: high-level requirements (policy) and step-by-step instructions (procedures). Auditors will still expect to see both elements clearly separated and maintained. ¹

Who should approve the AU policy?

Approval should come from the authority that owns security policy governance in your organization (often the CISO org) and align with your internal policy framework. What matters is that approval is documented and matches how other security policies are governed. ¹

What evidence is most persuasive for AU-1?

A version-controlled policy and procedure set, plus a clear dissemination record (acknowledgments or training completion) tied to roles. Pair that with a small sample of operational artifacts produced by the procedures. ¹

How do we handle third-party managed logging (MSSP/SIEM provider)?

Keep your AU policy internal, then add procedures that describe your oversight: what the third party does, what you review, and what evidence the third party must provide. Make dissemination include the internal service owners who manage the third party relationship. ¹

What’s the quickest way to fail AU-1 during an assessment?

Having a policy that says logs are reviewed, with no procedure that defines who reviews what, and no retained proof that reviews happened. Assessors treat that as a documentation and operation gap. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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