Skip to content

DOMAIN:SOC2_CRITERIA

OWNER: julian
UPDATED: 2026-03-24
SCOPE: SOC 2 Type II Trust Services Criteria mapped to GE operations
SERVES: julian (compliance officer), amber (auditor)
ALSO_USED_BY: marta (CC8 evidence), boris (access evidence), rutger (availability evidence)

OVERVIEW

SOC 2 Type II examines operating effectiveness of controls over a period (6-12 months).
AUDITOR: CPA firm (Big 4 or specialized), examines design AND operating effectiveness.
REPORT_TYPE: restricted use (NDA required) — shared with clients on request.
GE_SCOPE: multi-agent software development platform, client project delivery, infrastructure.

TRUST_SERVICE_CATEGORIES_SELECTED:
- Security (mandatory — Common Criteria CC1-CC9)
- Availability (client SLA commitments)
- Confidentiality (client code and data protection)
NOTE: Processing Integrity and Privacy may be added in future based on client demand.

CC1 — CONTROL ENVIRONMENT

TAG:CC1 TAG:CONTROL_ENVIRONMENT

WHAT_AUDITORS_LOOK_FOR

  • Commitment to integrity and ethical values (CC1.1)
  • Board/management oversight of internal controls (CC1.2)
  • Organizational structure with clear reporting lines (CC1.3)
  • Commitment to attracting and retaining competent personnel (CC1.4)
  • Accountability for internal control responsibilities (CC1.5)

HOW_GE_SATISFIES

CC1.1 — INTEGRITY_AND_ETHICS:
- Constitution v2 defines 10 binding principles for all agents
- Principle 2 (Real Over Simulated) prohibits deception
- Constitution enforced by Ron (Guardian), Jaap (SSOT), Amber (Participation)
- Violations produce documented findings with corrective actions
EVIDENCE: constitution document, violation records, corrective action logs
AGENT: julian (policy), amber (monitoring)

CC1.2 — MANAGEMENT_OVERSIGHT:
- Dirk-Jan reviews every agent commissioning personally
- Amber performs quarterly internal audits
- Admin-UI provides real-time visibility into agent operations
- Management review meetings produce documented decisions
EVIDENCE: commissioning records, audit reports, management review minutes
AGENT: amber (audit), dirk-jan (human oversight)

CC1.3 — ORGANIZATIONAL_STRUCTURE:
- AGENT-REGISTRY.json defines all 54 agents with roles, teams, reporting
- Three-zone architecture (Public, Shared, Team) with clear boundaries
- Team structure: Alpha (Faye PM), Beta (Sytske PM), shared services
- Escalation paths defined: agent -> team lead -> Mira -> Dirk-Jan
EVIDENCE: AGENT-REGISTRY.json, org chart, escalation procedures
AGENT: julian (structure documentation)

CC1.4 — COMPETENT_PERSONNEL:
- Agent profiling pipeline ensures role fitness before activation
- Tiered identity (CORE + ROLE + REFERENCE) verified per agent
- Provider selection per agent capability (Claude/OpenAI/Gemini)
- Wiki brain provides continuous knowledge updates
EVIDENCE: agent profiles, commissioning records, capability assessments
AGENT: julian (competency framework)

CC1.5 — ACCOUNTABILITY:
- Every work item tracked in DAG with assigned agent
- Pipeline execution logs attribute every action to specific agent
- PTY capture produces audit trail of all agent sessions
- Cost gate tracks resource consumption per agent
EVIDENCE: DAG records, execution logs, PTY transcripts, cost reports
AGENT: amber (accountability monitoring)

CC2 — COMMUNICATION AND INFORMATION

TAG:CC2 TAG:COMMUNICATION

WHAT_AUDITORS_LOOK_FOR

  • Relevant quality information generated and used (CC2.1)
  • Internal communication of controls objectives and responsibilities (CC2.2)
  • External communication about matters affecting controls (CC2.3)

HOW_GE_SATISFIES

CC2.1 — QUALITY_INFORMATION:
- PostgreSQL as SSOT — single source of truth for all operational data
- Wiki brain provides curated knowledge (not raw data)
- Session learnings extract structured insights from every execution
- Knowledge synthesizer detects cross-session patterns (6-hourly)
EVIDENCE: database records, wiki content, learning extraction logs
AGENT: annegreet (knowledge curation), eltjo (pattern analysis)

