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.2
Registration and authorization prior to issuing credentials
Logical and Physical Access Controls
6 evidence2 controls
CC6.3
Role-based access management
Logical and Physical Access Controls
6 evidence2 controls
CC6.4
Physical access restrictions
Logical and Physical Access Controls
3 evidence1 control
CC6.5
Disposal and destruction of information assets
Logical and Physical Access Controls
3 evidence1 control
CC6.6
Controls against threats from outside system boundaries
Logical and Physical Access Controls
8 evidence2 controls
CC6.7
Restricts transmission and movement of information
Logical and Physical Access Controls
7 evidence2 controls
CC6.8Controls to prevent or detect unauthorized softwareSOC 2Logical and Physical Access Controls
Official Requirement
The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.
Unauthorized software means anything not explicitly approved, from rogue scripts dropped by an attacker to a developer installing an unvetted tool on a production server. Controls here include application allowlisting on servers, dependency scanning in the CI/CD pipeline, secret scanning to catch leaked credentials before they reach production, and software inventory management so you know what is running.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Secret detection in CI/CD pipeline
Implementation Steps
Integrate a secret scanning tool into the CI pipeline to run on every commit and merge request before code reaches the main branch
Configure the pipeline to fail (block merge) on any detected secret, do not set it to warning-only, as that is not a control
Maintain a list of false positive dispositions with documented justification for suppressed findings
For historical secrets already in the codebase, run a full repository scan and rotate any exposed credentials immediately
Enable SCA (software composition analysis) scanning via Dependabot, Snyk, or Renovate to flag known CVEs in third-party dependencies; block merges on critical/high severity findings
Typical Control Secret detection in CI/CD pipeline
Evidence Artifacts
Branch protection rule screenshot showing secret scanning check is required to pass before merge
Sample CI pipeline run showing secret scan step passed (or a blocked run showing a detected secret was caught and not merged)
False positive disposition log with justifications for any suppressed findings
📅Pipeline runs continuously; branch protection configuration screenshot per audit window
Typical Control Software change approval before production deployment
Evidence Artifacts
Branch protection rule screenshot showing required reviewers and no self-approval allowed
Sample pull request showing independent approval before merge, include at least one example per audit period
Full list of merged pull requests for the audit period (for auditor sampling)
📅Branch protection configuration per audit window; PR list exported at audit window close
Cross-framework mappings coming in v1.1
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC7.1
Detection and monitoring for vulnerabilities
System Operations
8 evidence2 controls
CC7.2
Monitoring for anomalies and security events
System Operations
4 evidence1 control
CC7.3
Evaluation of security events as security incidents
System Operations
4 evidence1 control
CC7.4
Incident response program
System Operations
4 evidence1 control
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Secret detection in CI/CD pipeline
Implementation steps
Deploy a secret scanning step in your CI pipeline (GitLab CI, Jenkins, or GitHub Actions), scan every merge request before approval
Ensure the scanning step blocks the pipeline on confirmed secrets; document what constitutes a confirmed finding versus a false positive
Scan the full repository history as a one-time remediation step; rotate any discovered credentials
Store application secrets in a secrets manager, not in environment variables checked into version control
Run SCA (software composition analysis) scans against dependency manifests to detect known vulnerabilities in third-party libraries; integrate into the CI pipeline alongside secret scanning
Tools / systems
GitLeaks
Trufflehog
GitLab SAST (built-in)
OWASP Dependency-Check (SCA, open source)
HashiCorp Vault (secrets management)
Evidence artifacts
CI pipeline configuration showing secret scan step with fail-on-detection behavior
Sample pipeline run output showing secret scan completed on a recent merge request
Repository scan history or initial full-scan results confirming no live secrets remain in main branch
Evidence frequency: Continuous in CI pipeline; configuration screenshot per audit window; initial full-scan evidence retained
Software change approval before production deployment
Implementation steps
All code changes require a merge request with at least one independent approval before merge to the production branch
Infrastructure changes (firewall rules, server configs, network changes) require a ticket with management approval before implementation
Post-deployment: verify the deployment completed successfully and matches what was approved, document the result in the ticket
Self-approved changes (where team size forces it) are logged and reviewed in a quarterly self-approval audit
