How to Map Access Reviews to SOC 2, ISO 27001, and HIPAA Controls

Every mid-market GRC lead runs into the same pain: SOC 2 wants CC6.1 evidence, ISO 27001 wants A.5.18 evidence, HIPAA wants 164.308(a)(4) evidence, and each auditor asks for a slightly different artifact. The reality is that the underlying operational process is one process, and a well-run access review satisfies all three at once if you tag the evidence correctly.

Here is the crosswalk that actually works, plus the pitfalls that make audits harder than they need to be.

Which controls does a user access review satisfy?

Nine controls across three major frameworks. Grouped by concept.

A single access review campaign, correctly evidenced, satisfies all of these. The frameworks overlap; the operational process does not multiply.

What evidence does SOC 2 require specifically?

SOC 2 Type II wants operating effectiveness over the review period, not just one-time execution.

• CC6.1 (logical access controls). Evidence that access is restricted to authorized users, roles are defined, and privileged access has additional controls. For a review: the entitlement inventory, the reviewer decisions, and the executed revocations.
• CC6.2 (prior authorization). Evidence that new access is authorized before it is granted. This is provisioning-side, but access reviews test whether unauthorized access accumulated between provisioning events.
• CC6.3 (removal of access). Evidence that access is removed on role change or termination within a defined SLA. Auditors sample terminated users and confirm the removal timestamp.

Type II sampling: expect the auditor to pick 15 to 25 users from the population and test each against all three controls. Every sampled user needs a clean trail.

What does ISO 27001 require differently?

ISO 27001:2022 uses slightly different language and broader scope.

• A.5.15 (access control). Broader than SOC 2 CC6.1: covers all information assets, not just systems. Physical access, printed documents, and third-party access all in scope.
• A.5.16 (identity management). Evidence that identities are managed lifecycle-wide: created, modified, disabled, deleted with documented approval at each step.
• A.5.18 (access rights). The direct counterpart to SOC 2 CC6.3. Evidence that access rights are provisioned, reviewed, modified, and removed in line with policy.

ISO auditors tend to focus on policy documentation and process consistency; SOC 2 auditors focus on operating effectiveness testing. Both want the same evidence, but ISO wants to see the policy that governs it in more detail.

What is HIPAA-specific for access reviews?

Scope narrows to ePHI systems, but requirements broaden in specific ways.

• 164.308(a)(3)(ii)(B) workforce clearance procedures. Evidence that access authorization considered clearance level. In practice: HR onboarding checklist showing role, clearance, and access approvals before day one.
• 164.308(a)(4)(ii)(B) access authorization. Documented approval for each grant of ePHI access. Auditors want to see who approved, when, and against what role definition.
• 164.312(a)(1) access controls. Technical implementation: unique user identification, emergency access, automatic logoff, encryption. The review evidence is the "unique user identification" part.
• Minimum necessary standard (164.502(b)). Not a technical control, but reviewers should have applied minimum-necessary reasoning to decisions. Programs often add a "purpose" field to entitlement descriptions for HIPAA-scoped systems.

HIPAA auditors sample more aggressively than SOC 2 auditors, in my experience. Expect 30 to 50 users sampled from ePHI system populations, not 15 to 25.

What does one evidence bundle satisfy all three?

Seven artifacts. Tagged to all applicable controls.

1. Entitlement population snapshot at campaign start. Timestamped CSV, one row per user-per-entitlement.
2. Reviewer routing evidence. Documentation that each entitlement was assigned to an appropriate reviewer (usually direct manager).
3. Decision log. Every entitlement, every decision, every timestamp, every reviewer identity.
4. Revocation execution proofs. API responses or ticket-close artifacts confirming source-system state changed.
5. Exception log. Any entitlements flagged for extended review, with owner and target close date.
6. Control mapping index. Tag each artifact with all applicable controls (SOC 2 CC6.1, ISO A.5.18, HIPAA 164.308(a)(4), etc.).
7. Signed attestation. One page, signed by the CISO or IT lead, confirming completeness.

For HIPAA specifically, add: workforce clearance documentation and minimum-necessary purpose documentation. Both are pre-review artifacts, not campaign outputs.

How do you handle sampling failure?

Common sampling failures and their remediation.

• Sampled terminated user still has access. Immediate finding. Remediation: re-run the deprovisioning sweep, add the missed system to standard offboarding checklist, evidence the fix in-cycle.
• Sampled revoke decision, access still active in source system. This is the mean-time-to-revoke failure. Remediation: root cause the revocation pipeline break (ticket queue, missing API, unowned service account) and fix it before the next campaign.
• Sampled entitlement, no reviewer decision recorded. Coverage gap. Remediation: audit the reviewer routing, confirm no orphaned entitlements, extend campaign scope to catch them.
• Sampled user, evidence of access predates any approval record. Provisioning-side failure. Remediation: not solvable in access review; requires fixing the provisioning process (usually SCIM automation).

Every sampling failure has a fix. What auditors reward is the remediation timeline and the operational change, not perfection at first pass.

What are the framework-specific pitfalls?

Three pitfalls per framework. Named.

• SOC 2: Trust services criteria language changes across audit years. If your policy references old CC6 language, update it. Also: SOC 2 Type II wants operating effectiveness across the audit period, not a snapshot. One clean campaign is insufficient; you need consistent campaigns.
• ISO 27001: The 2022 revision consolidated controls. If your evidence maps to Annex A from ISO 27001:2013 (A.9.2, A.9.4), you need to remap to the 2022 controls (A.5.15 to A.5.18, A.8.3). Auditors will catch old mappings.
• HIPAA: Business Associate Agreements (BAAs) extend the review scope to third parties handling ePHI. Contractor access reviews are often the gap. Include BAA-covered contractors in the campaign.

The pitfalls are all about staying current with framework revisions and understanding scope boundaries. None are about the underlying access review process, which is stable across frameworks.

How do you avoid running three reviews for three frameworks?

One process, tagged evidence, aligned scope. Concretely:

• Define one entitlement population that covers the union of in-scope systems across all frameworks. SOC 2 scope + HIPAA ePHI scope + ISO information asset scope.
• Run one quarterly campaign against the union population.
• Tag every artifact with all applicable controls at export time. The tagging is metadata, not more work.
• Deliver one bundle to each auditor with the same content, filtered or tagged for their framework.

Programs that resist consolidation end up with three campaigns per quarter, three evidence bundles, and three sets of reviewer fatigue. Consolidation is not a compliance optimization; it is an operational necessity.

The mistake to avoid

The default reflex when adding a new compliance framework is to add a new access review campaign for that framework. This triples the reviewer load and produces inconsistent evidence across audits. The right move is to expand the existing campaign scope, add the new control tags to the existing evidence bundle, and treat the frameworks as overlapping label sets on the same operational reality. Auditors from different frameworks looking at the same artifact is a feature, not a problem. Design for it.