Knowledge Hub

ISO 27001:2022 Compliance Mapping: CleanStart Container Image Service

Document Version: 2.0 Last Updated: March 22, 2026 Classification: Confidential - For ISO 27001 Certification Audit Prepared for: CISO/GRC Review and External Auditors (ISO 27001:2022 Engagement)

Executive Summary

What is ISO 27001:2022?

ISO 27001 is the international standard for Information Security Management Systems (ISMS). Unlike SOC 2 Type II (which audits controls over a period), ISO 27001 defines a framework for:

Scope: What information assets and processes are managed
Risk Assessment: Identifying and evaluating security risks
Controls: 93 specific controls across 4 themes (Organizational, People, Physical, Technological)
Documentation: Policies, procedures, and records proving control operation
Certification: Third-party auditor certifies that ISMS is "fit for purpose"

Key Differences from SOC 2 Type II: ISO 27001 focuses on the organization's ISMS maturity; SOC 2 focuses on a specific service's controls ISO 27001 requires a Statement of Applicability (SoA) documenting which controls apply and why ISO 27001 emphasizes continuous improvement; SOC 2 emphasizes evidence of operating effectiveness ISO 27001 certification is point-in-time (valid 3 years with annual surveillance); SOC 2 requires annual renewal

Why ISO 27001:2022 Matters for CleanStart

CleanStart is a critical component of organizations' information security infrastructure, protecting the supply chain for containerized applications. Organizations using CleanStart can:

Demonstrate compliance with ISO 27001 Annex A controls, particularly: A.8.25 (Secure Development) A.8.26 (Application Security Requirements) A.8.28 (Secure Coding) A.8.8 (Vulnerability Management) A.8.9 (Configuration Management)
Reduce ISMS scope by outsourcing development and supply chain security to a certified vendor
Evidence generation for auditors: SBOMs, provenance, signatures, audit logs
Vendor risk assessment with explicit reference controls and audit documentation

How to Use This Document

CleanStart's controls map to ISO 27001:2022 Annex A. For each control: Control ID & Name: ISO 27001:2022 reference Control Statement: What the control requires CleanStart Mapping: How CleanStart addresses it Evidence: What to show auditors Customer Responsibility: What you must do Maturity Level: Design/Operational/Optimized

For Your Auditor:

Reference this mapping during the ISMS scoping phase
Use evidence references to gather required documentation
Include CleanStart vendor assessment in your third-party risk management process
Reference specific controls when demonstrating A.8.25 (Secure Development) and A.8.28 (Secure Coding)

For ISMS Implementation:

Add relevant controls to your Statement of Applicability (SoA)
Document CleanStart as a control implementation for applicable controls
Include CleanStart evidence in your control monitoring procedures
Schedule annual control effectiveness testing

Part 1: ISO 27001:2022 Control Framework Overview

The following diagram illustrates how CleanStart addresses ISO 27001:2022 control domains:

graph TB    A["ISO 27001:2022<br/>93 Controls<br/>Across 4 Themes"] -->|Theme 1| B["Organizational<br/>Controls"]     A -->|Theme 2| C["People<br/>Controls"]     A -->|Theme 3| D["Physical<br/>Controls"]     A -->|Theme 4| E["Technological<br/>Controls"]     B -->|Applies to| B1["A.5: Organizational<br/>Control"]    B1 -->|A.5.1| B2["Policies &<br/>Procedures"]     C -->|Applies to| C1["A.6: People<br/>Control"]    C1 -->|A.6.1| C2["Awareness &<br/>Training"]     D -->|Applies to| D1["A.7: Physical<br/>Control"]    D1 -->|A.7.1| D2["Facilities"]     E -->|Applies to| E1["A.8: Technological<br/>Control"]    E1 -->|A.8.8| E2["Vulnerability<br/>Management"]    E1 -->|A.8.25| E3["Secure<br/>Development"]    E1 -->|A.8.26| E4["Application<br/>Security"]    E1 -->|A.8.28| E5["Secure<br/>Coding"]     E2 -->|CleanStart| E2a["CVE Scanning<br/>SBOM Generation<br/>VEX Documents"]     E3 -->|CleanStart| E3a["Supply Chain<br/>Integrity<br/>SLSA Level 4"]     E4 -->|CleanStart| E4a["Image Signing<br/>Cosign<br/>Attestations"]     E5 -->|CleanStart| E5a["Code Analysis<br/>Static Analysis<br/>Binary Analysis"]     E2a -->|Evidence| F["Audit Trail<br/>Scan Reports<br/>Remediation<br/>Records"]     E3a -->|Evidence| F     E4a -->|Evidence| F     E5a -->|Evidence| F     F -->|Compliance| G["ISO 27001:2022<br/>Certification<br/>Audit Ready"]     B2 -->|Organization| H["ISMS<br/>Documentation"]     C2 -->|Organization| H     H -->|Support| G     style A fill:#99ccff    style E fill:#ccffcc    style E2a fill:#99ff99    style E3a fill:#99ff99    style E4a fill:#99ff99    style E5a fill:#99ff99    style G fill:#ffff99

Part 1: ISO 27001:2022 Control Framework Overview

The 4 Control Themes (93 Controls Total)

Theme	Controls	Focus
A.5: Organizational Controls	10 controls	Policies, governance, threat intelligence, asset management
A.6: People Controls	8 controls	Screening, awareness, responsibility, remote work
A.7: Physical Controls	14 controls	Facilities, perimeters, equipment, media
A.8: Technological Controls	61 controls	Access, cryptography, malware, logging, development, suppliers

CleanStart primarily addresses A.8 (Technological Controls), with secondary addressing of A.5 and A.6.

Part 2: CleanStart Control Mapping by Annex A Section

A.5: Organizational Controls (10 controls)

A.5.1 - Policies for Information Security

Control ID	A.5.1
Control Name	Policies for information security
Control Statement	Information security policies shall be defined, approved by management, published and communicated to employees and relevant external parties.
Applicability to CleanStart	High — CleanStart provides security policy documentation
CleanStart Mapping	• Published security and development policies • Vulnerability remediation SLAs and procedures • Incident response plan and escalation procedures • Data handling and classification guidelines • Supply chain security requirements • Third-party security assessment procedures
Evidence	1. Security policy documentation (published on website or documentation portal) 2. Development and build security standards 3. Incident response procedures 4. Vulnerability management SLA 5. Third-party assessment criteria and results
Customer Responsibility	Integrate CleanStart security policy into your organizational ISMS; communicate to teams using CleanStart; include in vendor management procedures
Maturity Level	Operational (policies documented and followed; regularly reviewed)

A.5.7 - Threat Intelligence

Control ID	A.5.7
Control Name	Threat intelligence
Control Statement	Threat intelligence information shall be gathered and analyzed to inform information security risk assessments and to support the definition and implementation of appropriate information security controls.
Applicability to CleanStart	Very High — CleanStart integrates multiple threat intelligence sources
CleanStart Mapping	• Vulnerability Intelligence: - National Vulnerability Database (NVD) integration - GitHub Security Advisories (GHSA) - Open Source Vulnerabilities (OSV) database - Package-specific advisories (npm, PyPI, Go, etc.) • Supply Chain Threat Modeling: - Documented threats: tampered source code, compromised build environment, unsigned images, outdated dependencies - Attack vectors addressed: Git signing (code origin), SLSA L4 (build integrity), Cosign signatures (image authenticity) • Real-Time Intelligence: - Daily vulnerability rescanning - Continuous monitoring of base images for new CVEs - EPSS scoring integration (exploit probability) - Automated alerting on critical threats • Incident Pattern Analysis: - Tracking of supply chain attacks (SolarWinds, Log4Shell, etc.) - Control designs informed by attack analysis
Evidence	1. Documented threat intelligence sources and integration procedures 2. Threat model document (supply chain attack vectors) 3. Vulnerability database integration configuration 4. Sample vulnerability intelligence reports (last 30 days) 5. Evidence of threat-informed control design (architecture documentation) 6. Incident analysis reports (if applicable) 7. EPSS integration documentation
Customer Responsibility	Subscribe to CleanStart advisories; integrate into your threat intelligence process; maintain awareness of supply chain threats
Maturity Level	Operational (threat intelligence actively collected and analyzed; informs controls)

