AU-14 Session audit: requirements and evidence

What AU-14 session audit asks for and why it is harder than event logging

If you have been asked to meet AU-14, your first decision is whether session content capture is needed at all. AU-14 requires the capability for defined users or roles to record, view, hear or log the content of a user session under defined circumstances. That is a different kind of obligation from the event logging in AU-2 through AU-12, which records that something happened, such as a login, a privilege change or a failed access attempt, along with its time, source and outcome. AU-14 asks for the words typed, the screens shown or the activity inside a session. Because it captures what people did in detail, the organization must first define who may watch or record, in which circumstances, and for which users, and must document why those circumstances justify the intrusion. Many programs find that event logs already answer their investigative questions, and that session capture is needed only for a narrow set of privileged or high-risk sessions.

AU-14 is absent from the low, moderate, high and privacy baselines in SP 800-53B Release 5.2.0, so no impact level brings it in automatically. You add it only by tailoring a baseline or through an overlay, and the decision should be recorded in your control selection rationale. The control also requires that session auditing be developed and used in consultation with legal counsel and in line with applicable law and policy. Counsel shapes the scope because recording session content can engage employee monitoring rules, notice and consent requirements, labor agreements, data protection law and rules on communications. Confirm with counsel which jurisdictions, user populations and session types are covered before any technical design begins, and ask them to review the notice that users receive.

The risk AU-14 addresses is the gap that event logs leave when an administrator or insider acts within a legitimate session, where the record shows a successful action but not what was done. Capturing that content is hard for practical reasons. Session content can include personal data, credentials and regulated information, so storage, access restriction and retention must be designed alongside AU-9 and AU-11. Recording tools also add their own privileged access and attack surface, and the sessions they capture must be protected from the same people they monitor. Plan for the review burden as well, since recordings no one reviews provide little assurance. Test whether your chosen mechanism captures what you need, and confirm with your platform vendor which session types it can record, rather than assuming coverage.

Which systems, users and circumstances put AU-14 in scope

AU-14 has no default population. The organization decides which systems carry sessions worth recording, which roles may capture or review them, whose sessions are covered and what triggers capture. Each choice widens or narrows the legal, technical and evidence work that follows.

Systems that carry sessions

Start with the interactive paths where a person or process acts on a system: administrative consoles, privileged shell access, remote support tools, database clients and application portals that handle sensitive records. Batch jobs and service-to-service calls usually fall outside the session concept, but they still need a documented decision. For each system, record whether sessions are captured, which fields are collected and where the capture data lives. Ask the system owner to confirm that the platform can produce the capture the policy describes, not just a generic login log.

Roles that may record and review

AU-14 requires the organization to name the defined roles that can record, view, hear or log session content. Separate the capture role from the review role, since a single administrator who can both turn on capture and read the results is a control weakness in its own right. Document who can enable capture, who can open recordings and who can export them. Keep these roles in the access control model so an assessor can match each permission to a named person or group.

Staff, administrators and outside users

Decide which populations are covered. Employees with privileged access are the usual starting point, but contractors, managed service staff and outside users who reach internal systems may also be in scope. Each population brings different notice, consent and contract obligations. Write the population list into the policy and tie it to the identity sources used for authentication, so the covered group can be reproduced from directory data during assessment.

Defined circumstances that trigger capture

The control expects the organization to define when capture happens, such as a privileged session on a production system, a session flagged by monitoring, or an investigation under a documented case. Vague triggers like "when needed" are hard to test. Write each trigger as a condition someone can check, state who authorizes it and how the authorization is recorded. Confirm with counsel which triggers are permitted in each jurisdiction where staff work.

Legal counsel and privacy duties

AU-14 requires session auditing to be developed in consultation with legal counsel and to follow applicable law and policy. Recording a person's screen, keystrokes or voice can engage employment, communications and data protection rules, and the privacy plan may need to address the captured data. Ask counsel to confirm notice requirements, retention limits, access restrictions and any works council or labor consultation. Record counsel's input so the decision is traceable.

Third parties that extend the scope

Managed service providers, cloud operators and SaaS vendors may hold the session data or run the capture tooling. Their contracts must state who records, where the data sits, who can view it and how long it is kept. If a third party captures sessions on your behalf, AU-14 evidence may sit outside your environment, which changes what you can produce during assessment. Confirm these terms before deciding that a third-party platform satisfies the control.

