Cyber · Trackr The Free Compliance Library
⌘K
AU · Plan wizard

Audit and Accountability Plan

Documents how the system generates, protects, retains, and reviews audit records to support accountability, anomaly detection, and forensic investigation. Covers the controls of the AU family in NIST SP 800-53 r5 and aligns with NIST SP 800-92 (Guide to Computer Security Log Management).

1 System metadata
Full official name of the information system.
Short identifier used in headings and references.
Role or named individual accountable for the system.
Describe what falls inside the authorization boundary - components, services, networks, data flows.
2 Baseline
Determines which controls in this family appear in your plan.
3 Audit and Accountability approach
Approach basics → §4.x

SIEM tooling, ingestion pipeline, and where audit records ultimately land.

Authoritative platform for audit records (e.g., Splunk Enterprise Security, Microsoft Sentinel, Elastic Security, Sumo Logic, Chronicle, Graylog, AWS CloudWatch + Athena).
How audit records get from generators to the SIEM. Mention agents (Splunk Universal Forwarder, Fluent Bit, Vector), kinesis / kafka pipelines, syslog relays, and any intermediate parsing.
Primary log encoding the SIEM ingests. JSON or OCSF is increasingly common for structured analytics.
Brief phrase describing protection (e.g., 'WORM-tier S3 + KMS encryption + RBAC restricting log access to the SOC group'). Detailed approach goes in the dedicated sub-section.
Event Inventory → §4.x

What categories of events are logged, and what data each record carries.

AU-2 requires periodic review of which events are logged. Most plans review annually + on material change.
Log Protection → §4.x

Tamper protection, access controls, and encryption for audit records.

How audit records are protected from unauthorized modification (WORM storage, hash chains, signed batches, immutable object lock).
Roles with each level of access. Reference AC-5 separation-of-duties — audit reviewers should not have administrative authority over the audit system itself.
Mechanism + key custody (e.g., 'AWS KMS customer-managed key in the SOC account; key admin separated from log readers').
Transport security between log sources, forwarders, and SIEM (TLS 1.2+ with mutual authentication preferred).
Log Review and Analysis → §4.x

Automated correlation, manual review, and SOC integration.

Categories of automated rules (failed-auth threshold, privilege escalation, data exfiltration patterns) and where they're authored / tuned.
Role accountable for ensuring review happens (often 'Tier 2 SOC analyst' or 'ISSO + SOC partnership').
What happens when review surfaces a probable incident — who's paged, what's logged in the IR tracker, who can authorize containment.
Audit Failure Response → §4.x

What the system does when audit-logging itself fails (AU-5).

Who is paged on audit failure (PagerDuty rotation, security email distribution).
Free space remaining that triggers a warning (e.g., '20% free' or '7 days of headroom at current ingest rate').
Privacy and Redaction → §4.x

What the system masks or redacts in audit records to balance investigative value with privacy.

Where redaction occurs (forwarder vs SIEM ingestion pipeline). Hash vs replace-with-token vs remove.
Pointer to the privacy assessment (PIA / SORN reference) governing audit-record handling.
Audit Volume and Scope → §2.x

Order-of-magnitude scope of the audit pipeline.

How many distinct sources feed the SIEM (hosts, containers, applications, network appliances).
Order of magnitude (e.g., '~10M events/day', '~50 GB ingest/day').
Multiple of baseline volume seen at peak (e.g., '3x normal during patch Tuesday').
Retention and Storage Strategy → §6.x

Online vs cold-archive split, retention period, and storage tiers.

How long records remain queryable in the SIEM without restore (e.g., '90 days').
How long records remain in cold storage before destruction (e.g., '7 years per NARA GRS 4.2').
Combined online + archive period in narrative form (e.g., '90 days online + 7 years cold archive').
Storage classes: hot (S3 Standard / Splunk indexer), warm (S3 IA), cold (S3 Glacier Deep Archive / Azure Archive).
How records are destroyed at end of retention. Verification / certificate of destruction. References NARA schedule if federal.
Time Synchronization → §6.x

Authoritative time source and accuracy verification (AU-8).

Stratum-1/2 NTP server or vendor service (e.g., 'Internal Stratum-2 NTP servers synced to USNO Master Clock', 'AWS Time Sync Service').
Threshold beyond which a host is flagged (e.g., '100 ms').
How drift is detected and remediated (SIEM rule, daily script, NTP-monitor integration).
Audit Metrics & KPIs → §6.x

Metrics tracked to demonstrate AU control effectiveness over time.

    Suggested:
    Cross-references to other RMF artifacts → §7

    Where this plan plugs into the broader RMF package.

    Where in the SSP the AU control implementations are summarized (e.g., 'SSP §13.3').
    Convention for AU-related POA&M items (e.g., 'POAM-AU-').
    How authentication / authorization events from the AC family land in the audit pipeline. Pointer to the AC plan if separate.
    How audit detections feed System Monitoring (SI-4). Reference SOAR playbook locations.
    Pointer to the CA-7 monitoring strategy document tying AU continuous-monitoring activities to the broader ConMon plan.
    4 Per-control implementation

    Pick a baseline in section 2 and the applicable controls will appear here. Each control gets a card with the official text, related controls, linked CCIs, and fields for your implementation status, narrative, responsible role, and evidence.

    5 Document metadata

    Your answers autosave to this browser. Click Save progress to download a JSON file you can re-upload later or share.