Knowledge Hub

SOC 2 Type II Compliance Mapping: CleanStart Container Image Service

Document Version: 2.0 Last Updated: March 22, 2026 Classification: Confidential - For Auditor Use Only Prepared for: CISO/GRC Review and External Auditors (SOC 2 Type II Engagement)

Executive Summary

What is SOC 2 Type II?

SOC 2 Type II is a compliance framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates the controls over a service organization's systems, specifically how those controls affect the security, availability, processing integrity, confidentiality, and privacy of customer data.

Key Distinction: Type II attestations require a minimum 6-month observation period (typically 12 months) to demonstrate that controls are not only designed but also operating effectively over time.

Why SOC 2 Type II Matters for CleanStart

CleanStart serves as a critical infrastructure component for container-based deployments, providing:

Supply chain integrity assurance (verified source code → secure images) Compliance evidence generation (SBOM, SLSA provenance, signatures, test results) Runtime security enforcement (admission control, integrity verification) Security operations visibility (audit logs, monitoring, incident response)

Organizations using CleanStart can:

Reduce audit burden by obtaining verified images with complete compliance artifacts
Demonstrate control over container supply chains (addressing NIST SSDF, CIS Controls, ISO 27001)
Provide auditors with evidence of secure development, testing, and deployment
Meet vendor security requirements for procurement and third-party risk assessments

How to Use This Document

A control-by-control mapping between SOC 2 Type II Trust Service Criteria (TSC) and CleanStart's technical and operational controls is provided below.

For Your Auditor:

Reference this document during the scoping phase to identify which CleanStart controls apply to your audit
Use the "Evidence Collection" section (page 8) to identify what artifacts to gather
Reference specific control points when CleanStart is a key component of your control environment
Share the "Gap Analysis" section to clarify what CleanStart provides vs. organizational responsibilities

Audit Timeline: Initial Assessment (Month 1): Identify applicable controls, gather design documentation Operating Effectiveness Testing (Months 2-6+): Collect evidence over observation period Final Assessment (Month 12): Comprehensive testing of sustained control operation

Part 1: Common Criteria (CC) — Foundation Controls

CC1: The Organization Demonstrates a Commitment to Competence

CC1.1 - Board and Management Oversight

Control ID	CC1.1
Control Description	The board of directors demonstrates independence from management and exercises oversight of the development, administration, and monitoring of internal controls.
Applicability to CleanStart	High — CleanStart is a managed service with documented governance
CleanStart Evidence	• CleanStart operates under documented governance structures • Service Level Agreements (SLAs) define availability and performance targets • Security policy documentation outlines incident response procedures • Engineering and security leadership accountability for control operation
How to Demonstrate	1. Provide organizational chart showing CleanStart leadership and responsibilities 2. Reference Board/Leadership meeting minutes addressing security and compliance (if applicable) 3. Provide SLA documentation with 99.9%+ uptime commitments 4. Demonstrate leadership review of security incidents (if any) during observation period 5. Document security roadmap approvals by senior leadership
Supporting Documentation	Service governance documentation, SLA agreements, incident summaries
Testing Performed	Inquiry with CleanStart leadership; document review of governance structure

CC1.2 - Organizational Structure and Resource Allocation

Control ID	CC1.2
Control Description	Management establishes structures, reporting lines, and appropriate authorities to achieve the entity's objectives.
Applicability to CleanStart	High — CleanStart has clearly defined roles and responsibilities
CleanStart Evidence	• Dedicated security and engineering teams with defined roles • Separation of duties between development, testing, and deployment • Change control board with documented approval authority • Incident response team with escalation procedures • Third-party vendor management (e.g., cloud infrastructure, container registries)
How to Demonstrate	1. Provide organization chart for CleanStart operations 2. Document role descriptions (e.g., Release Manager, Security Engineer, Platform SRE) 3. Reference change control procedures and approval authority levels 4. Provide incident response runbooks with team assignments 5. Document vendor contracts and SLAs for critical infrastructure (GCP, image registry)
Supporting Documentation	Role descriptions, responsibility matrices (RACI), vendor contracts
Testing Performed	Inquiry and document review; walk-through of change approval process

CC1.3 - Competence and Accountability

Control ID	CC1.3
Control Description	The entity obtains or generates, uses, and communicates relevant, quality information regarding the design and operation of internal controls to support the functioning of other components.
Applicability to CleanStart	High — CleanStart personnel demonstrate competency in secure development and DevSecOps
CleanStart Evidence	• Technical team certifications (CKA, CKAD, security credentials) • Security training and incident response drills conducted annually • Peer review process for all code changes (GitHub CODEOWNERS) • Documentation of security decisions and architectural reviews • Vendor/third-party security assessments and certifications
How to Demonstrate	1. Provide list of team certifications and training completion records 2. Document security awareness training completion (target: 100% annually) 3. Reference peer review evidence (e.g., pull request with approvals) 4. Provide architecture review documentation for security components 5. Demonstrate knowledge management (e.g., security runbooks, incident post-mortems)
Supporting Documentation	Training records, certification list, peer review artifacts, architecture documentation
Testing Performed	Document review of training records; inquiry with team members; review of technical decision documentation

CC2: The Organization Obtains or Generates, Uses, and Communicates Relevant Information

CC2.1 - Information and Communication Infrastructure

Control ID	CC2.1
Control Description	The entity obtains or generates, uses, and communicates relevant information in forms and formats that enable personnel to carry out their internal control responsibilities.
Applicability to CleanStart	High — CleanStart generates extensive security artifacts and audit logs
CleanStart Evidence	• SBOM Generation: SPDX 3.0 and CycloneDX 1.4 for every image • Provenance Tracking: SLSA Level 4 attestations with build metadata • Signature Verification: Cosign/Sigstore signatures for image authenticity • Audit Logging: Comprehensive logs of all image builds, pushes, deployments • VEX Documents: Vulnerability Exploitability eXchange files for supply chain transparency • In-Toto Metadata: Supply chain step links documenting build integrity
How to Demonstrate	1. Query registry (registry.cleanstart.com) to retrieve SBOMs for sample images (show both SPDX and CycloneDX) 2. Demonstrate SLSA provenance attestation retrieval using `slsa-verifier` 3. Show Cosign signature verification workflow 4. Provide sample audit logs covering build, test, push, and deployment events 5. Display VEX document for high-risk image (demonstrates vulnerability communication) 6. Show In-Toto metadata chain linking build steps
Supporting Documentation	Sample SBOMs, SLSA attestations, audit logs, VEX files
Testing Performed	Download and verify artifacts for 3+ images; inspect audit logs for completeness and timestamps

