AU-16: Cross-organizational Audit Logging

What this control requires

AU-16 requires organizations to establish coordinated methods for sharing and protecting audit information whenever that information crosses organizational boundaries. The control targets a specific gap. When your systems interact with external organizations’ systems, audit trails don’t automatically follow the transaction from end to end.

In practice, this means defining what audit data gets exchanged, how identities are tracked across system boundaries, and what protections apply to that data in transit and at rest. The NIST SP 800-53 framework recognizes that preserving individual identity across organizational lines is often impractical due to performance overhead and privacy constraints. Instead, the typical approach captures the requesting user’s identity at the originating system, while downstream systems simply record that the request came from an authorized source.

Where this breaks down is in the agreements themselves. Organizations that skip the step of formalizing audit coordination in their information exchange agreements end up with fragmented logs that can’t support incident reconstruction. The control pushes you to address audit logging requirements before the data starts flowing — not after an incident reveals the gap.

Why it matters

Cross-organizational audit logging sits at the intersection of two trends that aren’t slowing down: the growth of outsourced services and the tightening of regulatory expectations around accountability. When your audit and accountability posture stops at your own network boundary, you lose visibility into exactly the transactions that carry the most risk.

But the gap that auditors actually find is not a missing log file — it’s the absence of any agreement about what should be logged. Organizations routinely exchange data with cloud providers, managed service providers, and partner organizations without specifying what audit events each party captures, how long they retain them, or how they’ll share them during an investigation. The result is a patchwork of logs that can’t be correlated.

The result is direct audit risk that can lead to certification withdrawal or regulatory findings. Federal agencies and contractors operating under the Federal Information Security Management Act face direct scrutiny on cross-boundary logging during assessments. For organizations pursuing or maintaining FedRAMP authorization, the inability to demonstrate coordinated audit practices with external service providers is a documented weakness that assessors flag.

What attackers exploit

• Blind spots at trust boundaries: Attackers move laterally between connected organizations knowing that logs from one side rarely reach the other’s security operations center.
• Identity discontinuity: When user identity isn’t preserved across systems, attributing malicious actions to a specific actor becomes impossible after a boundary crossing.
• Unmonitored API integrations: Service-to-service connections between organizations often lack the same audit rigor applied to human user activity.
• Delayed incident detection: Without coordinated logging, indicators of compromise visible in one organization’s logs never surface in the partner’s detection workflows.

How to implement

The most common failure mode for AU-16 isn’t a technology gap — it’s a process gap. Organizations invest heavily in their own security information and event management (SIEM) infrastructure but never extend audit coordination requirements into vendor contracts or interconnection agreements.

For your organization

Step 1 — Inventory cross-boundary data flows. Map every system-to-system and user-to-system interaction that crosses an organizational boundary. Include cloud services, managed security providers, SaaS platforms with API integrations, and partner data exchanges.

Step 2 — Define audit information requirements per flow. For each boundary crossing, specify what events are logged (authentication, authorization decisions, data access, configuration changes), what data fields each log entry must contain, and who is responsible for generating and retaining each record.

Step 3 — Embed requirements in exchange agreements. Add audit coordination clauses to interconnection security agreements (ISAs), memoranda of understanding (MOUs), and service-level agreements (SLAs). Specify log formats, retention periods, and sharing procedures for incident response. Organizations pursuing NIST 800-53 compliance should treat these clauses as auditable artifacts.

Step 4 — Implement identity tracking at boundaries. Decide how user identity will be handled at each boundary. Options range from full identity preservation (where technically feasible) to recording the originating organization and authorization status without individual identity.

Step 5 — Establish log sharing procedures. Define how and when audit records will be shared — real-time forwarding via syslog or API, periodic batch transfers, or on-demand requests during investigations. Ensure that audit tools used by each party can ingest the agreed-upon formats.

Common mistakes:

• Assuming cloud providers’ native logging satisfies AU-16 without verifying what’s actually captured
• Defining audit requirements after the integration is live, rather than during the agreement phase
• Failing to test log sharing procedures before an actual incident forces their use
• Neglecting privacy implications when preserving individual identity across boundaries

