Privileged Session Review Checklist: What to Look for in Recorded Admin Sessions

Most organisations that record privileged sessions never watch them, and the few that do often have no agreed idea of what a reviewer is looking for. This checklist gives session reviewers a repeatable set of checks to run against a recorded administrator, vendor or service account session, from the request and ticket through to the commands, data movement and the way the session ended. It is written for PAM operations teams, SOC analysts who triage session alerts, and the control owners who must show an auditor that admin activity is reviewed. It assumes sessions are already brokered and recorded; how to design and deploy privileged session management is covered in the Privileged Session Management Guide, and the governing rules in the Privileged Access Management Policy Template.

How to use this template

• Replace text in square brackets, such as [Organisation], [PAM platform], [Session reviewer] and [Change system], with your own details.
• Run sections 1 to 8 for every session selected for review. Section 1 is a fast pre-check from metadata; if it raises nothing and the session scored low risk, sections 3 to 6 can be sampled rather than watched end to end. Our recommendation is to always watch high-risk, vendor and break-glass sessions in full.
• Record each check as Pass, Finding or Not applicable, with the recording timestamp for every finding. A finding without a timestamp cannot be verified by a second reviewer or an auditor.
• Escalate in the same shift, using section 8, anything that matches a "Stop and escalate" item. Do not continue a leisurely review of a session that may be live intrusion.
• Reviewers must not review their own sessions or sessions of the team they belong to. This is a segregation of duties control; see the Segregation of Duties Guide.

Which sessions to review

Reviewing everything is rarely possible. The selection rule below is NHI Mgmt Group's recommended starting point; tune the percentages to your volume and risk appetite and record the rule in your procedure so an auditor can test it.

1. Session metadata pre-check

Complete this from the PAM console or session index before opening the recording.

1. Identity: the session is tied to a named person through the PAM platform, not only to a shared or generic account. Record the human identity and the account used.
2. Request and approval: an access request exists, was approved by someone other than the requester, and the approval predates the session start.
3. Ticket match: the session links to a change, incident or service request in [Change system], and the target system appears in that ticket.
4. Time window: the session ran inside the approved window and the change window. Note sessions started outside business hours for the requester's location.
5. Source: the session originated from an approved management device or jump host, from an expected network location. A session from an unmanaged device or unusual country is a finding.
6. Duration: compare the session length with the ticket's planned effort. A 5-minute task that ran for 4 hours, or a 2-day session left open, needs explaining.
7. Recording integrity: the recording is complete, with no gaps, and the PAM platform shows no recording errors, paused recording or agent disconnects for this session.
8. Analytics: note the risk score and any alerts raised during the session by the [PAM platform] or SIEM, so the reviewer can jump to those timestamps first.

2. Scope and target checks

1. Target systems: every system touched in the session is in the ticket. Hops from the approved host to other hosts (RDP or SSH onwards, PowerShell remoting, database links) are listed and justified.
2. Accounts used inside the session: the user did not switch to other accounts (su, sudo -i to root where a narrower sudo rule exists, runas, "connect as" in a database client) beyond what the task needed.
3. Console and tool use: the tools used fit the task. A database administrator using a network scanner, or a network engineer opening a file share, is a finding to explain.
4. Data in view: the user did not browse, query or open business data, personal data or cardholder data unrelated to the task. Note any screen where sensitive data was displayed in full.

3. Identity and access changes

Changes to identities and permissions are the most common way a short admin session turns into lasting access. Check each one against the ticket.

For machine credentials created during a session, confirm they were registered in the inventory and vault. See the Privileged Account Inventory Template.

4. Commands and actions

1. Credential access: no attempt to read password stores, browser credential stores, memory of authentication processes, or files that commonly hold secrets (configuration files, shell history, environment files), unless the ticket requires it. These map to T1003 OS Credential Dumping and T1552 Unsecured Credentials.
2. Tooling brought in: no download or copy of unapproved tools, scripts or binaries onto the target (T1105 Ingress Tool Transfer). Approved scripts are run from the agreed repository.
3. Remote access tools: no installation of remote support or remote access software that would allow a return path outside the PAM broker (T1219 Remote Access Tools).
4. Persistence: no new scheduled tasks, cron jobs, services or start-up items beyond those in the change (T1053 Scheduled Task/Job).
5. Security tools: no disabling, uninstalling or reconfiguring of endpoint protection, firewall rules, logging agents or audit policy (T1685 Disable or Modify Tools).
6. Log tampering: no clearing or deleting of logs, shell history or audit files, and no changes to log forwarding (T1070 Indicator Removal).
7. Destructive actions: deletions, drops, truncations, mass permission changes or backup changes match the ticket and had the required second approval.
8. Errors and retries: repeated failed commands, permission denied messages or trial and error against several systems. These can mean an unskilled user or someone probing for access.

Command-level checks are much faster on platforms that index keystrokes, SQL statements and window titles. Search the index for the watch-list terms your team maintains before scrubbing the video.

5. Data movement