CC2.2 - External Communication

Control ID	CC2.2
Control Description	The entity communicates internal control responsibilities and significant matters regarding internal control to external parties.
Applicability to CleanStart	Medium-High — CleanStart communicates security information to customers
CleanStart Evidence	• Incident Notification: Security incident communication policy • Advisory Distribution: Security advisories via email and status page • API Documentation: Complete OpenAPI/GraphQL schema with security requirements • Compliance Documentation: This SOC 2 mapping and ISO 27001 certification evidence • Status Page: Public status.clnstrt.dev showing availability and incidents
How to Demonstrate	1. Provide incident notification examples (show communication timing and content) 2. Reference security advisory archive with distribution list 3. Show API documentation with authentication and rate-limiting requirements 4. Provide links to public status page 5. Demonstrate notification mechanism for image deprecation/retraction 6. Show compliance documentation repository access (for authorized users)
Supporting Documentation	Incident response templates, advisory archives, API documentation, status page screenshots
Testing Performed	Inquiry about incident communication procedures; review past incident notifications; test status page availability

CC3: The Organization Specifies Objectives and Identifies, Analyzes, and Addresses Risks

CC3.1 - Risk Identification and Analysis

Control ID	CC3.1
Control Description	The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives across the entity.
Applicability to CleanStart	High — CleanStart explicitly addresses supply chain security risks
CleanStart Evidence	• Supply Chain Risk Model: Documented threats in container image supply chain: - Dependency vulnerabilities in base images (mitigated by SBOM + scanning) - Tampered source code (mitigated by Git signing + commit verification) - Compromised build environment (mitigated by SLSA Level 4 provenance) - Unsigned/unverified images in registry (mitigated by Cosign signatures) - Outdated base images in production (mitigated by CleanSight monitoring) • Risk Register: Documented in architecture and security documentation • Vulnerability Management: Continuous scanning, threat intelligence integration • Dependency Analysis: Regular audits of build dependencies and transitive risks
How to Demonstrate	1. Provide risk register or threat model documentation 2. Document specific supply chain attack vectors and mitigations 3. Show vulnerability scanning results and historical trends 4. Demonstrate dependency audit process (e.g., `go list -json ./...` or equivalent) 5. Reference architecture diagrams showing security controls at each build stage 6. Provide evidence of risk assessment updates (frequency and trigger events)
Supporting Documentation	Risk register, threat model, vulnerability scanning reports, dependency audit logs
Testing Performed	Document review of risk assessment; inquiry about risk identification process; inspect vulnerability scanner configuration

CC3.2 - Fraud Risk Assessment

Control ID	CC3.2
Control Description	The entity considers potential for fraud in assessing risks to the achievement of objectives across the entity.
Applicability to CleanStart	High — Image tampering and unauthorized modifications are fraud/integrity risks
CleanStart Evidence	• Insider Threat Mitigation: - RBAC with least-privilege (only authorized developers can push images) - Audit logging of all administrative actions - Separation of duties (build automation ≠ push authorization) • Code Review Process: Mandatory peer review for all changes • Cryptographic Signing: All images signed by trusted identity; revocation possible • Build Automation: No manual image construction; all builds via automation with audit trail • Admission Control: Kyverno/OPA policies prevent unsigned/invalid images in production • Image Retraction: Ability to revoke image signatures, preventing further use
How to Demonstrate	1. Document RBAC policies and user access levels 2. Provide audit log examples showing administrative actions with timestamps and user identification 3. Show peer review requirement in code contribution policy 4. Demonstrate code review process for a sample change 5. Provide image retraction/revocation procedure documentation 6. Show Cosign key management procedures (key rotation, access control) 7. Reference admission control policies preventing unsigned images
Supporting Documentation	RBAC policy, audit logs, code contribution guidelines, key management procedures, admission control policies
Testing Performed	Attempt unauthorized image push (should fail); review audit logs for attempted/failed actions; inspect Cosign key access controls

CC3.3 - Risk Measurement and Prioritization

Control ID	CC3.3
Control Description	The entity considers how potential risks are measured and prioritized.
Applicability to CleanStart	Medium — CleanStart prioritizes vulnerability remediation
CleanStart Evidence	• Severity Scoring: CVSS 3.1 and EPSS (Exploit Prediction Scoring System) integration • SLA for Remediation: Critical vulnerabilities: 24-48 hours; High: 1 week; Medium: 2 weeks • Dashboard Metrics: Vulnerability count by severity, remediation rate, mean time to remediation (MTTR) • Prioritization Framework: Images blocked if critical vulnerabilities detected; warning for high severity • Automation: Continuous vulnerability rescanning on image updates
How to Demonstrate	1. Provide dashboard screenshots showing vulnerability metrics by severity 2. Reference SLA documentation for vulnerability remediation 3. Show historical remediation timelines (prove MTTR commitments) 4. Demonstrate CVSS/EPSS scoring integration in vulnerability reports 5. Provide examples of high-priority remediations completed within SLA 6. Show escalation procedures for critical vulnerabilities
Supporting Documentation	Vulnerability metrics dashboard, SLA documentation, remediation examples
Testing Performed	Review vulnerability backlog and resolution timelines; inspect dashboard for severity distribution

CC4: The Organization Monitors the System and Evaluates the Results

CC4.1 - Ongoing Monitoring Activities

Control ID	CC4.1
Control Description	The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
Applicability to CleanStart	High — CleanStart has continuous monitoring of image security and availability
CleanStart Evidence	• Automated Vulnerability Scanning: Every image scanned at push time and continuously (daily rescans) • Dependency Tracking: Transitive dependencies monitored for new vulnerabilities • Runtime Monitoring via Falco/eBPF: Process execution, file modifications, network activity • Image Freshness Monitoring (CleanSight): Detects outdated images in production; triggers alerts • Signature Verification Checks: Regular validation that all images in use have valid signatures • SBOM Completeness Audits: Verify all images include SBOMs and metadata • Availability Monitoring: Synthetic checks to registry endpoints; alerting on degradation • Performance Monitoring: Image pull/push latency, registry response times
How to Demonstrate	1. Access monitoring dashboard showing real-time vulnerability scan status 2. Provide vulnerability scan results history (last 90 days) 3. Show Falco/eBPF monitoring dashboard with sample alerts 4. Demonstrate CleanSight (optional) showing outdated images detection 5. Query audit logs showing signature verification checks 6. Provide SBOM audit results (% compliance) 7. Show availability metrics and alerting examples 8. Document monitoring tool configurations (thresholds, alert triggers)
Supporting Documentation	Monitoring dashboard screenshots, vulnerability scan history, Falco/eBPF logs, audit results
Testing Performed	Review monitoring tools and configurations; inspect 30 days of monitoring data for completeness; verify alert configurations are active

