AU-1 Policy and procedures: requirements and evidence

What AU-1 policy and procedures require before any logging control is assessed

When an assessor or a contract asks for AU-1, the team usually has logs but no current written policy. AU-1 asks for a documented audit and accountability policy and the procedures that implement it, distributed to defined roles, managed by a designated official, and reviewed and updated at a defined frequency and after defined events. The control is about the rules and the people behind logging, so an assessor will check the paper before checking the log pipeline. Start by confirming who the designated official is, which roles receive the policy, and what review frequency and triggering events the organization has actually defined, because those values are the parts an assessor tests first.

AU-1 is the first control in the audit and accountability family, and it anchors the rest. Controls such as AU-2 on event selection, AU-6 on review and AU-9 on protection of audit information all depend on the policy naming what is logged, who reviews it and how it is protected. Release 5.2.0 lists no control enhancements for AU-1, so the work is one control with a fixed set of determination statements, which SP 800-53A assesses through examine and interview methods. The 2025 release also updated the related controls of every -1 policy control, so confirm that your policy cross-references the current versions of the controls it governs. The NIST CPRT entry for AU-01 is the natural next read for the exact wording of the control.

Three problems make AU-1 hard in practice. The first is a document that describes an ideal process that nobody follows, which fails as soon as an assessor compares it with log review tickets or retention settings. The second is unclear ownership, where the policy names a team but no single official who approves changes. The third is the absence of a review record, meaning no dated approval, no change history and no evidence that the policy was revisited after an incident or a significant system change. Assign the designated official, align the policy with what the logging platform does today, and keep versions under change control so the review history can be shown. A self-hosted wiki with version history, such as XWiki, can hold these records inside your own infrastructure, though you should confirm that its retention and access settings meet your own requirements.

Which systems, teams and third parties the AU-1 policy must cover

AU-1 is only as good as its scope. The policy and procedures must name the systems, people and outside parties that generate, move or hold audit data, and that scope follows the baseline the system is authorized under. AU-1 is selected for the low, moderate and high baselines and the privacy baseline, so the same policy text may need different reach for each system.

Systems inside the authorization boundary

Every component inside the authorization boundary that generates or stores audit records falls under the policy, including operating systems, databases, applications, network devices and security tools. Start from the system security and privacy plan and check that each component named there has a logging owner. Systems outside the boundary that feed logs into it, such as identity providers or cloud control planes, also need to be named, because their records are part of the evidence chain. Confirm the boundary with the authorizing official before writing scope into the policy.

Platform engineering teams

Platform teams usually decide which logging agents run, where records are sent and how long hosts keep local copies. Their decisions shape what AU-2 and AU-12 can claim, so the policy should assign them responsibility for configuring generation and forwarding. Ask who approves changes to logging configuration and whether those changes flow through the same change control as other system settings. A policy that names the platform team without naming its duties leaves the procedures unowned.

Security operations and review roles

Security operations staff read, correlate and act on audit records, so they are the roles most often named in review and failure-response procedures. The policy should list who reviews records, who receives alerts about logging failures and who can change review frequency after a risk change. Check that these roles have documented backups, since a review procedure that depends on one person fails during absence. Record the named roles in the procedures, not only in the policy text.

Application owners and developers

Application owners decide which business events their software records and whether those records contain the content AU-3 requires. Their code often produces the only record of a transaction or approval, so the policy should require them to document event coverage for each application. Developers also need to know which fields must not appear in records because of privacy requirements. Ask for a list of applications in scope and the logging owner for each one.

Third parties that generate or hold audit data

Managed service providers, cloud providers, SaaS vendors and hosting partners may generate or hold audit data on the organization's behalf. The policy should state which third parties hold which records, how the organization obtains them and who is responsible for retention and protection at each provider. Contracts should give the organization access to records when needed for investigation. Confirm these terms in writing with each provider, because the organization remains accountable for the control even when a third party runs the logging.

Baseline-driven scope differences

The low, moderate and high baselines and the privacy baseline each select AU-1, so every system needs the policy applied at its own impact level. A high-impact system may need stricter review and alerting procedures than a low-impact one, while the policy text stays common. The privacy baseline adds a separate reach for systems that process PII. Check each system's baseline in SP 800-53B and record it next to the scope entry, so assessors can see the link between scope and control selection.

How an assessor tests AU-1 against 17 determination statements

