AU-9 Protection of audit information: requirements and evidence

What AU-9 protection of audit information requires and why it is hard

AU-9 requires you to protect audit information and audit logging tools from unauthorized access, modification and deletion, and to alert defined personnel or roles when such an attempt is detected. When an assessor or customer asks how your logs are kept tamper-resistant, the answer has two parts: the controls that stop an attacker or insider from changing the record, and the alerting that tells someone when a change was attempted anyway. Both parts need to be documented, configured and testable. The risk is familiar: an attacker who gains administrative access often tries to erase the traces of that access, and an insider with legitimate rights may alter records to hide a mistake or misconduct. If the audit trail can be silently changed, it cannot support an investigation or an accountability claim.

The control is hard to meet for a structural reason. Logs frequently live on the same hosts, hypervisors, databases and storage volumes that they describe, so a compromise of those systems can also reach the logs. System and network administrators, backup operators and cloud account owners usually hold broad rights that include the ability to stop services, rotate files and change retention settings. Protection therefore depends on separating who generates audit data from who can change it, and on making deletion or modification visible even when the actor has rights. Ask your team which accounts can read, write, truncate or delete audit storage today, which ones can change the logging configuration, and whether any of those actions would raise an alert outside the administrator's own reach.

SP 800-53A Rev. 5 breaks AU-9 into two determination statements, which assessors use to decide whether the protection and alerting are in place. The assessment methods examine audit tools and records, interview administrators and personnel with audit responsibilities, and test the mechanisms that protect audit information. Read the assessment procedure in the SP 800-53A Rev. 5 publication before you design evidence, so each mechanism you deploy maps to something an assessor will actually test.

Which systems and baselines bring AU-9 into scope

AU-9 applies to the low, moderate and high SP 800-53B baselines but not the privacy baseline, and its enhancements step up with impact level. The cards below help you decide which log stores, tools and external services count as audit information or audit tools for your system boundary.

Low, moderate and high baselines

AU-9 is selected in the low, moderate and high baselines, so it applies to any system categorized at those impact levels. It is not selected in the privacy baseline, which means a system whose only applicable baseline is privacy does not inherit AU-9 by default. Confirm the impact categorization for each system before you record AU-9 as applicable or not applicable in your security plan.

Enhancement AU-9(4) at moderate and high

AU-9(4) restricts access to audit information to a subset of privileged users. It is selected in both the moderate and high baselines, so a moderate system needs a documented list of who can read, export or change audit data. Check that log administrators are a defined subset, not every administrator on the platform.

Enhancements AU-9(2) and AU-9(3) at high

AU-9(2) requires storing audit records on separate physical systems or components, and AU-9(3) requires cryptographic protection of audit information. Both are selected in the high baseline only. For a high system, confirm that copies of audit records sit outside the production failure domain and that cryptographic mechanisms are approved for the data's sensitivity.

Log stores and SIEM as audit information

Treat the raw audit record store, the SIEM index, and any analytics copies as audit information. Each copy needs the same protection from modification and deletion as the original, even when a team owns it separately. List every store in the system boundary, including staging and exported files, so no copy escapes the AU-9 review.

Backups and logging tools as audit tools

AU-9 covers audit logging tools as well as audit records. Agents, collectors, forwarders, log shippers and the processes that run them count, along with backup jobs that copy audit data. Verify that backup copies of audit records are protected to the same standard, and that changes to collector configuration are logged and alerted.

Third-party and cloud-hosted log services

When a managed or cloud-hosted log service holds your audit records, it is part of your AU-9 scope even though the provider runs the infrastructure. Ask the provider in writing how it restricts administrative access, prevents deletion, and sends alerts on tampering. Your organization still owns the control, so keep the provider's evidence in your assessment file.

How the AU-9 enhancements change the work by baseline

AU-9 itself is selected in the low, moderate and high baselines, so every system in scope for those baselines must protect its audit information and logging tools from unauthorized access, modification and deletion, and alert defined personnel or roles when such an attempt is detected. The base control is where most of the work sits, because it applies regardless of the enhancements. An assessor will start by asking who can read, change or delete audit records and where the logging tools are configured.

