Document Version: 1.0 For Use By: Procurement, Risk Management, Legal, Security Teams Updated: 2026-03-22 Confidentiality: Internal - Vendor Assessment Use Only

Overview

This document provides comprehensive responses to standard vendor security questionnaires (e.g., CAIQ, TISAX, Procurement Risk Assessment templates). Organizations evaluating CleanStart can use this document directly in RFP processes, procurement due diligence, and third-party risk assessments.

Structure: Organized by assessment framework (Security Questionnaire, SOC 2, ISO 27001, HIPAA BAA, Disaster Recovery, Supply Chain Security).

Section 1: Standard Security Questionnaire Responses

Data Classification and Handling

Q1.1: How do you classify customer data?

Response: CleanStart distinguishes between three data categories:

1. Container Image Data (non-sensitive) Application container images, base images, build artifacts. Treated as internal technical data; does not contain customer PII. Access controlled via repository authentication.
2. Metadata and Artifacts (sensitive) SBOMs, SLSA attestations, audit logs, build records. Cryptographically signed; immutable once created. Access restricted to authenticated users with repository credentials.
3. Customer Account Data (sensitive) API keys, authentication tokens, usage metrics, billing information. PII: Name, email, company information. Encrypted at rest (AES-256); encrypted in transit (TLS 1.3+).

Storage Locations: Images: Distributed across customer-controlled registries (ECR, GCR, ACR). Metadata: CleanStart-managed registry with encryption at rest. Account data: Customer account database (encryption at rest + encrypted backups).

Data Retention: Per customer SLA; default 7 years for audit records, 30 days for operational logs

Q1.2: How do you handle encryption of data at rest?

Response: Algorithm: AES-256-GCM (NIST approved, FIPS 140-2 compliant). Key Management: HSM-backed (AWS CloudHSM or equivalent). Key Rotation: Automatic, every 90 days. Database Encryption: Native encryption enabled (PostgreSQL pgcrypto, DynamoDB encryption). Backup Encryption: All backups encrypted with same key material. Evidence: AWS KMS certificate, key rotation logs available for audit.

Scope: Container image registries (if CleanStart-hosted). Metadata databases (SBOM, attestation records). Audit logs (system events, API access).

Q1.3: How do you encrypt data in transit?

Response: Protocol: TLS 1.3 (minimum); TLS 1.2 for legacy compatibility. Certificate Management: Managed by AWS Certificate Manager (auto-renewal). Cipher Suites: ECDHE with 256-bit keys (no weak algorithms). API Endpoints: All HTTPS; HTTP redirects to HTTPS. Registry Access: Container image pulls use TLS with certificate pinning. Attestation Distribution: Signed containers use cosign TLS with integrity verification. Evidence: TLS configuration logs, certificate audit trail.

Q1.4: Do you store customer data?

Response: Container Images: Optionally (if using CleanStart-hosted registry). Customers may mirror to their own registries to avoid external storage. Metadata: Yes (SBOM, attestations, audit logs). Stored in AWS region specified by customer at setup. Account Credentials: Yes (API keys). Never stored in plaintext; hashed and salted. Customer PII: Minimal (name, email, company). Encrypted at rest; used only for account management and billing. No sensitive application data (source code, secrets, customer secrets) is stored by CleanStart.

Data Minimization: We collect only what's necessary for service operation and compliance reporting.

Access Controls

Q2.1: How do you control administrative access?

Response: Role-Based Access Control (RBAC): Implemented at multiple layers: Repository RBAC: Pull, push, delete permissions per user/service account Infrastructure RBAC: AWS IAM roles for CleanStart operations team Database RBAC: Least-privilege database users (read-only for audits). Authentication: Multi-factor authentication (MFA) required for: Console access (WebAuthn or TOTP) SSH access (SSH key + MFA challenge) API key generation (MFA required). Authorization: Every operation logged and checked against ACL before execution. Privileged Access Management (PAM): Vault-managed secrets; just-in-time credential issuance. Audit: Every administrative action logged with actor, action, resource, timestamp.

Evidence: CloudTrail logs, Vault audit logs, IAM policy documentation

