Prior to issuing credentials and granting access, the entity registers and authorizes new users

This requirement is a foundational access control expectation in SOC 2: you control who gets an account before they ever have a login. Auditors look for a tight chain of custody from identity proofing through approval and provisioning, with enough evidence to show the process works the same way every time. If your onboarding process allows “fast accounts,” shared inbox invites, ad-hoc admin creation, or credentials issued before approvals are captured, you will struggle to demonstrate effective operation.

For most service organizations, the practical scope includes workforce identities (employees, contractors, interns), privileged admins, break-glass accounts, and often customer or partner users if you administer those identities. The operational goal is simple: no access without registration and authorization. The execution is less simple because onboarding spans HR/PeopleOps, IT, Security, and application owners.

This page translates the requirement into implementable steps, evidence to retain, common audit traps, and a 30/60/90-day plan. It focuses on proving two things: (1) every user is registered to a unique identity record, and (2) access is authorized before credentials or access are granted.

Regulatory text

Requirement: “Prior to issuing credentials and granting access, the entity registers and authorizes new users.” ¹

Operator interpretation (what you must do):

• Register means you create an authoritative identity record for the person (or approved non-person account) before any access is possible. The record must be uniquely identifiable and traceable to the request and approvals.
• Authorize means an approved decision-maker validates the request (identity, role, and requested access) before provisioning occurs.
• Prior to issuing credentials and granting access means the sequence matters: request/registration/approval first, credentials/access second. If provisioning can happen before approvals are captured, the control fails in design even if “most” requests are approved later.

Plain-English interpretation

You need a controlled onboarding workflow that stops account creation and access enablement until:

1. the new user is known and recorded (unique identity, owner, type, start date, and relationship to the company), and
2. the access is approved by the right people for the right systems and roles.

Who it applies to (entity and operational context)

This applies to any service organization seeking SOC 2 alignment for logical access controls under the Trust Services Criteria. In practice, it applies wherever your organization issues credentials or grants access, including:

• Workforce access: corporate email, SSO/IdP, endpoint management, VPN, HRIS, ticketing, source code, cloud consoles.
• Privileged access: admins in cloud/IAM, databases, CI/CD, security tools, and production systems.
• Third-party workforce: contractors, consultants, outsourced support, and managed service provider staff who access your environment.
• Application-level accounts: direct app accounts not federated to SSO (common in legacy or customer-administered tools).
• Service accounts and API tokens: non-human identities must also be “registered” and “authorized” with an owner and purpose, even if they do not look like a person.

A common scoping decision: if customer identities are self-registered (public signup), the “authorization” step may be automated (email verification, admin approval workflows, contractual entitlements). If your internal staff creates customer accounts manually, treat them like new users under this requirement.

What you actually need to do (step-by-step)

Step 1: Define “user” and map the credential issuance points

Create a short inventory of where credentials/access can be issued:

• Identity provider (SSO directory)
• Corporate email
• Key SaaS apps with local accounts
• Cloud/IaaS consoles
• VPN / remote access
• Privileged access tooling
• Customer admin panels (if applicable)

Deliverable: an “Account Provisioning Scope” list that names the system, provisioning method (manual vs automated), and who can create accounts.

Step 2: Establish a registration standard (identity records)

Define what “registered” means in your environment:

• Unique identifier (directory ID or HRIS ID)
• Legal name / preferred name
• User type (employee/contractor/service account/customer/partner)
• Manager or sponsor
• Start date and end date (or contract end)
• Systems requested (or role template)
• Ownership for non-human identities (service owner)

Implementation tip: your IdP directory can be the system of record for registration, but you still need an intake record that shows who requested the user and why.

Step 3: Implement an access request and authorization workflow

Minimum viable workflow:

1. Request created (ticket or access request form)
2. Identity verified and registered (HRIS entry for employees; sponsor validation for contractors; service owner for service accounts)
3. Approvals captured before provisioning:
   • Manager/sponsor approval for business need
   • System owner approval for sensitive apps
   • Security approval for privileged access or production access
4. Provisioning executed by IT/IAM automation or a separate provisioning role
5. Request closed with provisioning evidence and timestamps

Decision matrix for approvals (example):

• Standard workforce baseline (email, chat, HR tools): manager approval via HR onboarding event
• Sensitive data systems (finance, customer data, incident tooling): system owner approval
• Privileged roles (admin, prod access): security approval plus system owner approval

Step 4: Enforce sequencing with technical controls

Auditors test whether provisioning can occur without approvals. Add hard stops:

• Restrict who can create users directly in apps; route provisioning through IdP groups and automation.
• Disable “invite anyone” settings in SaaS where feasible; require admin-managed invites tied to tickets.
• For manual provisioning, require the ticket number in the user creation record or in an admin note field.
• For privileged access, require time-bound elevation through an approval-based mechanism rather than permanent admin assignment.

Step 5: Handle exceptions explicitly (without breaking the control)

Common exceptions:

• Emergency access (incident response)
• Executive assistants onboarding quickly
• Acquisitions/migrations with bulk imports
• Customer escalations requiring temporary internal access

Rule: exceptions still require authorization, but the timing and approver path can differ. Create an “exception” request type with:

• documented rationale
• who approved
• when access was granted
• when access was reviewed and either normalized or removed

Step 6: Validate operation with recurring testing

Build a monthly or quarterly check that answers:

