Auditors do not ask whether you have a PAM tool. They ask you to prove, for a sample of privileged accesses, who asked, who approved, what was permitted, what actually happened and when it ended. The tool matters only if it can produce that chain on demand, in a form the auditor can trust.
Most teams assemble this by hand before every audit: exports, screenshots and a week of chasing people. This article lists what auditors typically want, how it maps to the major frameworks, and what makes evidence credible.
This is general guidance, not legal or audit advice. Confirm the scope and wording with your assessor.
The five questions behind every privileged access sample
Whatever the framework, a sample of privileged access tends to reduce to five questions:
- Who requested access, and why? A named person and a stated reason, not a shared account.
- Who approved it? A different person with the authority to approve, recorded at the time.
- What was permitted? The systems, the actions and the time window that were authorised.
- What happened? A record of the session: who connected, to what, for how long, and what they did.
- When did it end? Access that expired, or was revoked, rather than lingering.
If your evidence can answer all five for any session picked at random, most of the audit is already done.
How the frameworks ask
| Framework | Where privileged access shows up | What they tend to want to see |
|---|---|---|
| ISO/IEC 27001:2022 (Annex A) | 5.15 access control, 5.16 identity management, 5.17 authentication information, 5.18 access rights, 8.2 privileged access rights, 8.5 secure authentication, 8.15 logging, 8.16 monitoring activities | A policy, approved and time-limited privileged access, periodic review of rights, and logs that are protected and reviewed |
| SOC 2 (Trust Services Criteria) | Logical access controls (CC6) and system monitoring (CC7) | Provisioning and removal of access, authentication, restriction of privileged users, and monitoring of unusual activity, sampled over the audit period |
| PCI DSS v4.0 | Requirements 7 (restrict access by need to know), 8 (identify and authenticate users) and 10 (log and monitor) | Individual accountability, MFA for administrative access, and audit trails that cannot be altered |
| DORA | The ICT risk management framework, incident reporting, resilience testing and third-party risk rules for EU financial entities | Access control and strong authentication, logging and detection of anomalous activity, recovery capability, and oversight of ICT third parties such as vendors and managed service providers |
| HIPAA / SOX / GDPR / NIST CSF | Access control, audit controls, accountability and least privilege | Who accessed what, on what authority, with an unalterable record |
The wording differs; the evidence you need is largely the same. That is why mapping one internal control to the clauses of several frameworks saves so much effort: you gather the evidence once and use it several times.
What makes evidence credible
Auditors have learned to be sceptical of exports. Evidence is stronger when it has these properties:
- It is generated, not assembled. A record created at the moment of the event beats a spreadsheet built later.
- It is tamper-evident. If someone could edit it, the auditor has to trust that nobody did. A hash chain, where each record includes a hash of the one before it, makes alteration detectable: change one entry and every later hash stops matching.
- It can be verified independently. An auditor who can check the evidence without logging into your console does not have to take your word for it. Signed evidence with a manifest, and a verifier that runs offline, move the trust from the platform to arithmetic.
- It links the whole chain. Request, approval, scope, session and expiry belong in one trace, not in five systems that must be reconciled.
- It is complete. A sampling-based audit asks for sessions you did not choose. Gaps (sessions with no recording, approvals made outside the tool) are findings.
- It is scoped. An MSP or a multi-business group needs evidence per tenant or per entity, without exposing others.
Evidence an auditor can verify, and how to test it
Ask any vendor, including yours, to demonstrate:
- Export an evidence pack for a date range, covering requests, approvals, sessions and commands.
- Verify it offline on a machine that has no access to the platform.
- Change one file in the pack and confirm the verifier detects it.
- Verify the audit trail's integrity: run a chain check and confirm that a broken link would be reported, with where.
- Pick a session at random and walk the five questions end to end.
- Show review evidence: a completed access review campaign with approvals, rejections and escalations.
- Show what happens to evidence when a licence lapses or a tenant is suspended. Evidence should stay readable.
Preparing for the audit in practice
- Define the sample population with your auditor early: which systems count as privileged and which period.
- Run your own sample first. Pick ten sessions and answer the five questions. Anything you cannot answer is the gap to close.
- Close the loopholes: shared accounts, emergency access without review, and approvals by email or chat.
- Schedule access reviews (quarterly or semi-annual) and keep the outcomes with the evidence.
- Keep retention aligned with the longest framework you answer to.
- Document your controls once, mapped to clauses, so each audit starts from the map instead of from scratch.
How ZenXPAM supports this
ZenXPAM maps its internal controls to named clauses in SOC 2, ISO 27001, PCI DSS, HIPAA, SOX, GDPR, NIST CSF and DORA, scores each framework continuously, and runs certification campaigns (quarterly, semi-annual or annual) with approve, reject, bulk and delegate actions and automatic escalation of overdue reviews. The audit trail is a hash-chained, append-only record, with an API to verify a single entry or an entire chain and to report where a link is broken. Evidence packs are signed with a per-file manifest and come with an offline verifier, so an auditor can confirm them without access to the platform. Request, approval, scope, session and expiry are linked in one trace, and each tenant has its own recordings, command trails and evidence. This evidence supports your compliance work; it does not by itself make an organisation compliant. See compliance evidence automation or book a demo.
FAQ
Does a PAM tool make us DORA or ISO 27001 compliant? No. It produces evidence for specific controls, such as access control, logging and monitoring. Compliance depends on your whole programme.
What does an auditor mean by tamper-evident? That any change to a record can be detected afterwards. A hash chain achieves this: altering an entry breaks the hashes that follow it.
Do we need session recordings for audits? Frameworks rarely name recordings, but they require that privileged activity is logged and reviewable. Recordings and command trails are the strongest evidence of what happened.
How long should evidence be kept? Long enough for the longest requirement you face. Agree the period with your assessor, and keep evidence available through licence or tenancy changes.
Can evidence be produced per customer? It should be, for managed service providers and groups. Tenant-scoped recordings and evidence let each customer take their own record to their own audit.