How an assessor tests AU-14 against the five determination statements

This table walks through how an SP 800-53A assessor works the five AU-14 determination statements, listing the examine, interview and test objects for each method. Read it as a checklist of what to have ready before an assessor arrives, and note that the largest gaps usually sit in documented legal consultation and in capture rules tied to defined circumstances.

Assessment method	Objects the assessor looks at	Common finding
Examine	Audit and accountability policy, procedures addressing user session auditing, system security plan, privacy plan, system design documentation, system configuration settings and associated documentation	Procedures exist but do not say which roles may record or view sessions, or when
Interview	System and network administrators who operate the session capture mechanism, and system developers who built it	Administrators describe capture as on by default, while the written circumstances say otherwise
Test	Mechanisms implementing the user session auditing capability, exercised against defined roles and defined circumstances	Capture runs for sessions outside the defined circumstances, or viewing is open to roles not defined
Legal consultation evidence	Records of counsel review of the session auditing design, policy and applicable law reference (examined alongside the policy and privacy plan)	No dated record of consultation, or consultation covers an earlier design
Privacy plan alignment	Privacy plan and system design documentation showing how captured session content is handled and limited	Privacy plan is silent on session content, so assessors cannot confirm alignment
Configuration evidence	Configuration settings that enable, scope and restrict session auditing for each defined role	Settings differ between environments, and no baseline records the intended state

Implementing AU-14 session audit in order

This sequence turns AU-14 from a legal question into a documented, tested capability: legal basis first, then bounded roles, a capture mechanism limited to those roles and circumstances, recorded design, proof that capture only happens when it should, and ongoing review of use.

Obtain legal counsel input and define circumstances
The organization's counsel, with privacy and HR input where relevant, identifies the law, contract and internal policy that permit recording or viewing user session content, and the specific circumstances that justify it, such as a defined investigation or a defined class of privileged activity. Counsel should also address notice to users and any employee monitoring rules that apply. The output is a written legal memo or decision record listing each circumstance, its legal or policy basis and the conditions that must be met before capture starts. Confirm the required form of this record with your counsel, since the control expects session auditing to be developed in consultation with legal counsel.
Define authorized roles and permitted actions
Based on the counsel record, the security or compliance lead names the roles allowed to start, stop, record, view, hear or log session content, and separates these from the roles that administer the logging system itself. Each role is listed with the actions it may take and the circumstances in which it may act. The output is a role matrix approved by the control owner and the legal function. Assessors will check that these roles match the defined circumstances and that no other role has the capability, so keep the list short and reviewable.
Select and configure the capture mechanism
Engineering selects the session capture or logging mechanism for the in-scope systems and configures it so that only the approved roles can invoke it and only within the defined circumstances. Where an open-source platform already writes detailed activity logs, such as the admin_audit app in Nextcloud, which writes additional event information to a configurable audit log file, or the detailed request logging of OpenBao audit devices, the team confirms exactly what content is captured, where it is stored and who can read it. Where a platform does not provide session content capture, the team records that gap and the compensating approach. The output is a tested configuration baseline with access restrictions applied.
Document the design in the security and privacy plan
The system security and privacy plan, together with the privacy plan where personal data is involved, records the session auditing design: the defined circumstances, the authorized roles, the mechanism, the storage location, the access restrictions, the retention of captured content and the legal basis. The related controls AU-11 for retention and AU-9 for protection of audit information should be cross-referenced so that the captured content is protected and retained as the plan states. The output is a plan section that an assessor can compare directly against the configuration and the counsel record.
Test that capture occurs only under defined circumstances
The assessor's test method for AU-14 examines the session auditing mechanism itself. The team runs controlled tests in a non-production or approved environment: it attempts capture as an authorized role under a defined circumstance, attempts capture as an unauthorized role, and attempts capture outside the defined circumstances. It then confirms that each attempt produced the expected result and that the outcome is recorded. Test records should include the date, tester, role used, circumstance claimed and result. The output is a signed test report with any defects tracked to closure. Review the test design with your independent assessor before testing, since they will define what evidence satisfies them.
Establish periodic review of capability use
The security function sets up a recurring review of who invoked session auditing, under which circumstance, what was captured, who viewed it and whether each use matched the counsel record and the role matrix. The review also checks that the role list and the counsel record are still current after staff changes or legal changes. Findings are documented and routed to the owner of the control, and out-of-scope use is escalated to legal and HR. The output is a dated review record for each period and a log of any corrective actions. Confirm with counsel how often this review must occur and who must sign off, because the frequency is an organizational decision rather than a value supplied in the control text.

