AU-16 Cross-organizational audit logging: requirements and evidence

AU-16 cross-organizational audit logging: what it asks and why a baseline does not include it

An assessor or contract asks how you handle AU-16, and your SP 800-53B baseline does not select it. That is expected. AU-16 Cross-organizational audit logging is not in the low, moderate, high or privacy baseline in SP 800-53B Release 5.2.0, so the control only applies if your organization adds it by tailoring a baseline or through an overlay. Your first decision is whether the system actually sends audit information to another organization, such as a managed service provider, a shared security operations center, a federated identity partner or a business partner that holds records about your users. If it does not, document that scoping decision and move on. If it does, AU-16 requires you to define the methods for coordinating that audit information with the external organization and to apply them whenever audit information crosses the boundary.

The control exists because logs that split across parties lose their value. When one organization records a login, another records the resulting transaction, and a third holds the session data, each party's timestamps, user identifiers and event labels may not match. An investigator then cannot reconstruct who did what, in what order. The hard part is rarely the transport. It is agreeing in writing who holds which records, how long each party keeps them, how a user identity in one system maps to the identity in another, and which time source and offset each party uses. The three AU-16 enhancements, AU-16(1) to AU-16(3), add further expectations on top of the base requirement, and the current catalog lists none as withdrawn. None of them is selected by any SP 800-53B baseline, so each one must be justified in your own tailoring record if you adopt it.

Start by pulling the external-party inventory from your system security plan and listing every point where audit data leaves your boundary. For each flow, confirm with the partner which identifiers they preserve, which timestamp format they use, and who owns retrieval during an investigation. Ask your assessor which examine, interview and test evidence they expect, since SP 800-53A assesses AU-16 with one determination statement and those three methods. Ask the external party to confirm these facts in writing, because a shared log platform cannot prove coordination on its own. Where a partner is engaged to help design or document these agreements, that work prepares the evidence, but only your assessor's independent examination can judge whether the control is met.

Which boundaries and third parties put AU-16 in scope for your system

AU-16 applies when audit information leaves your organization's control and reaches another party. The cards below cover the common boundaries where that happens and the tailoring decisions that bring the control into your baseline. Use them to decide early which external flows need coordinated methods and which parties must be named in your documentation.

Managed logging and SOC services

When a managed detection provider or shared SOC receives your audit records, those records cross an organizational boundary even if the provider sits inside your cloud account. Check which event types leave your environment, which fields they carry, and whether the provider reads raw records or only alerts. Write down who coordinates timing, format and identity fields with the provider, because AU-16 asks for defined methods, not informal arrangements.

Payment and clearing partners

Payment processors, card networks and clearing partners often request transaction-level audit data to investigate disputes or fraud. Each request is a boundary crossing with its own recipient, purpose and retention expectation. Confirm which partner systems need audit extracts, how the identities of your staff and customers appear in them, and who approves each feed. Record the agreed method so an assessor can trace it.

Cloud and hosting providers

A cloud or hosting provider may hold copies of platform logs, control-plane events or support access records that relate to your systems. Some of these logs are generated and kept by the provider, not by you, so coordination depends on what the provider exposes and how you export it. Ask which audit records the provider keeps, how you obtain them, and how identities of your administrators are represented in them.

Parent organizations and regulators

Group companies, parent entities and regulators can require audit extracts for consolidated oversight or supervisory review. These requests often arrive as one-off exports, which makes them easy to handle outside any defined method. Identify which recipients are entitled to audit data, which format they need, and how time stamps and time zones will stay consistent across the handover. Treat each recurring recipient as an entry in your coordination method.

Personal identifiers in transit

Audit records often contain user names, email addresses, IP addresses or device identifiers. When these records cross a boundary, the same data may be subject to privacy obligations in the receiving party's jurisdiction. Review which identifiers are necessary for the recipient's purpose, whether pseudonymous references can replace them, and how the identities of the original actors remain traceable on your side. Pair this review with the AU-3 content decisions in your system.

Tailoring and overlay decisions