A.5.8 - Information Security in Project Management

Control ID	A.5.8
Control Name	Information security in project management
Control Statement	Information security shall be addressed in project management processes.
Applicability to CleanStart	High — CleanStart incorporates security in development projects
CleanStart Mapping	• Security in SDLC: - Threat modeling performed for new features - Security requirements defined before implementation - Code review includes security analysis - Security testing required before release • Project Planning: - Security acceptance criteria in user stories - Dependency scanning in sprint planning - Vulnerability remediation tracked in project backlog • Change Management: - All infrastructure changes via Terraform (version control) - Change approval process documented - Security impact analysis for major changes • Release Management: - Security sign-off required before production release - Release notes include security updates - Rollback procedures documented
Evidence	1. Project management process documentation (reference to security requirements) 2. Sample user stories with security acceptance criteria 3. Threat modeling examples for new features 4. Release notes from last 3 releases (highlight security items) 5. Change approval logs (30 days) 6. Terraform change history with approvals
Customer Responsibility	Implement security in your own project management; reference CleanStart security updates in your release planning
Maturity Level	Operational (security integrated in project processes)

A.5.9 - Asset Management

Control ID	A.5.9
Control Name	Asset management
Control Statement	All assets related to information and information processing facilities shall be identified, recorded, and managed according to their importance to the organization.
Applicability to CleanStart	Very High — CleanStart catalogs and manages container images as information assets
CleanStart Mapping	• Asset Inventory (Images): - Registry maintains complete inventory of all published images - Each image has unique identifier (SHA-256 digest) - Metadata tracked: name, version, base image, build date, publisher • Asset Classification: - Public vs. private images - Critical vs. standard images (based on usage) - Sensitive data classification guidelines • Asset Lifecycle: - Creation: build and push to registry - Maintenance: updates, patches, dependency updates - Deprecation: marking old images as unsupported - Retirement: removing from registry, retraction from production • Dependency Tracking: - Base image inventory and updates tracked - Library versions documented in SBOM - Transitive dependencies recorded - Supply chain component traceability • Asset Metadata: - SBOM (SPDX/CycloneDX) for each image - Build metadata (SLSA provenance) - Signature information (Cosign) - Test results and quality metrics - Vulnerability scan results • Change Tracking: - Build history for each image - Base image update history - Vulnerability remediation tracking - Deprecation notices
Evidence	1. Registry query showing image inventory (name, digest, build date) 2. Asset classification policy documentation 3. SBOM sample (showing dependency inventory) 4. Image deprecation/retirement procedures 5. Asset metadata for 5+ sample images 6. Lifecycle documentation (creation through retirement) 7. Dependency update audit logs (last 90 days)
Customer Responsibility	Inventory CleanStart images in your asset management system; classify by criticality; document in your ISMS; conduct periodic asset reviews
Maturity Level	Optimized (comprehensive asset tracking with automated metadata)

A.6: People Controls (8 controls)

A.6.2 - Information Security Awareness, Education and Training

Control ID	A.6.2
Control Name	Information security awareness, education and training
Control Statement	Organizations shall provide information security awareness, education and training to relevant personnel on information security risks, their responsibilities and the need for protecting information assets.
Applicability to CleanStart	Medium-High — CleanStart provides education on secure supply chain practices
CleanStart Mapping	• Training & Documentation: - API authentication guide (how to obtain and use API keys) - Image signature verification procedures - Supply chain security best practices - SBOM interpretation guide - Incident reporting procedures • Security Advisories: - Mailing list for security notifications - GitHub security advisories - Incident post-mortems (public, if applicable) • Developer Resources: - Secure development practices guide - Build security documentation - Dependency scanning integration guide - Vulnerability response procedures • Compliance Education: - SOC 2 Type II and ISO 27001 compliance documentation - SLSA and supply chain security frameworks - Container security best practices
Evidence	1. API authentication guide and examples 2. Security best practices documentation 3. Training materials on image verification 4. Security advisory mailing list subscription page 5. Knowledge base articles and FAQs 6. Incident post-mortem (if applicable) 7. Secure development guide
Customer Responsibility	Require training on CleanStart security procedures for all developers; integrate into organizational security awareness program; keep team updated on advisories
Maturity Level	Operational (comprehensive documentation available; self-paced training)

A.7: Physical Controls (14 controls)

A.7.1 - Physical Security Perimeter

Control ID	A.7.1
Control Name	Physical security perimeter
Control Statement	Physical perimeters shall be defined and used to protect areas which contain information and information processing facilities.
Applicability to CleanStart	Medium — Google Cloud physical security
CleanStart Mapping	• Data Center Security: Hosted in Google Cloud data centers with: - Biometric access control - Video surveillance - Physical barriers and fencing - Environmental monitoring (temperature, humidity) • Google Compliance: Google data centers comply with: - ISO 27001 - SOC 2 Type II - FedRAMP (for GCP Authority to Operate) - NIST SP 800-53 • Multi-Region Capability: Ability to deploy across Google regions for geographic redundancy
Evidence	1. Reference Google Cloud SOC 2 Type II report (security section) 2. Reference Google Cloud ISO 27001 certificate 3. Google Cloud data center security whitepaper 4. Regional deployment documentation
Customer Responsibility	Review Google Cloud compliance reports; ensure your organization accepts risk of Google data center locations; document in your ISMS
Maturity Level	Operational (compliance delegated to Google; monitored via third-party audits)

A.8: Technological Controls (61 controls) — PRIMARY FOCUS

This section is critical for CleanStart. A.8 contains the most complete mapping, particularly for secure development (A.8.25, A.8.26, A.8.28), access control (A.8.1-A.8.13), cryptography (A.8.23-A.8.24), and vendor management (A.8.31-A.8.34).

A.8.1 - User Endpoint Devices

Control ID	A.8.1
Control Name	User endpoint devices
Control Statement	Devices used by users shall be managed to reduce the risks to the confidentiality, integrity and availability of information.
Applicability to CleanStart	Low — CleanStart does not directly manage user devices
CleanStart Evidence	• CleanStart client libraries support secure credential handling (no credential embedding) • API keys managed securely (not stored in images) • Cosign verification can run on user devices (CLI tool) • Documentation on secure credential practices
Evidence	1. CleanStart security guidelines for credential management 2. API key best practices documentation 3. Cosign installation guide (for client-side verification) 4. Examples of secure credential handling (environment variables, Secret Manager)
Customer Responsibility	Implement device management policies (MDM); ensure developer devices have endpoint protection; enforce secure credential storage; audit API key usage on devices
Maturity Level	Design (CleanStart supports but does not enforce)

A.8.2 - Privileged Access Rights