Access restrictions: Show the permissions on log directories, log shipping endpoints and the log platform's administrative roles, and confirm that ordinary administrators cannot edit history.
Tamper detection: Show integrity monitoring on the audit files and tool configurations, with alerts that name the user or process involved.
Alert routing: Show the defined recipients, the alert rule and a sample alert from a test change.
Tool protection: Show how the logging agents and collectors are themselves protected from being stopped or reconfigured.

Confirm with the assessment team which personnel or roles are the defined alert recipients, since AU-9 requires alerting to be tied to a defined set.

How an assessor tests AU-9 under SP 800-53A

This table compares the parts of the SP 800-53A assessment for AU-9: what the assessor tests, the evidence to prepare, and the gaps that tend to come up. Read each row as a question the assessor will ask, then check your own environment against it before the assessment starts.

Assessment element	Evidence requested	Common findings
Determination statements (2), covering protection of audit information and logging tools and alerting on unauthorized access, modification or deletion	Documented protection requirements for audit data and log tools, and the defined personnel or roles who receive alerts on tampering	Protection is described in general terms without naming the audit data or tools covered, or alert recipients are not defined
Examine: audit tools and system audit records	Configuration of log file permissions, log server settings and records of who can change or delete log data	Logs are writable by the same accounts that generate system activity, or logging tool configuration is not captured in change records
Interview: personnel with audit and accountability responsibilities	Walkthrough of how log integrity is checked, who responds to tamper alerts and how the response is recorded	Staff describe protections that the documentation or system settings do not show, or no owner is named for alert review
Interview: system and network administrators	Explanation of administrative paths to audit data, including privileged accounts, backups and remote access to log stores	Administrators hold broad rights over log storage, and those rights are not reviewed or limited to a defined subset
Test: mechanisms implementing audit information protection	Demonstration that unauthorized changes or deletions are blocked or detected, and that an alert is generated and received	Test alerts are not delivered to the defined recipients, or detection only works for some log sources
Enhancement AU-9(4), where selected in moderate and high baselines	List of privileged users allowed to access audit information, with the reason each needs access	Access to audit records is granted to all administrators by default, with no separate subset defined
Enhancements AU-9(2) and AU-9(3), where selected in the high baseline	Evidence of separate storage for audit records and cryptographic protection applied to stored or transmitted logs	Audit copies are kept on the same system as the source, or cryptographic protection is not documented for stored records

Implementing AU-9 in order

This sequence turns the AU-9 requirement into a working set of protected log stores, tested alerts and documented evidence, built in the order that prevents the later steps from depending on decisions that were never made. Each step closes with an artifact an assessor can examine.

