AU-14: Session Audit

AU-14: session audit requirement means you must be able to record and review the actual content of certain user sessions (not just logins and timestamps) under defined conditions. Operationalize it by scoping which privileged and high-risk sessions qualify, selecting an approved recording method, protecting the recordings, and proving through evidence that recording and review occur. ¹

Key takeaways:

• Define exactly which sessions are in scope (roles, systems, triggers) and document the conditions for recording. ¹
• Implement a technically reliable way to capture session content (commands/screens/keystrokes) and secure the recordings end-to-end. ²
• Treat recordings as sensitive audit records: access control, integrity controls, retention, and review workflow with provable artifacts. ²

Session audit is the difference between knowing “an admin logged in” and being able to answer, with evidence, “what actions occurred during that session.” AU-14 pushes you toward that higher-fidelity visibility by requiring a capability to audit the content of a user session under defined conditions. ¹

For a CCO or GRC lead, the fastest path is to treat AU-14 as a scoped, testable control: you define what “session” means in your environment, which sessions are risky enough to record, what “content” means (screen video, command stream, proxy logs), and what conditions trigger recording (always for privileged access, only for production, only for break-glass, only for certain data types). Then you implement the technical capture and the governance around it: who can access recordings, how integrity is protected, how long you keep them, and how you prove reviews happen.

This requirement page focuses on execution: scoping decisions, implementation steps, evidence to retain, and the audit questions that derail teams. It also calls out the most common failure mode: having a tool that can record sessions, but no documented conditions, no consistent activation, and no durable evidence trail.

Regulatory text

NIST AU-14 (Session Audit) excerpt: “Provide and implement the capability for [organization-defined] to [organization-defined] the content of a user session under [organization-defined conditions]; and …” ¹

Operator meaning: AU-14 is intentionally parameterized. You must fill in three decisions and then implement them:

1. Who/what performs session auditing (for example, a privileged access management system, bastion host, VDI gateway, OS audit tooling, or application-layer session capture). ¹
2. What “audit the content” means in your environment (for example, record screens, capture commands, capture keystrokes, capture database queries, capture API calls tied to an interactive session). ²
3. Under what conditions you record and can later review session content (for example, all privileged sessions to production, break-glass sessions, sessions involving regulated data, sessions from unmanaged devices, or sessions by third-party administrators). ¹

A clean implementation reads like a control statement that an auditor can test: “For [in-scope systems], we record [defined session content] for [defined in-scope session types] and retain recordings for [defined retention], with access restricted to [defined roles] and periodic review documented.”

Plain-English interpretation (what AU-14 is really asking)

AU-14 expects reconstructability. If an incident, outage, or allegation arises, you should be able to replay or reliably reconstruct what happened in a session that mattered. Standard authentication logs and admin activity events often cannot do that alone, especially where actions occur through interactive shells, remote desktops, database consoles, or management planes.

A pragmatic interpretation you can defend:

• Session content capture is risk-based. You do not need to record every employee’s browser session. You do need a defensible scope for sessions that can cause material harm. ²
• It must be implemented, not aspirational. “Our PAM tool has recording capability” fails if it is not enabled under documented conditions and producing retained records. ¹
• Recordings become audit records. You must protect them from tampering and inappropriate access because they can contain secrets, personal data, or sensitive system information. ²

Who it applies to (entity and operational context)

AU-14 is commonly applied where NIST SP 800-53 is in scope, including:

• Federal information systems and their supporting environments. ²
• Contractor systems handling federal data (for example, environments supporting federal contracts where 800-53 is required by the customer or incorporated into the system security plan). ²

Operationally, AU-14 is most relevant for:

• Privileged access to production infrastructure (servers, cloud control planes, Kubernetes, network devices).
• Privileged access to security tooling (EDR consoles, SIEM, IAM, key management).
• Database administration sessions where query history and interactive tools matter.
• Third-party support sessions (MSPs, incident response retainers, SaaS administrators) where accountability and replay are needed.

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

1) Set the control owner and RACI