CC4.2 - Deficiency Evaluation and Remediation

Control ID	CC4.2
Control Description	The entity monitors system performance regarding the objectives related to the security, availability, processing integrity, confidentiality, or privacy of the system and addresses identified deficiencies timely.
Applicability to CleanStart	High — CleanStart addresses monitoring findings through documented processes
CleanStart Evidence	• Incident Classification: Security incidents categorized by severity (Critical/High/Medium/Low) • Response SLAs: Critical incidents require response within 1 hour; investigation within 4 hours • Root Cause Analysis: All significant incidents analyzed; findings documented • Deficiency Tracking: Issues tracked in GitHub Issues/JIRA with assignment and priority • Remediation Testing: All fixes tested in CI/CD pipeline before deployment • Metrics & Trend Analysis: MTTR, repeat incident tracking, control effectiveness metrics • Post-Incident Reviews: Documented for all Critical/High severity events
How to Demonstrate	1. Provide incident response SLA documentation 2. Reference recent incident (if any) with timeline, investigation, and resolution 3. Show deficiency tracking system (GitHub Issues labels, JIRA board) 4. Provide root cause analysis template and recent examples (sanitized if needed) 5. Demonstrate remediation testing in CI/CD pipeline 6. Provide MTTR metrics and trend analysis 7. Document post-incident review process and recent reviews 8. Show escalation procedures for unresolved issues
Supporting Documentation	Incident response policy, recent incident reports, deficiency register, post-incident reviews
Testing Performed	Review 3+ incidents from observation period; inspect incident tracking for timeliness and closure; verify remediation testing

CC5: The Organization Selects, Develops, and Implements Activities to Achieve Its Objectives

CC5.1 - Design and Implementation of Control Activities

Control ID	CC5.1
Control Description	The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
Applicability to CleanStart	Very High — CleanStart IS a collection of control activities
CleanStart Evidence	Security by Design Controls: 1. Source Code Verification - Git commit signing required; unsigned commits rejected - Branch protection rules enforce code review (minimum 2 approvals) - CODEOWNERS file ensures relevant reviewers approve changes 2. Build Integrity (SLSA Level 4) - Builds execute in ephemeral containers, no state persisted - Build environment isolation via GCP Cloud Build - Build steps logged with cryptographic hashes (In-Toto links) - Build parameters captured in provenance attestation - Reproducible builds verified (same source = same image hash) 3. Dependency Management - All dependencies pinned to specific versions (no floating tags) - Dependency scanning at build time (OSV, GitHub Advisories) - Automated dependency updates via Dependabot with testing - Transitive dependency visibility via SBOM 4. Testing & Quality Assurance - Mandatory 78-test inspection suite on every image - Tests verify: security properties, file permissions, signatures, SBOMs, provenance - Unit tests, integration tests, and security-specific tests all automated - Code coverage requirements enforced 5. Image Hardening - Shell-less images (no /bin/sh, reducing attack surface) - Read-only root filesystem (no persistent state in image) - Non-root user (UID 65532) enforced - Minimal base images (Alpine, Distroless) with few CVEs 6. Cryptographic Signing - All images signed with Cosign using hardware keys (HSM) - Signatures validate image authenticity and integrity - Signature revocation possible for compromised images - Time-based attestations (issued_at) prevent signature reuse 7. Cryptographic Standards - FIPS 140-3 cryptographic modules available - RSA-4096 and ECDSA keys for signing - SHA-256 hashing standard throughout 8. Artifact Generation - SPDX 3.0 SBOM (component list, dependency graph) - CycloneDX 1.4 SBOM (alternative format, license information) - VEX document (vulnerability exploitability data) - SLSA provenance (build context, materials, configuration) - In-Toto supply chain metadata - Build logs (100% traceability) - Test results evidence 9. Admission Control in Customer Environments - Kyverno policies: prevent unsigned images, enforce image registries - OPA/Gatekeeper policies: custom rules per organization - Runtime signature verification before pod launch 10. Registry Security - CleanStart registry at registry.cleanstart.com - Rate limiting on API endpoints - Authentication required (API keys, RBAC) - All registry operations logged - Immutable image tags (no overwrite after push)
How to Demonstrate	1. Source Code Verification: Show GitHub branch protection rules, require signed commits verification 2. Build Integrity: Walk through build execution in GCP Cloud Build; show build log with step hashes 3. Dependency Management: Provide dependency manifest (go.mod, requirements.txt); show Dependabot history 4. Testing: Show 78-test suite running; provide sample test results 5. Image Hardening: Pull image; inspect: `docker run --rm image sha256:... id`, `docker inspect image`, verify no shell 6. Cryptographic Signing: Verify image signature with `cosign verify --key ...` 7. Artifacts: Retrieve SBOM, SLSA, VEX for sample image from registry API 8. Admission Control: Show Kyverno/OPA policies; demonstrate failed pod admission (unsigned image) 9. Registry Security: Provide API authentication documentation; show audit logs 10. FIPS Compliance: Document HSM configuration; show crypto library compliance (if applicable)
Supporting Documentation	GitHub policies, Cloud Build configuration, dependency manifests, test suite documentation, image hardening specifications, Cosign configuration, Kyverno/OPA policies
Testing Performed	Comprehensive Control Testing: - Attempt to push unsigned image (must fail) - Attempt to merge PR without approval (must fail) - Verify all images in registry have SBOMs, signatures, provenance - Run 78-test suite; verify all pass - Verify image runs as UID 65532 (non-root) - Verify image filesystem is read-only - Inspect image for shell binary (should not exist) - Verify SLSA provenance completeness and accuracy - Test Kyverno policy: attempt to run unsigned image (should be blocked) - Verify image signature validity over 90-day period

CC5.2 - Quality of Control Activities