AU-16 is not selected by any SP 800-53B baseline, so it enters a system only when your organization tailors a baseline or applies an overlay that adds it. Decide whether your external flows justify adding the control, and record that decision in the system security plan. If you do not add it, document the reason, because an assessor will expect the absence of the control to match your actual data flows.

How an assessor tests AU-16 against SP 800-53A

This table breaks down how an assessor tests AU-16 under SP 800-53A, from the single determination statement to the examine, interview and test objects behind it. Read each row as a question the assessor will ask and the artifact or person that answers it. The main takeaway is that most AU-16 findings come from agreements and identities that exist on paper but are not carried through the system.

Assessment element	What the assessor does	Evidence that passes	Where it usually fails
Determination statement	Confirms the organization has defined the methods for coordinating defined audit information with external organizations when it crosses organizational boundaries.	Documented coordination methods that name the external organizations and the audit data each one receives.	Methods are described in general terms with no named external parties or defined audit information.
Examine: policy and procedures	Reads the audit and accountability policy and the procedures addressing cross-organizational coordination.	Approved policy text and procedures that assign owners and state how coordination is performed and reviewed.	Policy mentions external sharing, but procedures stop at the organizational boundary.
Examine: system security plan and privacy plan	Checks whether the SSP and privacy plan describe the cross-organizational audit flows and the controls protecting them.	SSP entries that list each boundary crossing, the data sent, and the parties receiving it.	Plans omit recipients added later, such as a managed monitoring provider or a partner SOC.
Examine: system design documentation	Traces how audit records leave the system, including formats, transport and any transformation along the way.	Data flow diagrams and interface specifications showing where audit records are exported and in what form.	Diagrams show the logging platform but not the export path to the external recipient.
Interview: responsible personnel	Asks the people who coordinate audit information with external organizations how they do it day to day.	Consistent answers from named staff that match the documented procedures and the actual export configuration.	Staff describe a manual process that differs from the written procedure, or no one can name the external contact.
Test: cross-organizational auditing mechanisms	Observes or inspects the mechanisms that send audit information across the boundary and checks what arrives.	Configuration exports, transfer logs and sample records at the receiving side showing the agreed content and identities.	User or host identities are dropped or replaced at the boundary, so the external party cannot tie events to actors.
Common finding: undocumented agreements	Compares the coordination arrangements in place with the written agreements and the SSP.	Signed information exchange agreements that match the actual flows and are reviewed on a stated schedule.	Working arrangements exist with no agreement, or the agreement no longer matches the data being sent.
Common finding: identities lost at the boundary	Samples events that cross the boundary and checks whether the source identity survives the transfer.	Records at both ends that preserve user, process and host identifiers and time stamps.	Time zones or identifiers change during export, breaking correlation across organizations.

Implementing AU-16 in six steps

This sequence turns AU-16 from a selected control into a documented, tested method for sharing audit information across organizational boundaries, so an assessor can see who receives what, under which agreement, and whether a shared event can be followed end to end.

