BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Identity and privileged access controls are among the most heavily scrutinized areas in every major compliance framework. SOC 2, ISO 27001, PCI DSS, HIPAA, and CMMC all include explicit requirements for MFA, least-privilege access, privileged account controls, access reviews, and lifecycle management. These are not aspirational guidelines; they are audited control requirements with specific evidence expectations. An IAM/PAM program that delivers architecture documentation, privileged account inventory, PAM configuration evidence, MFA deployment records, quarterly access review documentation, and joiner-mover-leaver workflow records is producing exactly the evidence package that auditors request across all of these frameworks. Organizations that operate without a documented IAM/PAM program consistently face findings in the access management control domain regardless of how well-controlled other areas of their environment are.

Key Takeaways

• Access management is a cross-cutting compliance requirement. Unlike controls that apply only in specific frameworks, IAM and PAM requirements appear in every major framework and are evaluated as a coherent program rather than isolated technical settings. The auditor who reviews your SOC 2 access management controls is asking the same fundamental questions as the auditor who reviews your PCI DSS privileged access controls: who has elevated access, how is it governed, how is MFA enforced, and how is access reviewed and revoked?
• MFA is explicitly required by every framework covered in this article. The specific language varies, but the substance is the same: multi-factor authentication is required for administrative access and is expected for all user access to systems that hold sensitive data. Organizations whose MFA coverage has gaps, specifically administrative accounts without MFA, are consistently cited in audit findings across all frameworks.
• Access reviews are a documented, recurring control requirement, not a one-time exercise. SOC 2, ISO 27001, PCI DSS, HIPAA, and CMMC all expect evidence that access reviews are conducted on a defined schedule, that the reviews result in access changes where appropriate, and that the review process is documented with reviewer assignments, certification records, and remediation tracking. An access review that was conducted once in response to an audit finding does not satisfy the operating effectiveness requirement of a Type II assessment.
• Privileged access controls are evaluated more rigorously than general user access controls. Every framework treats privileged accounts as a higher-risk category requiring elevated controls: individual accountability (no shared admin credentials), MFA (no exceptions), session monitoring or recording, more frequent access review, and documented justification for every privilege grant. The PAM program artifacts, specifically the privileged account inventory, vault configuration, session recording evidence, and access review records for privileged accounts, are the evidence set auditors focus on most intensively.
• The NIST SP 800-63 Digital Identity Guidelines provide the technical framework for identity assurance levels that underlies most framework requirements. Authenticator Assurance Level 2 (requiring MFA) is the baseline for most sensitive access scenarios; Authenticator Assurance Level 3 (requiring hardware-backed, phishing-resistant authentication) is expected for the most sensitive privileged access. Understanding where your access scenarios sit on the NIST SP 800-63 assurance level scale helps map the technical controls required by each framework to a common technical standard.

Framework by Framework: What IAM and PAM Address

SOC 2

SOC 2 Trust Services Criteria CC6.1 requires that the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives. CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. CC6.3 requires that the entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on approved and documented access requests and the joiner-mover-leaver process. CC6.6 requires that logical access security measures restrict access to information assets to authorized users, including use of appropriate MFA.

For SOC 2 Type II, which evaluates operating effectiveness over the audit period, the access management evidence request typically includes: a sample of user provisioning records showing that access was authorized before being granted (CC6.2), a sample of access modification and termination records showing timely updates following role changes and departures (CC6.3), evidence of MFA enforcement including configuration screenshots and a sample of authentication logs (CC6.6), and the most recent access review report including reviewer assignments, certification records, and any remediations completed as a result of the review (CC6.3). An IAM/PAM program that produces all of these artifacts as standard operational outputs is audit-ready for SOC 2 Type II without requiring a documentation scramble before each assessment.

ISO 27001