This table compares the three things an assessor examines and interviews for AU-1, the evidence each one produces and the findings that most often appear. Read each row as a test step: the approach says what the assessor does, the evidence column says what to have ready, and the findings column shows where audit programs usually fall short.

Test approach	Evidence requested	Common findings
Examine the audit and accountability policy	Current signed policy with owner, scope, purpose, roles, coordination among entities and a stated review date	Policy names no owner, has no review date, or describes logging duties that no system actually meets
Examine the audit and accountability procedures	Step-by-step procedures for enabling logging, reviewing records, handling failures and retaining logs, each tied to the policy	Procedures are generic templates that do not name the tools, log sources or teams used in practice
Examine the system security plan and privacy plan	Plan sections that reference AU controls, the logging scope and the responsible roles for each AU control	Plan says logging is in place but does not identify the components, event types or owners
Interview personnel with audit and accountability responsibilities	Named roles, role descriptions and records showing who received the policy and procedures	Staff interviewed cannot describe the policy, or the people named as owners have changed without an update
Confirm policy distribution to defined roles	Distribution list, acknowledgment records or access logs for the document repository	Policy not distributed to the named roles, or distributed only to the security team
Confirm periodic and event-driven review	Review history with dates, reviewer names, change records and the triggers defined in the policy	No evidence of periodic review, or review dates that are missed without explanation
Compare procedures with the logging configuration	Configuration exports, log source inventory and screenshots or exports showing what the procedures say is logged	Procedures describe logging that the system does not perform, or configuration changes were never reflected in procedures

Writing, approving and maintaining the audit policy in sequence

This sequence turns AU-1 into a policy set that names an accountable owner, reflects the organization's own audit requirements, connects to the security and privacy plans, reaches the people who run logging, and is reviewed on a schedule the organization has defined. Each step ends with a record an assessor can examine.

Name the designated official
Start by naming the official who owns the audit and accountability policy and procedures. This is usually a senior security or compliance role with authority to approve changes and to direct the teams that run logging. Record the appointment in a signed memo or role description that states the official's responsibilities for the policy. The output is that appointment record, which the assessor will check against the policy's ownership statement. Confirm the role with your own governance documents, since the control leaves the choice of role to the organization.
Define the parameters the policy must set
Before drafting, decide the values the control leaves to the organization: the roles that receive the policy, the review frequency, and the events that trigger an out-of-cycle review. Write these as named parameters so each one can be traced to a decision. Your system owners, legal team and compliance lead should agree on them. The output is a short parameter register that the assessor can compare against the approved policy. Do not copy values from another organization without testing them against your own risk and regulatory obligations.
Draft the policy and procedures from the AU family
Draft the policy statement, covering purpose, scope, roles, and management commitment, then write procedures that describe how the organization implements each audit and accountability control in the AU family for its systems. Keep the policy at the level of intent and the procedures at the level of steps, owners and records. Use the control IDs and titles from the SP 800-53 catalog and the baseline your systems are assigned in SP 800-53B. The output is a draft policy and a procedure set that map each AU control to an owner. Your reviewers should confirm that no AU control is left without a procedure.
Tie the policy to the security and privacy plans
Link the policy and procedures to the system security and privacy plans for each in-scope system. Each plan should cite the procedures that implement its audit controls and state how the system's logging meets them. Where a plan describes logging that the policy does not cover, or the policy requires logging that a plan omits, resolve the gap before approval. The output is a cross-reference table showing which plan sections cite which procedures. An assessor will test this alignment by comparing the policy with the plans and the system configuration.
Approve the policy with version and owner
Route the draft through the review and approval path the organization has defined, which typically includes the designated official and any governance body that signs off on security policy. Record the approval in the document itself: the version number, the owner, the approval date, and the approver. Keep the approved version under version control so each earlier draft and each change can be recovered. The output is an approved policy with a visible version and owner that the assessor can match to the approval record.
Distribute the policy and collect acknowledgments
Distribute the approved policy and procedures to the roles named in the parameter register, such as system administrators, security operations staff and system owners. Use the access model of your document platform so that each role can read the material it needs. Ask each recipient to acknowledge receipt and understanding. Track acknowledgments in a register and follow up on any that are missing. The output is a distribution record listing each role, the version delivered, the date and the acknowledgment status. The assessor will check that the recipients match the roles the policy itself names.
Run the first review and log the outcome
Run the first review at the frequency set in the parameter register and record the outcome in a dated review log. The review should confirm that the policy still matches the systems in scope, the plans that cite it, and any changes to the AU family in the current SP 800-53 release. Record whether the policy was confirmed unchanged or revised, and if revised, issue a new version and repeat distribution. The output is a dated review log entry with the reviewer, the findings and the decision. Assessors look for evidence that reviews happened on schedule and that triggered reviews occurred when the defined events took place.