Control ID	CC5.2
Control Description	The entity also designs and develops control activities regarding the use of the system to achieve the entity's objectives.
Applicability to CleanStart	High — CleanStart documentation enables effective control operation
CleanStart Evidence	• API Documentation: Complete OpenAPI specification with examples • Integration Guides: Step-by-step guides for Kubernetes, Docker, registries • Security Guidelines: Best practices for using CleanStart images in production • Onboarding Process: New team training on image verification, signature validation • Change Logs: Detailed release notes for breaking changes, security updates • Run Books: Operational procedures (image update, rollback, incident response) • Knowledge Base: FAQ, troubleshooting, common issues
How to Demonstrate	1. Provide API documentation link and sample requests 2. Show integration guide examples (Kubernetes, Docker Compose) 3. Provide security best practices documentation 4. Document onboarding checklist for new users 5. Provide last 3 release notes with security-related items highlighted 6. Reference operational runbooks (e.g., "How to Verify Image Signature") 7. Provide knowledge base articles showing customer support
Supporting Documentation	API docs, integration guides, security guidelines, onboarding checklist, release notes, runbooks
Testing Performed	Follow integration guide step-by-step; verify all API examples work as documented

CC6: The Organization Restricts System Access in Accordance with the Principle of Least Privilege

CC6.1 - Logical and Physical Access Controls

Control ID	CC6.1
Control Description	The entity restricts system access to authorized users, processes, and devices.
Applicability to CleanStart	Very High — Access control is foundational to supply chain integrity
CleanStart Evidence	Access Control Mechanisms: 1. API Authentication - Bearer token authentication (API keys) - Tokens issued with scopes (read, write, admin) - Token rotation required every 90 days - Revocation possible immediately 2. Role-Based Access Control (RBAC) - Registry roles: Viewer (read), Developer (push), Admin - Kubernetes ClusterRole/ClusterRoleBinding for image verification - Service accounts with minimal permissions - Team-based access (e.g., "platform-team" group) 3. GCP IAM Integration - Cloud Build service account with minimal permissions: - storage.buckets.list, storage.objects.get (build inputs) - artifactregistry.repositories.downloadArtifacts (push images) - No overly-permissive roles (e.g., Owner, Editor) - Audit logging of all IAM changes 4. Registry Access Control - Docker authentication required: `docker login registry.cleanstart.com` - kubeconfig authentication for Kubernetes pulls - Network-level access (firewall rules, IP allowlisting if needed) - Rate limiting prevents brute force attacks 5. Build Infrastructure Access - Cloud Build service account (not human accounts) executes builds - Build configuration versioned in Git (no ad-hoc commands) - Build logs encrypted and access-controlled - SSH/RDP to build agents: not permitted (immutable infrastructure) 6. Private Key Management (Cosign) - Signing keys stored in GCP Secret Manager or HSM - Key access restricted to release automation (service account) - Key rotation procedures documented - Private key never leaves secure storage (HSM-backed) 7. Source Code Access - GitHub repository access via SSH keys or OAuth - Branch protection requires authenticated commits - CODEOWNERS approval for sensitive paths - MFA required for admin-level access 8. Monitoring Access - Dashboard and alerting accessed via authentication - Audit log access restricted to authorized personnel - No public logging of sensitive data (e.g., API key patterns)
How to Demonstrate	1. API Authentication: Make authenticated API request with valid API key; show token scope output 2. RBAC: List users/service accounts with assigned roles; verify least privilege 3. GCP IAM: Provide IAM policy for Cloud Build service account; verify no Owner/Editor roles 4. Registry Access: Authenticate to registry; attempt push without credentials (should fail) 5. Build Infrastructure: Show Cloud Build configuration (no SSH/manual steps); query audit logs for human access 6. Key Management: Document Cosign key storage location; show access control policy; verify key rotation schedule 7. Source Code Access: Show branch protection rule requiring authenticated commits; test unsigned commit rejection 8. Monitoring: Access monitoring dashboard; verify authentication required
Supporting Documentation	API authentication guide, RBAC policy document, GCP IAM policies, key management procedures, GitHub branch rules, monitoring access control policy
Testing Performed	Access Control Testing: - Attempt to access API without credentials (should fail) - Attempt to use expired or invalid API token (should fail) - Verify API token cannot be used outside assigned scope (e.g., read-only token cannot push) - Attempt to push image from unauthorized account (should fail) - Inspect Cloud Build IAM policy; verify service account has only necessary permissions - Query audit logs for access events; verify all access captured with user/timestamp - Verify Cosign key access is restricted (attempt to access key as non-authorized user; should fail) - Test rate limiting: exceed API request limit; verify 429 response - Verify MFA requirement for GitHub admin access

CC6.2 - Prior to Issuing System Credentials

Control ID	CC6.2
Control Description	Prior to issuing system credentials, the entity registers and authorizes new internal and external users and the processes they employ.
Applicability to CleanStart	High — Credential issuance is critical for supply chain security
CleanStart Evidence	• User Provisioning Process: Formal request, manager approval, role assignment • Credential Generation: API keys generated via self-service portal with audit • Onboarding Workflow: Documented steps to activate account and obtain credentials • Access Review: Quarterly review of active users and credentials; unused revoked • Service Account Lifecycle: CI/CD service accounts created, documented, and decommissioned with audit • Audit Trail: All credential issuance events logged with requester, approver, timestamp
How to Demonstrate	1. Provide user provisioning policy and workflow documentation 2. Show API key generation audit log (last 30 days) 3. Demonstrate onboarding checklist completion 4. Provide credential access review results (quarterly) 5. Document service account creation and assigned permissions 6. Show user deprovisioning (revocation of credentials) 7. Provide audit log examples with complete context (who, what, when)
Supporting Documentation	User provisioning policy, API key generation audit logs, onboarding checklist, access review results, deprovisioning logs
Testing Performed	Inspect credential issuance audit trail for 30 days; verify all issuances were approved and authorized; test user deprovisioning (credentials revoked)

CC6.3 - Restricts Logical Access

Control ID	CC6.3
Control Description	The entity restricts logical access to system assets and associated facilities (e.g., data center) based on the principle of least privilege.
Applicability to CleanStart	Very High — Physical infrastructure access restricted
CleanStart Evidence	• GCP Cloud Infrastructure: Hosted in managed Google facilities with physical access controls • Data Center Security: Google's physical security (biometric access, surveillance, environmental controls) • Network Segmentation: VPCs, subnet isolation, firewall rules limiting inter-service communication • Bastion Host Access: SSH access to infrastructure via bastion host (not direct) • Just-in-Time (JIT) Access: Temporary elevated access with expiration; audit-logged • No Direct SSH: All infrastructure managed via Infrastructure-as-Code (Terraform, Cloud Build) • GCP Security Posture: No human access to production servers under normal operation
How to Demonstrate	1. Provide GCP account structure and project isolation 2. Show VPC configuration and security group rules 3. Document bastion host access procedures (if applicable) 4. Provide JIT access audit log examples 5. Demonstrate Infrastructure-as-Code deployment workflow (no manual commands) 6. Show audit logs for any human infrastructure access 7. Provide Google's data center security certifications (ISO 27001, SOC 2 Type II)
Supporting Documentation	GCP IAM policy, VPC configuration, network security group rules, bastion host configuration, IaC deployment logs
Testing Performed	Inspect VPC firewall rules for least privilege; verify all infrastructure access goes through approved channels (Cloud Build, IaC); inspect audit logs for compliance