Control ID	A.8.2
Control Name	Privileged access rights
Control Statement	The allocation and use of privileged access rights shall be restricted and managed.
Applicability to CleanStart	Very High — Registry access control is critical
CleanStart Mapping	• API Authentication & Authorization: - API keys required for all administrative operations - Scoped tokens: read-only, write (push), admin - Role-based access control (Viewer, Developer, Admin) • Privilege Levels: - Viewer: read images and metadata - Developer: push images, update metadata - Admin: manage keys, revoke images, configure registry • Least Privilege Enforcement: - Service accounts created with minimal required permissions - Human accounts never used directly; automation via service accounts - Separation of duties: build automation ≠ push authorization • Privilege Escalation Prevention: - No privilege escalation within API (cannot elevate token scope) - Approval workflow for admin actions (if applicable) • Privileged Action Logging: - All privileged actions (push, delete, revoke) logged with user ID and timestamp - Failed authorization attempts logged - Admin action audit trail maintained
Evidence	1. API role definitions and permission matrix 2. Service account audit log (creation, deletion, permission changes) 3. Privileged action logs (push, delete, revoke; 30 days) 4. Failed authorization attempt logs (sample) 5. Service account assignment documentation 6. Token scope examples
Customer Responsibility	Implement least privilege in your own systems; restrict API key distribution; audit privileged access to CleanStart registry; implement MFA for admin-level access; rotate API keys regularly
Maturity Level	Operational (RBAC implemented; audit logging in place)

A.8.3 - Access Control for Information Systems

Control ID	A.8.3
Control Name	Access control for information systems
Control Statement	User access to information and information systems shall be granted based on a clearly defined and documented access control policy.
Applicability to CleanStart	Very High — Foundational access control
CleanStart Mapping	• Access Control Policy: - Documented roles: Viewer, Developer, Admin - Access based on job function and minimum necessary privileges - Dual control for sensitive operations (image retraction, key management) • Access Request Process: - Users request access via formal process - Manager approval required - Access provisioned with audit - Access removed when role changes (deprovisioning) • Access Rights Review: - Quarterly review of active users - Unused access revoked - Role changes documented - Automated access removal for terminated employees • Special Access: - Break-glass procedures for emergency access (documented, audited) - Temporary access tokens for CI/CD (time-limited, scoped) - API key rotation (90-day cycle)
Evidence	1. Access control policy documentation 2. Access request template and approval workflows 3. User access audit logs (current active users, roles) 4. Access review results (quarterly) 5. API key rotation schedule and completion logs 6. Deprovisioning logs (users removed) 7. Break-glass access documentation (if applicable) 8. Service account creation requests with approval
Customer Responsibility	Request CleanStart access through formal process; approve access for your team; conduct quarterly access reviews; enforce API key rotation; revoke access when team members leave
Maturity Level	Operational (access control policy implemented; periodic reviews conducted)

A.8.4 - Access Control for Special Privileged Functions

Control ID	A.8.4
Control Name	Access control for special privileged functions
Control Statement	Access to special privileged functions shall be controlled and managed.
Applicability to CleanStart	High — Image retraction, key management, registry configuration
CleanStart Mapping	• Privileged Functions: - Image push/publish (requires write token) - Image retraction/deprecation (requires admin token) - Signature revocation (requires key access) - Registry configuration (requires admin token) - User/key management (requires admin token) • Dual Control (if implemented): - Require multiple approvals for image retraction - Image push requires build automation + approval - Require 2 admins to revoke signing key • Audit of Privileged Actions: - All privileged function execution logged - User identity, timestamp, parameters recorded - Approval workflow captured • Documentation: - Procedures for each privileged function - Escalation path for sensitive operations
Evidence	1. Privileged function procedures documentation 2. Approval workflow for image retraction (if dual control implemented) 3. Audit logs for privileged actions (push, retract, revoke; 30 days) 4. Evidence of dual control (if implemented) 5. Escalation procedures documentation
Customer Responsibility	Implement dual control for critical image operations in your deployment; audit CleanStart privileged function logs; integrate into your own privileged access management
Maturity Level	Operational (single control implemented; dual control optional)

A.8.5 - Access Control for Authentication Information

Control ID	A.8.5
Control Name	Access control for authentication information
Control Statement	Access to authentication information shall be restricted and managed.
Applicability to CleanStart	Very High — API key and Cosign key management
CleanStart Mapping	• API Key Management: - Keys generated on-demand (no pre-generated keys) - Keys stored in secure location (Secret Manager, HSM) - Keys not displayed in logs or error messages - Key rotation enforced (90-day expiration) - Compromised keys can be revoked immediately • Cosign Key Management: - Signing keys stored in HSM or KMS (never on disk) - Private key never exported - Access restricted to build automation service account - Key audit logging (who accessed when) - Key rotation schedule documented • Secret Handling: - Build logs exclude secrets (environment variables masked) - API keys never embedded in images - Temporary tokens with short expiration - Revocation possible immediately • Credential Distribution: - Credentials never sent via email or chat - Self-service portal for API key generation - Just-in-time credential delivery - Access-controlled credential retrieval
Evidence	1. API key management policy (generation, rotation, revocation) 2. Cosign key storage configuration (HSM or KMS) 3. Key access audit logs (last 30 days) 4. API key rotation schedule and completion 5. Build log samples (verify secrets masked) 6. Key compromise response procedure 7. Token expiration configuration 8. Secret management tool documentation (e.g., Secret Manager integration)
Customer Responsibility	Never commit API keys to Git; use Secret Manager; rotate keys regularly; implement key compromise procedures; audit key usage; educate team on credential security
Maturity Level	Operational (keys secured in external systems; rotation automated)

A.8.8 - Management of Technical Vulnerabilities

Control ID	A.8.8
Control Name	Management of technical vulnerabilities
Control Statement	Information about technical vulnerabilities of information systems shall be obtained in a timely manner, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken to address the associated risk.
Applicability to CleanStart	Very High — Core function of vulnerability management
CleanStart Mapping	• Vulnerability Information Sources: - National Vulnerability Database (NVD) - GitHub Security Advisories (GHSA) - Open Source Vulnerabilities (OSV) - Package-specific advisories (npm, PyPI, Go, Rust, Java) - Real-time threat intelligence feeds • Vulnerability Detection: - Automated scanning at image build time (before push) - Continuous rescanning daily (detect new vulnerabilities) - Dependency scanning (transitive vulnerabilities) - Base image vulnerability tracking • Vulnerability Assessment: - CVSS 3.1 scoring for each vulnerability - EPSS scoring (exploit probability) - VEX assessment (exploitability in context) - Risk prioritization (critical > high > medium > low) • Remediation: - Critical: remediation within 24-48 hours - High: remediation within 1 week - Medium: remediation within 2 weeks - Low: remediation as part of regular updates - Automated dependency updates via Dependabot - Rebuild images with patched dependencies • Remediation Verification: - All remediated images re-scanned to confirm - Test suite run on patched images - Release notes document vulnerability fixes • Vulnerability Tracking: - Dashboard showing vulnerability status (by image, by severity) - Historical trends (improving/degrading) - Vulnerability response metrics (MTTR) - Communication to customers (advisories) • Exception Management: - Documented exceptions for unpatched vulnerabilities (if any) - Compensating controls documented - Risk acceptance signed off by leadership
Evidence	1. Vulnerability management procedure documentation 2. Vulnerability scanning configuration and results (last 30 days) 3. CVSS/EPSS scoring examples 4. Vulnerability dashboard screenshots 5. Remediation timeline evidence (vulnerability discovered → patched) 6. Security advisory examples (customer notifications) 7. Dependabot activity logs (dependency update history) 8. Exception register (documented unpatched vulnerabilities, if any) 9. Vulnerability metrics (MTTR, backlog size) 10. Release notes highlighting security fixes
Customer Responsibility	Monitor CleanStart security advisories; update to patched versions promptly; implement vulnerability scanning in your own deployments; audit usage of vulnerable images; maintain vulnerability inventory
Maturity Level	Optimized (continuous scanning, automated remediation, real-time risk assessment)