Which documents pass AU-1 and how to keep them current between audits

An assessor testing AU-1 Policy and procedures looks for a chain of documents: a policy, the procedures that implement it, proof that the right people received them, and a record that someone reviewed them on schedule. The cards below cover each artifact and the routine that keeps it accurate between assessments, so the evidence still matches the system when the assessor arrives.

The approved audit and accountability policy

This is the top-level document that states the purpose, scope, roles, and commitments for audit and accountability, and it must name the defined organizational and system scope it covers. Confirm it carries an owner, an approval date, an approver with authority over the program, and a version number. Check that the policy still names the systems and log sources that exist today, since a policy that describes a decommissioned logging platform fails on its face. Tie each revision to a change in scope, architecture, or regulation, and keep prior versions so the assessor can see what was in force on a given date.

Implementing audit procedures

Procedures turn the policy into steps: how log sources are onboarded, how audit settings are configured, who reviews logs and how often, how failures are escalated, and how retention is applied. Write each procedure so an engineer on call can follow it without asking the author. Confirm every procedure names a responsible role rather than a person who may have left. Review procedures against the actual configuration of your logging platform, because assessors often compare the written steps with exported settings and find gaps.

Distribution and acknowledgment records

AU-1 expects the policy and procedures to reach defined roles, so keep a distribution list tied to those roles, not to individual names. Record when each version was published, where it was posted, and who acknowledged it, using an access-controlled wiki or document system that logs views and changes. When someone changes role, update the distribution list the same day and confirm the new holder has the current version. Assessors frequently ask for acknowledgments from the people who actually operate the logging tools, so check that those names appear.

Review and update history

Keep a dated log of every review and update, showing who reviewed the document, what changed, what triggered the review, and who approved the result. Set a defined review frequency in the policy and also list the events that force an earlier review, such as a major platform migration, a new log source, an incident that exposed a gap, or a change to a related control. Version control in a wiki platform helps here, because it records what changed, when and by whom, and lets you compare or restore earlier versions.

System security plan references

The system security plan should point to the audit and accountability policy and to the procedures that implement each AU control for that system. Check that the references are current, that the SSP names the same log sources and retention periods as the procedures, and that any inherited or common control statements match what the organization actually runs. A mismatch between the SSP and the procedures is one of the quickest findings an assessor can raise, so reconcile them at every SSP update.

Designated official appointment

AU-1 requires a named official who manages the policy, so keep a signed appointment record that states the person's role, responsibilities, and start date. Document a backup or successor for absences and role changes, and update the appointment record when the holder changes. Confirm the official has the authority and time to approve revisions, because an appointment without that authority will not satisfy an assessor asking who owns the decisions. Store the appointment with the policy so both are retrieved together.

Using XWiki and BookStack to version and control AU-1 documents

AU-1 is satisfied by an organization's governance of its audit and accountability policy and procedures, not by a tool. XWiki and BookStack are two open-source options for holding those documents, and the cards below describe what each one can contribute to ownership, distribution and review evidence.

Version history as change evidence

XWiki keeps every change to a page under version control and records what changed, when and by whom. For AU-1, this gives an assessor a trail showing when the audit and accountability policy was last updated and who made each change. Confirm with your own environment how the history will be exported or printed for the assessor, and whether earlier versions remain retrievable after a review cycle closes.

Comparing and rolling back versions

XWiki lets users compare any two versions and roll back to an earlier one. This matters when a review finds that an edit weakened the logging procedure or removed a defined review frequency. Record the approver for each approved version alongside the wiki history, because the wiki shows who edited a page but does not by itself show who authorized the change.

Role-based ownership in BookStack

BookStack derives each user's abilities from assigned roles. A policy owner role can be given edit rights over the audit and accountability shelf, while reviewers and general staff receive read-only access. Map these roles to the personnel named in your AU-1 policy so that the documented owner and the system permissions match.

Per-object permission overrides