1. Clipboard and file transfer: file transfer or clipboard use in the session is permitted by policy for this target and was used only for files named in the ticket.
2. Bulk export: no large query results, database dumps, mailbox exports or archive files (zip, 7z, tar) created and moved off the system without approval.
3. External destinations: no uploads to web storage, personal email, code hosting or paste sites from the target or jump host.
4. Screen capture of sensitive data: no screenshots or photos of sensitive screens taken through the session, where the platform records this.

Bulk export by an administrator is a classic insider data theft pattern. See the Insider Data Theft Guide.

6. Session behaviour and close

1. Continuity: the person at the keyboard appears to be the same throughout (typing pattern, working style, language of comments). Abrupt changes can indicate a shared or handed-over session.
2. Idle and unattended time: long idle periods with the session open are noted; the platform's idle timeout was not bypassed.
3. Clean close: the user logged off rather than leaving the session open, and checked-in credentials were rotated by the vault where that is the policy.
4. Clean-up: temporary files, test accounts and temporary firewall openings created for the task were removed before close.
5. Outcome: the ticket was updated with what was done, and the session evidence matches that description.

7. Service accounts, automation and AI agents

1. Interactive use of machine accounts: any interactive session by a service, system or application account is investigated. Record who used it, why the vault allowed it, and whether a named account should have been used instead.
2. Scripted sessions: sessions run by automation through the PAM broker execute only the expected job, at the expected time, against the expected targets. A scheduled job that suddenly runs new commands is a finding.
3. AI agents with admin tools: where an AI agent performs administrative actions through brokered sessions or tool calls, review the agent's tool call log and the human approvals in the same way, including the prompt or task that triggered the action.

See the PCI DSS Requirements for Service Accounts and NHIs Guide for a worked example of interactive-login rules for machine accounts.

8. Findings, escalation and sign-off

1. Record: reviewer name, date, session ID, checks completed, findings with timestamps and severity.
2. Escalate: follow [Organisation]'s incident procedure for anything in the first row. Recordings that may become evidence are placed under legal hold and their hash recorded.
3. Sign off: the reviewer confirms the review; a second reviewer confirms every High or Stop finding before it is closed.
4. Feed back: recurring findings become detection rules, PAM policy changes or training, so the next review is shorter.

Implementation guidance

1. Weeks 1 to 2, set the rules: agree the selection rule, severity table and escalation path with the SOC, PAM owner and HR or legal. In the UK, the Information Commissioner's Office guidance on monitoring workers covers recording and reviewing staff activity, so read it before you start. Our recommendation: tell administrators that sessions are recorded and reviewed, record why the monitoring is proportionate, and limit who can watch recordings. Equivalent rules apply in other jurisdictions and works council agreements may be needed.
2. Weeks 3 to 4, pilot: run the checklist on 20 to 30 past sessions, including some known-good and at least one simulated bad session prepared by the red team. Measure how long a review takes and which checks are slow.
3. Weeks 5 to 8, automate the pre-check: pull section 1 fields (ticket match, approval time, source, duration, recording errors) automatically from the PAM platform and change system, so reviewers start from a filled-in sheet.
4. Ongoing: review the watch-list and selection rule quarterly. If reviews never produce findings, the sample or the watch-list is probably wrong, not a sign that every administrator is perfect.
5. Rollback: if review backlog exceeds the agreed time limits, fall back to 100% review of break-glass, vendor and unticketed sessions only, and report the gap to the control owner rather than silently skipping reviews.

Smaller organisations with no session analytics can still apply sections 1, 3 and 8 to every break-glass and vendor session, using native logs. Larger organisations should risk-score sessions, route high scores to the SOC in near real time and keep the human review for what automation flags or cannot judge, such as whether an action matched the business intent.

Measures worth reporting monthly:

Framework mapping: the review itself supports NIST SP 800-53 AU-6 (Audit Record Review, Analysis, and Reporting), AC-6(9) (Log Use of Privileged Functions), AC-2(7) (Privileged User Accounts) and MA-4(1) (Logging and Review of nonlocal maintenance), and NIST CSF 2.0 DE.CM-03 (personnel activity monitored) and DE.AE-02 (potentially adverse events analysed). The NCSC's secure system administration principles include logging and auditing administration activities to confirm administrators only carry out legitimate, approved actions. For audit log review in general, see the CIS Control 8 Audit Log Management Guide.

Sources: NIST: SP 800-53 Rev. 5 Security and Privacy Controls · NIST: Cybersecurity Framework 2.0 · NCSC: Secure System Administration · ICO: Employment practices and data protection, monitoring workers · MITRE ATT&CK: T1098 Account Manipulation · MITRE ATT&CK: T1070 Indicator Removal

This checklist is provided for guidance, must be adapted to your organisation and is not legal advice. Related NHI Mgmt Group resources: Privileged Session Management Guide · Privileged Access Management Guide · Break Glass Access Procedure Template · Remote Support Sessions · Insider Threat Programme Guide