Confirm AU-16 is selected in the tailored baseline
Start by checking the system's control selection. AU-16 is not in the SP 800-53B low, moderate, high or privacy baselines, so it is present only if the organization added it by tailoring a baseline or through an overlay. The system owner and compliance lead record the decision in the system security plan, with the reason the system exchanges audit information across organizational boundaries. The output is a documented selection decision, or a documented decision that AU-16 does not apply, with the rationale an assessor can review.
Inventory external organizations receiving audit information
Identify every external organization that receives audit information from the system. Typical recipients include a managed security provider, a parent company, a regulator, a shared services partner or a cloud provider's log service. For each one, record the data flow, the event categories sent, the transport and who operates the receiving end. The output is a register of external recipients that the security team owns and reviews whenever a new integration is proposed, so no feed is set up without appearing on it.
Define the coordination method and covered audit information
For each recipient, define the method used to coordinate audit information, such as a scheduled export, a streaming feed or a shared query interface, and list the audit information it covers, mapped to the event types selected under AU-2 and the record content defined under AU-3. Name the owner on each side. The output is a coordination specification per recipient that states what is sent, how often and in what format, and what is deliberately kept inside the organization. Confirm the exact mechanics with the platform documentation for each product in use.
Configure identity and timestamp preservation across the boundary
Set up the transfer so each record keeps the identities involved and a time reference that the receiving organization can interpret. Check that user, service and device identifiers survive export without being replaced by local aliases, and that time stamps retain their source and offset, consistent with the AU-8 time stamp configuration. Where the platform hashes or redacts sensitive values, document which fields change and how a recipient can still correlate events. The output is a tested sample record set showing that identities and times arrive intact, or a documented list of fields that do not, with the agreed handling for each.
Document agreements and procedures
Write down the agreements and operating procedures that govern each exchange. The agreement should cover purpose, data classification, retention on the receiving side, access restrictions, incident notification between parties and the process for changing the feed. The procedures should show who starts, stops and audits each transfer, and how transfer failures are escalated, which connects with the AU-5 response process. Legal and privacy staff should review any agreement that carries personal data. The output is a signed or approved agreement and a procedure document for each recipient, filed with the AU-1 policy set and the system security plan.
Test that a shared event can be traced end to end
Run a controlled test in which a defined event is generated in the system, follows the agreed path to each external recipient, and is located there using the identifiers and time reference preserved in step four. Record the event identifier, the time at each hop, the recipient's copy and any fields that differ. Repeat the test after any change to the feed or the platform. An assessor will typically examine the procedures and interview the coordinators, then test whether the mechanism works, so retain the test record, its date and the person who ran it as the evidence that the method is operating.

Choosing methods that preserve identities and time order

The first decision for AU-16 is which identities travel with the audit information. When a record leaves your boundary, a bare account name such as admin tells the receiving organization little. Agree on one identity mapping before any exchange starts: how each internal user, service account and workload is named, how that name maps to the identifier the partner uses, and who maintains that table when accounts change. The AU-3 content your systems already produce, including the identities involved, event type, source and outcome, is the raw material for this mapping. Confirm with each partner whether they need the original local identifier, a pseudonymized token or both, because that choice determines what your records reveal to them and how investigations can be traced back.

Time order is the second decision. Records from two organizations only line up if their time stamps share a reference. Your AU-8 configuration should fix the time source, the granularity and whether timestamps are expressed in UTC or with a recorded offset, and you should confirm that every component producing records, including the ones an AU-7 reduction job touches, uses that same setting. Ask partners which format they expect and whether they will accept your records as exported or need a normalized schema. Agree on the transport and encoding as well, and protect that channel with encryption and authentication, since the records may contain sensitive detail. AU-7 reduction and report generation help here only if they preserve original record content and time order, so test that a filtered export still sorts correctly against an untouched source. The specific methods are yours to define, and they must be confirmed against your own environment, your agreements with each external party and any sector rules that apply to you. A practical check is to take one sample event that crosses the boundary, trace it from the source system through the transport to the receiving side, and confirm that the identity, time stamp and content survive unchanged. Record the result as test evidence, and document the mapping table and format specification as the artifacts an assessor will ask to see. Do not assume a partner's tooling handles these details; ask them to show you a sample exchange before you rely on it.

Evidence that passes AU-16 and how to keep it current

An assessor testing AU-16 looks for proof that cross-boundary audit sharing is defined, agreed, configured and actually exercised. The six artifacts below connect the policy-level method to records from live exchanges, and each needs a refresh trigger so it still matches the system when the assessment happens.

Coordination method documentation

This is the defined method the organization uses to coordinate audit information with external organizations, written so an assessor can match it to the AU-16 determination statement. It should name the transport, the parties, the direction of flow and who approves changes. Refresh it whenever a recipient, transport or log format changes, and check that the system security plan references the current version rather than an earlier one.

Information exchange agreements

Signed agreements with each external organization set out what audit data is shared, how it is protected in transit, retention at the recipient and who is contacted when something fails. Assessors compare the agreement terms against what the configuration actually sends. Review each agreement at its stated renewal point and after any change in recipient contacts or legal basis, since a stale agreement is a common gap.

External recipient and data element list