BookStack permissions can be overridden per role at the shelf, book, chapter or page level. Use this to restrict an operational procedure, such as log review steps, to the staff who perform it while leaving the policy readable across the organization. Test the effective permissions for a sample user, because overrides at lower levels can make a page visible or hidden in ways that differ from the shelf-level intent.

Single controlled location

Keeping the AU-1 policy and procedures in one wiki or one BookStack instance makes distribution and version history easier to defend. Confirm whether your organization already stores the policy elsewhere, such as in a document management system or the system security plan, and decide which copy is authoritative. Duplicate copies that drift apart are a common finding during assessment.

Limits of a documentation platform

Neither tool generates audit logs, reviews log data or proves that logging operates as the policy describes. Those activities are evidenced by the logging platform and by review records kept elsewhere. Treat XWiki and BookStack as the place where the policy lives and changes are recorded, and confirm with your assessor which additional records they expect to see.

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

This table compares the main cost components of writing, distributing and reviewing the audit and accountability policy and procedures behind AU-1, and whether each is paid once or repeats. Read it as a checklist for a quote: no figures are given because none are supported by NIST or a researched source, so each row names what drives effort and what to ask your provider to price. The main takeaway is that most of the recurring cost is review and acknowledgment, which a written scope and a fixed review cycle can keep predictable.

Cost component	One-time or recurring	Cost drivers	How to keep the cost down
Internal time to draft and approve the policy	One-time, then revised	Number of logging areas in scope, number of approvers, and whether an existing security policy can be extended	Start from an existing information security policy and limit the AU-1 document to audit and accountability scope
Procedure writing per logging area	One-time per procedure	Count of systems, log sources and event types covered by AU-2 and AU-12, and how many platform owners must review each procedure	Write procedures by log source type rather than by individual system, and reuse templates across similar platforms
Distribution and acknowledgment	Recurring with each revision	Number of defined roles, staff turnover, and whether acknowledgments are collected on paper or in a tracked system	Publish in a version-controlled wiki and record acknowledgments in the same place as the document
Recurring review effort	Recurring at the defined frequency and after defined events	Frequency set in the organization's own parameters, number of triggering events such as incidents or system changes, and reviewer seniority	Fix the review cycle in the written scope and link reviews to change management so updates happen once
Documentation tooling	Recurring if licensed, one-time for setup	Per-seat licensing for commercial wiki products, hosting, backup and access administration	Self-hosted open-source wiki platforms can remove license spend for the knowledge base, though hosting and administration still apply
Internal assessment and evidence collection	Recurring at each assessment cycle	Number of assessment objects examined, interviews with responsible personnel, and how policy versions are retrieved	Keep version history and approval records searchable so assessors can retrieve them without manual compilation
External review or readiness support	One-time or periodic, by agreement	Scope of the written document set, depth of gap analysis, and whether an independent assessor is also engaged	Ask for a written scope listing the procedures to write, the review cycle and the deliverables before work starts

Who owns the AU-1 policy, who helps prepare it and who assesses it

The organization owns AU-1. Someone with authority over the audit and accountability program must be named as the designated official, and that person is accountable for the policy and its procedures being current. Assessors look for a named role, not a team, so the designation should appear in the policy text itself. System owners then carry the procedures into daily operation, deciding which systems send logs where and who reviews them. Personnel with audit responsibilities must also acknowledge the policy, because an unread policy is hard to defend in an interview.

Designated official: Approves the policy, sets the review frequency and owns exceptions.
System owners: Confirm that their systems follow the logging procedures and report changes that affect audit scope.
Audit responsibility holders: Operate log review, retention and failure response as written.
Acknowledgment records: Keep signed or electronically recorded acknowledgments with dates for each role.
Review triggers: Record the defined review frequency and the events that force an earlier update.

Before an assessment, confirm that the named official, the review date and the acknowledgment list all match what the policy states.

Questions buyers ask about AU-1 cost, effort and outside help

Can our organization write AU-1 policy and procedures ourselves?

Yes. AU-1 is a governance document, and the organization owns its controls, so its own security, compliance and system owners can write the audit and accountability policy and the procedures behind it. The policy has to name a responsible official, define who receives it, set a review frequency and list the events that trigger an earlier review. Teams that already maintain policies under another framework usually reuse their document structure. An outside partner can help draft the text and check it against the AU-1 determination statements, but the policy must reflect how the organization actually logs and reviews events. Confirm with your assessor or auditor which format and approval records they expect before you start.