A.8.9 - Configuration Management

Control ID	A.8.9
Control Name	Configuration management
Control Statement	Information system configurations (including software, firmware and hardware) shall be managed to maintain security.
Applicability to CleanStart	Very High — Configuration as code for infrastructure and builds
CleanStart Mapping	• Build Configuration Management: - Dockerfile version control (Git) - Build scripts versioned and reviewed - Base image versions pinned (no floating tags) - Dependency versions pinned (go.mod, requirements.txt, etc.) - Build parameters documented and audited • Infrastructure Configuration Management: - All infrastructure via Infrastructure-as-Code (Terraform) - No manual configuration; all via automation - Configuration versioned in Git - Changes require code review and approval - Drift detection (verify actual config matches code) • Image Configuration: - Hardening configuration documented (shell-less, read-only root, UID 65532) - No mutable configuration; all immutable images - Configuration change tracking (base image updates, library updates) • Configuration Baseline: - Documented standard configurations - Deviations tracked and approved - Regular baseline reviews - Golden image concept (reference images for each ecosystem) • Configuration Version Control: - All configs in Git - Change history available (who changed what, when, why) - Rollback capability (revert to previous configuration) - Tags for releases • Configuration Monitoring: - Automated testing of configurations - Configuration compliance checks (do actual configs match documented?) - Alerts for unexpected configuration changes
Evidence	1. Dockerfile version control (Git history, branches) 2. Terraform configuration files (version control history) 3. Build configuration examples (Dockerfile + go.mod/requirements.txt) 4. Configuration change approval logs (30 days) 5. Golden image documentation (reference configurations) 6. Configuration baseline documentation 7. Drift detection results (if implemented) 8. Version tags for releases 9. Build parameter audit logs
Customer Responsibility	Use versioned images (avoid floating tags); track configuration changes in your deployments; audit configuration of CleanStart images in production; implement configuration management in your own systems
Maturity Level	Optimized (all configuration in code, version-controlled, automated)

A.8.12 - Access Control to Cryptographic Keys

Control ID	A.8.12
Control Name	Access control to cryptographic keys
Control Statement	Access to cryptographic keys shall be managed and controlled.
Applicability to CleanStart	Very High — Cosign key management is critical
CleanStart Mapping	• Key Generation & Storage: - Cosign keys generated in HSM or KMS - Private keys never leave secure storage - Public keys distributed securely - Key backup/recovery procedures documented • Key Access Control: - Access restricted to build automation (service account) - Multi-factor approval for key operations - Just-in-time access with time limits - Key audit logging (who accessed when) • Key Lifecycle: - Key generation: documented process - Key rotation: 1-year cycle (or per security policy) - Key retirement: secure destruction process - Key compromise: immediate revocation • Key Material Protection: - Encryption at rest (HSM storage) - Encryption in transit (TLS) - No key material in logs or error messages - Cryptographic module certification (FIPS 140-3 compatible) • Key Management System: - Google Cloud KMS or Cloud HSM - Audit logs of key operations - Key version management - Automatic key rotation (optional) • Backup & Recovery: - Keys backed up securely - Recovery tested regularly - Recovery restricted to authorized personnel - Audit trail of recoveries
Evidence	1. Key generation procedure documentation 2. KMS/HSM configuration (storage location, encryption) 3. Key access policy (who can use key) 4. Key audit logs (operations performed, access attempts) 5. Key rotation schedule and evidence 6. Key compromise response procedure 7. FIPS 140-3 certification (if applicable) 8. Backup/recovery testing results 9. Public key distribution mechanism 10. Key version history
Customer Responsibility	Verify key management procedures; audit key usage; implement key compromise procedures in your organization; use signature verification in your deployments
Maturity Level	Optimized (keys in HSM, rotation automated, audit comprehensive)

A.8.23 - Cryptography — Encryption

Control ID	A.8.23
Control Name	Cryptography — Encryption
Control Statement	Cryptographic controls shall be implemented to protect information against unauthorized access.
Applicability to CleanStart	Very High — Encryption throughout data lifecycle
CleanStart Mapping	• Encryption in Transit: - HTTPS (TLS 1.2+) for all API endpoints - No HTTP fallback; automatic redirection to HTTPS - Certificate validation enforced - Perfect forward secrecy (PFS) supported - Strong cipher suites (AEAD, ECDHE) • Encryption at Rest: - Google-managed keys (default) - Customer-managed keys (CMEK) via Cloud KMS - Image storage encrypted in GCS - Build logs encrypted - SBOM/metadata encrypted • Image Signing & Verification: - Cosign signatures (cryptographic proof of authenticity) - RSA-4096 or ECDSA keys - Digest-based image references (immutable) - Signature verification at pull time (recommended) - Revocation capability (compromised image keys) • Artifact Encryption: - SBOM signatures (authenticity)<br/> - SLSA provenance signatures - VEX document signatures - Time-based attestations (prevent replay) • Cryptographic Standards: - FIPS 140-3 compatible cryptography - SHA-256 hashing standard - NIST-approved algorithms - Key lengths: RSA-4096 (or ECDSA P-256+) - No deprecated crypto (MD5, SHA-1, DES) • Key Escrow & Recovery: - Key backup and recovery procedures - Secure key storage (HSM recommended) - Audit trail of key operations
Evidence	1. TLS certificate configuration (version, cipher suites) 2. HTTPS enforcement (redirect logs) 3. GCS bucket encryption configuration (Google-managed or CMEK) 4. Cosign key specifications (algorithm, size) 5. Image signature verification examples 6. Signature revocation procedure 7. FIPS 140-3 certification documentation (if applicable) 8. Cryptographic algorithm inventory 9. Key escrow and recovery procedures 10. Certificate management and rotation schedule
Customer Responsibility	Verify image signatures before deployment; use HTTPS to CleanStart registry; encrypt CleanStart API credentials; implement TLS enforcement in your own systems; audit encryption configurations
Maturity Level	Optimized (strong encryption throughout, standards-compliant, key management automated)

A.8.24 - Cryptography — Key Management

Control ID	A.8.24
Control Name	Cryptography — Key Management
Control Statement	Cryptographic key lifecycle shall be managed.
Applicability to CleanStart	Very High — Comprehensive key management
CleanStart Mapping	• Key Generation: - Keys generated using approved algorithms (NIST-approved) - Strong entropy source (TPM, HSM random number generator) - Generation documented and logged - Key material protected at generation • Key Distribution: - Secure key distribution (out-of-band for critical keys) - Public keys distributed via signed channels - Key binding verification - Key ownership established • Key Storage: - Keys stored in secure container (HSM, KMS) - Dual control (two individuals required for access) - Regular integrity verification - Secure backup storage (if applicable) • Key Usage: - Keys used only for intended purpose - Usage audit trail maintained - Anomalous usage detected and alerted - Rate limiting on key operations • Key Rotation: - Planned rotation schedule (1-year cycle) - Automated rotation (if supported) - Rotation testing - Historical key versions retained (for verification of old signatures) • Key Deactivation & Destruction: - End-of-life procedure documented - Secure destruction (cryptographic erasure) - Destruction logged and verified - Certificate of destruction (if HSM provided) • Key Recovery & Revocation: - Emergency recovery procedures - Compromise detection and immediate revocation - Revocation communication (to users) - New keys generated post-compromise
Evidence	1. Key generation procedure documentation 2. Key generation audit logs 3. Key distribution records 4. Key storage specifications (HSM, KMS) 5. Key usage audit logs (frequency, success/failure) 6. Key rotation schedule and completion logs 7. Historical key versions (retention policy) 8. Key deactivation procedure 9. Key compromise response procedure 10. Dual control records (if applicable) 11. Entropy source documentation
Customer Responsibility	Implement key rotation in your own systems; audit key usage; maintain key compromise procedures; verify key authenticity before trusting keys
Maturity Level	Optimized (comprehensive lifecycle management, HSM-backed, automated rotation)

