Buying a PAM tool alone won't satisfy an auditor; they want evidence it's being used. Usually, that shows up as a list of privileged changes from the period, with proof of who connected, how they got in, and what they did. Most of that you can have ready before anyone asks.
What's inside
Auditors look at two things: whether the control is designed correctly, and whether it operated during the period.
"Our privileged accounts are vaulted" answers the first one. The second is where teams get caught, because the auditor picks a sample of user activity and wants evidence for each item. For each one they pick, they look for the same five facts: who connected, which account they used, when, how they got in, and what they did once they were there.
If you can answer those five questions for any privileged session in the audit window, you have the evidence an auditor is asking for. The rest of this page is about producing them on demand instead of after the fact.
Who connected
The person, by name
Which account
The privileged identity used
When
Exact time of the session
How they got in
The path to the target
What they did
The activity inside the session
Those five facts come from three places: the vault activity log, the PSM session recording, and the change ticket that authorized the work.
Every PSM session gets an ID, and both the activity record and the recording are stored under it. Search the activity log for the account and date the auditor gave you, and that ID takes you straight to the recording of what happened. If you've integrated PAM with your ITSM platform, the admin supplies a change ticket number when requesting access, and it gets saved with the session record. The ticket and the session then show up together in one report. Build that report once and save it. Each time an audit comes around, you set the date range the auditor gave you and the report covers every item in their sample.
Don't rebuild the evidence for every audit. Build the joined report between vault activity, PSM recordings, and ITSM tickets once, then re-run it with a new date range each time. What used to be three weeks of digging becomes a five-minute export.
Vault activity log
Who checked out what, and when. The session ID lives here.
PSM recording
Video and keystrokes of what happened in the session, keyed by the same ID.
Change ticket
The ITSM record that authorized the work, attached to the session.
How far back an auditor looks depends on the framework. A lot of PAM deployments default to 90 days, and that rarely covers the period you'll actually be asked about.
A SOX audit generally covers your fiscal year, a SOC 2 Type II report covers a defined review period, and NERC CIP evidence retention runs three calendar years. PCI DSS is the most specific: at least 12 months of audit log history, with the last three months available for immediate analysis. Find the longest period that applies to you and set retention to cover it. To keep the storage cost manageable, keep recent recordings on fast storage and move older ones to cheaper archive storage.
It's also worth deciding up front whether your retention policy treats session recordings the same as audit logs. The frameworks are written about logs, and recordings are usually a policy choice your organization makes, so put that decision in writing before it comes up.
SOX
Generally covers your fiscal year.
SOC 2 Type II
Covers a defined review period.
NERC CIP
Evidence retention runs three calendar years.
PCI DSS
At least 12 months of logs, with the last three months available for immediate analysis.
Most environments have a few privileged logons that didn't come through PAM, and an auditor will eventually find them.
Break-glass accounts, a vendor with a local account, an admin using a local account on a server that was never onboarded. Run a monthly report comparing privileged logons on your servers to vault checkouts, and write down what each one was and how you handled it, whether that was onboarding the account, removing it, or confirming it was an approved break-glass use. Handing an auditor that report and saying "we found seven, here's what happened with each one" builds far more confidence than a clean report with no exceptions, since a perfectly clean report often means the detection isn't catching anything.
A clean report with zero exceptions usually means the detection is missing things, not that the environment is perfect. The monthly exception review is what proves the detection actually works, and it shows the auditor you know your environment well enough to call out the gaps yourself.
Break-glass accounts
Local accounts reserved for emergencies, never checked out of the vault.
Vendor local accounts
A third party with a local account that never got onboarded into PAM.
Servers not onboarded
An admin using a local account on a box PAM never learned about.
Most of this is work you do once: one joined report, a retention setting that matches your audit period, and a monthly exception review. After that, the next request is a date range away.
If audits mean digging for evidence at your company, please reach out. We can help you build the joined report, set the retention policy to match your audit period, and stand up the monthly exception review so the next request is a date range and a click away.