CC6.4 - Authentication and Authorization

Control ID	CC6.4
Control Description	The entity authenticates new or modified system users and the processes they employ on a periodic basis to confirm that system users are who they claim to be.
Applicability to CleanStart	High — Periodic authentication validates system access integrity
CleanStart Evidence	• API Token Validation: Tokens validated against identity provider (GitHub OAuth, SSO) at login • Token Expiration: Tokens expire after 90 days; refresh required • Service Account Rotation: Service account keys rotated every 90 days • MFA Enforcement: MFA required for all human administrative access • GitHub App Tokens: Scoped tokens with time-limited validity • Session Management: Active sessions monitored; idle timeout after 30 minutes • Periodic Access Review: Quarterly validation that active users still require access
How to Demonstrate	1. Document API token expiration policy and enforcement mechanism 2. Show API token expiration error when attempting to use expired token 3. Provide service account key rotation schedule and completion evidence 4. Document MFA requirement for admin-level access 5. Show token validation process (verification with identity provider) 6. Provide session timeout configuration and logs showing sessions ended 7. Show quarterly access review results (confirmed active users, revoked inactive access)
Supporting Documentation	Token management policy, token expiration logs, service account rotation schedule, MFA enforcement policy, access review results
Testing Performed	Attempt to use expired API token (should fail); test token refresh flow; verify MFA requirement for sensitive operations; inspect session timeout logs

CC6.5 - Identities and Credentials

Control ID	CC6.5
Control Description	The entity prevents or detects and acts upon the introduction, change, or removal of unauthorized, inactive, or unsupported functions in the system.
Applicability to CleanStart	High — Credential compromise is a risk vector
CleanStart Evidence	• API Key Rotation: Compromised keys can be revoked; new key issued • Key Compromise Procedures: Documented response (revoke key, audit logs, notify users) • Audit Logging: All credential creation, use, and revocation logged • Anomaly Detection: Unusual API usage patterns monitored (e.g., API key used from unexpected IP) • Rate Limiting: Brute force protection limits failed login attempts • Password Policy: (For user accounts) minimum 12 characters, complexity requirements, no reuse • Inactive Account Deprovisioning: Accounts unused for 90 days reviewed and disabled
How to Demonstrate	1. Provide API key revocation policy and examples 2. Show key compromise incident response procedure 3. Provide audit logs showing compromised key revocation and new key issuance 4. Document rate limiting configuration (threshold, lockout duration) 5. Show anomaly detection alerts for suspicious API usage 6. Provide password policy documentation (if user accounts present) 7. Document inactive account review process and results
Supporting Documentation	Key management policy, incident response procedures, audit logs, rate limiting configuration, anomaly detection rules
Testing Performed	Attempt to revoke API key; verify it no longer works; query audit logs for revocation event; test rate limiting by making repeated failed authentication attempts

CC7: The Organization Restricts the Transmission, Removal, and Removal of Information

CC7.1 - Logical Access Restrictions

Control ID	CC7.1
Control Description	The entity implements logical access security measures to protect against unauthorized internal access.
Applicability to CleanStart	Very High — Network-level controls protect data in transit
CleanStart Evidence	Data Protection in Transit: 1. Encrypted Communication - All API endpoints use HTTPS (TLS 1.2+) - Certificate pinning for sensitive clients (optional) - No HTTP fallback; requests redirected to HTTPS 2. Image Registry Communication - Docker pull/push via HTTPS only - Cosign signature verification (prevents MITM attacks) - Digest-based image references (immutable, prevents substitution) 3. Build Infrastructure - Cloud Build ↔ GitHub: HTTPS, SSH with key verification - Build artifacts stored in GCS with encryption - Build logs encrypted and access-controlled 4. Cryptographic Signing - Image signatures prevent tampering in transit - Artifact attestations cryptographically bound to images - VEX and SBOM signatures authenticate metadata 5. Network Segmentation - Registry API behind load balancer with DDoS protection - GCP Cloud Armor: WAF rules, rate limiting - VPC isolation: only necessary services accessible 6. API Rate Limiting - Per-user rate limits: 1,000 requests/minute (configurable) - Prevents account enumeration and credential brute force - Returns 429 status with backoff headers 7. Data at Rest Encryption - Google-managed encryption keys (default) - Optional: Customer-managed keys (CMEK) via KMS - Storage encryption for SBOMs, build logs, artifacts
How to Demonstrate	1. TLS Verification: Access API endpoint; verify certificate (TLS 1.2+), check issuer 2. HTTPS Only: Attempt HTTP request; verify redirect to HTTPS 3. Image Signature Verification: Pull image; verify signature with `cosign verify` 4. Network Architecture: Provide VPC topology diagram; show firewall rules 5. Rate Limiting: Exceed rate limit; verify 429 response with retry-after header 6. Encryption at Rest: Provide GCS bucket encryption configuration 7. Artifact Signatures: Retrieve SBOM/SLSA attestation; verify signature
Supporting Documentation	TLS certificate configuration, network topology diagram, firewall rules, rate limiting policy, encryption key management, API certificate details
Testing Performed	Network Security Testing: - Verify TLS 1.2+ is enforced (attempt TLS 1.1; should fail) - Verify HSTS headers present (prevents downgrade attacks) - Verify rate limiting: make 1,001 requests in 60 seconds; confirm 429 response on request 1,001 - Verify digest-based image references prevent tag substitution - Inspect build artifact encryption (GCS bucket properties) - Verify image signature validity (attempt to verify with wrong public key; should fail)

CC7.2 - Encryption and Protection of Information