A.8.25 - Secure Development Policy and Procedures

Control ID	A.8.25
Control Name	Secure development policy and procedures
Control Statement	Rules for the development of software and systems shall be established and applied.
Applicability to CleanStart	Very High — Core to CleanStart's mission
CleanStart Mapping	Secure Development Lifecycle (SDL): • Design Phase: - Security architecture reviews - Threat modeling for new features - Security requirements defined - Risk assessment performed • Development Phase: - Secure coding guidelines - Code review mandatory (2+ approvals) - SAST (Static Application Security Testing) integration - Dependency scanning for known CVEs - No hardcoded credentials or secrets • Build Phase: - SLSA Level 4 reproducible builds - Build environment isolated and ephemeral - Build steps logged (In-Toto metadata) - Build artifacts checksummed - Supply chain provenance captured • Test Phase: - Unit tests (code functionality) - Security-specific tests (authentication, encryption, input validation) - Integration tests (component interaction) - Penetration testing (if applicable) - 78-test inspection suite - Code coverage requirements enforced • Release Phase: - Security sign-off required - SBOMs generated (SPDX, CycloneDX) - Cryptographic signatures applied (Cosign) - Provenance attestations created - Release notes with security updates - Vulnerability disclosure process • Maintenance Phase: - Vulnerability monitoring (continuous scanning) - Security patches released promptly (SLA-based) - Dependency updates (Dependabot) - End-of-life communication - Deprecation notices • Documentation: - Secure development policy published - Build process documented - Security requirements specification - Architecture documentation - API security documentation - Threat model documentation
Evidence	1. Secure development policy documentation 2. SAST tool configuration and results (last 10 builds) 3. Code review records (PR approvals) 4. SLSA provenance attestations (5+ builds) 5. In-Toto metadata samples 6. Build environment documentation (isolation, ephemeral nature) 7. Test suite results (unit, integration, security tests) 8. Code coverage metrics 9. SBOM samples (SPDX and CycloneDX) 10. Threat model examples 11. Architecture review records 12. Security sign-off logs (before release) 13. Dependency update logs (Dependabot activity) 14. Vulnerability remediation records
Customer Responsibility	Use CleanStart images built via secure SDL; verify SBOMs and provenance before deploying; implement similar SDL in your own development; audit supplier SDL compliance
Maturity Level	Optimized (comprehensive SDL, automated checks, continuous monitoring)

A.8.26 - Application Security Requirements

Control ID	A.8.26
Control Name	Application security requirements
Control Statement	Information security requirements shall be defined and agreed with the owner(s) of the system and considered during the entire lifecycle of the system development.
Applicability to CleanStart	Very High — Security requirements drive all development
CleanStart Mapping	• Security Requirements Definition: - Supply chain integrity: Source code verification, build integrity, artifact authentication - Cryptographic controls: Image signing, SBOM signatures, encryption - Access control: Registry authentication, RBAC, privilege isolation - Vulnerability management: Scanning, remediation SLAs - Audit logging: Complete traceability, forensic capability - Configuration management: Immutable images, version control - Availability: Redundancy, auto-scaling, disaster recovery • Requirements Specification: - Functional requirements: What the system does - Security requirements: How the system protects information - Compliance requirements: Regulatory/standard conformance - Performance requirements: Response time, throughput - Availability requirements: SLA targets • Requirements Validation: - Each requirement traced to design (design specs) - Design requirements traced to implementation (code) - Implementation traced to test cases - Test results demonstrate requirement satisfaction • Requirements Traceability: - Requirement ID → Design ID → Code ID → Test ID - Traceability matrix maintained - Gaps identified and resolved - Coverage metrics tracked • Security Requirement Evolution: - Requirements updated as threats evolve - New vulnerabilities inform requirement updates - Standards updates incorporated - Customer feedback drives requirements
Evidence	1. Security requirements specification document 2. Functional specification with security requirements 3. Design documents tracing to requirements 4. Code traceability (comments linking to requirements) 5. Test cases tracing to security requirements 6. Test results demonstrating requirement satisfaction 7. Traceability matrix 8. Requirements management tool exports (if used) 9. Change logs for security requirements 10. Customer/stakeholder approval of requirements
Customer Responsibility	Define your organization's security requirements for image usage; verify CleanStart meets your requirements; document requirements in your ISMS
Maturity Level	Operational (requirements defined, traced to implementation, validated)

A.8.28 - Secure Coding

Control ID	A.8.28
Control Name	Secure coding
Control Statement	Secure coding principles shall be applied in the development of software.
Applicability to CleanStart	Very High — Fundamental to secure development
CleanStart Mapping	• Secure Coding Standards: - OWASP Top 10 principles applied - CWE (Common Weakness Enumeration) awareness - CERT Secure Coding Standards followed - Language-specific secure coding guidelines • Code Review for Security: - Security-focused code review (peer review) - Review checklist: input validation, authentication, encryption, error handling - CODEOWNERS require security expertise - Security team involved in critical PRs • Static Analysis: - SAST tools integrated in CI/CD pipeline - Automated scanning on every commit - Issues classified by severity - Blocking issues prevent merge - Security dashboard tracks SAST findings • Common Vulnerabilities Addressed: - SQL Injection: Parameterized queries - XSS: Input validation, output encoding - CSRF: Anti-CSRF tokens - Authentication: Secure credential handling - Authorization: Principle of least privilege - Cryptography: Approved algorithms, key management - Logging: No sensitive data in logs - Error Handling: Fail securely - Dependencies: Version pinning, vulnerability scanning • Code Quality: - Code coverage targets (e.g., 80%+) - Linting and formatting standards - Refactoring for maintainability - Technical debt tracking • Documentation: - Security-relevant code comments - Threat models in code (threat annotations) - Security decision documentation - API security documentation
Evidence	1. Secure coding guidelines documentation 2. SAST tool configuration and integration 3. Code review checklist (security items) 4. Sample PRs with security feedback 5. SAST findings dashboard (trends) 6. SAST tool reports (last 30 days) 7. Security findings and remediation records 8. Code coverage metrics 9. Linting and formatting standards 10. Security decision documentation 11. CWE awareness training records 12. OWASP Top 10 documentation
Customer Responsibility	Apply secure coding principles in your own development; use CleanStart images as examples of secure development; implement SAST in your pipeline; educate developers on secure coding
Maturity Level	Operational (secure coding standards applied; SAST integrated; peer review)

A.8.31 - Separation of Development, Test and Production Environments

Control ID	A.8.31
Control Name	Separation of development, test and production environments
Control Statement	Development, testing and production environments shall be separated to reduce the risks of unauthorized access or changes to the production environment.
Applicability to CleanStart	High — Infrastructure isolation
CleanStart Mapping	• Environment Separation: - GCP projects for each environment (Dev, Test, Prod) - Separate registries (or namespace isolation) - Separate databases and caches - Network isolation (VPCs, firewall rules) - IAM isolation (different service accounts) • Access Control per Environment: - Different API keys for each environment - Elevated privileges required for production - Audit logging per environment - Approval workflow for production changes • Configuration Management: - Environment-specific configs (Dev has verbose logging, Prod has minimal logging) - Secrets management per environment - Endpoint URLs different per environment • Testing in Non-Prod: - All tests run in Dev/Test environments - Integration tests before production promotion - Performance testing in test environment - Security testing in test environment - Staging environment mirrors production (for final validation) • Promotion Process: - Code changes tested in non-prod first - Production deployment requires approval - Rollback plan documented - Change window defined (if applicable) - Communication plan (status page, customer notification)
Evidence	1. GCP project structure (Dev, Test, Prod separate) 2. Network topology diagram (environment isolation) 3. IAM policy differences per environment 4. Registry isolation (separate or namespace-based) 5. API key audit logs (per environment) 6. Production change approval records 7. Test results before production deployment 8. Staging environment documentation 9. Rollback procedure documentation
Customer Responsibility	Implement environment separation in your own deployments; test image updates in non-prod first; implement change controls for production
Maturity Level	Operational (environments separated, access controlled, testing in non-prod)

