AU-14: Session Audit

What this control requires

AU-14 requires organizations to implement session-level auditing capabilities that capture the content of user sessions under defined circumstances. This requirement goes beyond standard event logging. Session auditing means recording what happens inside a session, including keystrokes, file transfers, websites visited, and screen activity, not just that a login or logout occurred.

But the requirement goes further than technology deployment. Federal and industry regulations govern when and how organizations can monitor user activity, and AU-14 makes legal alignment a first-class requirement rather than an afterthought. You can’t deploy session capture technology without addressing privacy, civil liberties, and applicable laws through documented consultation with legal counsel.

In practice, this control exists because event logs alone don’t tell you what a privileged user actually did during a session. If an insider threat or compromised account is active, your AU family controls need to reconstruct session-level activity, not just timestamps and access events. AU-14 fills that gap by requiring purpose-built session capture capabilities that sit on top of your existing logging infrastructure.

Why it matters

Failure to maintain session auditing capabilities introduces audit risk during federal assessments and compliance reviews. Assessors evaluating your NIST SP 800-53 implementation will look for evidence that you can capture session content when circumstances demand it, and that your legal team was involved in defining those circumstances. Without this evidence, you face findings that cascade into your overall audit and accountability posture.

The gap matters most in environments with elevated privilege. When a database administrator, system engineer, or security operator conducts a session with broad access, standard audit logs capture the access event but not the actions taken within that session. Organizations that lack session auditing capabilities can’t reconstruct what happened during an incident, making root cause analysis and forensic investigation significantly harder.

But the control’s risk cuts both ways. Session auditing, by definition, captures personally identifiable information (PII) and sensitive user activity. Organizations that implement session capture without proper legal consultation and documented policies expose themselves to regulatory violations, employee grievances, and civil liberties complaints. The control explicitly requires legal counsel involvement to mitigate this risk.

What attackers exploit

• Privileged session abuse: compromised or malicious insiders use elevated access to exfiltrate data, modify configurations, or create backdoors during sessions that standard event logs don’t fully capture
• Lateral movement without session-level visibility: attackers pivot between systems using hijacked sessions, and organizations without session auditing can’t reconstruct the path or scope of the compromise
• Credential reuse and session hijacking: stolen credentials allow attackers to operate within legitimate sessions, blending in with normal activity that only session-level recording would distinguish from authorized use
• Regulatory evasion through unmonitored sessions: threat actors target environments where they know compliance gaps exist between event logging and session monitoring

How to implement

A common implementation failure is activating session auditing without documented legal approval or defined triggering circumstances.

For your organization

Start by establishing the policy and legal framework before deploying any technology. Work with legal counsel to define the specific circumstances under which session auditing activates, such as investigations into suspected insider threats, privileged access to sensitive data environments, or sessions triggered by anomalous behavior alerts.

In practice, this obligation means documenting those circumstances in your system security plan and your privacy plan. Your audit and accountability policy should reference session auditing explicitly, including which roles are authorized to initiate, view, or manage session recordings.

Specifically, technology selection depends on your environment. Privileged access management (PAM) tools with session recording, terminal session loggers, and dedicated session auditing platforms are the main categories to evaluate. Configure the technology to capture the content types specified in your policy, whether that means keystroke logging, screen recording, file transfer tracking, or a combination.

The result is session data that must integrate with your existing audit infrastructure. Protect session recordings with the same controls you apply to audit logs, including encryption at rest, access restrictions, and tamper-evident storage, and retain them according to your audit record retention schedule.

Where most implementations break down is testing. Run tabletop exercises that require session recording retrieval to verify that authorized personnel can actually access and review captured session data when needed. A common mistake is deploying session capture technology that writes recordings to a storage location no one monitors or tests.

For your vendors

When assessing third-party compliance with AU-14, request evidence that the vendor has both the technical capability and the legal framework for session auditing. Technical deployment without documented legal authorization is itself a compliance gap.

Specifically, use these questions in your vendor risk assessment questionnaire to confirm both capability and governance:

• Does your organization have the capability to record and review the content of user sessions in defined circumstances?
• Under what documented circumstances does session auditing activate?
• Was legal counsel involved in developing your session auditing policies and procedures?
• How are session recordings stored, protected, and retained?
• Who is authorized to initiate, access, and review session recordings?

Specifically, request copies of the vendor’s audit and accountability policy with session auditing provisions, their system security plan referencing session capture, and evidence of legal counsel consultation. If the vendor claims session auditing is “not applicable” to their environment, ask them to document the risk acceptance and the rationale for that decision.

But documentation alone doesn’t guarantee compliance. Red flags include vendors who confuse event logging with session auditing, vendors who can’t produce evidence of legal consultation, and vendors who have session recording technology deployed but no documented policy governing its use. A vendor with the technology but no governance around it may actually be in a worse compliance position than one without the capability at all.

Evidence examples

Cross-framework mapping

Related controls

Frequently asked questions

What is NIST SP 800-53 AU-14

AU-14 is the NIST SP 800-53 control that requires organizations to provide session-level auditing capabilities for capturing the content of user sessions under defined circumstances. Unlike event logging, which records discrete actions such as logins and file access, session auditing captures continuous activity within a session, including keystrokes, file transfers, and websites visited. The control also mandates that session auditing activities be developed and used in consultation with legal counsel to address privacy, civil liberties, and applicable regulatory requirements.

What happens if AU-14 is not implemented

Without AU-14, your organization loses the ability to reconstruct what users and roles actually did during sessions involving sensitive systems or data. Assessors reviewing your AU family policy will flag the absence of session capture capabilities as a finding, particularly in environments with privileged access. The gap also weakens your incident response and forensic investigation capabilities, because event logs alone can’t show the full scope of activity during a compromised or suspicious session.

How do you audit AU-14

Auditing AU-14 starts with verifying that session auditing procedures document the specific circumstances under which session capture activates and that legal counsel was consulted during their development. Assessors then confirm the technical capability exists by reviewing system configuration settings for session recording tools and examining sample session audit records. The audit also checks that the privacy plan addresses PII implications of session capture and that authorized roles can demonstrate the ability to record, access, and review session content as documented.

What is the difference between session auditing and event logging

Session auditing captures the continuous content of a user session, such as keystrokes, screen activity, and file transfers, while event logging records discrete system events like logins, logouts, and access requests. Event logging (addressed by AU-02) tells you that something happened; session auditing under AU-14 tells you what happened in detail during that session. Organizations need both capabilities, because event logs provide breadth across all system activity while session recordings provide depth for high-risk or suspicious sessions that require full reconstruction.