Control ID	CC7.2
Control Description	The entity disposes of physical and digital information to protect against unauthorized access.
Applicability to CleanStart	Medium — Image retraction and key decommissioning
CleanStart Evidence	• Image Retraction: Images can be removed or marked deprecated; prevents further pulls • Signature Revocation: Compromised keys revoked; future signature validation fails • Audit Log Retention: Logs retained for minimum 1 year (configurable) • Data Deletion: Deprecated images and associated artifacts removed after retention period • Secure Key Destruction: HSM keys destroyed following vendor procedures • Build Artifact Cleanup: Temporary build artifacts deleted after image creation • Encryption Key Rotation: Encryption keys rotated annually (or per security policy)
How to Demonstrate	1. Document image retraction procedures and examples 2. Show signature revocation process (e.g., "revoke key" in Cosign workflow) 3. Provide audit log retention policy 4. Document data deletion procedures (e.g., GCS object lifecycle policies) 5. Reference HSM key destruction procedures (vendor documentation) 6. Show temporary artifact cleanup automation 7. Document encryption key rotation schedule
Supporting Documentation	Image retraction policy, signature revocation procedures, audit log retention policy, data deletion procedures, key rotation schedule
Testing Performed	Retrieve a deprecated/revoked image (should fail); inspect GCS lifecycle rules for automatic cleanup; query audit logs for key rotation events

Part 2: Trust Service Criteria (TSC) — Business Process Controls

A1: Availability

Criterion: The system is available for operation and use as committed or agreed.

A1.1 - Information System Resources

Control ID	A1.1
Control Description	The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to information system infrastructure and components to meet requirements.
Applicability to CleanStart	Very High — Infrastructure and image availability is critical
CleanStart Evidence	Infrastructure Design: • Redundancy: Multi-region deployment capability (currently us-central1; can expand) • Load Balancing: Google Cloud Load Balancer distributes traffic • Auto-Scaling: Cloud Run instances scale 1-10+ based on demand • Database Resilience: ClickHouse with replication (if applicable) • Backup & Recovery: Regular backups of image metadata; RTO <1 hour, RPO <4 hours • Change Control: All infrastructure changes via Terraform, reviewed and approved • Capacity Planning: Monitoring of CPU, memory, disk; alerts for approaching limits • Disaster Recovery Plan: Documented procedures for service restoration
How to Demonstrate	1. Provide infrastructure architecture diagram (load balancer, auto-scaling, multi-region capability) 2. Show Cloud Run auto-scaling configuration 3. Document backup procedures and RTO/RPO 4. Provide Terraform configuration for infrastructure (version-controlled) 5. Show capacity monitoring dashboard (CPU, memory, disk usage over time) 6. Document disaster recovery plan 7. Provide evidence of infrastructure change approvals (Terraform PR reviews)
Supporting Documentation	Architecture diagram, Cloud Run configuration, backup policy, Terraform files, disaster recovery plan
Testing Performed	Simulate component failure (test failover); verify auto-scaling by inducing load; test backup restoration process

A1.2 - Environmental Protections

Control ID	A1.2
Control Description	The entity protects its system infrastructure and related facilities from the effects of natural disasters and human-made threats to meet the objectives related to availability.
Applicability to CleanStart	High — Google Cloud infrastructure provides environmental protections
CleanStart Evidence	• Google Cloud Data Center Security: Physical security, fire suppression, cooling, redundancy • Geographic Redundancy: GCP regions in multiple geographic locations • Compliance with Standards: Google data centers comply with ISO 27001, SOC 2 Type II • Natural Disaster Resilience: Earthquake-resistant facilities, flood prevention • DDoS Protection: Cloud Armor, Cloud CDN for traffic shaping • Power Redundancy: Dual power feeds, on-site backup power • Network Redundancy: Multiple internet providers, fault-tolerant routing
How to Demonstrate	1. Provide Google Cloud data center security certifications 2. Reference Google's SOC 2 Type II report (availability section) 3. Show multi-region deployment capability 4. Provide Cloud Armor configuration (DDoS protection) 5. Document disaster recovery plan addressing natural disasters 6. Show historical uptime metrics (99.9%+ target)
Supporting Documentation	Google Cloud compliance documentation, Cloud Armor configuration, disaster recovery plan, uptime metrics
Testing Performed	Query historical uptime data (verify 99.9%+ SLA); test disaster recovery procedures; simulate DDoS attack (verify Cloud Armor blocks)

A1.3 - Recovery Planning

Control ID	A1.3
Control Description	The entity authorizes, designs, develops, configures, documents, tests, approves, and implements recovery and contingency procedures for the system.
Applicability to CleanStart	High — Image recovery and service restoration
CleanStart Evidence	• Backup Schedule: Daily backups of image metadata and registry data • Recovery Testing: Monthly recovery drills; verify RTO/RPO targets • Documented Procedures: Runbooks for common failure scenarios • Database Failover: Automatic failover for ClickHouse (if replicated) • Image Registry Failover: Capability to restore from backup or secondary registry • Communication Plan: Incident notification procedures during recovery • Change Approval: Recovery procedure updates tracked and approved
How to Demonstrate	1. Provide backup schedule and retention policy 2. Show backup verification logs (integrity checks) 3. Document recovery testing results (frequency, duration, success rate) 4. Provide recovery runbooks for common scenarios 5. Show RTO/RPO metrics achieved in testing 6. Document failover procedures and testing 7. Reference incident communication plan
Supporting Documentation	Backup policy, backup logs, recovery test results, runbooks, RTO/RPO documentation
Testing Performed	Execute full recovery drill: simulate data loss, restore from backup, verify image accessibility; measure actual RTO

PI1: Processing Integrity

Criterion: System processing is complete, accurate, timely, and authorized to achieve the entity's objectives.

PI1.1 - Accuracy and Completeness

