AU-16: Cross-organizational Audit Logging

AU-16 requires you to coordinate audit logging with external organizations whenever audit information crosses an organizational boundary, so logs remain trustworthy, consistent, and usable during investigations. Operationalize it by documenting which cross-boundary log flows exist, agreeing on shared logging/handling rules with each third party, and retaining evidence that those rules are implemented and monitored. ¹

Key takeaways:

• Identify every place audit data leaves or enters your environment, including managed services, SaaS, and shared platforms.
• Put cross-organization logging expectations into contracts, integration runbooks, and technical configurations.
• Keep assessor-ready evidence: data-flow maps, logging agreements, configs, and test results. ²

The au-16: cross-organizational audit logging requirement shows up when your audit logs or audit-relevant events move between you and a third party, a partner network, a customer environment, or a shared service. That includes common patterns like forwarding security logs to a managed SOC, sending cloud audit trails to a central SIEM, receiving identity events from an external IdP, or operating workloads in a customer-controlled environment where you must provide audit evidence.

AU-16 is narrower than “log everything.” It is about coordination across boundaries: aligning what gets logged, how it is formatted and protected, how time is synchronized, how custody is maintained, and how each side responds if logs are missing or disputed. The control text is short, but assessors expect you to prove two things: (1) you know where cross-boundary audit information exists, and (2) you have defined and implemented a coordination mechanism with each external organization involved. ¹

If you treat AU-16 as a contract-only checkbox, you will fail in operations. If you treat it as engineering-only, you will lack the paper trail. You need both, wired into your third-party risk management and your logging pipeline.

Regulatory text

NIST AU-16 states: “Employ {{ insert: param, au-16_odp.01 }} for coordinating {{ insert: param, au-16_odp.02 }} among external organizations when audit information is transmitted across organizational boundaries.” ¹

What the operator must do:
When audit information crosses a boundary, you must have a defined method (a “mechanism” in plain terms) to coordinate audit logging expectations with the external organization. The coordination must cover the audit information being exchanged, and it must be in place for the actual cross-boundary transmissions you operate, not just in a generic policy. ²

Because the parameters are organization-defined in the catalog text, your job is to define them for your environment (what mechanism, what aspects of logging you coordinate) and then show they are implemented for each relevant third party relationship. ¹

Plain-English interpretation (what AU-16 means in practice)

AU-16 means: if you send logs to someone else, receive logs from someone else, or rely on someone else’s systems to generate audit evidence, you need shared rules so everyone can reconstruct what happened.

Coordination typically needs answers to questions like:

• Which events are considered audit-relevant for the shared service?
• Who is the system of record for each event type?
• What time source is used, and what happens if timestamps disagree?
• How are logs protected in transit and at rest, and who can access them?
• What is the retention expectation, and how do you request extracts for investigations?
• How do you detect and respond to log gaps or pipeline failures?

AU-16 sits alongside other AU-family controls, but it is distinct: it focuses on cross-organizational audit data flows and the agreements and operational hooks that make that audit data defensible. ²

Who it applies to (entity and operational context)

Entity types commonly in scope:

• Federal information systems and contractors handling federal data (including cloud, managed services, and integrators) ²

Operational contexts that trigger AU-16:

• You forward logs to a third-party SOC/MSSP or IR retainer platform.
• Your SaaS depends on third-party infrastructure logging (cloud provider audit trails, platform logs).
• You ingest security telemetry from a customer environment (BYO cloud, private deployment).
• You use an external identity provider (IdP) and need authentication/audit events.
• You transmit audit data across enclaves, tenants, or partner networks where another organization operates the receiving endpoint.

If any of those are true, AU-16 becomes an execution requirement for your logging program and your third-party risk program, not a policy statement.

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

1) Build a cross-boundary audit log inventory

Create a list of every integration where audit information crosses boundaries. Tie each to:

• Sending system and receiving system
• Third party name and service owner
• Data types (auth events, admin actions, API activity, config changes, SIEM alerts)
• Transport (API, syslog, agent, webhook, file export)
• System of record and downstream consumers

