Compliance Audits Are Asking the Wrong Question

Why is everyone prepping for the wrong audit?

If you're like most access control teams, you treat an audit as a hoop to jump through. You gather screenshots, pull IAM reports, and hope the auditor doesn't dig too deep. That's backwards. The auditor isn't there to make you fail; they're there to see if you can prove your access is under control. The real question isn't "Are we compliant?" but "Can we demonstrate least privilege and a Zero Trust mindset with evidence?" We've been in your shoes, and we've learned that the teams who pass with flying colors are the ones who use audits as a forcing function to tighten their access models, not just to assemble a binder.

Does my access control model actually matter for compliance?

It matters more than you think. Many regulations don't dictate a specific model, but they do require you to restrict access to authorized users, which is the whole point of access control (Tenable). If you're still relying on Discretionary Access Control (DAC) where every file owner sets their own permissions, you're probably not going to convince an auditor that you have consistent, enforceable policy. On the other hand, a central, policy-driven model like Role-Based Access Control (RBAC) gives you a clean, auditable story: permissions are assigned to roles, and users inherit them by being in those roles (Tenable). That's the kind of structure auditors want to see, because it reduces the risk of sprawl and makes it possible to answer the question "Who can access X?" without chasing down every individual share.

If we have RBAC, are we basically done?

Not quite. RBAC is a solid baseline, but it's not enough if your roles are so broad that they violate least privilege. The principle of least privilege says grant users only the minimum access they need to do their job (Tenable). If you have a role called "Finance" that includes both read-only and admin permissions because it was easier to manage, you've defeated the purpose. An auditor will ask: "Can a junior analyst change a salary?" If your RBAC doesn't distinguish between levels of responsibility, you'll have to admit that yes, they can. That's a red flag. The fix is to start with Core RBAC — user-role and permission-role assignments — and then enforce separation of duties, which NIST SP 800-53 describes as dividing critical functions so no single individual has enough access to commit fraud. That's not just a nice-to-have; it's a control that auditors actively look for.

But we use ABAC, isn't that even better?

ABAC is more granular, sure, but it's not a silver bullet. ABAC evaluates attributes of the subject, object, action, and environment like time or location (Cisco Duo). That gives you fine-grained decisions, but it also creates a massive policy surface that's easy to get wrong. If you have thousands of attributes and policies, can you explain to an auditor why a specific access decision was made? That's a challenge. Most organizations do fine with RBAC as the backbone and add ABAC only for context-aware edge cases (Cisco Duo). If you're going to claim ABAC, you need to have a policy engine that can produce an audit trail of the attributes that were evaluated for every request. Otherwise, you're just generating noise.

Does the auditor really care about Zero Trust?

They should, and increasingly they do. Zero trust isn't just a buzzword; it's a paradigm that moves defenses from static network perimeters to focusing on users, assets, and resources (NIST SP 800-207). The core idea is that no user or device is implicitly trusted based on location (NIST SP 800-207). If your audit scope includes a cloud environment, the auditor will want to know how you're enforcing per-session access decisions based on dynamic policy — the state of the user, device, and environment (NIST SP 800-207). They'll also want to see that you've implemented phishing-resistant MFA, because the federal government mandated it by the end of fiscal year 2024 (OMB M-22-09). If you're still on SMS one-time codes, that's a compliance gap waiting to bite you.

What's the deal with phishing-resistant MFA? Is it really that important?

Yes, and this is where many teams are deluding themselves. CISA calls phishing-resistant MFA the "gold standard" and identifies FIDO/WebAuthn and PKI-based MFA as the only acceptable forms (CISA Phishing-Resistant MFA). Regular MFA — even with an authenticator app — is vulnerable to push bombing and SIM swap attacks (CISA Phishing-Resistant MFA). We've seen audits where the finding is: "MFA is in place, but it's not phishing-resistant." That's a serious deficiency. The fix is to deploy passkeys, which are FIDO2-based and phishing-resistant because they're bound to a specific domain (Microsoft Passkeys). Passkeys also count as MFA because they require something you have (the device) plus something you are or know (biometric or PIN) (Microsoft Passkeys). So, when you're building your compliance evidence, show that you're using modern, phishing-resistant methods, not legacy ones.

How do we prove least privilege in a cloud environment, like AWS?

If you're on AWS, you already have a powerful tool: IAM roles. An IAM role isn't tied to a person and has no long-term credentials; users assume the role to get temporary security credentials (AWS IAM Roles). That's perfect for audit because you can show exactly who assumed what role, when, and for what purpose. The problem arises when roles are too permissive. AWS IAM denies access by default, and an explicit Deny overrides any Allow (AWS IAM). That's good, but you need to be sure your policies are actually least privilege. We recommend using AWS's own guidance: create policies that allow only the permissions required to perform a task (AWS IAM). Then, for cross-account access, make sure you have both a permissions policy and a trust policy that specifies which principals can assume the role (AWS IAM Roles). Auditors love that level of specificity.

But our auditors keep asking for identity federation. What's that about?

Identity federation is how you integrate your existing identity provider with AWS or any cloud. Instead of creating a separate user for every employee, you establish a trust relationship between your IdP and the cloud, and users get assigned to an IAM role based on their existing identity (AWS IAM Roles). This is a huge win for compliance because it means you have centralized control over who can access what, and you can revoke access instantly when someone leaves. If you're not federated, you're likely managing duplicate accounts, which is an audit nightmare. The standard way to do this is with SAML 2.0 or OpenID Connect (OIDC) (AWS IAM Roles). OIDC is built on OAuth 2.0 and adds an identity layer with a signed ID token (OpenID Connect). That's the modern choice. SAML is older but still common in enterprise. Either way, the key is that you're not creating cloud-specific credentials that outlive the user's employment.

Should we use conditional access policies or just rely on MFA?

Conditional access is the next step. It's not just about MFA; it's about making access decisions based on signals like user, device, location, and risk (Microsoft Conditional Access). For example, you might say: "If a user is outside the office and on an unmanaged device, require MFA and device compliance." That's a dynamic policy that adjusts to context. Auditors like this because it shows you're not granting blanket access. Microsoft's Conditional Access is essentially a Zero Trust policy engine (Microsoft Conditional Access). If you're using Microsoft Entra, you can implement policies that block or grant access based on those signals. That gives you an audit trail of decisions that you can present to an auditor as evidence of your control framework.

What about privileged accounts? How do we audit those?

Privileged accounts are the "keys to the kingdom," and their compromise plays a role in many major breaches (NIST PAM). If you're not managing them with a Privileged Access Management (PAM) solution, you're flying blind. NIST lists common PAM controls: credential vaulting with rotation, just-in-time access, session recording, and MFA for privileged sessions (NIST PAM). When an auditor asks how you prevent an admin from having standing access to everything, you need to say: "We use just-in-time access." Microsoft's PIM is an example: it provides time-based and approval-based role activation (Microsoft PIM). So, instead of an admin having permanent rights, they request a role, it's approved, and it expires. That's a concrete control that auditors love. Don't wait until an audit to implement this — do it now, and the audit becomes a formality.

Bottom line

The single best move you can make today is to adopt a Zero Trust mindset and implement least privilege with just-in-time access for privileged roles. That means moving away from standing permissions and embracing tools like PIM, conditional access, and phishing-resistant MFA. When the auditor shows up, you'll have a story backed by evidence, not a stack of screenshots that crumble under scrutiny.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• OMB M-22-09 - https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• Microsoft PIM - https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
• AWS IAM Roles - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html