AU-14(3): Remote Viewing and Listening

AU-14(3) requires you to provide a real-time capability for authorized personnel to remotely view and hear what is happening in an active user session, typically for incident response, fraud investigation, and operational support. To operationalize it, define authorized roles, implement approved session-monitoring tooling, gate access with strong approvals, and retain precise audit evidence. ¹

Key takeaways:

• You must enable real-time remote viewing and listening of established user sessions for authorized users, not just “log review.” ¹
• The hard part is governance: who can monitor, under what triggers, with what approvals, and what gets retained as evidence.
• Build the control around bounded use cases (IR, insider risk, privileged support) and prove operation with access logs, case tickets, and monitoring records.

AU-14(3): Remote Viewing and Listening is a deceptively specific requirement. It is not asking you to record everything or to turn on constant surveillance. It is asking you to ensure the organization can, when justified, observe and listen to the content of an already-established user session in real time, and that only authorized users can do so. ¹

For a Compliance Officer, CCO, or GRC lead, the quickest path to operationalization is to treat AU-14(3) as a capability-plus-governance control: implement the technical mechanism (for example, session monitoring for remote support, call center desktops, VDI, privileged admin sessions, or trading floors), then put tight access controls, approvals, and audit logging around it. Your evidence strategy matters as much as the tool choice. Auditors rarely fail you for picking Tool A versus Tool B; they fail you because you cannot prove who accessed remote viewing, why they did it, what they observed, and whether that access was authorized.

This page translates the requirement into implementable steps, an evidence bundle you can hand to assessors, and common failure modes to avoid.

Regulatory text

Requirement (AU-14(3)): “Provide and implement the capability for authorized users to remotely view and hear content related to an established user session in real time.” ¹

Operator meaning (what you must do):

1. Provide the capability: deploy or configure tooling that can show a live session’s visual content and audio (where audio exists) for a user’s active session. ¹
2. Implement it with authorization controls: ensure only explicitly authorized roles can invoke the capability, and ensure the system captures an auditable trail of that access. The text is explicit about “authorized users.” ¹
3. Scope it to established sessions: the monitoring ties to a session that already exists, which typically means support/investigation of an active user activity rather than offline reconstruction. ¹
4. Do it in real time: this is distinct from after-the-fact recordings, log replays, or SIEM alerts. Those can complement AU-14(3), but they do not satisfy the “view and hear … in real time” requirement on their own. ¹

Plain-English interpretation

AU-14(3) is a “we can see what’s happening right now” control. You are expected to support real-time oversight for legitimate operational and security needs, such as:

• Confirming what occurred during an incident while the activity is underway.
• Assisting a user during remote support while ensuring the helper’s actions are accountable.
• Monitoring high-risk operational environments (for example, privileged admin sessions) where rapid detection matters.

Key compliance nuance: the requirement is about capability and authorization, not about always-on monitoring. Your policy should articulate permitted triggers, approvals, and privacy/notice boundaries, but your technical implementation must prove that only approved personnel can initiate remote viewing/listening and that access is logged.

Who it applies to (entity and operational context)

Entities:

• Federal information systems and contractor systems handling federal data commonly map to NIST SP 800-53 requirements, including AU-14(3). ¹

Operational contexts where AU-14(3) becomes “real”:

• Remote support / help desk tools that enable screen sharing or “view-only” modes.
• VDI / DaaS environments where session brokering supports shadowing.
• Privileged access management (PAM) workflows where an operator can watch privileged sessions live.
• Call centers or trading/operations floors where “listening” may be relevant if the user session includes voice/audio as part of the workflow.
• Third-party administered environments (outsourced IT, managed SOC, BPO) where your contract and technical controls must still ensure only authorized personnel can monitor sessions.

If your system has no audio component, “hear” may mean you must be able to capture or monitor session-related audio where it exists (for example, softphone audio tied to the workstation session). Document the boundary clearly so auditors understand what is technically in-scope versus not present.

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

1) Define the control as an operator-run requirement (control card)