Evidence that passes an AU-14 assessment and how to keep it current

An assessor testing AU-14 Session audit works through examine, interview and test methods, and each one needs its own artifact. The cards below cover the documents, configuration evidence, role records and test results that connect those methods, and how to refresh them when settings or circumstances change.

Legal consultation record

AU-14 requires session auditing to be developed and used in consultation with legal counsel and in line with applicable law and policy. Keep a dated record showing who advised, what questions were put to counsel, which circumstances counsel approved for session capture, and any conditions attached. Assessors will ask whether the approved circumstances match the ones in the configuration and policy. Ask counsel to re-confirm the advice whenever the capture scope or governing law changes.

Session audit policy and procedures

The examine method looks for an audit and accountability policy and procedures that address user session auditing. They should name the defined users or roles, the defined circumstances for capture, the notice given to users, and the handling rules for recorded content. Confirm the document is version-controlled, approved by the owner, and cross-referenced to the system security plan and privacy plan. Review it at the cadence your own policy sets.

Configuration baseline for capture

The test method examines mechanisms implementing user session auditing, so the configuration baseline must show capture enabled only for the defined circumstances and restricted for everything else. Export the effective settings from each component in scope, store them with the baseline record, and compare them to the approved design. Drift between environments is a common finding, so check production, staging and recovery sites separately.

Role assignments and interview records

Interviews with system and network administrators and system developers test whether people know who may start, view, hear or log a session. Produce a current role matrix that maps each defined role to its capture permissions, and keep notes from interviews showing each person can explain those limits. Remove access for people who change roles, and record the date of each access review so the matrix reflects who actually holds the permission.

Test records for defined circumstances

Test evidence should show that capture occurs only under the circumstances the policy defines. Record each test with its date, the scenario, the expected result, the observed result and the reviewer's name. Include negative tests showing that sessions outside the defined circumstances were not captured. Rerun these tests after any configuration change, upgrade or change in the approved circumstances.

Access records for captured content

Viewing captured session content is itself a sensitive event, so keep logs of who accessed recordings or session logs, when, and under which approval. Protect these logs against modification, since the audit trail is the evidence. Review access records periodically and compare them to the role matrix. Unexplained access is a finding that assessors commonly raise, so document the review and any follow-up action.

How Nextcloud and OpenBao support AU-14 evidence

Nextcloud is licensed under the AGPL-3.0-only license. Its admin_audit app writes additional event information to an audit log, which by default sits in the data directory as audit.log, or to a path set with the logfile_audit key. That log can document administrative activity around a session capture program, such as who changed logging settings, who accessed an audited area and when. It does not, by itself, record the content of a user session, and AU-14 requires the organization to define when and what is captured. Treat the app as one source of evidence for the surrounding administrative trail, not as the session recording mechanism.

Log location: Confirm where audit.log is written in your deployment and whether logfile_audit points it to a protected, centrally collected path.
Event coverage: Ask the vendor or test in your environment which events the admin_audit app records, and whether any event contains session content or only metadata.
Configuration evidence: Keep the logging configuration as a versioned file so assessors can see the defined settings at a given date.
Scope limits: Document that session content capture, if required, is handled by a separate mechanism that your legal counsel has approved.
Retention and protection: Plan retention and access controls for the log file under the audit protection and retention controls that apply to the rest of the system.

Confirm with the vendor and in a test environment exactly what the app produces against the circumstances your organization defined before you cite it as AU-14 evidence.

What meeting AU-14 costs in money and effort