Maintain a register of every external party that receives audit records, with the specific data elements each one gets. Include the event types from AU-2 and any fields removed under AU-3 privacy limits, so the list reflects what leaves the boundary and not just what is logged internally. Reconcile it against forwarder and SIEM connector settings each quarter, and after any onboarding or offboarding of a partner.

Identity and time preservation configuration exports

Export the relevant settings from log forwarders, collectors and receiving platforms to show that user identities, source system names and time stamps survive transfer unchanged. Check that time stamps keep the UTC or offset form defined under AU-8, and that identifiers are not rewritten by a pipeline stage. Re-export after every upgrade of a forwarder or parser, because default field mappings often change between versions.

Sample cross-boundary event traces

Keep recent traces of real events that crossed a boundary, showing the same event at the sender and the receiver with its identity and time intact. A trace is illustrative evidence of a working exchange, so pick samples across several recipients and at least one failure or retry case. Refresh the set before each assessment window, and store the queries used to pull them so an assessor can rerun them.

Coordination review records

Records of periodic reviews show that the people responsible for cross-organizational coordination actually meet, check recipients and resolve issues. Keep dated minutes, action items and closure evidence, and link any change to the method or agreements back to the review that triggered it. Set the review frequency in the organization's own procedure and confirm it with the assessor, since NIST does not set one for AU-16.

What meeting AU-16 costs in money and effort

This table breaks down the cost components of meeting AU-16 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. No prices or durations are published for this control, so use the drivers and quote questions in the right-hand columns to compare written proposals.

Cost component	Who is paid or who spends	One-time or recurring	What drives it, and what to ask for in a quote
Tooling and licenses	Software vendors or the organization's own budget	Recurring where licensed, one-time where self-hosted	Self-hosted open-source logging components can remove per-seat license spend, but the organization still pays for hosting and storage. Ask which components are licensed and which are open source.
Engineering time to build coordination	Internal platform or security engineers, and any implementation partner	One-time build, then recurring maintenance	Number of external parties and the transport methods in use drive effort. Ask the partner to list each interface, data format and identity mapping it will build.
Agreement drafting with legal counsel	Outside counsel and internal legal staff	One-time per agreement, with periodic review	Data sensitivity and the number of counterparties drive effort. Ask whether the quote covers drafting, review cycles and revisions to existing information exchange agreements.
Evidence upkeep	Internal compliance and engineering staff	Recurring	Frequency of coordination changes and partner onboarding drives effort. Ask how the partner will keep configuration records and partner lists current for assessors.
External testing or review	Independent testers, assessors or the organization's own reviewers	Recurring at the frequency the organization sets	Scope of cross-organization paths and the number of external parties drive effort. Ask whether testing of coordination mechanisms is in scope and how findings are delivered.
Auditor sampling	Independent auditor or assessor	Recurring with each assessment cycle	Number of documented external parties and sampled transfers drives effort. Ask the auditor for its sampling approach before work starts, since only independent assessors issue findings.
Existing logging stack	Internal teams that already operate logging	Varies	A mature logging stack with documented forwarding lowers build effort. Confirm with the team which forwarding and identity features already exist before accepting a new build estimate.

Who does what for AU-16: your team, a partner and the auditor

Your organization owns AU-16. That means deciding whether the control applies at all, since SP 800-53B Release 5.2.0 does not select AU-16 for any baseline and it enters a system only through tailoring or an overlay. Your team also decides which external organizations receive audit information, why they need it, and which methods coordinate that exchange. Those decisions belong in the system security and privacy plan and in the agreements with each external party, and they must be signed by people with authority to accept the risk.

Applicability decision: record whether AU-16 is in scope and the reasoning, so the choice can be defended to an assessor.
Partner list: name each external organization that receives audit data, the data types, and the transmission path.
Agreements: draft or approve the information exchange terms that define how coordination and identity handling work on both sides.
Policy and procedures: own the documented methods for coordinating audit information among external organizations.
Ongoing review: reassess the external list and agreements when systems, contracts or personnel change.

Before any outside party starts work, confirm that your own accountable owner can name each external recipient and each method without reading them from a vendor document.