Q2.2: How do you manage API keys and credentials?

Response: Generation: API keys generated via web console or API (MFA required). Format: Cryptographically random 256-bit keys; base64 encoded. Storage: Keys hashed (bcrypt with 12 rounds) before database storage; never stored in plaintext. Rotation: Organization can rotate keys on-demand; recommended every 90 days. Expiration: Optional TTL (time-to-live) for temporary API keys; can be set to hours or minutes. Revocation: Immediate; revoked key cannot authenticate within 30 seconds. Audit Trail: Every key creation, rotation, revocation logged with actor.

Access Restrictions: Keys can be scoped to specific operations (read-only, write, delete). IP whitelist optional (restrict key to specific IP ranges). Usage quotas can be enforced (rate limiting, monthly usage cap).

Threat Response: Compromised keys can be invalidated immediately without service restart.

Q2.3: How do you prevent unauthorized access to customer data?

Response: Network Security: AWS VPC with private subnets; no direct internet exposure. Database Access: Encryption at rest + encrypted TLS connections; SQL injection prevention via parameterized queries. Container Registry: Access controlled by repository credentials; unauthorized pulls return 401/403. SBOM/Metadata Access: Only customers with valid API key can retrieve metadata. Audit Log Access: Only authorized users can query audit logs; logs are immutable (write-once). Physical Security: AWS data centers (SOC 2 certified); no direct server access.

Detection: Unauthorized access attempts logged; real-time alerting if suspicious patterns detected (e.g., multiple failed auth attempts).

Application Security

Q3.1: How do you perform vulnerability scanning and patching of your own infrastructure?

Response: Vulnerability Scanning: Container image scanning: Trivy daily; Critical/High CVEs trigger immediate response Dependency scanning: OWASP Dependency-Check in CI/CD pipeline Infrastructure scanning: AWS Inspector on EC2 instances; CloudTrail for API security Web application scanning: OWASP ZAP in CI/CD (SAST) Infrastructure-as-Code scanning: Checkov for Terraform/CloudFormation. Patching SLA: Critical CVEs: Patched within 24 hours (or service disabled) High CVEs: Patched within 7 days Medium CVEs: Patched within 30 days Low CVEs: Patched in next scheduled release (quarterly). Evidence: Patch logs, CVE tracking spreadsheet, security scan reports available for audit.

Q3.2: How do you handle secure code review and secure development?

Response: Code Review Process: All code changes require peer review (minimum 2 reviewers for critical systems) Security-critical code flagged for dedicated security review Automated tools flag security issues: CodeQL, SonarQube, Snyk. Secure Development Lifecycle (SDLC): Threat modeling for new features (STRIDE) Security requirements documented in design phase Secrets scanning in pre-commit hooks (prevent credential commits) Static analysis (SAST) on all code Dynamic testing (DAST) on web endpoints Penetration testing: Annual external, quarterly internal. Third-Party Code: Vendored dependencies tracked; SBOM maintained for all software. Evidence: GitHub code review logs, security scan reports, penetration test results.

Q3.3: How do you handle security testing (SAST, DAST, penetration testing)?

Response: SAST (Static Analysis): Tools: CodeQL, SonarQube, Snyk Source Frequency: Every commit (pre-merge) Coverage: 100% of customer-facing code False positive review: Security team reviews findings before enforcement. DAST (Dynamic Testing): Tools: OWASP ZAP, Burp Suite Frequency: Nightly on staging environment Coverage: All web endpoints, API endpoints Findings triaged within 24 hours. Penetration Testing: Frequency: Annual (external), quarterly (internal) Scope: Full application, infrastructure, APIs Third-party vendor: [Vendor name], approved by CISO Report made available to customer upon request (redacted for other customers). Fuzzing: Continuous fuzzing on API endpoints via OSS-Fuzz integration.

Incident Response

Q4.1: Do you have an incident response plan?

Response: Yes. Documented in [Internal Incident Response Plan]. Key elements:

Severity Classification: P1-P4 (critical to low). Response SLA: P1 (Critical): Incident commander appointed within 5 minutes, containment plan within 30 minutes P2 (High): Response within 2 hours P3 (Medium): Response within 4 hours P4 (Low): Response within 1 business day. Escalation Path: On-call incident commander → CISO → VP Engineering → CEO (if customer impact). Forensics: Preserve evidence chain; log all investigative steps. Communication: Customer notification within 4 hours of confirmed incident affecting customer data. Root Cause Analysis: Complete RCA within 5 business days; customer briefing within 10 days.

Evidence: [Incident response playbook document], incident log showing response times

Q4.2: What is your incident notification procedure?

Response: Detection: Automated monitoring (Datadog) detects anomalies; alert to on-call team. Assessment: On-call engineer confirms incident; determines if customer data affected. Notification Timeline: Confirmed incident (customer data): Notification email within 4 hours to primary contact + CISO Details: Incident description, timeline, data affected, remediation steps Follow-up: Additional updates every 12 hours until resolved. Communication Channel: Email (primary), phone (for P1 incidents), status page (for visibility). Documentation: Public status page (status.cleanstart.com) updated in real-time for outages. Post-Incident: Detailed incident report provided within 10 business days.

Business Continuity and Disaster Recovery

Q5.1: Do you have a Disaster Recovery plan?

Response: Yes. CleanStart maintains:

RPO (Recovery Point Objective): 1 hour (data loss tolerance) Backups taken every hour for critical databases Immutable image registry replicated to secondary region every 4 hours. RTO (Recovery Time Objective): 4 hours (time to restore service) Automated failover to secondary region if primary fails Database failover: 5-15 minutes (RDS multi-AZ) Registry failover: 30 minutes (async replication to secondary region). Testing: Quarterly disaster recovery drills (restore from backup, test all systems) Most recent test: [Date] Results: All systems recovered successfully within RTO. Geographic Redundancy: Primary (US region) + Secondary (US region, different AZ) Critical data replicated synchronously (RTO <5 min) Non-critical data replicated asynchronously (RPO ~1 hour).

Evidence: DR playbook, backup test logs, RDS failover configuration

Q5.2: How do you handle database backups?

Response: Frequency: Hourly incremental backups; daily full backups. Retention: Automated retention for 30 days; customer request for extended retention (up to 7 years for audit records). Encryption: Backups encrypted at rest (AES-256); encrypted during transport (TLS). Geographic Diversity: Backups replicated to secondary region (AWS cross-region replication). Testing: Monthly restore test from backups to verify recoverability. Versioning: All backup versions maintained; customer can request restore to specific point-in-time. Evidence: AWS RDS backup configuration, automated backup test logs.

Q5.3: What is your uptime/availability commitment?

Response: SLA: 99.95% uptime (monthly) Planned maintenance windows excluded (up to 4 hours monthly) Service credits for shortfalls: 10% credit per 0.1% below SLA. Measurement: Uptime calculated from external monitoring; reported monthly. Monitoring: 24/7 health checks from multiple regions. Incident Response: P1 incidents receive dedicated incident commander. Status Page: Public status dashboard (status.cleanstart.com) with real-time updates.

Section 2: SOC 2 Type II and ISO 27001 Compliance

SOC 2 Type II Certification

Current Status: SOC 2 Type II audit completed; report available to customers under NDA

Scope: CleanStart production infrastructure and source code management systems

Audit Period: 12 months (January - December 2025)

Trust Service Criteria Addressed: CC (Control & Change): Version control, code review, change management. OP (Operational): Backup and recovery, incident response. S (Security): Access controls, encryption, network security. C (Confidentiality): Data encryption, access restrictions. A (Availability): Uptime SLA, redundancy, failover.

Key Findings: No material weaknesses; one low-priority observation (documented remediation in progress)

Auditor: [Big 4 Firm Name], [Address]

Report Access: Available to customers under SOC 2 NDA; typically provided within 48 hours of signed agreement

ISO 27001 Certification

Current Status: ISO 27001 certification in progress; expected completion Q2 2026

Scope: Information security management system (ISMS) covering: Access control. Cryptography. Incident management. Business continuity. Supplier management.