This table lists each cost component of running AU-14 session auditing, who pays for it, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to ask potential partners and assessors for the line items that matter.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Legal counsel time to define circumstances	Organization's counsel or outside privacy and employment lawyers	One-time, then recurring on review	Number of jurisdictions, employee monitoring rules, and how often session-capture circumstances change
Engineering time to configure and test capture	Internal platform team or an implementation partner under a fixed-scope agreement	One-time per system	Number of systems in scope, number of defined roles, and whether capture is native or needs custom work
Tooling and licenses	Software vendor for commercial session recording; none for many open-source options	Recurring where licensed	Choice of self-hosted open source versus commercial products, and per-seat or per-session pricing terms
Storage and protection of session records	Organization, for infrastructure it owns or rents	Recurring	Volume of recorded content, retention periods set with counsel, and encryption and access controls applied under AU-9
Evidence upkeep	Organization's control owners, with partner support if retained	Recurring	How many times circumstances, roles or system configurations change, and whether evidence is collected continuously or on request
Access reviews of who may view sessions	Organization's security and legal staff	Recurring	Number of roles with view or hear rights and how often role membership changes
External review by a partner or consultant	Implementation partner or consultant, if engaged	One-time or periodic	Scope of review and whether it covers counsel-approved procedures as well as technical configuration
Auditor or assessor sampling	Organization pays the independent assessor under its engagement	Periodic	Number of systems selected for testing and how completely evidence is organized before fieldwork

Who owns AU-14 and what an implementation partner can take on

Your organization owns AU-14 in full. Because the control requires session auditing to be developed and used in consultation with legal counsel and in line with applicable law and policy, the decisions about whether to record sessions at all, for whom, and under which circumstances belong to you and your counsel, not to a technical provider. Your security leadership also owns the risk acceptance for the residual exposure that remains once a capability is defined and bounded.

Legal determination: Counsel decides whether session recording or viewing is lawful for each user population, jurisdiction and purpose, and documents that advice.
Capture policy: Your policy names the defined roles, the defined circumstances, the content types that may be captured, and who may view or hear them.
Risk acceptance: A named authority accepts the privacy, employee relations and data protection risk of the capability, and records it in the system security plan.
Notice and retention rules: Users are told what is captured and how long it is kept, consistent with the AU-11 retention decisions you make.
Review of changes: Each change to scope, roles or circumstances goes back through counsel and the risk owner.

Before any engagement starts, confirm in writing which of these decisions are yours and who signs for each one.

Where organizations fall short on session audit and how to close each gap

AU-14 is easy to overlook because no SP 800-53B baseline selects it, yet it touches legal, privacy, access and evidence decisions at once. The gaps below cluster around one problem: session capture is switched on before the rules for it are settled, documented and provable.

Leaving AU-14 out by default

Because SP 800-53B does not select AU-14 for the low, moderate, high or privacy baselines, many programs never assess it. If a system records administrator or user sessions anyway, that capability sits outside the control record. Decide explicitly whether AU-14 applies, document the decision in the system security plan, and tailor it in if the organization's policy or the system's risk calls for it.

Enabling capture before legal sign-off

AU-14 requires session auditing to be developed in consultation with legal counsel and in line with applicable law and policy. Session recording switched on by an engineer before counsel reviews the circumstances, the notice given to users and the retention period creates legal exposure. Get written counsel approval of the defined circumstances, the defined roles and the retention terms before any capture is enabled.

Granting view rights too broadly

Captured session content often includes credentials, personal data and business records, so the people who can play it back are a sensitive population. Limit viewing to the defined roles named in the policy, and separate the role that can enable capture from the role that can view it. Review that membership on a set schedule, and confirm the platform's access controls can enforce the split rather than relying on a shared admin account.

No record of who viewed captured content

Viewing a recording is itself a sensitive act, yet many setups log the capture but not the playback. Each view, hear or export of captured session content should generate an audit record that names the reviewer, the time, the session and the reason. Confirm with your platform vendor which events its audit trail records for session content, and test that a view by an authorized reviewer produces an entry.

Privacy duties left unaddressed

Session content can capture personal data of employees, customers and third parties, which brings the privacy plan and privacy impact considerations into scope alongside AU-14. Map which personal data appears in captured sessions, define minimization steps such as masking fields or excluding certain applications, and record the lawful basis and notice in the privacy plan. Assessors will examine the privacy plan for AU-14, so it must reflect the actual capture design.

Evidence that lives in someone's memory

Teams often run session audit successfully but cannot show an assessor how it works. Assessors test AU-14 by examining the policy, procedures, system security plan, configuration settings and design documentation, interviewing administrators and developers, and testing the mechanism itself. Write the procedures, export the configuration, keep a dated record of each defined circumstance that triggered capture, and rehearse a test capture and authorized review so the evidence exists on paper before the assessment begins.

What buyers ask about AU-14 cost, effort and whether to do it in-house

Is AU-14 session audit required by any NIST SP 800-53 baseline?