Define alert recipients and unauthorized activity
Start by naming the personnel or roles that receive alerts when audit information or logging tools are accessed, modified or deleted without authorization, and writing down what counts as unauthorized for your environment. The control owner (usually the security or platform lead) sets these with input from system administrators. Done means a signed alert matrix listing each defined role, the activities that trigger notification, and the channel used. Assessors will compare this list against the alerts you later test, so keep it specific.
Inventory audit stores and logging tools
List every location where audit records are written or held, and every tool that produces, forwards, indexes or processes them. This includes application audit files, the logging agent, the log collector, the SIEM or log database, backup copies and the administrative consoles that can change log settings. For each entry, record the owner, the account or service identity that writes to it, and the hosting boundary. The output is an audit store register that becomes the scope for every later step. Gaps found here usually mean an audit store nobody thought to protect.
Restrict write and delete rights to audit data
For each store in the register, remove delete and modify rights from ordinary users and from administrators who do not need them, and grant the logging service only the append permissions it needs. Where the platform supports it, make log files append-only and forward records to a collector that the source host cannot rewrite. Configuration of these settings is performed by the platform team and verified by a test account that attempts the prohibited action. The output is a permissions export per store plus the failed-attempt test results.
Add integrity monitoring and alerting
Deploy file integrity monitoring or an equivalent check on the audit directories, log configuration files and logging tool binaries. Establish a baseline of checksums and attributes, then configure alerts for creation, modification or deletion, choosing real-time or scheduled checks according to your risk. Wazuh file integrity monitoring and Bareos verify jobs are open-source examples that record baseline attributes and report changes, though you should confirm each tool's coverage, alert routing and retention in your own environment before relying on it. The output is a monitored-path list, a baseline record and a routing configuration that delivers alerts to the roles defined in step one.
Separate storage where the baseline requires it
For the high baseline, the AU-9(2) enhancement calls for storing audit records on separate physical systems or components from the systems that generate them. Moderate and low baselines do not select this enhancement, so confirm your system's baseline before spending effort here. Design the separation with the platform team, record the hosting boundary for each collector or archive, and confirm that administrators of the source system cannot reach the protected store with ordinary credentials. The output is an architecture diagram showing the storage locations and the access paths between them.
Apply cryptographic protection for high systems
For the high baseline, AU-9(3) calls for cryptographic mechanisms that protect audit information and tools. Choose the mechanisms with your cryptography owner, covering encryption at rest for archives and signing or hashing that lets you detect tampering with stored records. Key custody matters as much as the algorithm, so keep keys in a managed secrets store with its own audit trail. OpenBao audit devices, for example, hash most sensitive values with HMAC-SHA256 in their logs, which shows one way sensitive fields can be protected within the record. The output is a cryptographic protection specification and a key custody record.
Restrict read access to a privileged subset
For the moderate and high baselines, AU-9(4) calls for limiting access to audit information and logging tools to a defined subset of privileged users. Create a named group of log readers, grant it read access through the central access control model, and remove standing read rights from other administrators. Keep the approval process for adding members, since this group's membership is itself evidence. Nextcloud's admin_audit app, for instance, writes to an audit.log file that you can restrict to specific accounts by file permissions, and you should confirm the exact configuration for your version. The output is the reader group roster and the permission exports showing that only members can read the stores.
Test alerts and document the evidence
Trigger each alert type deliberately in a test environment and in production where safe. Attempt an unauthorized modification, a deletion and a read by a non-member, then confirm that each event reaches the defined recipients and is recorded. Compare results against the determination statements and assessment methods in SP 800-53A for AU-9 so the test plan matches what an assessor will examine. Write up the results, the remediation for any failed test, and the review schedule, then store everything with the system security plan. The output is a dated test report with screenshots or alert records, which becomes the core evidence for AU-9.

Evidence that passes an AU-9 test

An assessor testing AU-9 looks for proof that audit data and logging tools are locked down, that tampering is detected, and that someone acts on it. The artifacts below connect those three points, and each one should be exported or re-reviewed on a schedule so it still reflects the system on the day of the assessment.

Access control lists on log stores

Export the permissions on every location that holds audit records, including the Nextcloud audit.log path set with logfile_audit, the OpenBao audit device output and Wazuh and Bareos repositories. Confirm that ordinary administrators and application accounts cannot modify or delete entries, and that write access is limited to the logging service. Ask the assessor's expectations for the export format before you schedule it, and export the same set each month so differences stand out.

Integrity monitoring configuration and sample alerts

Keep the file integrity monitoring configuration that defines which audit files and directories are watched, along with the baseline of checksums and attributes. Attach a few sample alerts showing a create, modify or delete on a monitored audit file, with the user or process responsible and the time of the change. Wazuh file integrity monitoring provides this, and Bareos Verify jobs can compare files against cataloged attributes. Test the alert path with a controlled change so the sample is genuine.

Alert records and response tickets

AU-9 requires alerts to defined personnel or roles when unauthorized access, modification or deletion is detected, so the evidence must show both the alert and the action. Keep a log of alerts raised against audit data, the recipient roles, and the ticket or case that records triage and outcome. Review whether recipients are still the right people, since staff changes often break alert routing without anyone noticing.

Separate storage and cryptographic protection settings