Where AU-16 programs usually fall short

AU-16 is easy to overlook because it is not in any SP 800-53B baseline, so it is often never assigned an owner. The gaps below tend to appear once audit data actually leaves the organization, whether it goes to a managed service, a partner SOC, a regulator or a cloud provider. Each gap has a closing action you can check before an assessor does.

No documented coordination method

AU-16 requires defined methods for coordinating audit information with external organizations. Many programs have an informal understanding with a partner but no written method that names the data, the channel, the contact and the escalation path. An assessor reviewing the audit and accountability procedures will look for this text first. Action: write one method per external party that states what is shared, how it is transmitted, who coordinates it and how changes are handled.

Agreements that omit audit data

Contracts and information exchange agreements often cover data and availability but say nothing about logs, retention or who may request them. When an incident crosses organizational boundaries, the organization may find its provider holds the only copy of a key event. Action: check each agreement for audit record types, delivery timing, retention at the provider and the right to obtain records during an investigation.

Identities lost in translation

Audit information shared with an outside party is often stripped of the user, service account or device identity that made it useful. A source system may log an internal account ID that means nothing to a partner, or a federated login may be recorded under a different name in each system. Action: test a sample exchange and confirm that the identifiers a partner receives still resolve to a person or process in your own directory.

Unsynchronized clocks across boundaries

Events recorded in two organizations are only correlatable if their time stamps agree on a common reference and offset. A partner system set to local time, or a forwarder that drops time zone data, can make a timeline appear to run backward. Action: confirm each sending and receiving system uses a synchronized time source and that exchanged records state their time zone or UTC offset.

No test of a real cross-boundary event

Teams often verify that a log forwarder is running but never send a realistic event end to end. The first real test then happens during an incident, when a missing field or blocked connection is costly. Action: run a scheduled exchange test that generates a known event at the source, confirms receipt and identity fields at the external party, and records the result as assessment evidence.

Shared logs without access limits

Once audit information is shared, the receiving organization may hold copies with broader access than the source system allows. Those copies can expose personal data or security details beyond the people who need them. Action: document which external roles receive audit data, limit those recipients to the fields they need, and review the list when a partner changes staff or scope.

AU-16 questions buyers ask before bringing in help

Is AU-16 required by default under NIST SP 800-53?

No. SP 800-53B Release 5.2.0 does not select AU-16 or any of its three enhancements for the low, moderate, high or privacy baselines. It applies only when your organization adds it by tailoring a baseline or through an overlay that a sponsoring authority or contract requires. Start by reading your system's security plan and the contract or authorization letter to see whether AU-16 is named. If it is not named, confirm with the authorizing official or contracting officer before spending effort on it, because adding a control without a requirement creates evidence work with no assessor expectation behind it. The control is still useful where audit data is shared with partners, service providers or regulators, so the decision should be based on your data flows, not on the baseline alone.

What drives the effort of meeting AU-16?

The main driver is how many external organizations receive audit information and how that information leaves your boundary. Effort rises when there are several recipients with different formats, time standards, identity schemes or legal terms, and when the data includes personal information or security-sensitive events. The work usually includes:

Mapping which audit data crosses organizational boundaries and to whom
Defining the methods used to coordinate that data, such as agreed formats, transfer paths and time handling
Writing the agreements and procedures that describe those methods
Confirming that identities in shared records remain traceable to their source

If your audit pipeline is already central and exports are documented, the effort is mostly documentation and testing. Ask any provider to break its estimate down by these items.

Can we implement AU-16 with our own team?

Yes, in most organizations the control can be handled in-house, especially where the security and platform teams already own the logging pipeline and the external agreements. The obligations are concrete: define the coordination methods, document them in the audit and accountability procedures and the system security plan, configure the transfers, and keep evidence that the methods work. Teams without experience in cross-organization data sharing often find the legal and contractual side slower than the technical side. An outside partner can prepare configuration, documentation and test evidence, but your organization still owns the control, its procedures and the decisions about what leaves your boundary. An independent assessor, not the implementation partner, reviews the result.

What skills does the team need to meet AU-16?