Control ID	PI1.1
Control Description	The entity obtains or generates, uses, and communicates relevant, accurate, and complete information regarding the objectives of the system.
Applicability to CleanStart	Very High — SBOM, provenance, and metadata accuracy is critical
CleanStart Evidence	Metadata Accuracy Controls: • Automated Generation: SBOMs generated programmatically (not manually), reducing errors • Validation Rules: Generated SBOMs validated against SPDX/CycloneDX schema • Provenance Verification: SLSA attestations cryptographically signed; tampering detected • Dependency Completeness: All direct and transitive dependencies captured in SBOM • Checksum Verification: Build artifacts checksummed (SHA-256); verified on retrieval • Build Log Integrity: Build logs append-only; cannot be modified post-build • Test Result Accuracy: 78-test results tied to specific image hash; versioned • Metadata Deduplication: No duplicate vulnerability records; deduplicated by CVE ID
How to Demonstrate	1. Retrieve SBOM for image; validate against SPDX schema (use `sbom-tool` or similar) 2. Verify SBOM is complete: match component count to build configuration 3. Validate SLSA provenance signature; show provenance details (builder, source, config) 4. Retrieve image; verify SHA-256 matches registry checksum 5. Show build log; verify append-only format (timestamps increase monotonically) 6. Provide test results; verify bound to specific image hash 7. Query vulnerability data; show deduplication (no duplicate CVE IDs for same image)
Supporting Documentation	SBOM samples, SLSA provenance samples, checksum verification logs, build logs, test results
Testing Performed	Accuracy Testing: - Download SBOM; validate XML/JSON schema compliance - Manually count components in build configuration; compare to SBOM component count (must match) - Verify all declared dependencies are actually present in image (inspect layers) - Test checksum mismatch: modify image locally; attempt to verify with registry checksum (should fail) - Modify build log (if accessible); verify immutability (changes should fail) - Link test results to image hash; verify consistent across multiple retrievals

PI1.2 - Completeness and Timeliness of Information

Control ID	PI1.2
Control Description	The entity completeness and timeliness of information system monitoring addresses the requirements related to the security of the system to achieve related objectives.
Applicability to CleanStart	High — Real-time monitoring and alerting
CleanStart Evidence	• Real-Time Vulnerability Scanning: Images scanned immediately at push; results available within minutes • Continuous Monitoring: Vulnerabilities rescanned daily; new findings reported within 24 hours • Alert Timeliness: Critical vulnerabilities trigger alerts within 1 hour • Metric Freshness: Monitoring dashboards update every 5 minutes • Completeness: All images monitored; no gaps in coverage • Audit Log Completeness: 100% of API calls logged; no sampling • Availability Monitoring: Synthetic checks every 1 minute; alerts within 5 minutes of outage detection
How to Demonstrate	1. Push a test image; measure time to first vulnerability scan completion (target: <5 min) 2. Access monitoring dashboard; verify data freshness (timestamp within 5 min) 3. Provide alert configuration; show alert fired within SLA for critical vulnerability 4. Query audit logs; verify 100% coverage (no gaps) 5. Show synthetic check results; verify <1 min check interval 6. Demonstrate alert notification (email/SMS) timing
Supporting Documentation	Monitoring configuration, alert thresholds, audit log policy, synthetic check frequency
Testing Performed	Push test image and measure scan time; trigger test alert and measure notification time; verify audit log completeness by cross-referencing with external event log

C1: Confidentiality

Criterion: The system is protected against unauthorized disclosure of information.

C1.1 - Confidentiality of Information

Control ID	C1.1
Control Description	The entity restricts access to information assets and facilities in accordance with roles, responsibilities, and the principle of least privilege regarding confidentiality.
Applicability to CleanStart	Medium-High — Image metadata confidentiality (if applicable)
CleanStart Evidence	• API Access Control: Registry API requires authentication; anonymous access not permitted for private images • Image Visibility: Private vs. public image distinction (if applicable) • Audit Log Confidentiality: Logs contain no sensitive data (API keys, credentials); masked • Build Log Confidentiality: Build logs exclude secret values (environment variables, credentials) • Network-Level Confidentiality: HTTPS encryption in transit; no HTTP fallback • Storage Encryption: Images at rest encrypted (Google-managed or CMEK) • Access Logging: Who accessed what, when logged (but access itself logged, not payload)
How to Demonstrate	1. Attempt anonymous registry API access (should fail or return only public images) 2. Try to view private image without authentication (should fail) 3. Inspect audit logs; verify no credentials are exposed 4. Review build logs; verify secret values are masked 5. Verify HTTPS enforcement (no HTTP) 6. Provide GCS bucket encryption configuration (verify encryption enabled) 7. Show access audit logs (who accessed, when, from where)
Supporting Documentation	Image access control policy, audit log format documentation, build log template, GCS encryption configuration
Testing Performed	Attempt to access private image without credentials (should fail); inspect audit logs for credential patterns (should find none); verify HTTPS enforcement

Evidence Collection Checklist

For your SOC 2 Type II audit, gather these artifacts:

Design Phase Evidence (Month 1)

[ ] Organization chart and roles/responsibilities documentation [ ] Information security policy and standards documentation [ ] Risk assessment and risk register (supply chain risks) [ ] Control framework documentation (this mapping) [ ] System architecture and data flow diagrams [ ] Incident response plan and procedures

Operating Effectiveness Evidence (Months 2-12)

Access Control & Authentication: [ ] API key generation audit logs (last 90 days) [ ] User access review results (quarterly) [ ] Failed authentication attempt logs (sample week) [ ] MFA enforcement logs (if applicable) [ ] Credential rotation/revocation events

Development & Build Controls: [ ] Git commit signing verification logs (sample week) [ ] Code review approval records (5+ examples) [ ] Branch protection rule enforcement logs [ ] Cloud Build execution logs (10+ builds) [ ] Dependency scanning results (3+ images) [ ] Test suite execution results (78-test proof)

Vulnerability Management: [ ] Vulnerability scan results for 10+ images [ ] Vulnerability rescanning schedule and evidence [ ] CVSS/EPSS scoring examples [ ] Remediation timelines (proof of SLA compliance) [ ] Vulnerability advisory distribution examples

Cryptographic Controls: [ ] SBOM samples (SPDX and CycloneDX) for 5+ images [ ] SLSA provenance attestation samples [ ] Cosign signature verification examples [ ] VEX document samples [ ] Image signature validation audit logs

Monitoring & Incident Response: [ ] Monitoring dashboard screenshots (30-day period) [ ] Alert examples and response times [ ] Incident reports (if any; sanitized) [ ] Root cause analysis examples [ ] Post-incident review documentation

Infrastructure & Disaster Recovery: [ ] Infrastructure as Code (Terraform) files [ ] Change approval logs (30 days) [ ] Backup and recovery testing results [ ] Disaster recovery procedure documentation [ ] Capacity planning reports (quarterly)

Third-Party/Dependency Evidence

[ ] Vendor security assessments (Google Cloud, ClickHouse) [ ] Software bill of materials for CleanStart itself (meta-SBOM) [ ] Dependency vulnerability scan results [ ] Compliance certifications of key vendors (ISO 27001, SOC 2)

Gap Analysis: CleanStart Coverage vs. Customer Responsibilities

What CleanStart Provides (Design & Implementation)

