What is SOC 2?
SOC 2 (System and Organisation Controls 2) is an auditing standard developed by the American Institute of CPAs (AICPA). It evaluates whether a service organisation's information security controls meet the Trust Services Criteria (TSC) — a framework of five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
The distinction between Type I and Type II matters enormously in practice. A Type I report is a snapshot: an auditor evaluates your controls at a single point in time and opines that they are suitably designed. A Type II report evaluates whether those controls operated effectively over a period — typically six to twelve consecutive months. Enterprise customers and security-conscious buyers almost exclusively require Type II, because it demonstrates that controls are not just documented but actually running.
The Security category is mandatory for all SOC 2 reports. Within it, the CC6 series — Logical and Physical Access Controls — is the section where most organisations accumulate deficiency findings.
The CC6 Access Control Criteria
CC6 contains six individual criteria. In practice, CC6.1 through CC6.3 are the controls most directly related to user access management, and the ones where evidence gaps most frequently appear:
| Control | What it requires |
|---|---|
| CC6.1 | Logical access security software, infrastructure, and architectures have been implemented to protect information assets from security events — including restriction to authorised users only. |
| CC6.2 | Prior to issuing system credentials and granting system access, the completeness, accuracy, and validity of the registration and authorisation process is verified. |
| CC6.3 | The entity authorises, modifies, or removes access to data, software, functions, and other protected information assets based on authorised roles and in accordance with policies. Access is removed when no longer needed, and periodic reviews are performed. |
| CC6.6 | Logical access security measures restrict access to information assets from external sources, including filtering of communications to maintain integrity. |
The key phrase in CC6.3
"Periodic reviews are performed." This is the criterion that generates the most deficiency findings. It is not enough to remove access when someone leaves — you must also periodically confirm that current access is still appropriate, and maintain a record of who reviewed it, when, and what they decided.
Why this matters for management
SOC 2 Type II has become the default security prerequisite for B2B software sales. Enterprise procurement teams require it before signing contracts. Security questionnaires include it. Cyber insurers ask for it. Without a clean SOC 2 Type II report, deals stall at legal review, vendor assessments fail, and sales cycles extend by weeks or months. Conversely, a clean report with no exceptions in CC6 signals security maturity and accelerates procurement. The question is not whether to pursue SOC 2 — it is how to produce CC6 evidence without building a full-time compliance programme from scratch.
What auditors actually test (CC6)
During a Type II engagement, your CPA auditor will perform both walk-throughs and sample testing. For CC6, this typically means:
- Access listing walk-through: Request a complete list of users with access to in-scope systems at a point in time during the audit period, then cross-reference against your HRIS to find terminated employees who retained access.
- Provisioning sample: Select a sample of access grants (typically 25–40 records) and trace each one — who requested access, who approved it, was the approval documented before credentials were issued.
- Periodic review sample: Ask for evidence of each quarterly or semi-annual access review — who performed the review, when, which accounts were reviewed, and what decisions were made on any exceptions.
- Privileged access: Specifically test admin and superuser accounts — when were they last reviewed, and is there a process to approve elevated access separately from standard access.
The Three Most Common CC6 Deficiency Findings
In practice, auditors encounter the same gaps repeatedly across organisations of all sizes:
No evidence of periodic access reviews
The organisation states that access is reviewed quarterly, but cannot produce a record showing who reviewed what, when the review occurred, and what happened to accounts that were flagged. An email chain saying "looks good" is not sufficient — auditors need a documented, timestamped process.
Unable to determine who approved the access grant
The access exists in the target system, but there is no record in a tracking system of who requested it, who approved it, and when the approval was given. For CC6.2, approval must be verified before credentials are issued, not assumed retroactively.
Access not removed within policy timeframe after role change or termination
The HRIS shows an employee changed roles or left the organisation, but access to one or more systems was not removed until days or weeks later — or worse, was never removed. Auditors will find this when cross-referencing the access list with HR data.
Why Spreadsheets and Emails Fail the CC6 Test
The most common approach to access reviews is exporting a CSV of user accounts, emailing it to managers, and asking them to confirm it looks correct. This process has three fatal flaws for SOC 2 purposes:
- No attribution at the record level. When the auditor asks "who reviewed User X's access to System Y?" the answer is buried in a thread, not attached to the specific access record.
- No linkage between review and action. Even if a manager replies saying to remove Bob's access, there is no tracked record connecting the review decision to the actual removal or the implementor who did it.
- No enforcement of completeness. Nothing stops a manager from approving the whole list without reading it. Auditors know this and will ask follow-up questions to test whether reviews are genuine.
What auditors need is a systematic record where every access assignment has a named reviewer, a timestamp, a decision, and a traceable link to any resulting action (approval, revocation, or implementation). That is what purpose-built compliance tooling provides.
How AllowNow Addresses CC6
| CC6 Criterion | AllowNow evidence |
|---|---|
| CC6.1 | Complete access inventory: every user, service, role, and access level in one place — queryable and exportable at any point in time. |
| CC6.2 | Every assignment records who granted it (granted_by) and when (granted_at) — before access is issued. No access exists without an attributed approver. |
| CC6.3 | Each review stamps the reviewer identity (reviewed_by), the timestamp (last_reviewed_at), and the decision (approved/revoked). Revocations flow into an implementor queue, tracked until acted upon. |
| CC6.3 reviews | 90-day check automatically surfaces accounts not reviewed within the review window. Bulk review with a single click — all records individually attributed. |
When it is time for a SOC 2 Type II audit, AllowNow generates a SOC 2 CC6 Evidence Report — a structured PDF that maps directly to CC6. It includes an observations section that surfaces how many assignments are overdue for review, how many admin accounts lack recent review evidence, and whether provisioning records are complete — alongside the full access detail table showing every reviewer, timestamp, and decision. The report is designed to be handed directly to an auditor without manual assembly.
Built for small organisations preparing for their first SOC 2 audit
AllowNow is designed for teams of 5 to 100 people that need CC6 evidence without a dedicated compliance officer or an enterprise GRC platform. If your organisation is approaching its first SOC 2 Type II report and does not yet have a systematic access review process, AllowNow closes that gap — setup takes hours, not months.
The result: CC6 deficiency findings disappear because the evidence is continuous, systematic, and always available — not assembled under deadline pressure at the start of an audit window.