For your vendors

What to ask in a security questionnaire:

• How do you log and attribute actions initiated by our users or systems within your environment?
• What audit events do you capture for cross-organizational transactions?
• Can you provide audit records in a format compatible with our SIEM or log aggregation platform?
• What is your retention period for audit logs related to our data and transactions?
• How do you handle identity tracking for requests originating from external organizations?

Evidence to request from vendors:

• Sample audit log entries showing cross-boundary transaction recording
• Documentation of log retention policies applicable to your organization’s data
• Interconnection security agreement or audit coordination addendum
• Evidence of periodic review and testing of cross-organizational audit procedures

Red flags:

• Vendor cannot describe what events are logged for your organization’s transactions
• No formal process exists for sharing audit records during incident response
• Log retention periods are undefined or shorter than your regulatory requirements
• Vendor treats compliance and auditing as separate concerns with no documented coordination

Verification beyond self-attestation: Request a live demonstration of log retrieval for a recent transaction involving your organization. Confirm that the vendor’s logs contain the data fields specified in your exchange agreement. For critical vendors managing third-party risk, consider periodic audit log reconciliation exercises where both parties independently produce records for the same transaction window and compare results.

Evidence examples

Cross-framework mapping

No cross-framework mappings are configured for this control.

Related controls

• AU-03 — Content of Audit Records: Defines what data fields each audit record must contain — directly determines what information is available for cross-organizational exchange under AU-16.
• AU-06 — Audit Record Review, Analysis, and Reporting: Establishes the review and analysis processes that consume cross-organizational audit data shared under AU-16.
• AU-07 — Audit Record Reduction and Report Generation: Provides the tooling to process and reduce the volume of cross-organizational audit records into actionable reports.
• CA-03 — Information Exchange: Governs the agreements and protections for information exchanged between organizations — the contractual foundation on which AU-16’s audit coordination clauses are built.
• PT-07 — Specific Categories of Personally Identifiable Information: Addresses privacy constraints on PII in audit records, directly relevant when AU-16 requires decisions about preserving individual identity across boundaries.

Frequently asked questions

What is NIST SP 800-53 AU-16

AU-16 requires organizations to define and use specific methods for coordinating audit information with external organizations whenever audit data crosses organizational boundaries. The control addresses the operational challenge of maintaining accountability when transactions span multiple organizations’ systems. You need to specify what events are logged, how identities are tracked, and how audit records are protected and shared — all formalized in your information exchange agreements before data flows begin.

What happens if AU-16 is not implemented

Without AU-16, your organization loses the ability to reconstruct cross-boundary transactions during an incident investigation. Audit trails end at your network perimeter, leaving you unable to trace a compromised account’s actions into a partner’s or vendor’s environment. Auditors will flag the absence of cross-organizational audit coordination as a control gap, and in federal environments, this gap directly affects your authorization to operate. The downstream effect is slower incident response, incomplete forensics, and a weaker negotiating position when coordinating with external parties after a security event.

How do you audit AU-16

Auditors assess AU-16 by examining your information exchange agreements for explicit audit coordination clauses, reviewing your cross-organizational audit procedures for completeness, and testing whether your systems actually capture the required audit data at organizational boundaries. They look for evidence that you’ve defined which audit information is shared, how identity is handled across boundaries, and what protections apply to audit data in transit. Expect auditors to interview staff responsible for cross-organizational audit coordination and to request sample log entries from boundary systems to verify that documented procedures match operational reality.

What are the control enhancements for AU-16

AU-16 has three control enhancements that extend its base requirements. AU-16(1) Identity Preservation requires maintaining individual user identity across organizational audit trails — useful when full attribution is legally or operationally required. AU-16(2) Sharing of Audit Information mandates providing cross-organizational audit data to specified organizations under defined sharing agreements. AU-16(3) Disassociability requires implementing measures to separate individual identity from audit records transmitted across boundaries, addressing privacy concerns when identity preservation isn’t appropriate or legally permissible.