Very High Coverage: Source code security (commit signing, code review enforcement) Build integrity (SLSA Level 4 provenance, reproducibility) Image hardening (shell-less, read-only, non-root) Dependency management (SBOM, transitive dependency tracking) Cryptographic signing (Cosign/Sigstore) Testing & quality assurance (78-test suite) Vulnerability management (continuous scanning, SLA-based remediation) Access control (API authentication, RBAC) Encryption (TLS in transit, encryption at rest) Monitoring & alerting (real-time vulnerability tracking) Incident response procedures (documented escalation) Disaster recovery capabilities (backup/restore, failover)

Medium Coverage: Vendor management (responsibility shared; CleanStart uses secure vendors) Capacity planning (CleanStart provides monitoring; customer determines sizing) Change management (CleanStart uses IaC; customer implements for their deployments) Information classification (CleanStart applies; customer defines for their use)

What Customers Must Provide

Access Control in Consumer Environment: Implement image admission control (Kyverno/OPA policies) Enforce image signature verification before pod deployment Manage authentication to CleanStart registry (API keys, credentials) Audit image pulls in their Kubernetes environment

Deployment & Runtime Security: Implement network policies restricting image sources Configure Falco/eBPF for runtime monitoring of deployed images Integrate CleanStart with their CI/CD pipeline Implement image update policies (manual, automated, staged rollout) Monitor for outdated images in production (use CleanSight if available)

Incident Response & Business Continuity: Define incident response procedures for supply chain compromises Establish backup strategies for critical images Conduct disaster recovery drills for their deployments Maintain communication channels with CleanStart security team

Compliance & Governance: Document their use of CleanStart controls in their control environment Maintain their own risk register and security policy Conduct periodic reviews of CleanStart SLA compliance Perform third-party security assessments (including CleanStart verification)

Operational Controls: Monitor image pull metrics and anomalies Maintain audit logs of image deployments Review access logs for unauthorized access attempts Conduct quarterly user access reviews

Glossary of Terms

Term	Definition
SBOM	Software Bill of Materials — comprehensive list of components and dependencies in an image
SPDX	Software Package Data Exchange — open standard for SBOM format
CycloneDX	Lightweight BOM standard with focus on license and security information
SLSA	Supply Chain Levels for Software Artifacts — framework for supply chain security maturity (Levels 0-4)
Level 4	Highest SLSA level; requires hermetic builds, cryptographic provenance, and offline verification
Cosign	Container image signing tool using Sigstore/Keyless signing
Sigstore	Open-source project providing keyless, OIDC-based signing infrastructure
VEX	Vulnerability Exploitability eXchange — document format for communicating if vulnerabilities are exploitable
In-Toto	Supply chain integrity metadata format; records materials, environment, and results of each build step
Falco	Open-source runtime security tool using eBPF to detect anomalous process behavior
eBPF	Extended Berkeley Packet Filter — kernel technology for monitoring without instrumenting code
Kyverno	Kubernetes policy engine for enforcing admission control policies (e.g., require signed images)
OPA/Gatekeeper	Open Policy Agent with Kubernetes admission controller for policy enforcement
CleanSight	(Optional) Image freshness monitoring tool detecting outdated images in production
Cloud Build	Google Cloud's container image build service with supply chain integrity features
HSM	Hardware Security Module — secure device for storing cryptographic keys
RTO	Recovery Time Objective — target time to restore service after outage
RPO	Recovery Point Objective — maximum acceptable data loss (time-based)
CVSS	Common Vulnerability Scoring System — standardized vulnerability severity scoring (0-10)
EPSS	Exploit Prediction Scoring System — probability that vulnerability will be exploited (0-1)
MFA	Multi-Factor Authentication — two or more verification methods (password + code, etc.)
FIPS 140-3	Federal Information Processing Standard for cryptographic modules; highest security standard

Appendix: Sample Control Testing Procedures

Test Procedure 1: Image Signature Verification

Objective: Verify that all images in registry are properly signed and signatures can be validated.

Steps:

Select 10 random images from CleanStart registry
Retrieve each image manifest and signature data
Using cosign verify --key <public-key>, validate each signature
Document pass/fail for each image
Expected Result: 100% signature validation success

Evidence: Screenshot of cosign verification output showing "Verification successful"

Test Procedure 2: SBOM Completeness

Objective: Verify that SBOMs include all components and are schema-compliant.

Steps:

Select 3 images representing different base images
Retrieve SBOM (SPDX format) for each image
Validate SBOM XML against SPDX schema using validation tool
Manually inspect Dockerfile/build configuration
Count components in SBOM; compare to build configuration
Expected Result: SBOMs validate against schema; component count matches

Evidence: SBOM validation tool output; component count comparison table

Test Procedure 3: Access Control Enforcement

Objective: Verify that image push requires authentication and authorization.

Steps:

Obtain a Docker daemon without authentication to CleanStart registry
Attempt to push a test image: docker push registry.cleanstart.com/test:latest
Expected Result: Push fails with authentication error (HTTP 401)
Authenticate with API key: docker login registry.cleanstart.com
Attempt to push with limited-scope token (read-only): Should fail with authorization error (HTTP 403)
Authenticate with admin token; push succeeds
Query audit log; verify push event logged with user identity and timestamp

Evidence: Error messages, audit log entry

Test Procedure 4: Vulnerability Remediation SLA

Objective: Verify that critical vulnerabilities are remediated within documented SLA.

Steps:

Identify all images with critical vulnerabilities (CVSS >= 9.0)
For each critical vulnerability, determine discovery date
Determine remediation date (date image was patched/removed)
Calculate days to remediation
Expected Result: All critical vulnerabilities remediated within 48 hours
Acceptable exceptions: Document any exceptions with justification

Evidence: Spreadsheet showing vulnerability discovery → remediation timeline

SOC 2 Type II Final Audit Roadmap

Phase	Duration	Activities	Deliverables
Planning	1 month	Scope definition, control mapping, audit plan	Audit plan, control matrix
Interim	3-6 months	Design testing, control observation begins	Interim report, identified gaps
Final	3-6 months	Operating effectiveness testing, sampling	SOC 2 Type II Report
Total	6-12 months		SOC 2 Type II Report with opinion

Document Approval

Role	Name	Date	Signature
CISO	[Name]	[Date]	[Signature]
Chief Compliance Officer	[Name]	[Date]	[Signature]
VP Engineering	[Name]	[Date]	[Signature]

END OF SOC 2 TYPE II MAPPING

This document is confidential and intended only for authorized auditors and internal compliance personnel. Unauthorized distribution is prohibited.