For the high baseline, document where audit records are stored on separate physical systems or components (AU-9(2)) and how they are cryptographically protected (AU-9(3)). Export the storage topology, the encryption settings and the key custody arrangement. Confirm that keys used to protect audit records are not held by the same administrators who manage the logs. Ask your assessor whether the high baseline applies to your system before building this artifact.

Documented list of privileged log users

AU-9(4) expects access to audit information to be limited to a subset of privileged users, and the moderate and high baselines select it. Maintain a named list of the people and service accounts allowed to read or manage audit records, with the business reason for each. Compare the list against directory group membership on each export, because a list that drifts from actual access is a common finding.

Periodic access reviews

Record a dated review of the log store permissions, the privileged user list and the alert routing, signed by the accountable owner. Each review should note any removed access, any alert that was not acted on, and any configuration change since the last review. Scheduling these reviews as recurring calendar items, and storing the exported configurations beside each review, lets the evidence stay current between audits rather than being rebuilt the week before one.

What meeting AU-9 costs in money and effort

This table separates the cost components of protecting audit information, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Read it as a checklist for a quote: the license line can fall to zero with self-hosted open source, but the engineering, tuning and evidence lines remain.

Cost component	Who is paid or who does the work	One-time or recurring, and main drivers
Tooling or licenses	Software vendors or none for open-source components	Recurring for commercial tools; open-source removes license spend but not hosting or support. Drivers: number of log sources and log volume.
Storage separation and access design	Internal platform engineers or implementation partner	Mostly one-time: designing separate log storage, write-once or restricted paths and admin access. Drivers: number of systems and existing architecture.
Cryptographic protection and key handling	Internal security engineers or implementation partner	One-time build, then recurring key rotation and review. Drivers: whether the high baseline enhancement AU-9(3) applies and existing key management.
Integrity monitoring tuning	Security operations staff or implementation partner	Initial setup is one-time; tuning is recurring as file changes and alert noise change. Drivers: monitored paths, baseline selection and number of administrators changing files.
Restricting log access to privileged subset	Identity and access engineers	One-time role design, recurring access reviews. Drivers: number of administrators and whether the moderate or high baseline applies (AU-9(4)).
Alert routing for tamper events	Security operations team	Recurring staff time to triage. Drivers: number of defined alert recipients and the frequency of false positives.
External testing of log tamper resistance	Independent testers or implementation partner	Periodic and recurring if scheduled. Drivers: scope of logging tools and whether testing covers privileged-user bypass paths.
Evidence upkeep	Control owner and compliance staff	Recurring: keeping configuration exports, access lists and alert samples current for assessors. Drivers: assessment frequency and number of systems in scope.
Assessor sampling	Independent assessor (fee set by assessor)	Recurring at each assessment cycle. Drivers: number of log sources and samples the assessor selects. Ask the assessor to state sampling in writing.

Open-source tools that produce AU-9 evidence

Several self-hosted open-source tools can produce evidence for the AU-9 protections, but each covers a different slice of the requirement. Nextcloud's admin_audit app writes additional event information to an audit.log file in the data directory, or to a path set with the logfile_audit setting, so the log location is a decision you make at deployment. Confirm in the target version that the log file sits outside the web-accessible tree, that the application service account can append but cannot rewrite history, and that the file is shipped to a store the application administrators cannot edit. The Nextcloud admin manual's logging section is the place to check the current configuration keys.

OpenBao audit devices take a different approach. They keep a detailed JSON log of every API request and response, including errors, and hash most sensitive values with HMAC-SHA256 so the log is useful for investigation without exposing secrets. For AU-9 this means the secrets engine itself produces tamper-relevant records of who touched what. Confirm which fields are hashed in your version, decide whether the audit device must block requests if logging fails, and make sure the device file destination is separate from the Bao operators' write access. Licensing is MPL-2.0, which should be reviewed alongside your own distribution plans.