Create a one-page control card that includes:

• Objective: Provide authorized real-time remote viewing and listening for established user sessions. ¹
• Owner: typically Security Operations (tooling) + IT (end-user computing) + GRC (governance).
• In-scope systems: VDI, remote support, PAM, call center desktops, etc.
• Trigger events: incident response, fraud investigations, privileged session oversight, user-requested support, or other approved triggers.
• Exception rules: emergency access, break-glass, or systems where the capability is infeasible and compensating controls apply.

Practical tip: put the control card in the same repository as your SSP/control descriptions so it is discoverable during an assessment.

2) Identify use cases and map them to “authorized users”

You need a tight definition of “authorized users”:

• Roles (SOC analyst, IR lead, fraud ops lead, IT support tier leads).
• Required training (privacy, monitoring etiquette, evidence handling).
• Segregation of duties (avoid self-monitoring; avoid monitoring without a case/ticket).
• Approval model (manager approval, IR commander approval, or dual approval for sensitive cases).

Write this as a RACI table. Auditors will ask “who can do this?” and “who approves this?” before they ask about tools.

3) Select and configure the technical capability

Implement remote session monitoring in a way that is:

• Bounded: view-only modes where possible; separate “observe” from “control” permissions.
• Authenticated: integrated with SSO and MFA.
• Logged: captures who initiated viewing/listening, which session was observed, timestamps, and reason codes (ideally tied to a ticket/case ID).

Typical implementation patterns:

• PAM session monitoring for privileged sessions (watch live, optionally record).
• Remote support shadowing for employee desktops with explicit user consent prompts where appropriate.
• VDI session shadowing controlled by admin roles and logged centrally.

4) Gate access with policy, workflow, and technical controls

Minimum guardrails that hold up in exams:

• Pre-authorization: only members of an “AU-14(3) Monitors” group can initiate remote viewing/listening.
• Just-in-time access: grant time-bound access for specific cases, then revoke automatically.
• Case linkage: require a ticket/case ID at the time of access (or immediate post-event documentation for emergencies).
• Dual control for sensitive populations: executives, HR-related investigations, or regulated activities may warrant additional approval.

5) Implement audit logging and review

AU-14(3) sits in the Audit and Accountability family, so you need to treat logs as first-class artifacts:

• Centralize logs in your logging platform.
• Alert on anomalous monitoring (after-hours, excessive sessions, monitoring of sensitive users).
• Run a periodic review of monitoring events for authorization and appropriateness.

Operationally, define a review cadence that matches your risk, and document it in the control card. If you use Daydream, track the control’s health checks, evidence attachments, and remediation items in one place so you can show sustained operation during audits.

6) Train and test the capability

Run tabletop or functional tests:

• Can the authorized role initiate view/listen within policy?
• Do logs capture the right fields?
• Can you retrieve evidence quickly for an assessor?

A common audit failure is “we bought the tool” but nobody can demonstrate it end-to-end.

Required evidence and artifacts to retain

Retain evidence that proves capability, authorization, and operation:

Control design artifacts

• Control card/runbook for AU-14(3) (objective, owner, triggers, steps, exceptions).
• Role-based access policy defining “authorized users” and approval requirements.
• System architecture or configuration documentation showing where remote viewing/listening is enabled.

Control operating artifacts (the evidence bundle auditors want)

• Access control lists / group membership for monitoring roles (with change history).
• Sample monitoring event logs (who/what/when), ideally with session identifiers.
• Tickets/cases that justify monitoring events, including approvals and closures.
• Evidence of periodic review (review checklist, findings, remediation tracking).
• Training completion records for users granted monitoring privileges.

Retention note: set retention based on your organization’s audit log retention standard and contractual/regulatory obligations. The key is consistency and retrievability.

Common exam/audit questions and hangups

Expect these questions:

1. “Show me how an authorized user can view and hear a live session.”
   Be ready with a demo in a non-production environment and screenshots of configuration settings.

2. “Who is authorized, and how do you prevent unauthorized monitoring?”
   Provide group membership, approval workflow, and MFA/SSO enforcement evidence.

