Free compliance framework explorer — browse controls, evidence, and implementation guidance.Subscribe for updates →
BETA
SOC 247
ITSP.10.17198
ISO 42001soon
ISO 27001soon
Browse
Ctrl+K
33 controls
CC1.1
Commitment to integrity and ethical values
Control Environment
6 evidence2 controls
CC1.2
Board independence and oversight of internal control
Control Environment
3 evidence1 control
CC1.3
Organizational structure, reporting lines, and authority
Control Environment
3 evidence1 control
CC1.4
Commitment to attract, develop, and retain competent individuals
Control Environment
6 evidence2 controls
CC1.5
Accountability for internal control responsibilities
Control Environment
3 evidence1 control
CC2.1
Obtains or generates and uses relevant quality information
Communication and Information
3 evidence1 control
CC2.2
Internal communication of information to support internal control
Communication and Information
6 evidence2 controls
CC2.3
External communication regarding matters affecting internal control
Communication and Information
4 evidence1 control
CC3.1
Specifies objectives with sufficient clarity
Risk Assessment
3 evidence1 control
CC3.2
Identifies and analyzes risks to achievement of objectives
Risk Assessment
3 evidence1 control
CC3.3
Considers potential for fraud in assessing risks
Risk Assessment
3 evidence1 control
CC3.4
Identifies and assesses significant changes
Risk Assessment
3 evidence1 control
CC4.1
Selects, develops, and performs ongoing and separate evaluations
Monitoring Activities
6 evidence2 controls
CC4.2
Evaluates and communicates internal control deficiencies
Monitoring Activities
3 evidence1 control
CC5.1
Selects and develops control activities that mitigate risks
Control Activities
3 evidence1 control
CC5.2
Selects and develops general controls over technology
Control Activities
6 evidence2 controls
CC5.3
Deploys control activities through policies and procedures
Control Activities
3 evidence1 control
CC6.1
Logical access security infrastructure
Logical and Physical Access Controls
11 evidence3 controls
CC6.2Registration and authorization prior to issuing credentialsSOC 2Logical and Physical Access Controls
Official Requirement
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. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
Every account that exists in your systems must trace back to an approved provisioning request. When someone joins, there's a documented, approved ticket before credentials are issued. When someone leaves, especially involuntarily, access is revoked within a defined SLA. Auditors will sample onboarding and offboarding events and ask you to produce the approval record for each.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Provisioning workflow with documented approval before access is granted
Implementation Steps
Implement a ticketing-based provisioning workflow: new hire or role change triggers a ticket that must be approved before the IdP account is created
Use an RBAC matrix that maps job role to system access, provisioning follows the matrix, not ad-hoc requests
For SaaS tools (GitHub, AWS, Jira, etc.), configure SCIM provisioning from the IdP so account creation is centrally controlled
Enforce that no account is created manually outside the provisioning workflow, this is a common audit finding
Tools / Systems
Okta + SCIM provisioningAzure AD + SCIMJira / Linear (ticketing)
Typical Control Termination access revocation within defined SLA
Implementation Steps
Define termination SLAs in policy: involuntary termination = immediate (same-day) revocation; voluntary = end of last working day
Disable the IdP account first, SCIM propagation then deprovisions downstream SaaS; this is faster and more reliable than manual per-app removal
Maintain an offboarding checklist that enumerates every system requiring manual revocation (systems not integrated with SSO)
Generate and retain offboarding ticket with per-system confirmation and timestamps, auditors will test this population
Tools / Systems
Okta account deactivation + SCIMAzure AD account disableGitHub org member removal
Typical Control Provisioning workflow with documented approval before access is granted
Evidence Artifacts
Sample onboarding ticket showing: user name, requested systems, approver name, approval date, and list of access granted
SCIM provisioning log showing user created in downstream systems after IdP account was provisioned
RBAC matrix document (signed by management) mapping roles to system access
📅Sample provisioning tickets collected at each audit evidence window; RBAC matrix reviewed annually
Typical Control Termination access revocation within defined SLA
Evidence Artifacts
Offboarding ticket showing user name, termination date, per-system removal checklist with completion timestamps
Okta or Azure AD screenshot showing account disabled/deleted, dated, within SLA window