ISO 27001:2022 Annex A contains multiple access management controls directly addressed by an IAM/PAM program. A.5.15 (Access Control) requires a policy for access control that limits access based on business and security requirements. A.5.16 (Identity Management) requires the full lifecycle management of identities. A.5.17 (Authentication Information) requires the management of authentication information including passwords. A.5.18 (Access Rights) requires provisioning and deprovisioning of access rights following defined processes. A.8.2 (Privileged Access Rights) specifically requires that privileged access rights be restricted, controlled, allocated, and reviewed to prevent unauthorized access and changes to systems. A.8.5 (Secure Authentication) requires multi-factor authentication where appropriate based on access risk.

ISO 27001 certification assessors evaluate both the documented policies and procedures and the evidence of their implementation. For access management, this means the access control policy document (A.5.15), the identity lifecycle process documentation (A.5.16 and A.5.18), the privileged access policy (A.8.2), and evidence of MFA deployment (A.8.5) are the documentation artifacts. The access review records, provisioning and deprovisioning records, and PAM configuration evidence are the implementation evidence. An IAM/PAM engagement produces all of these as standard deliverables and maps them to the applicable Annex A controls in the compliance mapping document.

PCI DSS

PCI DSS v4.0 has some of the most prescriptive access management requirements of any compliance framework. Requirement 7 requires that access to system components and cardholder data is limited to only those individuals whose job requires such access. Requirement 8 addresses identification and authentication of users and administrators. Its sub-requirements are specific: 8.2.1 requires that all users are assigned a unique ID before access to system components is granted, 8.2.2 restricts the use of shared, group, or generic accounts to only when necessary and with additional controls, 8.4.1 requires MFA for all non-console administrative access into the cardholder data environment, and 8.4.2 requires MFA for all access into the cardholder data environment, not just administrative access. This expansion of MFA to all CDE access, not only administrators, is one of the most significant changes v4.0 introduced over v3.2.1, and it became mandatory on March 31, 2025.

Requirement 8 also governs account lifecycle: accounts that have been inactive for more than 90 days must be disabled (8.2.6), and application and system accounts and their authentication factors are managed under 8.6, including changing credentials that are not in use and confirming accounts are still needed. Requirement 10 requires logging and monitoring of all access to system components, with audit log review and log retention (at least 12 months, with 3 months immediately available). The PAM session recording capability directly addresses the audit logging requirement for privileged access; the quarterly access review process supports the periodic account-review discipline PCI DSS expects. PCI DSS is unusually specific about the 90-day cadence for inactive accounts, which aligns well with the quarterly access review cadence in the Armour Cybersecurity IAM/PAM program.

HIPAA

HIPAA’s Security Rule requires covered entities and business associates to implement access controls for electronic protected health information (ePHI) under 45 CFR 164.312(a). The access control standard includes unique user identification (prohibiting shared accounts for ePHI access), emergency access procedures, automatic logoff, and encryption and decryption. The information access management standard at 45 CFR 164.308(a)(4) requires policies and procedures for authorizing access to ePHI. The workforce security standard at 45 CFR 164.308(a)(3) requires appropriate access controls for the workforce and procedures for authorizing access and terminating access when no longer needed.

HIPAA enforcement through the HHS Office for Civil Rights evaluates whether the required administrative, physical, and technical safeguards have been implemented and whether the organization can produce evidence of implementation. The unique user identification requirement maps directly to the prohibition on shared admin credentials. The information access management standard maps to the provisioning and access review processes. The workforce security termination procedures map to the leaver deprovisioning workflow. Organizations under HIPAA that use shared administrative accounts or cannot demonstrate timely deprovisioning of departed employees’ access are exposed to HIPAA enforcement action.

CMMC

Cybersecurity Maturity Model Certification Level 2 maps to NIST SP 800-171, which includes access control practices that directly address IAM and PAM requirements. AC.L2-3.1.1 limits system access to authorized users and the types of transactions and functions that authorized users are permitted to execute. AC.L2-3.1.5 requires employment of the principle of least privilege, including for specific security functions and privileged accounts. AC.L2-3.1.6 requires use of non-privileged accounts when accessing non-security functions. AC.L2-3.1.7 requires preventing non-privileged users from executing privileged functions and capturing the execution of such functions in audit logs. IA.L2-3.5.3 requires use of multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