Assign a control owner who can coordinate IAM/PAM, SecOps, and Infra. Write RACI for:

• Scope definition (GRC + system owners)
• Tooling configuration (Infra/SecOps)
• Review and exceptions (SecOps + GRC)
• Evidence production (GRC)

Daydream fit: Create a single AU-14 control record with an owner, implementation procedure, and recurring evidence checklist so you can pass audits without re-inventing the narrative each cycle. ¹

2) Define “session” and “content” for your environment

Document:

• Session types: SSH, RDP, VDI, bastion-proxied shell, web admin consoles, database consoles, cloud console sessions.
• Content types: screen recording, command transcript, keystrokes, file transfer metadata, executed queries/commands, admin console actions.

Decision tip: Prefer command and transaction capture where possible for searchability, and screen capture for tools that do not generate reliable command logs.

3) Define the conditions that trigger recording (your AU-14 parameters)

Create a scope matrix (this is a high-yield artifact for auditors):

In-scope condition	Example	Recording requirement
Privileged role	root/admin/DBA/security admin	Required
Environment	production or regulated enclave	Required
Access path	via bastion/PAM jump host	Required
Break-glass	emergency elevation	Required + flagged for review
Third party	MSP/contractor admin	Required + tighter access to playback

Make exceptions explicit (for example, “no recording for legacy device X” plus compensating controls and a remediation plan). AU-14 allows organization-defined conditions, but auditors expect those conditions to be risk-justified and consistently enforced. ¹

4) Implement session capture architecture

Common patterns that satisfy AU-14 when configured correctly:

• PAM with session recording (proxy-based for SSH/RDP; integrates with vaulting and approval).
• Bastion host / jump server recording for administrative entry points.
• VDI-based admin workstations with recording at the broker/session layer.
• Application-layer session logging for admin consoles (where a “session” is within the app, not the OS).

Minimum technical expectations to design for:

• Recording cannot be trivially bypassed for in-scope sessions.
• Recordings are time-synchronized and tied to an authenticated identity.
• Storage is resilient and access is logged. ²

5) Protect session recordings as sensitive audit records

Treat recordings as high-risk data:

• Restrict access to a small set of roles (SecOps, internal audit, designated admins).
• Enforce MFA and strong authorization for playback/download.
• Encrypt in transit and at rest.
• Maintain integrity protections appropriate for audit records (for example, tamper-evident storage, immutable logging where available). ²

Also handle privacy and secrets:

• Session content can contain passwords, tokens, personal data, customer data, or proprietary code.
• Define redaction/masking where tooling supports it, and define who can view unredacted recordings.

6) Define review, alerting, and “when do we actually look?”

AU-14 is about capability and implementation, but audit teams frequently test whether you can use the recordings. Define:

• Review triggers: break-glass, privileged actions on crown-jewel systems, anomalies, incident tickets, or change windows.
• Sampling approach: periodic sampling of recorded sessions for policy adherence.
• Escalation workflow: what happens when suspicious activity is observed.

Keep it simple: a lightweight checklist plus ticket evidence beats an elaborate process no one follows.

7) Test the control and make it repeatable

Run a tabletop test:

• Start an in-scope session.
• Perform a few actions (create a user, change a firewall rule, run a database query).
• Retrieve the recording and confirm it is tied to the correct identity and timestamp.
• Confirm access controls prevent unauthorized playback.
• Document the test as evidence. ²

Required evidence and artifacts to retain

Auditors look for “defined, implemented, operating.” Keep:

• AU-14 control statement with filled parameters (who audits, what content, what conditions). ¹
• Scope matrix of in-scope systems, roles, and access paths.
• Architecture diagram of session capture flow (user → PAM/bastion → target; recording store; access controls).
• Configuration evidence (screenshots/exports) showing recording enabled for in-scope targets and roles.
• Access control listing for who can view/export recordings and the approval process.
• Sample recordings or metadata exports (with sensitive content handled appropriately) demonstrating actual capture.
• Review evidence (tickets, case notes, sampling logs) showing recordings are reviewed when triggered.
• Exception register for gaps, with compensating controls and remediation tracking.