CC2.2 — INTERNAL_COMMUNICATION:
- Constitution v2 injected on every agent boot
- Wiki brain provides JIT (just-in-time) domain knowledge
- Redis Streams for operational messaging
- Discussions API for multi-agent consensus decisions
EVIDENCE: constitution acknowledgement logs, Redis stream records, discussion records
AGENT: julian (policy communication)

CC2.3 — EXTERNAL_COMMUNICATION:
- Client communication through defined channels (Dima intake, PM updates)
- Incident communication templates (see incident-response/index.md)
- SOC 2 report shared with clients under NDA
- Privacy notices per GDPR requirements
EVIDENCE: client communication logs, incident notifications, privacy notices
AGENT: faye/sytske (client communication), mira (incident communication)

CC3 — RISK ASSESSMENT

TAG:CC3 TAG:RISK_ASSESSMENT

WHAT_AUDITORS_LOOK_FOR

  • Suitable risk objectives specified (CC3.1)
  • Risk identification and analysis (CC3.2)
  • Consideration of fraud risk (CC3.3)
  • Identification and assessment of significant changes (CC3.4)

HOW_GE_SATISFIES

CC3.1 — RISK_OBJECTIVES:
- Security objectives defined in Constitution v2
- Availability targets per client SLA
- Confidentiality requirements per data classification
- Compliance objectives per regulatory framework (GDPR, NIS2, etc.)
EVIDENCE: risk register, security objectives document, SLA definitions
AGENT: julian (risk framework)

CC3.2 — RISK_IDENTIFICATION:
- Threat intelligence collection (Annegreet)
- Vulnerability scanning (Trivy, Semgrep)
- Cross-session pattern detection identifies emerging risks
- Regulatory monitoring for new compliance requirements
EVIDENCE: risk register, vulnerability reports, pattern analysis outputs
AGENT: julian (risk assessment), annegreet (threat intelligence)

CC3.3 — FRAUD_RISK:
- Segregation of duties in anti-LLM pipeline (no agent both writes and approves)
- Cost gate prevents unauthorized resource consumption
- Amber audits participation and contribution quality
- Dima (public-facing) is stateless — cannot be socially engineered
EVIDENCE: segregation of duties matrix, cost gate logs, audit findings
AGENT: amber (fraud detection), julian (fraud risk assessment)

CC3.4 — CHANGE_ASSESSMENT:
- Constitution Principle 6 (Blast Radius Awareness) requires impact analysis for changes
- New regulation monitoring (EU AI Act, NIS2, CRA timelines tracked)
- Provider changes trigger security reassessment
- New agent onboarding includes risk assessment
EVIDENCE: blast radius assessments, regulatory tracker, provider review records
AGENT: julian (change risk assessment)

CC4 — MONITORING ACTIVITIES

TAG:CC4 TAG:MONITORING

WHAT_AUDITORS_LOOK_FOR

  • Ongoing and/or separate evaluations of control effectiveness (CC4.1)
  • Evaluation and communication of control deficiencies (CC4.2)

HOW_GE_SATISFIES

CC4.1 — CONTROL_EVALUATION:
- Ron (System Integrity Monitor) performs continuous runtime monitoring
- Amber performs quarterly internal audits (see audit-procedures.md)
- Automated compliance checks via kube-bench, Semgrep, Trivy
- Health escalation thresholds trigger automated responses
- Cost gate provides continuous financial control monitoring
EVIDENCE: monitoring dashboards, audit reports, automated scan results
AGENT: ron (continuous monitoring), amber (periodic evaluation)

CC4.2 — DEFICIENCY_COMMUNICATION:
- Audit findings classified (major/minor/observation)
- Corrective actions tracked with owners and deadlines
- Management review receives quarterly control status
- Critical deficiencies escalated immediately to Dirk-Jan
EVIDENCE: audit finding records, corrective action tracker, management review minutes
AGENT: amber (deficiency reporting), julian (corrective action tracking)

CC5 — CONTROL ACTIVITIES

TAG:CC5 TAG:CONTROL_ACTIVITIES

WHAT_AUDITORS_LOOK_FOR

  • Control activities designed and implemented to mitigate risks (CC5.1)
  • General controls over technology selected and developed (CC5.2)
  • Controls deployed through policies and procedures (CC5.3)