CMMC assessors evaluate the practice implementation for Level 2. The practice implementation evidence is the technical configuration of MFA enforcement, PAM vaulting, and access controls, together with the documented policies, procedures, and access review records that demonstrate the controls are operated consistently over time rather than configured once and never maintained. Armour Cybersecurity produces compliance mapping to NIST SP 800-171 and CMMC practices as a standard deliverable of the identity and privileged access management engagement, structured for direct use during the CMMC assessment.

Frequently Asked Questions

What evidence do auditors typically request for MFA controls?

Auditors evaluating MFA controls typically request configuration screenshots showing MFA is enabled and required for the applicable user populations, with the specific policy settings visible (which users are in scope, whether legacy authentication is blocked, whether there are any exceptions). They then request a sample of authentication logs from the audit period showing MFA challenges and successful MFA completions for the user accounts in scope. For privileged access specifically, they may request evidence that MFA is required for all privileged account access without exception, and that any exception request requires documented approval. Some auditors also request evidence of MFA method strength: an organization that uses SMS-based MFA may receive a finding noting that SMS is a weaker assurance method than authenticator app or hardware key, particularly for privileged account access.

How do we handle access review for service accounts?

Service account access reviews follow a different process from user access reviews because service accounts do not have individual owners in the traditional sense. The review assigns each service account to a functional owner, typically the team responsible for the application or process the service account supports, who certifies that the service account is still in use, that its permissions remain appropriate for its function, and that its credentials have been rotated within the defined rotation schedule. Service accounts that cannot be assigned to a current owner or whose function cannot be identified are candidates for decommissioning. The review frequency for privileged service accounts should match or exceed the quarterly cadence for privileged user accounts given the elevated risk profile of service accounts with broad permissions. Bringing service accounts under privileged access management is what makes this review enforceable rather than aspirational.

Can we use our existing Active Directory group membership as a substitute for formal access reviews?

Active Directory group membership documents what access has been granted but does not constitute a review of whether that access remains appropriate. A formal access review requires a reviewer with knowledge of the business role to examine the access and make an affirmative determination that each access grant is still required and appropriate. Simply confirming that group memberships exist does not satisfy this requirement because the question the review must answer is not whether the access exists but whether it is still justified. Auditors consistently distinguish between access attestation, where a reviewer actively certifies that access is appropriate, and access reporting, where a system produces a list of who has what access. The former satisfies the access review requirement; the latter is a prerequisite for the review but not the review itself. The structured access governance process is what turns raw group-membership data into a defensible attestation.

What is the difference between access certification and access recertification?

Access certification is the initial formal review and approval of an access grant, confirming that the access requested is appropriate for the requester’s role and that the approver has authority to grant it. Access recertification is the periodic review of existing access grants to confirm they remain appropriate over time, which is what the quarterly access review process provides. Both are required: certification ensures that access is granted appropriately at the outset, and recertification ensures that access that was granted appropriately does not persist beyond its justified scope as roles, responsibilities, and business requirements change. Compliance frameworks that reference access reviews are typically referring to recertification, the ongoing periodic process, rather than only the initial certification that occurs at provisioning time.

The Bottom Line

Identity and privileged access is the control domain every framework scrutinizes hardest, and it is where organizations without a documented program get cited regardless of how strong the rest of their environment is. SOC 2, ISO 27001, PCI DSS, HIPAA, and CMMC ask the same core questions in different language: who has elevated access, how is MFA enforced, how is access reviewed, and how is it revoked when someone leaves. The good news is that one well-run IAM/PAM program produces the evidence for all of them at once: the privileged account inventory, the vault and session-recording configuration, the MFA deployment records, the provisioning and deprovisioning records, and the quarterly access review documentation are the same artifacts every auditor asks for. Build that program so those artifacts are standard operational outputs, not a scramble before each assessment, and audit readiness becomes a byproduct rather than a project. Armour Cybersecurity’s identity and privileged access management engagement produces the control set and the framework-mapped evidence package as a standard deliverable.