Interim Measures: Current controls documented in internal ISMS; gap assessment completed

Section 3: Regulatory Compliance

HIPAA Business Associate Agreement (BAA)

Status: BAA available; standard form provided

Key Provisions: CleanStart acts as Business Associate (BA) per HIPAA definition. Customers are Covered Entities (CE) or other Business Associates. CleanStart commits to HIPAA Security Rule safeguards: Administrative, Physical, Technical safeguards implemented Business Associate safeguards documented Subcontractor safeguards managed via subcontract BAAs.

HIPAA Alignment: Encryption at rest (AES-256): §164.312(a)(2)(i). Encryption in transit (TLS 1.3): §164.312(a)(2)(i). Access controls: §164.312(a)(2)(i). Audit controls: §164.312(b). Integrity: §164.312(c)(1).

ePHI Handling: Container images may contain ePHI if customer application processes health data. CleanStart provides encryption and access controls but does NOT decrypt/access ePHI. Customers retain responsibility for ePHI classification and retention.

Subcontractors: AWS (IaaS), Okta (identity), DataDog (monitoring), GitHub (source control) All subcontractors have signed BAAs with CleanStart.

GDPR and Data Residency

Compliance: CleanStart is GDPR-compliant

Personal Data Handling: Minimal PII collected: Name, email, company (for account management). Legal basis: Legitimate interest (contract performance) and consent (newsletter signup). Retention: Until customer account terminated + 30-day hold, then deleted.

Data Subject Rights: Right to access: Customers can download their data via API. Right to deletion: Requested data deleted within 30 days. Right to portability: Data export in standard format (JSON). Right to object: Marketing emails can be opted out immediately.

Data Residency: Customers can select EU-based data storage (AWS EU regions) at deployment time. Once selected, data never leaves specified region without customer consent.

Evidence: Privacy policy, data processing agreement (DPA), subprocessor list

PCI DSS Compliance

Status: PCI DSS compliance not required (CleanStart does not handle payment card data)

Rationale: CleanStart does not store, process, or transmit credit card numbers. Billing handled by Stripe (PCI-DSS certified); CleanStart never sees card data. Invoice management is receipt-only; no card tokens stored.

FedRAMP Authorization

Status: In process; expected moderate baseline approval Q3 2026

Current: CleanStart runs on AWS GovCloud (for federal customers) Separate infrastructure tenant. Dedicated AWS account for FedRAMP compliance. CUI (Controlled Unclassified Information) controls implemented.

Evidence: [FedRAMP Agency Authorization Letter] available under NDA

Section 4: Third-Party Audit Results

Recent Security Audit Results

External Penetration Test (completed [Date]) Vendor: [Penetration Testing Firm]. Scope: Web application, APIs, infrastructure. Findings: No critical vulnerabilities; two medium findings (both resolved). Methodology: OWASP Top 10 testing.

Supply Chain Security Audit (completed [Date]) Vendor: [Security Firm]. Scope: Vendor dependencies, open-source software, software bill of materials. Findings: 23 transitive dependencies; all up-to-date; SBOM generated and reviewed. Remediation: Automated dependency updates via Dependabot; security scanning on all PRs.

Compliance Audit for SOC 2 (completed [Date]) Auditor: [Big 4 Firm]. Scope: Controls and operational effectiveness. Findings: No material weaknesses.

Evidence: Copies available under NDA and executed audit agreements

Section 5: Supply Chain Security Controls

Software Supply Chain Security

Commitment: CleanStart implements SLSA Level 2+ controls on its own software

Source Control: GitHub (private repositories); signed commits required. Build: Hermetic builds (no external dependencies fetched at build time); signed by build automation. Provenance: SLSA attestations on all release artifacts. Distribution: Signed container images; checksums published. Dependency Management: SBOM generated for all releases (SPDX format).

Customer Transparency: Customers can verify CleanStart's own image signatures:

cosign verify --key <key> registry.cleanstart.com/cleanstart:latest

Subcontractor and Vendor Management

CleanStart Key Vendors:

Vendor Evaluation: Each vendor undergoes security assessment: SOC 2 Type II report reviewed. Incident response SLA verified. Business continuity plan reviewed. Subcontractor contractual requirements (for BA relationships).

Ongoing Monitoring: Vendors re-assessed annually; critical CVEs in vendor software trigger immediate assessment

Third-Party Dependencies

Dependency Scanning: All open-source dependencies scanned for vulnerabilities: OWASP Dependency-Check in CI/CD. Snyk for continuous monitoring. Automated pull requests for dependency updates (Dependabot).

SBOM for CleanStart itself: Available in SPDX format; includes all transitive dependencies

License Compliance: All dependencies reviewed for license compatibility (GPL, Apache, MIT, etc.); none with problematic licenses

Section 6: Information Security Program

Security Training and Awareness

Annual Training: All employees complete: Mandatory annual security training (SANS, SecurityIQ, or equivalent). Role-specific training (developers: secure coding; operations: incident response). Phishing awareness training (monthly simulations; 5% click rate company-wide).

Evidence: Training completion records, phishing simulation reports

Vulnerability Management Program

Vulnerability Disclosure: CleanStart accepts security reports via: Security email: security@cleanstart.com (monitored 24/7). HackerOne program: [HackerOne profile URL] (bug bounty up to $10,000). Responsible disclosure: 90-day disclosure timeline (or earlier if patch is ready).

Response SLA: Critical: Response within 4 hours, patch within 24 hours. High: Response within 8 hours, patch within 7 days. Medium: Response within 1 day, patch within 30 days.

Historical Disclosures: No public security vulnerabilities in past 24 months

Change Management

Approval Process:

1. Developer proposes change via pull request
2. Peer code review (minimum 2 reviewers)
3. Automated testing (unit, integration, security scanning)
4. Change approval ticket (for production releases)
5. Deploy (via automated CI/CD pipeline)
6. Post-deployment verification

Rollback Procedure: All changes are reversible; automated rollback available if health checks fail

Section 7: Customer Data Protection

Data Deletion and Retention

Retention Policy: Active customer data: Retained indefinitely (customer responsibility to delete). Deleted account data: Hard-deleted within 30 days (no recovery possible). Audit logs: Retained for 7 years (for regulatory compliance). Backup data: Purged after 30 days (unless extended retention requested).

Procedure for Account Deletion:

1. Customer requests deletion via console or API
2. Confirmation email sent to account owner
3. Account marked for deletion (14-day grace period for recovery)
4. After 14 days: All data deleted, backup purged

Verification: Can customer verify data has been deleted? Yes, via API. CleanStart provides certificate of deletion after 30 days.

Data Residency and Jurisdiction

Default: Data stored in US regions (AWS us-east-1 or us-west-2)

Options: EU (AWS eu-west-1): GDPR-aligned; all data stored in Ireland. Asia-Pacific (AWS ap-southeast-1): Stored in Singapore. Other regions: By special request.

Immutability: Container image registry data cannot be moved after initial upload; new deployments required for region change

Appendix A: Certification and Compliance Artifacts

The following documents are available upon request (typically via signed NDA):

1. SOC 2 Type II Report (12-month audit, completed [Date])
2. ISO 27001 Certificate (once audit completed, Q2 2026)
3. Penetration Test Report (annual, most recent [Date])
4. SBOM for CleanStart (SPDX format, every release)
5. Business Continuity Plan (annual testing documentation)
6. Privacy Impact Assessment (customer data handling)
7. Disaster Recovery Plan (annual drill logs)
8. Subcontractor Risk Assessment (vendor evaluation summary)
9. Incident Response Plan (summary; full details under NDA)
10. HIPAA BAA (standard agreement, customizable)

Appendix B: Contact Information for Compliance Questions

General Questions: security@cleanstart.com. HIPAA/Compliance: compliance@cleanstart.com. Incident Reporting: security@cleanstart.com (monitored 24/7). Vendor Risk Assessment: procurement@cleanstart.com.

Document Control: Maintained by Chief Information Security Officer. Last reviewed: [Date]. Next review: [Date + 12 months].