A.8.32 - Change Management

Control ID	A.8.32
Control Name	Change management
Control Statement	Changes to systems and associated information shall be subject to change control.
Applicability to CleanStart	Very High — Foundational control
CleanStart Mapping	• Change Control Process: - All changes via formal request (GitHub PR, change ticket) - Change description, impact analysis, testing plan - Peer review and approval (code review) - Security review for security-related changes - Automated testing in CI/CD • Change Types: - Configuration changes (base image, dependency versions) - Code changes (feature, bugfix, refactoring) - Infrastructure changes (Terraform) - Dependency updates (Dependabot) - Security patches (immediate escalation) • Change Categories: - Standard changes: routine updates (pre-approved template) - Emergency changes: security patches (expedited approval) - High-risk changes: major refactoring (enhanced review) • Testing Requirements: - Unit tests must pass - Integration tests must pass - Security tests must pass - Code review approval required - Optional: staging deployment before production • Change Documentation: - Change request captured (GitHub PR) - Approval recorded - Test results attached - Deployment executed (Git commit history)<br/> - Rollback plan documented • Change Communication: - Release notes published - Security advisories (if applicable) - Status page updated (during deployment) - Stakeholders notified • Change Tracking & Audit: - Complete audit trail (who, what, when, why) - Build logs capture change deployment - Image tags link to change request - Release notes link to changes • Change Rollback: - Rollback procedure documented - Previous image versions retained - Automatic rollback (if health checks fail) - Manual rollback capability
Evidence	1. Change management policy documentation 2. Change request template (GitHub PR) 3. Change approval records (60+ days) 4. Test results for changes 5. Code review records 6. Release notes (last 5 releases) 7. Security advisory examples (if applicable) 8. Build/deployment logs (showing change promotion) 9. Image tagging scheme (links changes) 10. Rollback examples (if any) 11. Emergency change procedures (security patches) 12. Change communication examples (release notes, advisories)
Customer Responsibility	Implement change management in your deployments; test image updates before production; document and approve image updates in your organization
Maturity Level	Optimized (fully automated CI/CD, approval workflows, rollback capability)

A.8.33 - Information and Technology Security Testing

Control ID	A.8.33
Control Name	Information and technology security testing
Control Statement	Security effectiveness shall be tested and evaluated.
Applicability to CleanStart	Very High — Comprehensive testing program
CleanStart Mapping	• Testing Types: - Unit Testing: code-level security logic - Integration Testing: component interaction security - Security Testing: authentication, authorization, encryption - Vulnerability Scanning: SCA, SAST, image scanning - Penetration Testing: simulated attacks (if conducted) - Regression Testing: ensure fixes don't break functionality - Load Testing: availability under stress - Disaster Recovery Testing: failover and recovery • Test Coverage: - 78-test inspection suite (comprehensive) - All new code requires security tests - Test cases trace to security requirements - Test results documented - Code coverage metrics tracked (target: 80%+) • Vulnerability Assessment: - Continuous SAST (every commit) - Continuous SCA (dependency scanning) - Image vulnerability scanning (before push) - Rescanning (daily, to detect new CVEs) - Remediation tracking - Metrics: vulnerability count, MTTR • Testing Automation: - CI/CD pipeline enforces testing - Blocking issues prevent merge - Automated reporting and dashboards - Test result history • Testing Documentation: - Test plan documented - Test cases (what, how, expected result) - Test results recorded - Issues tracked and remediated • Third-Party Testing: - External security audits (if conducted) - Penetration testing (if conducted) - Vulnerability disclosure program - Bug bounty program (if applicable)
Evidence	1. Test plan and testing strategy documentation 2. Test case examples (security-focused) 3. Test results history (last 30 days) 4. Code coverage metrics 5. Vulnerability scanning results 6. SAST findings and remediation 7. SCA findings and dependency updates 8. 78-test suite documentation and results 9. Penetration testing results (if conducted) 10. Security audit reports (if conducted) 11. Vulnerability disclosure policy 12. Bug bounty program (if applicable) 13. Test automation scripts
Customer Responsibility	Test CleanStart images in your environment; implement security testing in your CI/CD; audit image security before deployment; conduct penetration testing of your applications
Maturity Level	Optimized (automated testing, comprehensive coverage, continuous scanning)

A.8.34 - Protection of Information Systems from Malware

Control ID	A.8.34
Control Name	Protection of information systems from malware
Control Statement	Information systems shall be protected against malware.
Applicability to CleanStart	High — Image security and supply chain integrity
CleanStart Mapping	• Malware Detection: - Image scanning for known malware signatures - Container escape detection (behavioral analysis) - Dependency scanning (detect vulnerable libraries used by malware) - Binary analysis (suspicious executables) • Supply Chain Malware Prevention: - Source code scanning (SAST detects code that could enable malware) - Dependency verification (trusted sources only) - Build isolation (ephemeral, no persistence) - Build artifact verification (checksums, signatures) • Runtime Protection: - Falco/eBPF monitoring (detects suspicious behavior) - Process whitelisting (known processes only) - File integrity monitoring (detect changes) - Network monitoring (unusual outbound connections) • Image Hardening: - Shell-less images (no /bin/sh to execute commands) - Read-only root filesystem (no persistence) - Non-root user (UID 65532; less privilege) - Minimal base images (fewer components, fewer vulnerabilities) • Vulnerability Prevention: - Vulnerability scanning (no known CVEs) - Dependency auditing (trusted dependencies) - Automatic patching (Dependabot, image rebuilds) • Incident Response: - Malware detection triggers alert - Incident investigation procedure - Affected images retracted/revoked - Customer notification - Root cause analysis • Documentation: - Malware detection policy - Incident response procedures - Tools and techniques used - Lessons learned
Evidence	1. Malware scanning tool integration (configuration, results) 2. Image scanning results (sample images) 3. Shell-less image examples (verify no /bin/sh) 4. Falco/eBPF monitoring configuration (rules, alerts) 5. Dependency verification process 6. Build isolation documentation 7. Incident response examples (if any malware detected) 8. Malware detection policy 9. Tools and techniques documentation 10. Lessons learned from incidents
Customer Responsibility	Use only CleanStart images from trusted registry; verify image signatures; implement runtime monitoring in your deployments; educate teams about malware risks
Maturity Level	Operational (multiple detection layers, hardened images, incident response)

A.8.35 & A.8.36: Supplier Relationships & Supplier Security (Critical for B2B)

A.8.35 - Information Security for Supplier Relationships

