AU-9(2): Store on Separate Physical Systems or Components

AU-9(2): Store on Separate Physical Systems or Components is one of the fastest ways to raise your investigation and incident response readiness, because it addresses a common failure mode: the system you are trying to investigate is the same system that can erase the evidence.

For a CCO, GRC lead, or Compliance Officer, the practical challenge is translating “physically different system or system component” into a design you can defend in an audit: what counts as separate, what does not, how often logs must be moved, and what evidence proves the control operates continuously. You also need to align Security, Infrastructure, and Application teams around a single implementation pattern, because partial coverage (for example, only network logs but no identity logs) creates blind spots that show up immediately in examinations.

This page gives you requirement-level implementation guidance: scope, decisions you must make, a step-by-step runbook, and the evidence bundle to retain so you can answer audit questions without rebuilding the story from screenshots and tribal knowledge.

Regulatory text

Requirement (AU-9(2)): “Store audit records [frequency] in a repository that is part of a physically different system or system component than the system or component being audited.” ¹

What the operator must do

1. Define the [frequency] for moving/storing audit records off the audited system (for example: near-real-time forwarding for high-value systems, scheduled batch export for lower-risk systems). The control explicitly leaves frequency as an organization-defined parameter. ¹
2. Ensure the log repository is physically separate from the audited system/component. The intent is to prevent a compromise of the audited system from giving the attacker the ability to delete or alter the audit trail. ¹
3. Operate it continuously, not as a one-time migration. You need monitoring, failure handling, and periodic control health checks because “separate storage” fails silently when forwarding breaks.

Plain-English interpretation

You must get audit logs off the system being audited and into a separate place an attacker cannot easily change after compromising that system. If a database server is the “audited component,” you cannot meet AU-9(2) by keeping logs on the same database server, the same appliance, or the same underlying hardware. You need a separate logging system or component with its own access controls and lifecycle.

A useful mental model for audit conversations:

• Goal: preserve integrity and availability of audit records for investigation.
• Threat: attacker compromises the production system and wipes local logs to hide activity.
• Control: send logs away to a separate system/component so log tampering requires a second, distinct compromise path.

Who it applies to (entity and operational context)

AU-9(2) commonly lands on:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data (including regulated environments aligned to NIST baselines or customer contractual requirements). ²

Operational contexts where AU-9(2) becomes high-priority:

• Systems supporting incident response, fraud investigation, or safety-critical operations.
• Environments with privileged admin access spread across multiple teams.
• Multi-tenant services where a single compromise can affect many customers.
• Third-party hosted workloads where you rely on platform logs and must export them to your own repository.

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

1) Write the control card (owner, scope, frequency, exceptions)

Create a one-page “control card” that an auditor can read in five minutes:

• Objective: audit records are stored on physically separate systems/components.
• Owner: Security Engineering or Platform Security (named role), with Infra as implementer.
• Scope: systems/components required to forward logs (production first; include supporting identity, network, and admin planes).
• Frequency: explicitly define the forwarding/export cadence per system tier. AU-9(2) requires you to specify [frequency]. ¹
• Exceptions: how you approve them, maximum duration, compensating controls, and required sign-off.

2) Decide what “physically separate” means in your architecture

Document a defensible interpretation for your environment:

• Meets intent (typical patterns):
  • Central log platform hosted on separate servers/appliances from production systems.
  • Cloud logging service with logs exported into a separate logging account/subscription/project with restricted admin access.
  • Dedicated SIEM/log archive where production admins do not have delete permissions.
• Often fails in audits (common misreads):
  • Logs stored on the same VM, same host, or same hypervisor cluster as the audited workload without strong separation.
  • Local disk, attached volume, or shared filesystem attached to the same system under the same admin control plane.
  • A “separate” bucket/repo where the same production admins have broad delete rights.

Your standard should state the minimum separation requirement you will accept (separate host, separate logging cluster, separate cloud account boundary, separate administrative control plane). Then apply it consistently.

3) Build the log flow: generate → collect → transmit → store → protect

Implement an end-to-end pipeline with clear ownership:

• Generate: confirm audited systems produce required audit events (authentication, authorization, privilege use, config changes, admin actions, and relevant application events).
• Collect: deploy agents/forwarders or use native platform integrations.
• Transmit: use encrypted transport and authenticated endpoints (so attackers cannot spoof or intercept easily).
• Store: write to the separate repository that satisfies AU-9(2). ¹
• Protect: restrict access, set retention, and prevent deletion/alteration outside an approved process.

4) Lock down administrative access (separation of duties matters)

AU-9(2) is easier to defend when:

• Production system admins cannot delete or modify stored audit logs.
• Log platform admin rights are limited to a small group and require strong authentication.
• Deletion is controlled through a ticketed, approved process with audit trail.

In practice, auditors ask less about your log viewer and more about who can destroy evidence.

5) Prove coverage and detect failures

Add operational checks:

• Coverage mapping: list each in-scope system/component and the log sources it forwards.
• Forwarding health: alerts for missing logs, agent downtime, ingestion failures, and time drift.
• Periodic control health checks: recurring review that the pipeline still works after infrastructure changes (patching, scaling, re-platforming).