What drives the effort and cost of AU-1 work?

Effort depends mostly on how many systems the policy must cover, how many documents already exist, and how many roles must approve and receive the material. The main cost components are internal staff time, any outside drafting or review work, and the assessment itself, which an independent assessor performs. Costs rise when there are no written procedures for logging, when several business units run separate tools, or when the organization has never run an approval cycle. They fall when a current policy set can be extended. The NIST SP 800-53 materials do not estimate compliance costs, so ask any provider for a fixed-scope quote that lists the documents, the review rounds and the systems in scope.

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

The timeline is set by approval cycles, the number of people who must review the material, and how quickly the organization can confirm facts about its logging environment. NIST does not set implementation timelines for SP 800-53 and leaves that to the agency or the program that requires it, so the duration depends on your contract or authorization schedule. Drafting is usually the shortest part. Most delay comes from waiting for the named official to sign off, from gathering the current system security plan, and from scheduling interviews with the people responsible for audit data. Ask for a written schedule with milestones before work starts, and confirm the deadline with the party that requires the control.

What does the organization need to provide for AU-1 work?

The organization must name an official who owns the audit and accountability policy, identify the system owners whose logging depends on it, and make people available for interviews. The assessment method for AU-1 includes examining the policy and procedures and the system security plan, and interviewing personnel with audit and accountability responsibilities. Those interviews must be scheduled, so the people who run logging, review logs and approve policy changes should be reachable during the assessment window. Gather the current policy set, the system security plan, the list of logged systems and any prior assessment findings before drafting starts. These inputs usually shorten the work more than any other single step.

Does NIST publish cost estimates for SP 800-53 compliance?

No. NIST does not estimate certification or compliance costs for SP 800-53, and its risk management FAQ states that it does not offer or endorse any compliance program or tool. NIST describes the controls as flexible and customizable, implemented as part of an organization-wide risk management process, so the cost of AU-1 depends on each organization's environment. Under FISMA, Inspectors General independently assess agency system security and report to OMB, and OMB Circular A-130 governs federal implementation timelines. For a cost figure, ask your contracting authority which assessment requirements apply and request quotes from providers based on your written scope.

What does an implementation partner do for AU-1, and what does the assessor do?

An implementation partner prepares the policy, procedures and supporting evidence, and it may help configure the systems that the procedures describe. DeployOpen works this way: it drafts and documents controls, integrates and configures self-hosted open-source platforms in the client's own infrastructure, and prepares evidence for assessment. The organization owns the controls and approves the policy. Only an independent auditor, assessor or certification body examines the evidence and issues any report or certificate. DeployOpen does not issue audit reports, attestations or certifications. Confirm the assessor's requirements before scoping, because the assessor decides what evidence it will accept.

How DeployOpen scopes and prepares AU-1 evidence

DeployOpen helps organizations prepare the audit and accountability policy, procedures and supporting records that AU-1 asks for, inside the client's own infrastructure. We plan and document the work in a written, fixed scope, and independent assessors decide whether the controls meet the requirement.

How we scope

Confirm which systems, business units and logging platforms the AU-1 policy and procedures must cover
Agree in writing which policy, procedure and plan documents DeployOpen will draft, revise or review
Identify the named roles, the designated official and the review frequency the organization must set
Note that engagements are fixed-scope and that ongoing support is available as a retainer

How we build

Draft audit and accountability policy and procedures that connect to the organization's logging and audit controls
Map the procedures to the system security plan and privacy plan so assessors can trace each statement
Set up version-controlled documentation with recorded approvals, distribution lists and review dates
Test that the documented procedures match how the self-hosted logging platform is actually configured

How we hand over

Deliver the approved policy, procedures and a change log in formats the organization controls
Provide a short evidence index that points assessors to the documents and records examined for AU-1
Record open gaps, owners and dates so the organization can close them before an assessment begins
Confirm with the organization's assessor which artifacts they expect, since only independent assessors judge conformity

How we support

Review the AU-1 documents when systems, roles or related controls change, at the frequency the policy sets
Support evidence collection for internal reviews and external assessments under a retainer if the organization chooses
Keep documentation current after upgrades to the logging platform or updates to the NIST release in use
Agree the scope of any follow-up work in writing before it starts