Control ID	A.8.35
Control Name	Information security for supplier relationships
Control Statement	Information security requirements shall be addressed in agreements with suppliers.
Applicability to CleanStart	High — CleanStart IS a supplier to your organization
CleanStart Mapping	• Supplier Assessment: - CleanStart security assessment (this document) - Compliance certifications (SOC 2 Type II, ISO 27001 target) - Third-party security audit results - References and case studies • Contractual Terms: - Security requirements in SLA - Availability commitments (99.9% uptime) - Data protection commitments (encryption, RBAC) - Incident notification requirements - Audit rights (access to evidence) - Liability and insurance • Security Requirements for CleanStart: - Image integrity (signed, SBOM, provenance) - Vulnerability management (scanning, SLA) - Access control (authentication, RBAC) - Encryption (TLS, at-rest) - Audit logging (complete traceability) - Disaster recovery (backup, RTO/RPO) - Incident response (SLA, communication) • Supplier Monitoring: - Regular check-ins on security posture - Annual security assessment - Review of audit reports - Incident tracking (are security issues increasing?) - Service level monitoring (is SLA being met?) • Supplier Incident Response: - Notification of security incidents - Impact assessment - Remediation plan - Communication to affected customers
Evidence	1. CleanStart compliance documentation (this mapping) 2. SOC 2 Type II report (when available) 3. ISO 27001 certificate (when available) 4. Service Level Agreement 5. Security addendum to contracts 6. Evidence of security assessments 7. Incident history (if any) 8. Communication examples (security advisories) 9. Disaster recovery testing results 10. References and case studies
Customer Responsibility	Request CleanStart security assessment; review compliance documentation; execute security addendum to contract; monitor CleanStart security posture; include in vendor risk management program
Maturity Level	Operational (compliance documentation available, contractual terms in place)

A.8.36 - Supplier Security for ICT Supply Chain

Control ID	A.8.36
Control Name	Supplier security for ICT supply chain
Control Statement	Organization shall implement and monitor the application of security and privacy requirements in ICT supply chain relationships.
Applicability to CleanStart	High — CleanStart manages ICT supply chain (software supply chain)
CleanStart Mapping	• ICT Supply Chain Management: - Software source verification (Git signing) - Build integrity verification (SLSA, provenance) - Component traceability (SBOM) - Vulnerability tracking (CVE, EPSS) - Patch management (dependency updates) • Supplier Vetting: - CleanStart uses verified suppliers: - Base images (official Docker images, Distroless) - Package registries (npm, PyPI, Go, Rust official sources) - Vulnerability databases (NVD, GHSA, OSV) - Supplier security assessments conducted - Contractual requirements established • Supply Chain Security Controls: - Integrity verification (signatures, checksums) - Authenticity verification (GPG keys, Sigstore) - Availability monitoring (registry uptime) - Incident response (if supplier compromised) • Supply Chain Risk Management: - Dependency monitoring (new vulnerabilities) - Base image updates (security patches) - Breaking changes (API compatibility) - Lifecycle management (end-of-life notification) • Supply Chain Transparency: - SBOM lists all components and suppliers - Provenance attestation shows build origin - VEX documents vulnerability context - Audit logs show all modifications - Release notes document changes and fixes • Incident Management: - Supplier incidents monitored - Impact assessment conducted - Mitigation strategy developed - Customers notified (if needed) - Lessons learned captured
Evidence	1. Supply chain mapping (base images, dependencies, suppliers) 2. Supplier vetting results 3. Contractual agreements with suppliers 4. Dependency update history 5. Base image monitoring (updates, CVEs) 6. Vulnerability disclosure handling 7. Incident examples (if any) 8. SBOM examples (showing supply chain) 9. Provenance attestation examples 10. Supply chain risk register 11. Incident communication examples 12. Recovery plans (if supplier compromised)
Customer Responsibility	Audit CleanStart supply chain (review SBOM, provenance); monitor for security updates; subscribe to security advisories; implement supply chain security in your own deployments
Maturity Level	Operational (supply chain mapped, suppliers vetted, incidents managed)

Part 3: Statement of Applicability (SoA) Template

An SoA is a requirement for ISO 27001 certification. It documents which Annex A controls apply to your organization and how they're implemented.

Sample SoA Entry for CleanStart Usage

Control ID	Control Name	Applicable	Implementation Method	Evidence	Responsibility
A.8.8	Management of Technical Vulnerabilities	Yes	CleanStart performs vulnerability scanning on all images using NVD, GHSA, OSV databases. Organization receives advisories and updates images per remediation SLA.	Vulnerability scan results, advisory history, MTTR metrics, SBOM samples	Shared: CleanStart scans; Organization updates
A.8.25	Secure Development Policy and Procedures	Yes	CleanStart implements secure SDLC: Git signing, code review, SAST, SLSA L4 builds, 78-test suite, SBOM/provenance generation. Organization uses these controls for supply chain security.	Architecture doc, SBOM samples, provenance attestations, test results, code review records	Shared: CleanStart develops; Organization adopts
A.8.26	Application Security Requirements	Yes	Security requirements defined for image integrity, cryptography, access control, and audit logging. CleanStart addresses requirements through design and implementation.	Requirements spec, design docs, test cases, verification records	Shared: CleanStart implements; Organization verifies
A.8.28	Secure Coding	Yes	CleanStart applies secure coding standards, mandatory code review, SAST scanning, OWASP Top 10 principles.	Code review records, SAST configs/results, secure coding guidelines	Shared: CleanStart develops; Organization audits
A.8.31	Separation of Dev, Test, Prod Environments	Yes	CleanStart maintains separate GCP projects for Dev/Test/Prod with isolated registries, databases, networks, and access controls.	GCP project structure, network diagrams, IAM policies, change records	CleanStart
A.8.32	Change Management	Yes	CleanStart implements formal change control: PRs, code review approval, automated testing, release management, audit logging. Organization implements change management for image deployments.	Change approval records, release notes, deployment logs, rollback examples	Shared: CleanStart for platform; Organization for deployments
A.8.33	Information and Technology Security Testing	Yes	CleanStart conducts continuous testing: unit tests, security tests, SAST, SCA, image scanning, 78-test suite. Organization conducts security testing of applications using CleanStart images.	Test plan, test results, vulnerability scans, code coverage, audit logs	Shared: CleanStart platform; Organization apps
A.8.34	Protection from Malware	Yes	CleanStart hardens images (shell-less, read-only root, non-root UID) and scans for malware. Organization implements runtime monitoring (Falco) in deployments.	Image hardening specs, scanning configs, Falco rules, incident logs	Shared: CleanStart images; Organization runtime
A.8.35	Information Security for Supplier Relationships	Yes	CleanStart (supplier) provides security documentation and compliance evidence. Organization assesses CleanStart security and establishes contractual terms.	SoC 2 report, ISO 27001 certificate, SLA, security addendum, assessment results	Shared: CleanStart provides evidence; Organization assesses
A.8.36	Supplier Security for ICT Supply Chain	Yes	CleanStart manages supply chain: source verification, build integrity, SBOM, vulnerability tracking, patch management. Organization integrates CleanStart into supply chain risk management.	SBOM samples, provenance attestations, dependency audit logs, supply chain mapping	Shared: CleanStart manages; Organization monitors

Evidence Collection Checklist for ISO 27001 Audit

Pre-Audit Phase

[ ] Request CleanStart security documentation (this mapping) [ ] Request CleanStart SOC 2 Type II report (if available) [ ] Request CleanStart ISO 27001 certificate (if available) [ ] Review CleanStart SLA and contractual security terms [ ] Understand CleanStart architecture and controls [ ] Map CleanStart controls to your SoA

Design Phase Evidence (PDCA Plan & Do)

A.8.25 - Secure Development Policy & Procedures: [ ] CleanStart secure development policy documentation [ ] Architecture and threat modeling documents [ ] Security requirements specification [ ] Design documentation (how requirements are addressed)

A.8.26 - Application Security Requirements: [ ] Requirements traceability matrix (requirements → design → code → test) [ ] Security functional requirements examples [ ] Requirements approval records

