CC6.2 CC6 · Logical and Physical Access Controls · Security (Common Criteria)

CC6.2 — Provisioning and deprovisioning

New internal and external users are registered and authorized prior to issuing credentials; access is removed when no longer authorized.

Also written as CC 6.2, TSC CC6.2, SOC2 CC6.2, SOC 2 Type 2 CC6.2.

Written by Jett N. · Last reviewed

What SOC 2 CC6.2 requires

Provisioning and deprovisioning is one of 8 criteria in the Logical and Physical Access Controls (CC6) series of the Security (Common Criteria) category. New internal and external users are registered and authorized prior to issuing credentials; access is removed when no longer authorized. CC6 is the heaviest-tested series in most SOC 2 reports and the one where exceptions most often appear — expect user access reviews, provisioning and deprovisioning tickets, and configuration exports to be sampled across the full period.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC6.2, gather artefacts such as:

  • Access request and approval tickets for new users
  • Timely termination / deprovisioning records (within SLA)
  • Periodic user access reviews with sign-off
  • Orphaned account audit results

Points of focus for CC6.2

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC6.2. They are not themselves requirements, but they shape the testing:

How to implement CC6.2

  1. Make the approval traceable to a person and a dateEvery access grant an auditor samples needs to trace back to a request, an approver with authority, and a timestamp before the credential was issued. Access provisioned first and approved afterwards is an exception even when the access was appropriate.
  2. Define and measure a deprovisioning SLATermination timeliness is one of the most sampled items in the whole report. Set a target — same day for involuntary departures is common — and measure against it. Auditors compare HR termination dates to access removal timestamps directly, so the arithmetic has to work.
  3. Automate the joiner-mover-leaver trigger from HRManual deprovisioning driven by someone remembering is what produces the one missed leaver in the sample. An HR-triggered workflow removes the failure mode and generates the evidence automatically.
  4. Do not forget moversRole changes that add access without removing the old access accumulate privilege silently. This is the "mover" half of the lifecycle and it is far more commonly unimplemented than joiner or leaver handling.
  5. Run access reviews with real consequencesA review where nothing is ever revoked reads as a rubber stamp. Keep evidence of the revocations that resulted — that is what demonstrates the review is operating.

Common audit findings for CC6.2

What actually gets raised against CC6.2, in rough order of how often it comes up:

Scoping CC6.2

CC6.2 is Common Criteria and unavoidable. Because the test is arithmetic — comparing HR dates to access logs — it is one of the few criteria where you can self-assess accurately before fieldwork. Run the comparison yourself across the review period first; whatever you find, the auditor will find.

ISO 27001 mapping

CC6.2 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.16, A.5.17, A.5.18. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC6.2 rather than duplicating work.

Map CC6.2 to ISO 27001 & NIST CSF →
Crosswalk this criterion in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against CC6.2 in the Risk Register.

Other Logical and Physical Access Controls criteria

CC6.1 Logical access security architecture CC6.3 Role-based access and least privilege CC6.4 Physical access restriction CC6.5 Secure disposal CC6.6 Protection against external threats CC6.7 Protection of data in transmission and movement CC6.8 Prevention and detection of malicious software

All CC6 Logical and Physical Access Controls criteria →

Frequently asked questions

Is CC6.2 required for a SOC 2 report?

Yes. CC6.2 sits in the Common Criteria, which apply to every SOC 2 engagement regardless of which additional categories you scope in — there is no SOC 2 report that omits them.

How does an auditor test CC6.2?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC6.2 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.

What happens if CC6.2 fails testing?

A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.

Does SOC 2 CC6.2 map to ISO 27001?

Yes — CC6.2 aligns with ISO 27001:2022 Annex A control(s) A.5.16, A.5.17, A.5.18. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.

What are the most common audit findings for CC6.2?

One or more terminated users retaining access beyond the stated SLA, which is the single most common CC6.2 exception. Access granted without documented approval, or approved by someone without the authority to approve it.