Skip to content
compliancebase
SOC 2CC6 — Prior to Issuing System Credentials

CC6.2

Prior to Issuing System Credentials

SOC 2 · 2017 TSC (2022 Revised Points of Focus) · Last verified July 2026

Objective

Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity.

Points of focus

  • Registers new users prior to issuing credentials
  • Authorizes new user access before credentials are issued
  • Documents approvals for access grants

Implementation notes

Make IdP provisioning wait on an approved ticket so registration and authorization precede credentials — the core of AICPA CC6.2. Use SCIM where possible to reduce manual grants. Time-box contractor and vendor access with automatic expiry and a named sponsor. Keep role matrices so auditors can see what was authorized, not only that someone clicked approve. For Type II, export joiner/mover/leaver populations from the IdP and ticketing system for the full observation window, including service accounts. Spot-check that privileged roles still match the current org chart after reorganizations. Document break-glass accounts separately with dual control and logging — they are a frequent sample target when left undocumented.

Audit tip: Auditors sample new hires and contractors: show request, approval, and credential issue timestamps in order.

Evidence auditors typically request:

  • Access request / approval tickets
  • Role-based access matrices
  • Joiner checklist including IdP account creation
  • Screenshots or exports showing approval before grant timestamps

Common gaps

  • Admin creates accounts before approval is recorded
  • Shared onboarding Slack approvals without durable tickets
  • External users provisioned without sponsor or expiry

Cross-Framework Mapping

FrameworkRequirementImplementation note
SOC 2CC6.2This control
ISO 27001A.5.16, A.5.18Identity management & access rights
HIPAA164.308(a)(3), 164.312(a)(1)Workforce clearance / access
GDPRArticle 32(1)(b)Access restriction measures

Primary sources

Frequently Asked Questions

Chat approvals are weak evidence unless exported and retained with identity and timestamp. Prefer a ticketing system of record so Type II samples show request → approval → credential issue in durable form.

Pre-stage emergency accounts with strict controls, monitoring, and post-use review — do not invent undocumented shared passwords at incident time. Document who may use them and how issuance differs from normal joiner provisioning.

Customer users of your product are often outside entity-administered credentials; focus on workforce and vendor users you administer. Product signup flows are usually described separately in the system description, not as CC6.2 joiner tickets.

CC6.2 is issuance and authorization before access is granted. CC6.3 addresses removing or modifying access when employment or business relationships change. Joiner and leaver controls should share the same IdP and ticket systems.

Role-based models are the usual way to make authorization auditable for SaaS. Document how roles map to job functions and keep the matrix current so approvals reference defined roles rather than one-off entitlement lists.

Framework versions referenced in this page:

  • SOC 2 — 2017 TSC (2022 Revised Points of Focus)

Last verified: July 2026 · Primary sources linked above