Wazuh file integrity monitoring (GPL-2.0-only) addresses the alerting half of AU-9. It records a baseline of checksums and attributes for monitored files and directories, then raises an alert when a user or process creates, modifies or deletes a monitored file, either on a schedule or in real time, with details on how and when the change happened and who made it. Point it at the audit log directories and the audit tool configuration, then test that a deliberate edit produces an alert routed to the defined personnel. Bareos Verify jobs (AGPL-3.0-only) offer a complementary check: they compare files against previously cataloged attributes, which helps detect changes after an intrusion, though they run on a schedule rather than in real time. Confirm the verify level and schedule in your version, and keep the Bareos catalog and backup storage out of reach of the administrators whose changes you are checking for.

Who owns AU-9 and what is worth outsourcing

Who is responsible for AU-9 protection of audit information?

The organization owns AU-9. It decides which audit information and logging tools must be protected, who is alerted when unauthorized access, modification or deletion is detected, and how the protection is operated and reviewed. An implementation partner such as DeployOpen can plan, configure and document the systems that carry out those decisions, but it does not take over the control itself. Ownership stays with the accountable role inside the organization, typically the security or IT operations leader, who signs off the design and answers to assessors for how it works day to day.

What can a partner prepare for AU-9 on self-hosted platforms?

A partner can prepare the technical parts that produce AU-9 evidence. In practice this covers:

Log stores configured so administrators cannot silently rewrite or delete audit records, with access limited to a defined subset of privileged users.
Integrity monitoring on audit files and logging configuration, so changes raise alerts to the defined roles. Wazuh file integrity monitoring is one open-source option for this.
Separate storage and cryptographic protection for audit data where the selected baseline requires it.
An evidence pack that shows the configuration, alert rules, access lists and sample alert records an assessor will examine.

The partner delivers these as documented, tested systems. Which tools fit depends on the platform and must be confirmed in the client's environment.

What must the organization keep doing after the systems are built?

The organization must keep operating the protection after handover. Logging tools need access reviews, alert routing must be tested, and integrity alerts must be triaged and recorded with a documented outcome. Changes to logging configuration should go through change control, and the defined roles should confirm that alerts reach people who can act on them. Policies and procedures for audit protection need periodic review, and the organization should keep the evidence current as platforms are upgraded. If these routines lapse, the partner's original build will not show that the control still works.

What will an independent assessor check for AU-9, and what will they not do?

An independent assessor examines the protection mechanisms, interviews the personnel responsible for audit and accountability and the system administrators, and tests whether unauthorized changes are actually blocked or detected and alerted. The assessor then forms findings from that work. Only an independent assessor, auditor or certification body issues findings, reports or certificates. DeployOpen prepares systems and evidence but does not assess, attest or certify AU-9, and the assessor does not design the controls for the client. Confirm with the assessor in advance which evidence formats and test samples they expect.

What parts of AU-9 are usually worth outsourcing?

The parts that most often benefit from outside help are the initial hardening of log stores, the design and testing of integrity monitoring and alerting, and the assembly of the evidence pack. Organizations usually keep policy ownership, access approvals, alert triage and assessor relationships in house. Outsourcing these build tasks is most useful when the team lacks time or experience with the logging platform, and the scope should be fixed in writing before work starts so that deliverables and testing are clear.

What drives the cost of protecting audit information?

Cost is driven by how many logging tools and audit stores are in scope, how many systems feed them, whether the target is the moderate or high baseline (the high baseline adds the separate storage and cryptographic enhancements), how much existing configuration must be changed, and how much testing and evidence assembly is required. One-time costs cover design, hardening and the first evidence pack. Recurring costs cover access reviews, alert handling, upgrades and assessor support. Ask any partner for a quote built from a written scope, and ask the assessor separately what their fees and sampling assume. NIST does not estimate compliance costs, so no general figure applies.

Can an internal team implement AU-9 without outside help?

Yes, an internal team can implement AU-9 if it has the skills to configure audit storage, access control and integrity monitoring for its platforms, and the capacity to document and test the result. The main gaps teams report are unfamiliarity with the logging platform's protection settings, no time to build an evidence pack, and no independent test of whether alerts fire. Before deciding, check the platform documentation for the protection features it actually offers and confirm them in your own environment rather than assuming them.