No. AU-14 is not selected in the low, moderate or high baselines or in the privacy baseline of SP 800-53B Release 5.2.0, and none of its two current enhancements are selected either. It becomes required only when your organization selects it by tailoring a baseline or through an overlay, usually because a legal review, contract or regulator calls for session recording or logging of user session content. Start by documenting the reason for selection, since the control is tied to defined circumstances that your own policy and counsel must set.

What drives the cost of implementing AU-14?

Cost depends on the scope of what must be recorded, not on the control text itself. The main cost drivers are the number of systems and user roles where sessions are in scope, the legal review needed to define circumstances and who may view recordings, the storage and protection of session content, and the engineering effort to add recording or logging to each system. Recurring costs include storage growth, access reviews for the roles that can view sessions, and periodic re-review when law or policy changes. Ask any partner for a line-item quote that separates one-time design and build work from recurring support.

How long does it take to put AU-14 in place?

The duration depends on how many systems are in scope, how quickly legal counsel can settle the defined circumstances, and whether the target platforms already support session capture. Legal definition usually sets the pace, because the control requires session auditing to be developed in consultation with counsel and in line with applicable law and policy. Engineering work follows that decision. NIST does not publish implementation durations for SP 800-53 controls, so ask a partner to tie any timeline to a written scope with named systems and milestones.

What does AU-14 require from our legal and engineering teams?

Legal counsel must help define the circumstances in which sessions may be recorded, viewed, heard or logged, the roles allowed to do so, and the rules for handling personal information in those records. Engineering teams must confirm which platforms can capture session content, design how that content is stored and protected, and build access controls around it. Security and compliance staff document the decisions in the policy and system security plan, and system administrators and developers are the people assessors typically interview when they test the capability. Agree these responsibilities before any build work starts.

Can we implement AU-14 ourselves without an outside partner?

Yes, if you have the legal review, engineering capacity and security skills in-house. Many organizations build session auditing with their own staff, and nothing in SP 800-53 requires an outside firm to do it. An implementation partner can take on the platform configuration, hardening, documentation and evidence preparation, while your organization keeps ownership of the control and its decisions. Only an independent assessor or auditor can test the control and issue findings. Consider a partner when the platform inventory is large, legal scoping is still open, or internal teams cannot cover the work.

What should a written scope for AU-14 work include?

A useful written scope names each system where sessions are in scope, the defined circumstances and roles as approved by counsel, the capture method for each platform, the storage location and protection model for session content, and the access and review process for recordings. It should also list deliverables such as configuration records, runbooks and evidence that maps to the SP 800-53A examine, interview and test methods. Ask for the assumptions, exclusions, responsibilities of your staff, and the process for changes. Most DeployOpen engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

Which open-source platforms can produce AU-14 evidence?

Platforms differ in what they log and whether they capture session content, so confirm each one against your requirement. Nextcloud's admin_audit app writes additional event information to an audit log file set in its configuration, which is useful for audit trails but should be checked against any session content requirement. OpenBao's audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed. Neither should be assumed to meet AU-14 on its own. Verify the exact capability with the vendor and your legal counsel before you rely on it.

How DeployOpen scopes, implements and prepares AU-14 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so session auditing can be set up where the sessions actually run. Engagements are fixed-scope, and the organization keeps ownership of its controls, its legal review and its audit decisions.

How we scope

Agree in writing which systems, user roles and session types fall within the AU-14 session auditing scope.
Record the defined circumstances and defined roles with the client's legal counsel before any build work starts.
Confirm the applicable privacy law and internal policy that govern monitoring, and document the limits agreed for each system.

How we build

Configure session auditing capability on the in-scope platforms, using the audit features each product documents and confirms.
Restrict who can view or retrieve recorded session content to the roles defined in the written scope.
Test the mechanism against the agreed circumstances to show it records, restricts and logs access as designed.

How we hand over

Deliver configuration records, design notes and test results mapped to the SP 800-53A examine, interview and test objects for AU-14.
Provide a runbook for administrators covering how sessions are recorded, where content is stored and who can access it.
Hand over the evidence package to the client and its independent assessor, who decide whether the control is satisfied.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement closes.
Review session auditing settings again when platforms are upgraded, roles change or counsel revises the defined circumstances.
Keep documentation current so the next assessment cycle starts from accurate configuration and evidence records.