Auditors ask the same four questions across every compliance framework: who has access, who approved it, when was it reviewed, when was it revoked. This guide maps how IAM controls answer those questions across SOX, SOC 2, HIPAA, PCI DSS, and ISO 27001.
IAM compliance looks like a multi-front challenge when you approach it framework by framework: SOX ITGC has its access control requirements, SOC 2 has its own, HIPAA and PCI DSS add theirs, and ISO 27001 frames the whole thing differently again. Security and IT teams in organizations facing multiple framework requirements can end up building separate evidence packages, running separate review cycles, and treating each audit as a distinct compliance program.
The underlying logic is simpler than this. Every access control requirement across every major enterprise compliance framework is asking some version of four questions:
Who has access to what? The inventory question: completeness, accuracy, and currency of the access record.
Who approved it, and why? The authorization question: evidence that access grants were deliberate decisions made by accountable people.
When was it last reviewed? The governance question: evidence that access appropriateness is periodically verified, not just set and forgotten.
When did access end? The revocation question: evidence that access is terminated promptly when the relationship that justified it changes.
An IAM program that answers these four questions consistently, for all identities, across the complete application estate, is compliant with the access control dimensions of every framework on this list. The framework-specific sections below map the exact requirements to the common IAM controls that satisfy them, with the evidence artifacts each framework expects.
The Four IAM Controls That Drive Compliance
Before mapping to frameworks, it's worth being precise about which IAM controls produce compliance evidence, because the gap between "we have IAM" and "we can prove our IAM controls work" is where most compliance programs run into difficulty.
Provisioning audit logs record every access grant: who provisioned it, when, under what approval, and what the access scope is. This is the evidence for the authorization question. If access was granted and no provisioning record exists, the auditor's follow-up question is how access was authorized. The answer "informally, by the department head, via email" is a finding.
Deprovisioning audit logs record every access revocation: which accounts were closed, when, and in response to which trigger (departure event, role change, access review finding). This is the evidence for the revocation question. Deprovisioning records with timestamps showing same-day or next-day revocation demonstrate a functioning offboarding control. Deprovisioning records showing 30+ day delays, or missing records for departed employees, produce findings.
Access review records document that periodic certification happened: which access populations were reviewed, who conducted the reviews, what decisions were made, and what remediation followed. This is the evidence for the governance question. A completed access review record with follow-through remediation is clean evidence. A review that completed but with 40% of flagged items unresolved is partial evidence that creates questions.
SoD violation reports document conflicting permission combinations identified and remediated. These are required specifically by frameworks with financial control requirements (SOX ITGC primarily), but increasingly expected in SOC 2 and ISO 27001 audits as well.
The common thread: all four of these evidence types are byproducts of a functioning IAM program, not additional work created for audit purposes. Organizations that produce them naturally produce clean compliance evidence. Organizations that assemble them manually before each audit incur significant cost and risk inconsistency.
Framework-by-Framework Mapping
SOX ITGC (Sarbanes-Oxley IT General Controls)
SOX ITGC access controls are the strictest access requirements most publicly traded companies face. The specific control areas that auditors examine cover five categories: access controls (logical access to financial systems), network and systems security, physical security, incident management, and data processing controls.
For IAM, the directly relevant areas are access controls and, at the edge, data processing controls for organizations handling financial data.
What auditors look for:
Provisioning controls: evidence that access to financial systems was granted through a formal approval process, that the approval was documented, and that access was scoped to minimum necessary. Auditors review provisioning records for the audit period, looking for access grants without documented approvals and for permission levels that exceed what the role requires.
Deprovisioning controls: evidence that access was revoked within the organization's documented SLA (typically 24 hours for standard users, immediate for privileged accounts) when users departed or changed roles. Auditors pull departure records from HR and match them against access revocation timestamps. Gaps are findings.
Periodic access reviews: evidence that someone other than the access holder reviewed and certified that access remained appropriate during the audit period. For SOX, this typically means quarterly access review completion records for financial system access, with evidence that flagged items were remediated within a defined window.
SoD controls: evidence that no single user holds access to both sides of a financial transaction: payment approval and payment processing, or journal entry creation and journal entry approval. Cross-application SoD analysis covering ERP, finance, and approval systems is expected.
IAM evidence package: Provisioning log exports for the audit period, deprovisioning records with timestamps matched to HR departure events, access review completion records with remediation evidence, SoD violation detection and remediation reports.
SOC 2 Type II
SOC 2 evaluates controls against five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. Most SOC 2 audits focus on security and, depending on the service, availability and confidentiality. The access control requirements sit within the security criteria.
What auditors look for:
Logical access controls: the organization has defined which users should have access to which systems, and can demonstrate that actual access matches defined policy. This requires both a policy document (what access each role should have) and evidence that access grants implement the policy (provisioning records showing role-appropriate access at appropriate permission levels).
User access reviews: evidence that access was reviewed periodically throughout the audit period (typically the 12-month SOC 2 Type II period), with completion documentation and evidence of remediation. Reviewers cannot be the access holders; access owners, managers, or security team members must conduct the review.
Provisioning and deprovisioning: evidence that the provisioning process is consistent and approval-gated, and that deprovisioning happens within the organization's defined SLA. SOC 2 auditors look specifically at whether deprovisioning is triggered systematically or relies on manual checklist completion. The latter produces higher finding rates.
IAM evidence package: Access control policy documentation, provisioning records for the audit period, access review completion records with reviewer attribution, deprovisioning records with timing evidence.
HIPAA (Health Insurance Portability and Accountability Act)
HIPAA's Security Rule access requirements apply to covered entities and business associates handling protected health information (PHI). The relevant safeguards are within the administrative and technical safeguard categories.
What auditors look for:
Access authorization: documented procedures for granting and modifying access to PHI systems, with evidence that those procedures were followed. Every access grant to a system containing PHI should have an authorization record: who authorized it, under what policy, when.
Workforce access controls: evidence that access to PHI is limited to the minimum necessary for each workforce role. This is HIPAA's version of least privilege: not just that users are authenticated, but that their access scope is appropriate for their function.
Automatic logoff and encryption: technical controls that limit the window of unauthorized access if a session is left unattended. These are typically platform-level controls but must be documented as implemented.
Audit controls: activity logs showing who accessed PHI systems, when, and what actions were performed. HIPAA requires both access controls (preventing unauthorized access) and audit controls (detecting it if it occurs).
Workforce termination procedures: evidence that access to PHI systems was revoked when workforce members departed, with timing documentation. HIPAA auditors look specifically at the gap between departure date and deprovisioning completion for PHI-relevant systems.
IAM evidence package: PHI system access authorization records, workforce access scope documentation mapped to minimum-necessary standard, deprovisioning records for PHI systems with departure-to-revocation timing, activity audit logs for PHI system access.
PCI DSS (Payment Card Industry Data Security Standard)
PCI DSS Requirement 7 (restrict access to cardholder data by business need) and Requirement 8 (identify users and authenticate access) are the primary IAM-relevant requirements. PCI DSS v4.0, effective March 2025, strengthened several access control requirements.
What auditors look for:
Need-to-know access: evidence that access to cardholder data environments (CDE) is limited to personnel with a documented business need. Each user with access to CDE systems should have a documented justification, and access should be scoped to minimum necessary for that justification.
Unique user IDs: no shared accounts for access to CDE systems. Every individual accessing cardholder data must have a unique, individually attributable account. Shared accounts or service accounts with shared credentials in CDE systems are findings.
MFA for all access: PCI DSS v4.0 requires MFA for all access to CDE systems, not just remote access. Evidence that MFA is enforced for every authentication event to CDE-relevant applications.
Access review: periodic review (at least every six months under PCI DSS v4.0) of user access to all system components, with evidence of review completion and timely follow-through on revocations.
Account management: evidence that accounts are disabled within 24 hours of personnel departure, and that inactive accounts (unused for more than 90 days) are removed or disabled.
IAM evidence package: CDE access authorization records with business-need documentation, evidence of unique account enforcement (no shared accounts), MFA enforcement logs for CDE access, semi-annual access review records, inactive account detection and remediation evidence.
ISO 27001
ISO 27001 Annex A includes access control as control domain A.9 (in the 2013 version) and redistributed across multiple controls in the 2022 version (A.5.15 through A.8.5). The framework is risk-based rather than prescriptive: it requires that access controls exist and are appropriate to the organization's risk profile, not that they take a specific form.
What auditors look for:
Access control policy: a documented policy that defines the principles governing access (least privilege, need-to-know, segregation of duties) and the procedures for implementing those principles. The policy must exist, be approved by management, and be reflected in actual practice.
User access provisioning: documented procedures for granting access, with evidence that the procedures were followed consistently during the audit period. Provisioning records are the evidence.
User access rights management: evidence that access rights are reviewed at regular intervals and after significant changes (role changes, departures, organizational restructuring). ISO 27001 does not specify review frequency; auditors look for a defined frequency and evidence that it was maintained.
Privileged access management: specific controls for privileged accounts, typically including more frequent review, additional authorization requirements, and tighter deprovisioning SLAs.
Removal or adjustment of access rights: evidence that access was modified or revoked as appropriate when employment or contractual relationships changed.
IAM evidence package: Access control policy documentation with management approval, provisioning and deprovisioning records for the audit period, access review records with defined frequency evidence, privileged account management documentation.
How Zluri Produces Compliance Evidence as a Program Byproduct
Organizations that treat compliance evidence as something to assemble before each audit spend more on compliance than organizations that produce evidence continuously as a byproduct of normal governance operations. The difference is architectural.
Zluri is an identity security platform whose four IGA modules (Access Management, Access Requests, Access Reviews, Segregation of Duties) produce the evidence artifacts each framework above requires as part of normal operations.
Provisioning and deprovisioning events across 300+ application integrations generate timestamped logs automatically, with approver attribution from the Access Requests workflow. When an auditor asks for a list of all access grants to a financial system during the audit period, with approval records, the export exists.
Access Reviews run on defined schedules at application, group, or user level, generating completion records, reviewer attribution, decision documentation, and remediation tracking. The access review evidence package for a SOC 2 or SOX audit is an export, not an assembly project.
SoD enforcement runs continuously across cross-application permission combinations, generating violation detection records and remediation evidence. The SoD report for a SOX audit is current, not reconstructed.
IRIS, the intelligence layer, continuously surfaces dormant accounts, over-permissioned identities, and policy violations so that remediation happens before the audit cycle rather than during it. Auditors reviewing a clean, current access posture with evidence of continuous remediation produce fewer findings than auditors reviewing a posture that was cleaned up in the weeks before their arrival.
Run logs are exportable on configurable cadences (daily, weekly, monthly) for SOX ITGC, SOC 2, HIPAA, PCI DSS, and ISO 27001 evidence requirements.
Book a demo to see how Zluri produces compliance evidence across your active frameworks
Related Compliance Guides
Zluri's SOX ITGC compliance guide Zluri's SOC 2 access control guide Zluri's HIPAA compliance guide Zluri's PCI DSS compliance guide Zluri's ISO 27001 access review guide
Frequently Asked Questions
Is IAM required for SOC 2 compliance?
IAM controls are not explicitly mandated by name in SOC 2, but the access control requirements within the Security Trust Service Criteria (logical access controls, user access reviews, provisioning and deprovisioning evidence) require a functioning IAM program to satisfy consistently. Organizations that attempt to produce SOC 2 access control evidence without structured IAM processes typically find audit preparation expensive and findings rates high.
What is the difference between SOX ITGC and general IAM compliance?
SOX ITGC (IT General Controls) is the set of IT controls that support the reliability of financial reporting under the Sarbanes-Oxley Act. The access control dimension of SOX ITGC is stricter and more specifically defined than general IAM best practice, particularly around SoD requirements for financial systems and deprovisioning timing evidence. SOX ITGC compliance requires the same IAM infrastructure as other frameworks but with tighter SLAs, more frequent access reviews for financial system access, and explicit SoD conflict documentation.
Do all five frameworks require access reviews?
Yes, all five require some form of periodic access review, though the specific frequency and scope requirements differ. PCI DSS v4.0 specifies semi-annual review. SOX ITGC typically expects quarterly review for financial system access. SOC 2 Type II expects reviews throughout the 12-month audit period. ISO 27001 requires a defined frequency without specifying it. HIPAA requires periodic review without defining the interval. In practice, quarterly access reviews covering all sensitive systems satisfy the review requirements of all five frameworks simultaneously.
What is an IAM compliance audit?
An IAM compliance audit is a formal review of an organization's identity and access management controls against the requirements of a specific framework (SOX, SOC 2, HIPAA, PCI DSS, or ISO 27001). Auditors examine provisioning records, deprovisioning evidence, access review completion documentation, and SoD reports to determine whether controls operated effectively during the audit period. Internal IAM compliance audits (self-assessments against the same criteria) are a standard preparation practice before external audits.
How does IAM compliance relate to continuous compliance?
Continuous compliance is the model where compliance controls operate and produce evidence throughout the year rather than only at audit time. IAM is one of the primary domains where continuous compliance is achievable: provisioning and deprovisioning logs exist continuously, access reviews can run on a rolling rather than point-in-time basis, and SoD monitoring can run continuously rather than at quarterly checkpoints. The alternative, treating compliance as a periodic event, produces higher audit preparation costs and higher findings rates because issues accumulate between review cycles rather than being remediated as they occur. See Zluri's continuous compliance guide for the architectural distinction.
.svg)