Where AU-9 implementations usually fail

AU-9 is tested by asking whether anyone who can change a system can also change its audit trail without being noticed. The gaps below recur in assessments because they break that separation, the alerting, or the proof that alerting works. Each card names the gap and the action that closes it.

Admins can edit logs on the same host

Audit files often sit on the same server as the application, and the administrators who run that server can usually rewrite or truncate them. An assessor will ask who holds write or delete rights on the audit directory and the logging service configuration. Close the gap by restricting write access to the logging agent account, removing interactive delete rights from administrators, and documenting the exceptions that remain. Confirm this in the environment itself, since default file permissions differ across operating systems and packages.

No alert on deletion

Protection that is never tested in practice does not tell anyone when it fails. AU-9 expects defined personnel to be alerted when audit information is accessed, modified or deleted without authorization. Check whether a change to the audit directory, the log configuration or the logging service generates an event that reaches a person or a monitored queue. File integrity monitoring tools such as Wazuh can raise alerts on creation, modification or deletion of monitored files, so set the monitored paths to include the audit store and confirm the alert route.

Log copies not separated for high

The high baseline adds enhancements that require audit information to be stored on separate physical systems or components and protected with cryptography. A copy that sits beside the source logs does not meet that intent. Map which log stores are authoritative, where replicas go, and who administers each. Then decide whether a separate log host, a write-once destination or a backup target with its own credentials is the right separation for the system's impact level. Confirm the exact separation the assessor expects against the control text for the baseline you are under.

Read access too broad

AU-9 enhancement AU-9(4) is selected in the moderate and high baselines and limits access to audit information to a subset of privileged users. In practice, many teams let every engineer read production logs, which exposes personal data and security-relevant detail well beyond the people who investigate incidents. Produce a list of roles with read access to each audit store, remove standing access that is not needed, and record who approves additions. Access logs for the audit store should themselves be reviewed.

No evidence of alert testing

Assessors examine the alerting mechanism and interview the personnel who receive alerts, so a configured rule with no record of firing is weak evidence. Plan a controlled test that modifies a test file in a monitored audit path, then capture the alert, the recipient's acknowledgment and the ticket or response that followed. Repeat the test after configuration changes or upgrades. Keep the test plan, dates, results and any defects in the assessment evidence package.

Unmanaged third-party log services

Many organizations forward audit records to a hosted logging or security analytics service that the internal team does not administer. AU-9 still applies to the audit information and the tools that protect it, so the provider's administrators, retention settings and deletion rights become part of the scope. Request the provider's documented controls for access, deletion and alerting, confirm which tenant roles can purge data, and state in the system documentation who is accountable for each protection. Where the service is outside your control, record that dependency as a risk.

AU-9 questions buyers ask before hiring help

How much effort does AU-9 take to implement?

The effort depends on how many logging sources you run and how well access to them is already controlled. AU-9 itself is short: it asks you to protect audit information and logging tools from unauthorized access, modification and deletion, and to alert defined personnel when those attempts occur. The work usually splits into three parts: restricting who can read, write or delete audit data, detecting changes to logs and log configuration, and proving both to an assessor. Effort rises with the number of systems that generate audit records, the number of administrators who hold broad rights, and whether logs already leave the system of origin. Ask any provider to break its estimate down by system and by enhancement, since AU-9(2), AU-9(3) and AU-9(4) add separate work for separate storage, cryptographic protection and restricted access.

Can we implement AU-9 in-house without outside help?

Yes, many organizations do, provided they have people who understand log administration, identity management and change detection. The organization owns the control and must make the decisions: which roles may access audit data, who receives alerts, and how tampering is handled. An in-house team usually needs skills in operating a central log store, configuring file integrity monitoring and managing privileged accounts. Outside help is most useful when the environment is large, when the team lacks time to document and test the controls, or when an assessor will expect evidence in a particular format. Whichever path you choose, the assessor reviews the result independently, so decide early who will gather the evidence.