Output artifact: “Cross-Organizational Audit Logging Register” (a table is fine).

2) Define your AU-16 coordination mechanism (your “standard”)

Pick a mechanism you can repeat across third parties. Common patterns:

• Contract clauses + security addendum + technical integration runbook
• Joint logging specification (fields, formats, time standard, event taxonomy)
• Incident response and eDiscovery procedure for log requests
• Shared responsibility matrix (who generates, forwards, stores, monitors)

Make it explicit which topics are mandatory for each relationship:

• Event scope and minimum fields
• Time sync expectations (source of time, timezone handling)
• Integrity controls (hashing, signing, immutability expectations)
• Access control and segregation of duties
• Retention and disposal
• Monitoring and alerting on pipeline health
• Investigation support (RACI for log requests)

Tip for GRC operators: Put this into a template annex so procurement and legal do not renegotiate from scratch each time.

3) Classify each cross-boundary flow by risk and assurance need

You do not need identical rigor everywhere. You do need a defensible rationale. Create tiers such as:

• Tier A: Logs needed for security investigations or compliance evidence (admin actions, auth, key changes)
• Tier B: Operational logs that support troubleshooting but are not primary evidence
• Tier C: Non-sensitive telemetry

Then map tier to requirements. Example: Tier A requires immutable storage or equivalent compensating controls, documented access controls, and tested retrieval.

4) Put coordination into third-party obligations (contract + operating model)

For each third party in the register:

• Add logging and audit evidence obligations to the MSA/SOW/security addendum.
• Define SLAs for log availability and log request turnaround as internal requirements (even if you keep external contract language qualitative).
• Require notice of changes that affect logging (platform upgrades, schema changes, retention changes).
• Require cooperation during incident response involving audit evidence.

Daydream fit: Daydream can track AU-16 as a requirement with a named control owner, a repeatable procedure, and a recurring evidence checklist so you can show consistent operation across your third-party portfolio. ¹

5) Implement the technical controls for cross-boundary transmission

Coordinate with Security Engineering and the service owner to ensure:

• Logs are transmitted over authenticated, encrypted channels appropriate to your architecture.
• Source identity is preserved (service account identity, tenant identifier, customer ID).
• Time is normalized (consistent timezone, validated time source on log producers).
• Schema mapping is documented (field mapping into SIEM, parsing rules).
• Replay and duplication behaviors are understood (idempotency keys, dedup rules).

6) Add monitoring for the logging pipeline itself

Most AU-16 failures are operational: logs stop flowing and no one notices. Implement:

• Heartbeat alerts for each log source
• Volume anomaly alerts (sudden drop to zero, unexpected spikes)
• Parsing failure monitoring (schema drift)
• Backpressure/queue failure alerts

Document who responds and what “good” looks like.

7) Test retrieval across the boundary (tabletop + technical pull)

At least once per major integration change, perform a practical test:

• Request a defined time window of audit events from the third party (or confirm your ability to retrieve them).
• Validate completeness, timestamp consistency, and actor attribution.
• Store the test results as evidence.

This is where assessors gain confidence that the coordination mechanism works in real life.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design evidence

• Cross-Organizational Audit Logging Register (system-to-system data-flow list)
• AU-16 standard / logging coordination template (contract annex + runbook template)
• Shared responsibility matrix per third party relationship
• Architecture diagram showing log flow across boundaries

Operational evidence

• Executed agreements or security addenda with logging obligations (redacted as needed)
• Integration runbooks (how logs are forwarded, parsed, stored)
• Configuration snapshots (SIEM connectors, API integrations, agent configs)
• Monitoring alerts and tickets for log pipeline failures (with resolution notes)
• Periodic test results for log retrieval and integrity checks
• Change records for schema/connector changes that affected logging

Daydream-style control mapping helps here: assign an owner, define the procedure, and define what evidence is collected on a recurring basis so you are not scrambling at assessment time. ¹

Common exam/audit questions and hangups

Assessors typically press on these points:

• “Show me all places audit data crosses your boundary.” They will compare your list to vendor inventory, network diagrams, and SIEM sources.
• “Where is the agreement with the third party that covers audit logs?” A policy alone rarely satisfies AU-16 intent.
• “If logs are disputed, how do you prove integrity and chain-of-custody?”
• “How do you know logs are complete?” Expect questions about pipeline monitoring and gaps.
• “Who is responsible when the third party changes a log schema?” If you do not have a change-notice mechanism, parsing failures become silent failures.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating AU-16 as a generic policy statement.
   Fix: Tie AU-16 to a per-integration register and per-third-party artifacts.

2. Mistake: No single owner for cross-boundary logging.
   Fix: Assign ownership to Security Operations or Platform Security, with GRC owning the requirement and evidence collection.

3. Mistake: Assuming the SIEM receiving logs equals “coordination.”
   Fix: Add explicit agreements on scope, retention, access, and change management.

4. Mistake: Ignoring customer-hosted or partner-hosted deployments.
   Fix: Include customer environments where you depend on their logs (or where they depend on yours) in the register, with a defined evidence exchange process.

5. Mistake: No proof of operational testing.
   Fix: Run periodic retrieval tests and retain the output, tickets, and sign-off.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-16, so you should treat this as an assessment-readiness and incident-readiness control rather than an enforcement-citation checklist.

Operationally, AU-16 gaps create predictable risk:

• You cannot reconstruct incidents that traverse third parties (identity, cloud, managed SOC).
• You cannot prove what happened when responsibilities are split.
• You lose time during investigations because log requests and formats are ad hoc.
• You face assessment findings for missing evidence that cross-boundary audit information is coordinated. ²

Practical 30/60/90-day execution plan

First 30 days: establish scope and ownership

• Name the AU-16 control owner and backups.
• Build the Cross-Organizational Audit Logging Register from vendor inventory + SIEM source list.
• Select your coordination mechanism template (contract language + runbook sections).
• Identify the top high-impact integrations (identity, cloud audit trail, SOC/MSSP, critical SaaS).

Next 60 days: implement coordination for highest-risk flows

• Update agreements or security addenda for top integrations to include audit logging coordination requirements.
• Publish per-integration runbooks with schema, transmission method, retention expectations, and escalation paths.
• Implement pipeline health monitoring for each Tier A flow and route alerts to an owned queue.

Next 90 days: prove operation and scale

• Execute retrieval tests for Tier A integrations; store results as evidence.
• Close gaps found in parsing, timestamp normalization, or missing actor attribution.
• Expand coordination and monitoring to remaining tiers.
• In Daydream, link each third party relationship to AU-16 evidence tasks so collection is recurring, not manual. ¹

Frequently Asked Questions

Does AU-16 apply if we only send logs to a third-party SIEM or SOC?

Yes, if audit information is transmitted across your boundary you need coordination with that external organization on audit logging expectations and handling. Treat the SOC/MSSP relationship as a cross-boundary audit evidence pipeline. ¹

What counts as “audit information” for AU-16?

In practice, it includes security-relevant and compliance-relevant events used to reconstruct actions, such as authentication, privilege changes, administrative actions, and configuration changes. Define your scope in your AU-16 standard and apply it per integration. ²

Can we satisfy AU-16 with contract language alone?

Contract language helps, but assessors often expect to see the technical implementation and operational monitoring that matches the agreement. Pair the contract annex with runbooks, configurations, and retrieval test evidence. ¹

How do we handle AU-16 for customer-managed deployments where the customer controls logging?

Document the boundary and define an evidence exchange process: what logs the customer must provide, how requests are made, required fields/timezone, and how integrity is validated. Put it in the customer agreement and the deployment runbook.

What if a third party refuses to commit to specific retention or access terms?

Record the exception, document compensating controls (for example, forwarding critical events into your controlled logging store), and update the risk acceptance with the service owner. The key is to show a deliberate coordination mechanism and a managed residual risk. ²

How should we present AU-16 evidence during an assessment?

Start with the register of cross-boundary log flows, then provide one complete example package (agreement excerpt, runbook, config snapshots, monitoring proof, and a retrieval test). After that, show that the same template is used across the rest. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5