A.8.28 - Secure Coding: [ ] Secure coding guidelines [ ] SAST tool configuration documentation [ ] Code review process documentation [ ] Sample PRs with security feedback

A.8.8 - Vulnerability Management: [ ] Vulnerability management policy [ ] Vulnerability scanning tool configuration [ ] Remediation SLA documentation [ ] CVSS/EPSS scoring framework

A.8.9 - Configuration Management: [ ] Configuration management policy [ ] Dockerfile version control (Git history) [ ] Infrastructure-as-Code (Terraform) files [ ] Base image pinning documentation

A.8.12 - Cryptographic Key Management: [ ] Key management policy [ ] Cosign key generation and storage procedures [ ] HSM or KMS configuration documentation [ ] Key rotation schedule

A.8.23 - Cryptography (Encryption): [ ] Encryption policy (TLS, at-rest) [ ] TLS certificate configuration [ ] GCS bucket encryption settings [ ] Image signing and verification procedures

A.8.31 - Environment Separation: [ ] GCP project structure and separation [ ] Network topology diagrams [ ] IAM policy per environment [ ] Registry isolation documentation

A.8.32 - Change Management: [ ] Change management process documentation [ ] Change request templates [ ] Approval workflow documentation [ ] Release management procedures

A.8.33 - Security Testing: [ ] Test plan and testing strategy [ ] Test case examples (security-focused) [ ] 78-test suite documentation [ ] Test automation configuration

A.8.34 - Malware Protection: [ ] Image hardening policy [ ] Malware scanning tool configuration [ ] Falco/eBPF monitoring rules

A.8.35 & A.8.36 - Supplier Management: [ ] Supplier assessment framework [ ] CleanStart security assessment (this document) [ ] SLA and security addendum [ ] Supplier monitoring procedures

Operating Effectiveness Evidence (PDCA Check & Act)

Operational Records (Last 12 Months): [ ] Git commit logs (source code changes, reviews, approvals) [ ] Build logs (Cloud Build) - 10+ recent builds [ ] Vulnerability scan results - monthly trending [ ] Security advisory communications - 3+ recent advisories [ ] Image release notes - last 5 releases with security items highlighted [ ] Change approval records - 20+ recent changes [ ] Deployment logs - evidence of testing before production [ ] Incident logs - if any security incidents occurred [ ] Audit logs - authentication, API calls, administrative actions [ ] SBOM samples - 5+ images with complete SBOMs [ ] SLSA provenance samples - 5+ builds with provenance [ ] Image signature verification - examples of successful verification [ ] Key rotation evidence - Cosign key rotation history [ ] Access review results - quarterly reviews documenting active users [ ] Monitoring dashboard screenshots - vulnerability trends, metrics

Test Results (Demonstrate Operating Effectiveness): [ ] Test attempts to push unsigned image (should fail) [ ] Test verification of image signature (should succeed) [ ] Test SBOM completeness (component count matches build) [ ] Test image hardening (pull image, verify no shell, verify read-only root, verify non-root UID) [ ] Test Falco/eBPF alerts (generate sample alert, verify response) [ ] Test admission control (attempt to deploy unsigned image; should be blocked) [ ] Test access control (unauthorized user cannot push image) [ ] Test API rate limiting (exceed limit; should get 429 response) [ ] Test disaster recovery (restore from backup, verify image accessibility)

ISO 27001 Certification Readiness Checklist

[ ] Risk Assessment: Completed assessment of CleanStart usage in your organization [ ] Asset Inventory: Added CleanStart images and related assets to RACI/asset register [ ] Control Mapping: Mapped applicable Annex A controls to CleanStart [ ] Statement of Applicability: Draft SoA including CleanStart controls [ ] Evidence Collection: Gathered evidence of CleanStart control operation (last 12 months) [ ] Gap Analysis: Identified gaps between current state and required controls [ ] Remediation: Addressed gaps (policies, procedures, system changes) [ ] Testing: Conducted tests demonstrating control operating effectiveness [ ] Documentation: Updated security policies, procedures, and records [ ] Training: Team training on CleanStart security procedures and controls [ ] Monitoring: Established ongoing monitoring of CleanStart controls (dashboards, alerts) [ ] Supplier Assessment: Assessed CleanStart as supplier; documented in vendor risk management [ ] Contractual Terms: Established SLA and security addendum with CleanStart [ ] Audit Preparation: Reviewed readiness with auditors (pre-audit call) [ ] Final Assessment: External auditor certifies ISMS includes effective CleanStart controls

Glossary

Term	Definition
ISMS	Information Security Management System — organization's approach to managing information security
SoA	Statement of Applicability — document listing which controls apply and why
PDCA	Plan-Do-Check-Act — continuous improvement cycle (Plan = design; Do = implement; Check = monitor; Act = improve)
Risk Assessment	Process of identifying security risks and evaluating likelihood/impact
Control	Safeguard or countermeasure to reduce risk
Annex A	ISO 27001:2022 appendix containing 93 specific controls
Auditor	External party who verifies ISMS compliance
Non-Conformity	Finding where control is not implemented or operating effectively
Observation	Finding where control could be improved
Certification	Third-party confirmation that ISMS meets ISO 27001 standard (valid 3 years)
Audit Evidence	Documentation proving control design and operation
Design Testing	Auditor verifies control design is sound (initial audit)
Operating Effectiveness Testing	Auditor verifies control operates as designed (annual audit)
Management System	Integrated processes and procedures across organization
Context	External and internal factors relevant to organization
Scope	What systems/processes/assets are included in ISMS
Monitoring	Ongoing checks to verify controls are working
Metrics	Quantitative measures of control performance (e.g., MTTR)

Appendix: CleanStart Features Cross-Reference

Feature	Primary Controls Addressed	Benefit to ISMS
Git Commit Signing	A.8.25, A.8.26, A.8.28	Verifies source code authenticity
Mandatory Code Review	A.8.25, A.8.26, A.8.28	Reduces development defects
SAST Integration	A.8.25, A.8.28, A.8.33	Detects code vulnerabilities early
SLSA Level 4 Builds	A.8.25, A.8.9, A.8.32	Ensures build integrity
SBOM Generation	A.5.9, A.8.8, A.8.36	Provides supply chain visibility
Vulnerability Scanning	A.8.8, A.8.33, A.8.34	Detects vulnerable dependencies
Image Hardening	A.8.34, A.8.7	Reduces attack surface
Cosign Signatures	A.8.23, A.8.24, A.8.35	Authenticates images
78-Test Suite	A.8.33	Validates security properties
Falco/eBPF Monitoring	A.8.34	Runtime anomaly detection
Kyverno/OPA Admission Control	A.8.2, A.8.4	Enforces image policies
CleanSight (Optional)	A.8.8, A.5.9	Detects outdated images
Incident Response	A.4.1, A.4.2	Rapid response to security events

Final Certification Roadmap

Phase	Duration	ISO 27001 Activities	CleanStart Role
Scoping	2-4 weeks	Define ISMS scope, identify applicable controls	Document controls used
Planning	4-8 weeks	Develop ISMS policy, SoA, risk assessment	Provide security documentation
Implementation	2-4 months	Deploy controls, update policies, train personnel	Already implemented for CleanStart
Monitoring (Design Testing)	2-3 months	Document evidence of control design	Auditor reviews this mapping
Monitoring (Operating Effectiveness)	6-9 months	Collect operational evidence, conduct testing	Provide operational records
Audit (Initial)	3-5 weeks	External auditor assesses compliance	Demonstrate control operation
Certification	2-4 weeks	Auditor issues ISO 27001 certificate	Controls certified as compliant
Total Timeline	12-18 months

Document Approval

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

END OF ISO 27001:2022 MAPPING

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