What does the team need to provide for an AU-9 project?

A project needs named access to the people and systems that hold audit data. In practice that means:

A system owner who can approve which roles may read, modify or delete audit records
Administrators who can explain how the logging platform and its configuration files are managed today
Identity or directory staff who can confirm group membership and privileged account lists
A security or operations contact who will receive and act on tamper alerts
Access to the systems that generate logs, so the implementer can test protection and alerting in the real environment

Make sure the scope document lists these contacts, because delays in access are a common reason work slips.

How long does AU-9 implementation take?

No duration is supplied for this topic, so do not plan around a number from this page. The time depends on the number of logging sources, the state of current access controls and how much testing the assessor expects. Ask any provider to state the timeline in a written scope with defined deliverables, and confirm with your assessor or authorizing official what evidence they will accept and how they expect it to be delivered. Confirm the schedule early, because an assessor's availability can determine when the evidence review happens.

What will an assessor ask for to test AU-9?

An assessor follows the SP 800-53A procedure for AU-9, which uses examine, interview and test methods. Expect requests for:

Documented audit protection policy and procedures, and the list of roles allowed to access audit data
Configuration evidence from the logging tools showing access restrictions and permissions
Samples of audit records and file integrity or tamper alerts, along with records of how staff responded
Interviews with personnel responsible for audit and accountability and with system and network administrators
A live demonstration or test showing that an unauthorized change is detected and that the right people are alerted

The assessor makes the determination. Your team prepares the evidence, and the assessor reports on it.

Are open-source tools enough to meet AU-9?

Open-source tools can produce much of the evidence AU-9 needs, but they do not satisfy the control on their own. Nextcloud's admin_audit app writes additional event information to a log file, OpenBao's audit devices record every API request and response with sensitive values hashed, Wazuh's file integrity monitoring alerts on creation, modification or deletion of monitored files, and Bareos Verify jobs compare files against cataloged attributes. Each tool still needs a defined protection design, restricted permissions, alert routing and documented procedures. Confirm each tool's capabilities against its own documentation in your environment before relying on it in an assessment.

Does DeployOpen issue an AU-9 certification or assessment report?

No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can plan, implement and document the systems and evidence that support AU-9, and it can run security testing that checks whether alerts fire when tampering is simulated. The organization owns its controls, and an independent assessor or certification body reviews the evidence and issues any report or certificate. Ask any implementation partner to state in writing which parts of the work are preparation and which parts the independent assessor will perform.

How DeployOpen prepares AU-9 evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it prepares the AU-9 configuration and evidence that an assessor will examine. For AU-9, that work usually means deciding where audit data lands, who can reach it, how tampering is detected and how alerts reach the defined personnel. The organization still owns the control, sets the roles that receive alerts and signs off on the design. DeployOpen works under a fixed-scope written agreement that lists the systems, the baseline and the deliverables before work starts. It does not issue audit reports, attestations or certifications. An independent assessor performs that role.

Before any scoping call, ask which components hold audit information and which logging tools must be protected, since AU-9 covers both. Then confirm which SP 800-53B baseline applies to each system, because AU-9 is selected for low, moderate and high baselines, while the enhancements that restrict access to a subset of privileged users, separate physical storage and cryptographic protection depend on the baseline. Confirm with your assessor which of the two determination statements in SP 800-53A they will test against your environment. A written scope should name each log store, each administrator role with access to it and the alert recipients, so the evidence set can be built against those named items.

Expect the deliverables to be tied to the specific tools in your environment. Examples include the configuration that writes Nextcloud audit records to a protected path set with logfile_audit, the audit devices configured in OpenBao, file integrity monitoring rules in Wazuh and verify job results in Bareos, along with their alert routing. Each deliverable should produce something an assessor can examine or test, such as a configuration export, an access list, an alert test record or a change log. Ask whether the scope includes running a test that modifies a monitored file or log to show that an alert fires, and who will review the results. Clarify in writing that any remediation, process ownership and final control determination stay with your team and your independent assessor.