HOW_GE_SATISFIES

CC5.1 — CONTROL_DESIGN:
- Controls mapped to risks in risk register
- Anti-LLM pipeline implements multiple control layers
- Defense in depth: network policies + RBAC + application controls + monitoring
EVIDENCE: risk-control mapping matrix, control design documentation
AGENT: julian (control design)

CC5.2 — TECHNOLOGY_CONTROLS:
- k8s RBAC for access control
- Network policies for zone isolation
- Vault for secrets management
- Automated scanning (Trivy, Semgrep, kube-bench)
- Cost gate for resource controls
EVIDENCE: RBAC manifests, network policies, Vault configuration, scan configurations
AGENT: rutger (technology controls), julian (policy)

CC5.3 — POLICY_DEPLOYMENT:
- Constitution v2 = master policy document
- CODEBASE-STANDARDS.md = development policy
- Wiki brain = distributed policy and procedure library
- Agent identity documents include role-specific policies
EVIDENCE: policy documents, acknowledgement records, wiki content
AGENT: julian (policy management)

CC6 — LOGICAL AND PHYSICAL ACCESS CONTROLS

TAG:CC6 TAG:ACCESS_CONTROLS TAG:FOCUS

WHAT_AUDITORS_LOOK_FOR

  • Logical access security over infrastructure and software (CC6.1)
  • Registration and authorization before access granted (CC6.2)
  • Access removal when no longer needed (CC6.3)
  • Access restricted to authorized individuals (CC6.4 — network, data)
  • Protection of system boundaries (CC6.5 — firewalls, DMZ)
  • Encryption of data in transit (CC6.6)
  • Management of credentials and secrets (CC6.7)
  • Protection against security threats (CC6.8)

HOW_GE_SATISFIES

CC6.1 — INFRASTRUCTURE_ACCESS:
- k8s RBAC with least privilege per agent role
- Admin-UI protected by WebAuthn (FIDO2 hardware keys)
- No shared credentials — per-agent Vault paths
- Database access restricted to admin-ui service account and boris (DBA)
- kubectl access controlled via kubeconfig mounted as hostPath
EVIDENCE: RBAC role bindings, WebAuthn enrollment records, Vault access policies
AGENT: rutger (RBAC), julian (access policy)
REVIEW: quarterly access review — verify no privilege creep

CC6.2 — REGISTRATION_AND_AUTHORIZATION:
- Agent commissioning process requires Dirk-Jan approval before activation
- Agent status in AGENT-REGISTRY.json controls access (unavailable = no work)
- New agent activation goes through profiling pipeline
- Client project access granted per project assignment only
EVIDENCE: commissioning records, registry change history, project assignment records
AGENT: julian (registration process)

CC6.3 — ACCESS_REMOVAL:
- Agent decommissioning sets status to unavailable in registry
- Vault tokens revoked on agent decommission
- k8s RBAC bindings removed
- Database access revoked
- Client project access ends with project completion
EVIDENCE: decommission records, Vault revocation logs, RBAC change history
AGENT: julian (decommission process), rutger (technical removal)

CC6.4 — ACCESS_RESTRICTION:
- THREE_ZONE_ARCHITECTURE enforces boundaries:
- ZONE_PUBLIC: Dima only — stateless, no internal knowledge
- ZONE_SHARED: service agents — cross-team access with purpose limitation
- ZONE_TEAM: Alpha/Beta — client data isolated per team
- Network policies restrict inter-namespace communication
- Database row-level security per client/team
- Redis stream permissions per agent (triggers.{agent} pattern)
EVIDENCE: network policy manifests, database permission matrices, Redis ACL config
AGENT: boris (database access), rutger (network access), julian (access policy)

CC6.5 — SYSTEM_BOUNDARY_PROTECTION:
- k3s cluster: all services internal, minimal external exposure
- NodePort services explicitly enumerated (wiki 30080, admin-ui)
- No direct database access from outside cluster
- Ingress controller with TLS termination
- Dima as only public-facing entry point (stateless, unhackable by design)
EVIDENCE: k8s service manifests, ingress configuration, network policy manifests
AGENT: rutger (boundary implementation)

