Skip to content

SOC 2 controls mapping#

Not a regulatory profile per se — a generic controls map aligning swarm features to SOC 2 Trust Services Criteria (TSC). Useful for audit prep.

swarm SOC 2 status (April 2026)

swarm is pre-SOC-2. Target: SOC 2 Type II by month 9 post-OSS-launch. The mapping below is what we're preparing to certify against. Customers can use this as input to their own SOC 2 audits when swarm is a sub-processor.

Common Criteria (CC)#

CC1 — Control environment#

Criterion swarm evidence
CC1.1 — Commitment to integrity Published Code of Conduct (Contributor Covenant v2.1) + security.md
CC1.2 — Board oversight Founder-level, documented in .project/decisions.md
CC1.3 — Organizational structure CONTRIBUTING.md defines roles
CC1.4 — Personnel competence Background checks on maintainers (policy)
CC1.5 — Accountability Per-person commit attribution (Co-Authored-By), PR reviews

CC2 — Communication + information#

Criterion swarm evidence
CC2.1 — Internal communication .project/decisions.md ADR log + GitHub issues
CC2.2 — External communication Documented support channels, SECURITY.md disclosure process
CC2.3 — Service commitments communication Public SLA at docs.theaisingularity.org/sla

CC3 — Risk assessment#

Criterion swarm evidence
CC3.1 — Specify objectives .project/strategy/*.md (open-source, deployment, compliance)
CC3.2 — Identify risks .project/strategy/10-additional-questions.md covers anti-patterns + failure modes
CC3.3 — Assess fraud risk Input validation at every API boundary; permission engine
CC3.4 — Assess significant change Release notes document every minor/major change

CC4 — Monitoring activities#

Criterion swarm evidence
CC4.1 — Evaluate + communicate deficiencies CI drift detection, release retrospectives
CC4.2 — Communicate reviewed deficiencies Published CHANGELOG + security advisories

CC5 — Control activities#

Criterion swarm evidence
CC5.1 — Select + develop controls Permission engine, feature flags, RBAC, audit trail
CC5.2 — Select + develop technology controls Pydantic validation, TLS, BYOK, rate limiting
CC5.3 — Deploy through policies permission_policies*.yaml enforced at runtime

CC6 — Logical + physical access controls#

Criterion swarm evidence
CC6.1 — Logical access restriction RBAC + OIDC + per-agent tool allowlists
CC6.2 — New credential authorization Admin-approval workflow for new users; OIDC auto-provisioning with role gate
CC6.3 — Access modification Dashboard role changes logged to permission_denials
CC6.4 — Physical access Cloud provider's responsibility (AWS SOC 2, GCP SOC 2, Azure SOC 2)
CC6.5 — Logical + physical access termination OIDC deprovisioning → immediate session revocation; token refresh fails
CC6.6 — External-access threats TLS 1.3; rate limiting; network policies; WAF
CC6.7 — Transmission of information TLS everywhere; no plaintext egress
CC6.8 — Prevent malicious software Signed container images + SHA-256 manifest pinning for plugins

CC7 — System operations#

Criterion swarm evidence
CC7.1 — Configuration + change detection Git as source of truth; CI; .github/workflows/doc-drift.yml
CC7.2 — Anomaly monitoring Prometheus + OTel; alerting on drift / rate-limit violations
CC7.3 — Security event evaluation permission_denials table; incident response process
CC7.4 — Incident response Operations: Incident response
CC7.5 — Recovery procedures Backup/restore documented; RTO/RPO documented

CC8 — Change management#

Criterion swarm evidence
CC8.1 — Authorized change process PR review + CI gates; DCO sign-off
CC8.2 — Integrity + security of changes Signed commits (policy); image signing with cosign

CC9 — Risk mitigation#

Criterion swarm evidence
CC9.1 — Risk identification + mitigation SECURITY.md; dependency auditing (SBOM)
CC9.2 — Vendor risk management .project/research/deployment-patterns.md documents sub-processor list

Availability (A)#

A1 — Availability#

Criterion swarm evidence
A1.1 — Maintain processing capacity HPA (Kubernetes); HPA scaling policy in values.yaml
A1.2 — Maintain system components Retention daemon; health probes; automated restart on failure
A1.3 — Recovery from disruption RTO 4h / RPO 1h for Enterprise tier; backup + restore procedures

Confidentiality (C)#

C1 — Confidentiality#

Criterion swarm evidence
C1.1 — Identify + maintain confidential information Data classification in compliance profiles
C1.2 — Dispose of confidential information Retention daemon with configurable TTLs

Gap analysis — what swarm still needs before SOC 2 Type II#

Things we need to ship / institutionalize before we can certify:

  • Formal Information Security Policy (ISP) — written, versioned, acknowledged by all contributors
  • Vendor risk assessment — documented per sub-processor
  • Pen test — quarterly (external, \(15K–\)20K/yr budget)
  • Security awareness training — annual; documented attendance
  • Vulnerability management program — SAST + DAST + SBOM on every release
  • Incident response tabletop — quarterly drills; documented outcomes
  • Business continuity plan — documented, tested annually
  • Background checks on new hires — policy documented
  • Dedicated ISMS or compliance platform — Drata / Secureframe / Vanta (planned month 2-4)

Customer SOC 2 sub-processor report#

When your SOC 2 audit asks about swarm as a sub-processor:

  • System description — point them at What is swarm?
  • Control mapping — this page
  • Our SOC 2 report — once available (month 9 target); currently "in progress with "
  • Sub-processor list — https://trust.theaisingularity.org/sub-processors (published)

Shared responsibility model#

Control area Your responsibility swarm responsibility
Physical security of data center — Cloud provider (inherits AWS/GCP/Azure SOC 2)
Customer data classification ✓ —
OIDC IdP security ✓ —
IAM policy configuration (AWS/GCP/Azure) ✓ swarm Helm provides defaults
swarm platform code security — ✓
Dependency vulnerabilities — (monitor our advisories) ✓ (patching + disclosure)
Audit log integrity — ✓
Incident response on swarm-internal events — ✓
Incident response on customer-infra events ✓ (we assist)

Next#