Daydream (if you use it) fits naturally here as the system of record for the control card, the evidence bundle definition, and recurring health check tracking tied to remediation items and due dates.

Required evidence and artifacts to retain

Keep an evidence bundle that an auditor can validate without guesswork:

Design & scope

• Control card with scope, [frequency], owner, and exception process.
• Architecture diagram showing audited systems and the physically separate log repository boundary.
• Inventory/mapping of in-scope systems to log sources and destinations.

Configuration & access controls

• Configuration exports/screenshots showing log forwarding destinations and settings.
• Access control list / IAM role mapping for the log repository (who can read, who can administer, who can delete).
• Change management records for log pipeline changes.

Operational proof

• Samples of logs showing timestamps and source identifiers from multiple systems.
• Monitoring alerts or dashboards for ingestion/forwarding health.
• Records of recurring health checks and remediation closures.

Exceptions

• Approved exceptions with risk acceptance, compensating controls, and expiration.

Common exam/audit questions and hangups

Auditors and assessors usually drill into:

• Define [frequency]: “Where is it documented, and is it appropriate for the system’s risk?” ¹
• What is ‘physically different’ here? Expect to explain physical/logical boundaries and administrative separation.
• Can production admins delete logs? If yes, you need a very strong story or a redesign.
• Is forwarding complete and continuous? They may pick a random system and ask you to prove it is sending logs now.
• How do you detect pipeline failure? Silent failure is a common finding.

Frequent implementation mistakes and how to avoid them

1. Calling logical separation “physical”
   Avoidance: document the boundary (separate host/appliance or separate cloud account boundary) and show it in diagrams.

2. Forwarding only “some” logs
   Avoidance: create a coverage matrix and make onboarding to centralized logging part of production readiness.

3. No defined frequency
   Avoidance: set frequency by tier and record it in the control card; tie exceptions to formal approval. AU-9(2) requires an org-defined [frequency]. ¹

4. Same admin group controls production and log deletion
   Avoidance: separate roles, restrict delete, and require approvals for destructive actions.

5. Evidence is screenshots-only and not repeatable
   Avoidance: export configs, keep change records, and store runbooks plus health-check results.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-9(2), so you should treat this as a control assurance and incident survivability requirement rather than a “find a case and map it” exercise.

Risk-wise, AU-9(2) reduces:

• Post-compromise evidence destruction
• Delayed detection due to missing logs
• Inability to support investigations, legal holds, or customer incident reporting

In regulated contracting and federal contexts, failure often shows up as an audit finding because assessors can test it directly: compromise assumptions aside, they can verify where logs land and who can delete them.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Name the control owner and approvers; publish the AU-9(2) control card with [frequency] by system tier. ¹
• Identify the separate logging repository pattern you will standardize on (on-prem or cloud) and document what qualifies as “physically different” in your environment.
• Build the system-to-log-destination coverage matrix for in-scope systems.

Days 31–60 (implement and prove)

• Onboard highest-risk systems first (identity systems, admin planes, internet-facing services, core data stores).
• Restrict log repository permissions; remove delete rights from production admins where possible.
• Stand up ingestion health monitoring and alerting for missing logs and pipeline errors.
• Run a tabletop: “If this production system is compromised, can the attacker erase the audit trail?” Document gaps and fixes.

Days 61–90 (operationalize and audit-proof)

• Expand onboarding to remaining in-scope systems; close coverage gaps from the matrix.
• Implement recurring control health checks with tracked remediation to closure (Daydream can manage the evidence bundle and recurring checks cleanly).
• Package evidence: diagrams, access controls, forwarding configs, sample logs, monitoring outputs, and exception register.

Frequently Asked Questions

Does a separate VM on the same hypervisor meet “separate physical systems or components”?

Often no, because the underlying hardware and administrative plane may be shared. Document your boundary and be prepared to justify that a compromise of the audited component cannot modify the stored audit records. ¹

Can we meet AU-9(2) with a managed cloud logging service?

Yes, if logs are stored outside the audited system/component and you can show strong administrative separation and protection from deletion or alteration. Your evidence should include the destination architecture and access controls. ¹

What should we pick for the [frequency] field?

Set it by risk tier and document it explicitly in the control card; auditors will look for a defined cadence and proof it is met. If you need exceptions, time-box them with approvals and compensating controls. ¹

If logs are forwarded off-host but stored in the same cloud account, is that enough?

It depends on whether admins of the audited systems can also administer or delete the log repository. Many teams strengthen this by using a separate logging account/project with restricted roles to make log tampering require a distinct compromise path.

What evidence is most persuasive in an audit?

A clear architecture diagram plus a coverage matrix, access-control proof showing who can delete, and monitoring evidence showing ingestion is healthy. Add a small set of representative log samples from multiple systems with timestamps and source identifiers.

How do we operationalize this without creating a constant scramble for screenshots?

Define a minimum evidence bundle (what, where stored, and who approves), then run recurring health checks with tracked remediation. A GRC system like Daydream helps by standardizing the control card, evidence requests, and review cadence.

Footnotes

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

2. NIST SP 800-53 Rev. 5