CC6.6 — ENCRYPTION_IN_TRANSIT:
- TLS 1.3 on all external-facing endpoints
- PostgreSQL SSL connections enforced
- Redis communication within cluster (internal only)
- Inter-service communication via k8s internal DNS (not exposed externally)
EVIDENCE: TLS certificates, PostgreSQL SSL configuration, cipher suite configuration
AGENT: rutger (TLS implementation), julian (crypto policy)

CC6.7 — CREDENTIAL_MANAGEMENT:
- Vault stores all secrets (API keys, database credentials)
- Per-agent Vault paths — agents cannot access other agents' secrets
- No credentials in code (Semgrep rules detect hardcoded secrets)
- WebAuthn eliminates password management for admin access
- Secret rotation policy documented
EVIDENCE: Vault configuration, secret scanning results, rotation records
AGENT: rutger (Vault management), julian (credential policy)

CC6.8 — THREAT_PROTECTION:
- Trivy container scanning (prevent vulnerable images)
- Semgrep static analysis (prevent vulnerable code)
- Ashley (Adversarial Agent) performs pre-deployment security testing
- Network policies prevent lateral movement
- Cost gate prevents resource abuse
EVIDENCE: Trivy reports, Semgrep results, adversarial test reports, network policies
AGENT: ashley (adversarial testing), koen (code security), rutger (infra security)

CC7 — SYSTEM OPERATIONS

TAG:CC7 TAG:SYSTEM_OPERATIONS TAG:FOCUS

WHAT_AUDITORS_LOOK_FOR

  • Detection of unauthorized changes (CC7.1 — change detection)
  • Monitoring for anomalies and security events (CC7.2)
  • Evaluation of detected events (CC7.3)
  • Response to identified incidents (CC7.4)
  • Recovery from incidents (CC7.5)

HOW_GE_SATISFIES

CC7.1 — CHANGE_DETECTION:
- Git tracks all code changes with attribution
- k8s audit logging detects configuration changes
- Jaap (SSOT Enforcer) detects drift from declared state
- Constitution Principle 1 (Config Is King) — config changes are version-controlled
- Container image rebuild required for all code changes (no runtime modification)
EVIDENCE: git audit log, k8s audit logs, SSOT enforcement records
AGENT: jaap (drift detection), ron (runtime monitoring)

CC7.2 — ANOMALY_MONITORING:
- Ron (System Integrity Monitor) performs continuous monitoring
- Health escalation: 3=warn, 5=escalate to mira, 10=critical
- Grafana dashboards with alerting rules
- Loki for log aggregation and pattern matching
- Cost gate detects abnormal token consumption
- Executor dedup detects double-delivery anomalies
EVIDENCE: alert configurations, Grafana dashboards, Loki queries, cost gate logs
AGENT: ron (monitoring), mira (escalation handling)

CC7.3 — EVENT_EVALUATION:
- Ron performs first-pass assessment of all security events
- Two-signal verification prevents false positive escalation
- Classification criteria per severity level (SEV1-4)
- Mira makes final classification decision for escalated events
EVIDENCE: event assessment logs, classification decisions with rationale
AGENT: ron (first-pass), mira (classification)

CC7.4 — INCIDENT_RESPONSE:
- Full incident lifecycle: detect -> classify -> respond -> mitigate -> resolve -> post-mortem
- Mira as designated Incident Commander
- Sandro (backend hotfix) and Tobias (frontend hotfix) as responders
- SLAs per severity: SEV1 acknowledge 5min, respond 15min, mitigate 1hr
- Communication templates for internal and client-facing notifications
EVIDENCE: incident records with timestamped actions, communication logs
AGENT: mira (commander), sandro/tobias (responders)
CROSS_REF: domains/incident-response/index.md

CC7.5 — INCIDENT_RECOVERY:
- ge-orchestrator: 2 replicas, HA consumer group, automatic recovery
- PodDisruptionBudget prevents simultaneous failures
- Recovery procedures: startup drain + 2-phase orphan claiming + stale consumer cleanup
- Post-mortem within 48 hours with mandatory action items
- Every SEV1/SEV2 produces wiki brain learning
EVIDENCE: recovery procedure documentation, PDB configurations, post-mortem records
AGENT: mira (recovery coordination), rutger (infrastructure recovery)

CC8 — CHANGE MANAGEMENT