The team needs three kinds of knowledge. Security or platform engineers must understand the audit pipeline, including how records are generated, filtered and exported. Governance staff must be able to write procedures that name the methods and the responsible roles. Someone with authority over external relationships must be able to agree data-sharing terms with each recipient. Engineers should also be able to verify that identities and time stamps survive the transfer. Check whether your audit tooling records the source of each event and whether exported records keep their original time base, because assessors commonly ask how the record received outside your boundary can be traced back. Where skills are thin, a fixed-scope engagement can cover the technical preparation while your staff own the decisions.

How long does AU-16 implementation take?

No duration can be stated responsibly from general principles, because it depends on the number of recipients, the state of your existing audit exports and how quickly partners agree terms. Ask any provider to base its timeline on a written inventory of cross-boundary audit flows. Confirm three things before committing dates: which external organizations are involved, whether their agreements already exist, and when the system's next assessment is scheduled. Agreements with outside parties often set the critical path, so begin those conversations early. Ask the provider to show which milestones depend on your partners rather than on its own work.

What does a fixed-scope DeployOpen engagement cover for AU-16?

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. For AU-16, a scope could cover reviewing the self-hosted audit pipeline in your own infrastructure, configuring the export methods you have decided on, preparing procedures and system documentation, and producing test evidence for an assessor. Platforms such as Wazuh and OpenSearch can forward or index audit data, and OpenBao audit devices keep detailed request logs, but you must confirm each platform's export capabilities for your design. DeployOpen does not issue audit reports or certifications. Your independent assessor does, and the agreed scope should name the decisions that remain with your organization.

Where to read the AU-16 control and assessment text

Start with the NIST CPRT entry for AU-16 in SP 800-53 Release 5.2.0, which shows the control statement, its enhancements and related controls in the official reference tool. Pair it with the OSCAL catalog in the usnistgov/oscal-content repository, where the same control and the SP 800-53A assessment procedure are available in machine-readable form. The assessment procedure is the document your assessor will follow, so read its single determination statement and the examine, interview and test objects it lists. Those objects tell you which policies, procedures, system security plan content, personnel and mechanisms must exist and be shown before a test can pass. Record the release number you used, since the catalog moves to numbered releases and your evidence should cite the same version.

Then confirm the scope decision in the SP 800-53B profiles for the low, moderate, high and privacy baselines. The profile files in the same repository show whether AU-16 and its three enhancements are selected, and the current release does not select them for any baseline. If a contract, authorization package or regulator asks for cross-organizational audit logging, that requirement must come from tailoring or an overlay, and the decision belongs in your system security plan with a stated reason. Ask your compliance lead or assessor to confirm which baseline and release they will use, because they determine what is tested. The NIST SP 800-53B publication page describes how tailoring and overlays are documented.

How DeployOpen scopes and prepares AU-16 evidence

DeployOpen works on AU-16 by preparing the systems, documentation and evidence that show how audit information is coordinated with external organizations when it crosses organizational boundaries. The organization owns its control decisions, and an independent assessor determines whether the control is met.

How we scope

Confirm which external organizations receive audit information and why the flow crosses organizational boundaries.
Record the defined methods for coordinating audit information with each external party in the written scope.
Agree in writing which systems, log sources and documents are in scope before any work starts, since engagements are fixed-scope.

How we build

Configure the self-hosted logging and audit components that carry records to external parties, using the organization's defined methods.
Verify that identities and event context survive transfer, so records remain attributable when a partner reviews them.
Test the cross-organizational audit mechanisms against the defined methods and record the results for the assessor.

How we hand over

Deliver the system design documentation, configuration records and coordination procedures that the assessor will examine for AU-16.
Document the named personnel responsible for coordinating audit information with each external organization.
Walk the organization's team through the evidence so they can explain and maintain it, and confirm the final deliverables list in writing.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if the organization wants help keeping AU-16 evidence current.
Review changes to external partners, data flows or logging tools that could affect how audit information is coordinated.
Coordinate with the organization's chosen independent assessor during their review, while noting that DeployOpen does not issue audit reports or certifications.