Daydream fit: Store these artifacts against the AU-14 control and set an evidence cadence so you can produce the same package each audit with minimal scramble.

Common exam/audit questions and hangups

Expect these questions:

1. “Which sessions are recorded, exactly?” If you cannot name roles, systems, and conditions, you will lose time in the exam.
2. “Can an admin bypass recording?” Auditors often ask for a demonstration path and will probe alternate access routes.
3. “Who can watch recordings, and is that access logged?” Playback access is privileged.
4. “Show me a recording from last month for a privileged session.” They want operational proof, not capability slides.
5. “What about third-party access?” Auditors look for parity: third-party admins should not be a blind spot.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Recording is enabled only on some jump hosts. Fix by enforcing “all admin access must traverse recorded pathways” through network controls and IAM policy.
• Mistake: Recording exists, but identity mapping is weak. Fix with strong authentication, shared account elimination, and session attribution in the recording metadata.
• Mistake: Everyone in IT can view recordings. Fix with least privilege, documented approvals, and logging for playback/export.
• Mistake: No documented “conditions.” Fix with a one-page scope/conditions matrix tied to risk and system categorization. ¹
• Mistake: Recordings retained but never reviewed. Fix with trigger-based reviews and simple sampling tied to change management and incident response.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-14, so you should treat this as an assessment-readiness and risk-reduction control rather than a “case law” control in this write-up.

Risk implications to brief leadership:

• Without session content, investigations rely on partial logs and testimony, which slows containment and can weaken accountability.
• Session recordings can expose sensitive data if mishandled; implement strict access controls and retention discipline. ²

Practical 30/60/90-day execution plan

Your prompt requires speed, but numeric day targets risk implying a universal timeline. Use phases you can run quickly and track in a plan of action.

Immediate phase (establish scope + governance)

• Name control owner, approvers, and evidence owner.
• Draft AU-14 parameters: who audits, what content, what conditions. ¹
• Inventory privileged access paths (PAM, bastion, direct SSH, cloud consoles, third-party VPN).
• Identify top systems where a recorded session would matter most (crown jewels).

Near-term phase (implement + prove)

• Turn on session recording for the highest-risk access path first (often PAM or bastion).
• Block or tightly restrict non-recorded admin paths.
• Implement secure storage and restrict playback permissions.
• Run and document an end-to-end test: record, retrieve, and review a session. ²

Ongoing phase (operate + audit readiness)

• Add remaining in-scope systems and session types.
• Implement review triggers and periodic sampling with ticket evidence.
• Maintain an exceptions register with compensating controls and remediation.
• Package recurring evidence in Daydream (control narrative + artifacts + test results) for repeatable audits.

Frequently Asked Questions

Does AU-14 require recording every user session?

No. AU-14 is parameterized around organization-defined conditions, so you scope the requirement to sessions where content capture is justified and then implement it consistently. ¹

What counts as “session content” for AU-14?

“Content” should allow reconstruction of actions taken during the session, such as command transcripts for SSH or screen recordings for GUI admin tools. Your definition must be documented and testable. ²

If we have strong system logs (AU-2/AU-12), do we still need AU-14?

Often yes for privileged interactive access, because standard logs may not capture full context or may be incomplete for certain tools and consoles. AU-14 specifically targets session content capability under defined conditions. ¹

How do we handle privacy and sensitive data in recordings?

Treat recordings as sensitive audit records: restrict access, encrypt storage, and define who can view or export content. If your tooling supports masking, document when it applies and when it does not. ²

What’s the minimum evidence an auditor will accept to show AU-14 is operating?

A clear scope/conditions statement, configuration evidence that recording is enabled for in-scope sessions, and samples of recording metadata or playback plus a review ticket tied to a trigger event. ²

How should third-party administrators be handled under AU-14?

Include third-party privileged access in your in-scope conditions and route it through the same recorded access paths, with tighter playback permissions and explicit approvals. Keep an exceptions register if any third-party access cannot be recorded yet. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5