Security check

SOC 2 access control (CC6): prove least privilege, concretely

SOC 2's CC6 criteria require access to be restricted, authorised and removed in time. We map your GitHub permissions, MFA posture and secrets handling and provide the evidence auditors ask for.

Run a free domain scan All checks →
Relates to: SOC 2 · CC6.1–CC6.3 — logical access ISO 27001 · A.5.15 / A.5.18 access control NIS2 · art. 21 — access control

What we check

We map SOC 2's CC6 requirements to concrete technology: who has admin/write per repo (least privilege), whether MFA is enforced in the org, how secrets are handled and rotated, and whether access for ended engagements is actually revoked.

Why it matters

CC6 is the heart of SOC 2 and where most exceptions are found. Excessive access, missing MFA and leaked secrets are all technical gaps — measurable and fixable, unlike a policy that only describes how it ought to be.

How Security Guru tests it

Common mistakes

  • Every developer has admin — violates least privilege
  • MFA recommended but not enforced in the org
  • Leaked keys in git history that were never rotated
  • Access for ended contractors left long afterwards

What you get in the report

  • CC6 status per criterion with technical evidence
  • Excessive access, MFA gaps and leaked secrets
  • Prioritised cleanup and rotation list
  • Ready evidence package for your SOC 2 auditor

FAQ

Which CC6 points do you cover?

The technically measurable ones: CC6.1 (logical access & authentication), CC6.2 (registration/deregistration) and CC6.3 (access changes) — via GitHub and your attack surface.

Do you really check MFA?

We verify whether the org enforces MFA, not just that it's possible. That difference decides CC6.1.

Do you write anything in our org?

No — read only. You do cleanup and rotation from our list.

Want to know your status?

Run a free scan or order a full Security Assessment — prioritised, not noise.

Run a free domain scan