• Were any accounts created without a matching approved request?
• Were approvals recorded before the provisioning timestamp?
• Were service accounts created with owners and purposes?

If you find drift, fix the root cause (app-level local admins, informal invites, unmanaged directories), not just the samples.

Required evidence and artifacts to retain

Auditors typically want end-to-end traceability. Keep:

• Policy/standard: access control policy and an onboarding/provisioning standard describing registration and authorization.
• Process documentation: workflow diagram or runbook showing request, approvals, provisioning, and sequencing.
• System configurations (screenshots/exports):
  • list of who can create users in key systems
  • invitation settings restricted to admins (where applicable)
  • IdP group-based assignment rules (if used)
• Access request records: tickets/forms showing requestor, user identity, requested access, approvals, and timestamps.
• Provisioning evidence: automation logs, admin audit logs, or screenshots showing account creation and group assignment.
• Population + sampling support: a user list from the IdP and/or key apps for the audit period, with join dates and creators.
• Service account register: owner, purpose, scope, and approval reference.

Practical evidence rule: each sampled new user should have a single “packet” that ties identity → approval → provisioning.

Common exam/audit questions and hangups

Auditors and examiners commonly ask:

• “Show me how a new hire gets an account. Where is the approval captured?”
• “Can an admin create a user directly in this SaaS without a ticket?”
• “How do contractors get access? Who sponsors them?”
• “Are approvals obtained before access is granted? Prove it with timestamps.”
• “How do you register and approve service accounts and API tokens?”
• “What happens in emergencies? Show an example and the follow-up review.”

Hangups that trigger findings:

• HR onboarding triggers account creation automatically, but approvals for app access happen later or informally.
• Slack/Google Workspace/Microsoft 365 allows broad invitations with no documented authorization.
• Local app accounts bypass SSO and group-based controls.
• Shared accounts exist without identity registration.

Frequent implementation mistakes and how to avoid them

1. Approvals exist, but not before access.
   Fix: enforce sequencing by automation and provisioning role separation; require approvals in the request before workflow proceeds.

2. No clear registration record for contractors.
   Fix: require a sponsor, contract end date, and identity entry in your directory before access.

3. Service accounts treated as “technical details.”
   Fix: maintain a service account register with ownership and approvals; require tickets for creation and changes.

4. Admins provision directly in apps “just this once.”
   Fix: remove standing permissions to create users in apps; centralize through IdP or a provisioning queue.

5. Evidence scattered across tools.
   Fix: make the ticket the hub; add links to HR record, approval capture, and provisioning logs in one place.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog, so this page does not list specific actions. Operational risk is still clear: issuing credentials without registration and authorization increases the likelihood of unauthorized access, orphaned accounts, and privilege sprawl. For SOC 2, the audit risk is equally practical: you can have good intentions but still fail if you cannot prove sequencing and approvals with reliable evidence ¹.

Practical 30/60/90-day execution plan

First 30 days: lock the scope and stop obvious bypasses

• Inventory systems where accounts are created and who can create them.
• Choose the authoritative identity record (IdP directory plus HRIS for workforce, sponsor registry for contractors).
• Standardize an access request intake (ticket templates with required fields and approvals).
• Disable broad user invitations in major SaaS where feasible; restrict user creation to admins.

Days 31–60: enforce authorization paths and build evidence packets

• Implement approval rules by access tier (baseline, sensitive, privileged).
• Route provisioning through groups/roles tied to the request; reduce manual app-level creation.
• Create a service account register and require owner + purpose + approval reference.
• Build an evidence packet template for auditors (request + approvals + provisioning log).

Days 61–90: test, remediate drift, and operationalize reporting

• Run a lookback review for the period: identify accounts without approved requests and remediate gaps.
• Add recurring control testing (monthly/quarterly) with documented results and follow-ups.
• Train IT admins and app owners on “no ticket, no account” and exception handling.
• Consider workflow tooling to reduce manual joins: Daydream can centralize access requests, approvals, and evidence collection so each provisioned account has audit-ready traceability without chasing screenshots.

Frequently Asked Questions

Does this requirement mean every system must use SSO?

No. SOC 2 expects registration and authorization before access, whether access is via SSO or local accounts ¹. If you cannot use SSO, tighten local admin rights and require tickets plus approvals before local account creation.

How do we meet this for contractors and other third-party workforce?

Require a named internal sponsor, record the contractor in your directory (or equivalent register), and capture sponsor approval before provisioning any access ¹. Also record an end date and review access at offboarding.

What counts as “authorization” for a new user?

Authorization is an explicit approval by an appropriate decision-maker for the identity and requested access, recorded before provisioning ¹. Email-only approvals can work if they are retained and tied to the request, but workflow approvals are easier to evidence.

Can HR-driven auto-provisioning satisfy “prior to”?

Yes, if the HR event represents an authorized onboarding and downstream access is limited to baseline access until additional approvals are captured ¹. If HR triggers privileged or sensitive access automatically, you need pre-approval controls upstream.

How should we handle emergency access during incidents?

Use an emergency access path with documented approver, rationale, and a post-incident review that confirms access was removed or normalized ¹. Keep the emergency request record as evidence.

What evidence is strongest for auditors?

A single traceable chain: request ticket with required fields, recorded approvals with timestamps, and system logs showing account creation/group assignment after approval ¹. Make this repeatable for samples across the audit period.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017