Every security review eventually gets to the same section: access. Who can reach production. How access is granted and revoked. Whether MFA is actually enforced or just recommended. If your answers involve phrases like “I’d have to check” or “let me ask around,” that’s usually the moment the review slows down.
None of these questions are exotic. They’re the same handful every time, and they’re answerable well in advance — if the access model is built to answer them, rather than reconstructed under deadline. Here’s what actually gets asked, and what a good answer looks like.
“Who currently has access to production?”
The weak answer is a spreadsheet someone half-remembers to update. The strong answer is a live, queryable list: which roles exist, which resources each one reaches, and which people hold each role — visible in one place, not reconstructed from onboarding docs and Slack history.
If answering this question requires cross-referencing three systems, that’s the finding, not the answer.
“How is MFA enforced, and can it be bypassed?”
Auditors aren’t just asking if MFA exists — they’re asking if it’s enforced org-wide, with no silent exceptions. A defensible answer covers three things: MFA is required for every account, not optional per-user; there’s a documented recovery path (backup codes, or an owner-level password-only fallback) so a lost authenticator can’t lock out every admin at once; and there’s no service account or legacy login that quietly skips it.
“Are credentials shared between people?”
This is the one that catches teams off guard, because the honest answer is often yes — a database password in a shared vault, an SSH key copied into onboarding docs. The fix isn’t a stricter vault policy; it’s removing the need for people to hold credentials at all. When access is brokered through a gateway that decrypts credentials only for the target login, the question stops being “how do we protect the shared password” and becomes “there isn’t one.”
“What happens when someone leaves?”
This is where checklists fail quietly. Offboarding-by-checklist means someone has to remember every system access was granted on, across however many tools accumulated it. The stronger answer: revoking one role, or disabling one account, cuts access everywhere at once — because access was never granted system-by-system to begin with.
“Can you show me exactly what a specific user did last month?”
This is the question that separates “we have logging” from “we have an audit trail.” Shell history and VPN connection logs tell you someone connected; they don’t tell you what they ran, what they queried, or what they saw on screen during an RDP session. A real answer means every login, grant, role change, and connection is searchable — SSH and SQL commands logged line by line, RDP sessions recoverable as video.
“Are credentials encrypted at rest, and who can decrypt them?”
The expected answer: yes, with a managed key (for infrastructure hosted on AWS, that typically means KMS), and decryption happens only transiently, inside the connection process, never returned to the end user’s client. If the honest answer involves a plaintext password field anywhere, that’s worth fixing before the review, not during it.
A shorter way to prepare
Every one of these questions has the same underlying fix: stop granting access per-person and per-system, and start granting it through roles tied to resources, with sessions recorded by default. That’s not a compliance workaround — it’s what privileged access management is for. Teams that set this up before the review spend the access section of an audit confirming things, not scrambling to answer them.
Curious what that looks like against your own infrastructure, resource by resource? Book a demo, or read PAM vs VPN: what’s actually different if you’re still weighing whether your current VPN setup is enough on its own.