3. “How do you ensure monitoring is tied to a legitimate purpose?”
   Show ticket linkage, reason codes, and managerial/IR approvals.

4. “Do you record sessions? If yes, where are recordings stored and who can access them?”
   If you record, treat recordings as sensitive evidence with strict access controls and retention rules. If you do not record, explain how real-time viewing still meets AU-14(3) and what other controls cover forensic needs.

5. “How do you review monitoring activity for abuse?”
   Show periodic review outputs and follow-up actions.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating SIEM logs as “remote viewing”	AU-14(3) requires real-time view/hear of the session, not just telemetry. 1	Keep logs as supporting evidence, but implement live session shadowing/monitoring where appropriate.
Too many admins can monitor	“Authorized users” becomes meaningless if the permission is broad. 1	Create a dedicated monitoring role, enforce JIT access, and require approvals.
No case linkage	Auditors will flag inability to show legitimate purpose.	Require ticket IDs and capture them in logs or in a post-event record with timestamps.
Missing “listening” analysis	Assessors may ask how audio is handled if your environment uses voice.	Document where audio exists, how it can be monitored, and where it is technically out-of-scope.
One-time implementation, no ongoing review	Control operation is as important as control design.	Schedule periodic reviews and track remediation to closure in a system of record (Daydream or equivalent).

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, AU-14(3) failures usually show up as:

• Slower incident containment because responders cannot observe active misuse.
• Insider risk blind spots, especially in privileged access scenarios.
• Investigations that rely on informal screen shares without proper logging, which creates evidence integrity and accountability issues.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Define in-scope systems and the top monitoring use cases (IR, remote support, privileged sessions).
• Publish the AU-14(3) control card with owner, triggers, and exceptions.
• Define “authorized users” roles, training prerequisites, and approval workflow.
• Inventory existing tools that already provide real-time view/listen (remote support, VDI, PAM).

Days 31–60 (implement and log)

• Configure the technical capability in each in-scope system:
  • enable view/listen where technically possible,
  • enforce SSO/MFA,
  • restrict to dedicated monitoring roles.
• Implement ticket/case linkage and reason capture.
• Centralize monitoring audit logs and validate log fields needed for evidence.

Days 61–90 (prove operation and harden)

• Run controlled tests and document results (screenshots + logs + tickets).
• Start recurring reviews of monitoring events for authorization and appropriateness.
• Close gaps: remove excess privileges, tighten approvals, add alerts for anomalous monitoring.
• In Daydream, attach the minimum evidence bundle to the control record and track remediation items to closure.

Frequently Asked Questions

Does AU-14(3) require recording user sessions?

The text requires real-time remote viewing and listening for established sessions; it does not state you must record. ¹ If you do record, treat recordings as sensitive audit evidence with strict access and retention controls.

What counts as “authorized users” for remote viewing/listening?

Users are “authorized” when you have explicitly assigned the permission through role-based access control and can show approvals and training prerequisites. The control language is explicit that access must be limited to authorized users. ¹

If our environment has no audio, how do we satisfy “listening”?

Document that the session has no audio component or that audio is handled outside the session context. Implement “listening” where audio is part of the session (for example, softphone in a VDI desktop) and clearly define scope boundaries.

Can our managed service provider monitor sessions to meet AU-14(3)?

Yes, if your contract and technical controls ensure only their authorized personnel can perform monitoring, and you receive auditable logs and case justification. You remain accountable for demonstrating the capability and its controlled use. ¹

What evidence do auditors ask for most often?

They typically want (1) proof the capability exists, (2) proof only authorized roles can use it, and (3) logs/tickets showing actual monitored events with proper approvals. Align your evidence bundle to those three points. ¹

How do we prevent AU-14(3) from becoming a privacy issue?

Limit monitoring to defined triggers, require documented justification, and restrict access to trained roles. Add review and oversight so monitoring events are checked for appropriateness and not used for informal supervision.

Footnotes

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