TAG:CC8 TAG:CHANGE_MANAGEMENT TAG:FOCUS

WHAT_AUDITORS_LOOK_FOR

  • Authorized changes before implementation (CC8.1)
  • Change testing before deployment (CC8.2 — test environments, test results)
  • Change approval and documentation (CC8.3 — audit trail)
  • Emergency changes managed appropriately (CC8.4)

HOW_GE_SATISFIES

CC8.1 — CHANGE_AUTHORIZATION:
- Anti-LLM pipeline: no code reaches production without multi-agent review
- Anna(spec) -> Antje(TDD) -> Devs -> Koen(linting) -> Marije(test) -> Jasper(reconcile) -> Marco(conflict) -> Ashley(adversarial) -> Jaap(SSOT) -> Marta(merge)
- Marta (GitHub Goalkeeper) is sole merge authority — controls what reaches main branch
- Feature branches required (Constitution: never commit to main directly)
- Work packages tracked in DAG with dependencies enforced
EVIDENCE: PR history with review records, DAG execution logs, merge approvals
AGENT: marta (merge authority), koen (code review), julian (change policy)

CC8.2 — CHANGE_TESTING:
- Antje (TDD) writes tests BEFORE development begins
- Marije (Testing Lead) ensures test coverage meets standards
- Jasper (Test Reconciliation) verifies test results match specifications
- Ashley (Adversarial Agent) performs pre-deployment security/edge-case testing
- Environment separation: dev -> staging -> production promotion path
EVIDENCE: test results, test coverage reports, adversarial test reports, environment configs
AGENT: antje (TDD), marije (testing), jasper (reconciliation), ashley (adversarial)

CC8.3 — CHANGE_DOCUMENTATION:
- Git commit history provides complete change attribution
- PR descriptions document change purpose and scope
- Blast Radius section required for shared interface changes (Principle 6)
- Constitution v2 acknowledged per session
- Container image rebuild log for deployments
EVIDENCE: git log, PR records, blast radius assessments, deployment logs
AGENT: marta (PR management), jaap (SSOT)

CC8.4 — EMERGENCY_CHANGES:
- Hotfix procedures documented (see incident-response/hotfix-procedures.md)
- Emergency: rollback-first philosophy (fastest mitigation)
- Mira authorizes emergency changes during incidents
- Emergency changes receive post-facto review within 24 hours
- All emergency actions timestamped in incident record
EVIDENCE: incident records, emergency change logs, post-facto review records
AGENT: mira (emergency authorization), sandro/tobias (hotfix execution)

MARTA_EVIDENCE_PRODUCTION:
- Every merge to main produces: PR number, reviewer list, test results, approval timestamp
- GitHub webhook captures merge events into PostgreSQL
- Monthly summary: total changes, review coverage, rejection rate, average review time
- SOC 2 auditors review sample of PRs for evidence of review process
FORMAT: structured JSON in PostgreSQL change_records table

CC9 — RISK MITIGATION

TAG:CC9 TAG:RISK_MITIGATION

WHAT_AUDITORS_LOOK_FOR

  • Vendor and business partner risk managed (CC9.1)
  • Risk acceptance decisions documented (CC9.2)

HOW_GE_SATISFIES

CC9.1 — VENDOR_RISK:
- LLM provider assessment: Anthropic, OpenAI, Google evaluated
- Data processing agreements with all providers
- No client PII sent to LLM providers
- SBOM for dependency supply chain visibility
- Vendor review cycle: annual or on significant change
EVIDENCE: vendor assessment records, DPAs, SBOM manifests
AGENT: julian (vendor assessment)

CC9.2 — RISK_ACCEPTANCE:
- Risk register with documented acceptance decisions
- Residual risk documented with compensating controls
- Management (Dirk-Jan) approves risk acceptance above defined threshold
- Risk acceptance review: annual
EVIDENCE: risk register, risk acceptance records with signatures
AGENT: julian (risk documentation)

AVAILABILITY — TRUST SERVICE CRITERIA

TAG:AVAILABILITY

WHAT_AUDITORS_LOOK_FOR

  • Performance monitoring against commitments (A1.1)
  • Recovery from incidents that affect availability (A1.2)
  • Testing of recovery procedures (A1.3)

HOW_GE_SATISFIES

A1.1 — PERFORMANCE_MONITORING:
- Grafana dashboards track system metrics (CPU, memory, response time)
- Health dump script (scripts/k8s-health-dump.sh) runs on host cron
- SLA tracking: monthly report on uptime, response time, incident count
- Ron (System Integrity Monitor) alerts on performance degradation
EVIDENCE: monitoring dashboards, SLA reports, health dump data
AGENT: ron (monitoring), rutger (infrastructure)

A1.2 — AVAILABILITY_RECOVERY:
- ge-orchestrator: 2 replicas, consumer group failover
- PodDisruptionBudget (PDB) prevents full outage during updates
- Circuit breaker prevents cascading failures
- Incident response procedures (see CC7.4, CC7.5)
EVIDENCE: PDB configurations, failover test results, incident recovery records
AGENT: rutger (infrastructure), mira (incident recovery)

A1.3 — RECOVERY_TESTING:
- Backup restoration tests
- Failover simulation (orchestrator replica loss)
- Incident simulation exercises
EVIDENCE: recovery test results with timestamps and outcomes
AGENT: rutger (infrastructure testing), amber (test verification)
NOTE: recovery testing frequency = quarterly minimum

CONFIDENTIALITY — TRUST SERVICE CRITERIA

TAG:CONFIDENTIALITY

WHAT_AUDITORS_LOOK_FOR

  • Identification of confidential information (C1.1)
  • Disposal of confidential information (C1.2)

HOW_GE_SATISFIES

C1.1 — CONFIDENTIAL_INFORMATION_IDENTIFICATION:
- Client code and data classified as confidential by default
- Data classification schema: public, internal, confidential, restricted
- Three-zone architecture enforces confidentiality boundaries
- Dima (public zone) has zero access to confidential data
- Team zone isolation prevents cross-client data access
EVIDENCE: data classification records, network policy manifests, zone architecture docs
AGENT: julian (classification policy), boris (data controls)

C1.2 — CONFIDENTIAL_INFORMATION_DISPOSAL:
- Client data deletion on project completion or client request
- Redis stream MAXLEN prevents unbounded data retention
- Log rotation with defined retention periods
- Secure deletion procedures for storage media
EVIDENCE: deletion records, retention configuration, MAXLEN settings
AGENT: boris (data disposal), julian (retention policy)

AUDIT_EVIDENCE_COLLECTION

CONTINUOUS_EVIDENCE (automated)

  • Git commit history (change management)
  • k8s audit logs (access and configuration changes)
  • Trivy scan reports (vulnerability management)
  • Semgrep scan reports (code security)
  • Cost gate logs (resource consumption)
  • Health dump data (availability monitoring)
  • Redis stream records (operational messaging)
  • PTY capture transcripts (agent session traces)

PERIODIC_EVIDENCE (manual/semi-automated)

  • Quarterly internal audit reports (Amber)
  • Annual vendor assessments (Julian)
  • Quarterly access reviews (Julian + Rutger)
  • Monthly SLA compliance reports (Ron)
  • Post-mortem records (Mira)
  • Management review minutes (Dirk-Jan)

EVIDENCE_RETENTION

  • SOC 2 Type II examination period: 12 months
  • Evidence retained: minimum 3 years beyond examination period
  • PostgreSQL as SSOT for structured evidence
  • Wiki for human-readable documentation

SOC2_READINESS_CHECKLIST

BEFORE_ENGAGEMENT:  
[ ] scope defined (systems, categories, period)  
[ ] all CC1-CC9 controls documented  
[ ] evidence collection automated where possible  
[ ] internal audit completed (Amber)  
[ ] management review conducted (Dirk-Jan)  
[ ] corrective actions from internal audit closed or documented as in-progress  

DURING_EXAMINATION:  
[ ] auditor access to evidence systems provisioned  
[ ] designated contact for auditor inquiries (Julian)  
[ ] evidence samples prepared per CC  
[ ] walkthroughs of key processes scheduled  
[ ] system descriptions (description criteria) reviewed and current  

POST_EXAMINATION:  
[ ] management response to findings prepared  
[ ] corrective action plan for any exceptions  
[ ] lessons learned documented in wiki brain  
[ ] next examination cycle planned

READ_ALSO: iso27001-controls.md, evidence-automation.md, audit-procedures.md, domains/incident-response/index.md