SOC 2 — TRUST SERVICES CRITERIA¶

OWNER: julian
UPDATED: 2026-03-24
SCOPE: SOC 2 Trust Services Criteria (2017, with 2022 revisions) mapped to GE operations
STANDARD: AICPA Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy

WHAT_IS_SOC_2¶

SOC 2 is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants).
It evaluates an organization's controls relevant to Trust Services Criteria.
Unlike ISO 27001 (prescriptive management system), SOC 2 is PRINCIPLES-BASED — the criteria describe WHAT to achieve, not HOW.

RULE: SOC 2 reports are issued by licensed CPA firms only
RULE: SOC 2 is NOT a certification — it is an attestation (auditor's opinion on controls)
RULE: Security (Common Criteria) is MANDATORY. Other categories are optional.

GE_SELECTED_CRITERIA:
- Security (Common Criteria CC1-CC9) — MANDATORY
- Availability (A1) — SELECTED (enterprise SaaS must be available)
- Confidentiality (C1) — SELECTED (client data protection)
- Processing Integrity (PI1) — SELECTED (software correctness matters)
- Privacy — NOT SELECTED (covered by GDPR compliance separately)

CC1 — CONTROL ENVIRONMENT¶

PURPOSE: the foundation — organizational commitment to integrity, ethical values, governance, competence, and accountability.

CC1.1 — COSO Principle 1: Integrity and ethical values¶

WHAT_AUDITORS_TEST:
- Code of conduct or equivalent exists and is communicated
- Tone at the top — management demonstrates commitment
- Deviations from expected behavior are addressed
GE_DEMONSTRATES:
- Constitution v2 (10 principles) — injected at every agent boot
- Discussion model for ethical decisions (vote → escalate to human if no majority)
- amber monitors agent compliance, reports violations
EVIDENCE: constitution.md, agent boot logs, amber audit reports, discussion records

CC1.2 — COSO Principle 2: Board exercises oversight¶

WHAT_AUDITORS_TEST:
- Oversight body (board/management) provides oversight of ISMS
- Independence from management where needed
GE_DEMONSTRATES:
- Dirk-Jan (owner/founder) performs quarterly management reviews
- amber (Internal Auditor) operates independently of julian (Compliance Officer)
EVIDENCE: management review minutes, amber independence documentation

CC1.3 — COSO Principle 3: Management establishes structure, authority, and responsibility¶

WHAT_AUDITORS_TEST:
- Organizational structure defined
- Reporting lines clear
- Roles and responsibilities assigned
GE_DEMONSTRATES:
- AGENT-REGISTRY.json — complete organizational structure
- RACI matrix for security activities
- Clear ownership per Annex A control (see iso27001-annex-a.md)
EVIDENCE: AGENT-REGISTRY.json, org chart, RACI matrix

CC1.4 — COSO Principle 4: Commitment to competence¶

WHAT_AUDITORS_TEST:
- Competence requirements defined per role
- People (and agents) have necessary skills
- Training and development programmes
GE_DEMONSTRATES:
- Agent profiles define capabilities and domain expertise
- Agent profiling pipeline ensures alignment
- JIT learnings provide continuous development
- Knowledge synthesizer detects competence gaps
EVIDENCE: agent profiles, profiling records, JIT injection logs

CC1.5 — COSO Principle 5: Accountability¶

WHAT_AUDITORS_TEST:
- Individuals held accountable for internal control responsibilities
- Performance measures include internal control objectives
GE_DEMONSTRATES:
- Agent compliance scores tracked
- amber audits participation and compliance
- Violations trigger disciplinary process via discussion model
EVIDENCE: compliance monitoring data, amber reports

CC2 — COMMUNICATION AND INFORMATION¶

PURPOSE: obtain/generate and use relevant, quality information. Communicate internally and externally.

CC2.1 — COSO Principle 13: Quality information¶

WHAT_AUDITORS_TEST:
- Organization obtains, generates, and uses relevant quality information
- Information is timely, current, accurate, complete, accessible
GE_DEMONSTRATES:
- Wiki brain = quality-controlled knowledge base
- Knowledge synthesizer validates patterns across sessions
- PostgreSQL as SSOT — no conflicting data sources
EVIDENCE: wiki content, knowledge_patterns table, SSOT verification

CC2.2 — COSO Principle 14: Internal communication¶

WHAT_AUDITORS_TEST:
- Internal communication of ISMS objectives and responsibilities
- Communication channels effective
GE_DEMONSTRATES:
- Redis Streams = auditable internal communication
- Constitution injection = policy communication
- Wiki = institutional knowledge communication
- Admin-UI = management communication interface
EVIDENCE: Redis stream logs, constitution injection records, wiki update history

CC2.3 — COSO Principle 15: External communication¶

WHAT_AUDITORS_TEST:
- External communication about matters affecting internal control
- Communication with regulators, clients, partners
GE_DEMONSTRATES:
- Client communication via margot (Client Communications)
- Regulatory communication via julian
- Incident notification procedures documented
EVIDENCE: client communication logs, regulatory correspondence, notification procedures

CC3 — RISK ASSESSMENT¶

PURPOSE: identify and analyze risks that threaten achievement of objectives.

CC3.1 — COSO Principle 6: Specifying objectives¶

WHAT_AUDITORS_TEST:
- Security objectives clearly specified
- Measurable where possible
GE_DEMONSTRATES:
- Security objectives documented (see iso27001-overview.md clause 6.2)
- Per-control objectives in SoA
EVIDENCE: security objectives document, SoA

CC3.2 — COSO Principle 7: Identifying and analyzing risks¶

WHAT_AUDITORS_TEST:
- Risk identification process exists
- Risks analyzed for likelihood and impact
- Risk register maintained
GE_DEMONSTRATES:
- Asset-based risk assessment methodology
- Risk register with likelihood, impact, treatment
- Quarterly risk assessment cycle
EVIDENCE: risk assessment methodology, risk register, quarterly review records

CC3.3 — COSO Principle 8: Assessing fraud risk¶

WHAT_AUDITORS_TEST:
- Fraud risk considered (management override, data manipulation, misappropriation)
GE_DEMONSTRATES:
- Agent capability restrictions prevent unauthorized actions
- Segregation of duties prevents single-agent fraud
- Audit trails on all data modifications
- amber monitors for anomalous patterns
EVIDENCE: capability restriction configs, segregation evidence, audit trail samples

CC3.4 — COSO Principle 9: Identifying and analyzing significant changes¶

WHAT_AUDITORS_TEST:
- Changes to business environment, technology, regulations assessed
GE_DEMONSTRATES:
- Regulatory monitoring (julian — eu-regulation domain)
- Technology change assessment (LLM model updates, dependency changes)
- Business change impact analysis
EVIDENCE: regulatory register updates, change impact assessments

CC4 — MONITORING ACTIVITIES¶

PURPOSE: ongoing and/or periodic evaluations to ensure controls are functioning.

CC4.1 — COSO Principle 16: Ongoing and separate evaluations¶

WHAT_AUDITORS_TEST:
- Monitoring activities exist (continuous + periodic)
- Evaluations determine if controls are present and functioning
GE_DEMONSTRATES:
- Continuous: monitoring agents (annegreet, ron, mira), Falco, automated scans
- Periodic: amber internal audits, quarterly management reviews
- Cost gates = continuous financial monitoring
EVIDENCE: monitoring agent reports, Falco alerts, scan results, audit reports

CC4.2 — COSO Principle 17: Communicating deficiencies¶

WHAT_AUDITORS_TEST:
- Control deficiencies communicated to parties responsible for corrective action
- Significant deficiencies communicated to management
GE_DEMONSTRATES:
- amber reports findings to julian and management
- Monitoring agents escalate via mira (3=warn, 5=escalate, 10=critical)
- Discussion model for multi-agent consensus on deficiencies
EVIDENCE: audit finding reports, escalation records, discussion outcomes

CC5 — CONTROL ACTIVITIES¶

PURPOSE: select and develop control activities that contribute to risk mitigation.

CC5.1 — COSO Principle 10: Selecting and developing control activities¶

WHAT_AUDITORS_TEST:
- Controls selected to mitigate identified risks
- Controls appropriate for the technology environment
GE_DEMONSTRATES:
- Risk treatment plan maps risks to controls
- Controls automated where possible (compliance-as-code)
- Anti-LLM pipeline = control activity for software quality
EVIDENCE: risk treatment plan, automated control configurations, pipeline definitions

CC5.2 — COSO Principle 11: Technology general controls¶

WHAT_AUDITORS_TEST:
- IT general controls: access management, change management, operations, etc.
GE_DEMONSTRATES:
- Access: k8s RBAC, Vault, WebAuthn
- Change: git-based, PR required, CI/CD pipeline, marta as gatekeeper
- Operations: automated deployment, monitoring, alerting
EVIDENCE: RBAC config, Vault policies, PR history, CI/CD logs, monitoring dashboards

CC5.3 — COSO Principle 12: Deploying through policies and procedures¶

WHAT_AUDITORS_TEST:
- Policies and procedures deployed to put control activities into action
GE_DEMONSTRATES:
- Wiki policies = authoritative source
- JIT injection = policy deployment to agents
- CODEBASE-STANDARDS.md = development policy deployment
EVIDENCE: wiki policies, JIT injection logs, CODEBASE-STANDARDS.md

CC6 — LOGICAL AND PHYSICAL ACCESS CONTROLS¶

PURPOSE: restrict logical and physical access to authorized users and protect from threats.

CC6.1 — Logical access security¶

WHAT_AUDITORS_TEST:
- Logical access to infrastructure, data, and software restricted to authorized
- Access provisioning and deprovisioning procedures
GE_DEMONSTRATES:
- k8s RBAC with namespace isolation
- Vault with path-based policies
- Agent capability restrictions in executor
- WebAuthn for admin-ui (no passwords)
EVIDENCE: RBAC manifests, Vault policies, capability configs, WebAuthn setup
CONTINUOUS_MONITORING: quarterly access reviews by amber + piotr

CC6.2 — Prior to issuing access credentials¶

WHAT_AUDITORS_TEST:
- Registration and authorization process before granting access
- Identity verification
GE_DEMONSTRATES:
- Agent access provisioned via AGENT-REGISTRY.json (reviewed by hugo)
- Human access requires management approval
- No shared credentials, no default accounts
EVIDENCE: access provisioning records, registry change history

CC6.3 — New access and removal¶

WHAT_AUDITORS_TEST:
- Access created/modified/removed based on authorization
- Periodic access reviews
GE_DEMONSTRATES:
- Agent onboarding/offboarding via registry
- Quarterly access reviews
- Decommissioned agents have access revoked
EVIDENCE: access lifecycle records, quarterly review reports

CC6.4 — Physical access restrictions¶

WHAT_AUDITORS_TEST:
- Physical access to facilities, equipment restricted
GE_DEMONSTRATES:
- Hetzner datacenter physical controls (ISO 27001 certified)
- No GE physical office — remote-only
EVIDENCE: Hetzner certifications, remote working policy

CC6.5 — Disposal of assets¶

WHAT_AUDITORS_TEST:
- Secure disposal of assets including data destruction
GE_DEMONSTRATES:
- Server decommissioning procedure includes data wipe
- Database deletion per retention policy
- Hetzner hardware disposal procedures
EVIDENCE: disposal procedures, deletion records

CC6.6 — Logical access to assets¶

WHAT_AUDITORS_TEST:
- Protection from threats — encryption, firewalls, intrusion detection
GE_DEMONSTRATES:
- TLS 1.3 for all communication
- k8s network policies = microsegmentation
- Falco = runtime intrusion detection
- Encryption at rest for databases and backups
EVIDENCE: TLS config, network policies, Falco rules, encryption config

CC6.7 — Management of credentials¶

WHAT_AUDITORS_TEST:
- Credentials managed (creation, storage, rotation, revocation)
GE_DEMONSTRATES:
- Vault manages all secrets
- Automated rotation per policy
- No plaintext secrets in code or config (secrets scanning enforced)
EVIDENCE: Vault audit trail, rotation logs, scanning results

CC6.8 — Threats from external parties¶

WHAT_AUDITORS_TEST:
- Threats to system components from external sources managed
GE_DEMONSTRATES:
- Firewall, network policies
- DDoS protection at infrastructure level
- LLM provider API rate limiting
- Agent capability restrictions prevent external manipulation
EVIDENCE: firewall config, network policies, rate limit configs

CC7 — SYSTEM OPERATIONS¶

PURPOSE: detect and respond to anomalies and incidents affecting the system.

CC7.1 — Detection of anomalies¶

WHAT_AUDITORS_TEST:
- Monitoring infrastructure exists and is effective
- Anomalies detected in timely manner
GE_DEMONSTRATES:
- Falco (runtime monitoring)
- Monitoring agents (annegreet, ron) for pattern detection
- Cost gates detect anomalous spending
- k8s health monitoring
EVIDENCE: monitoring configuration, alert history, Falco events
CONTINUOUS_MONITORING: 24/7 automated, human review of alerts

CC7.2 — Monitoring for anomalies — system components¶

WHAT_AUDITORS_TEST:
- Monitoring covers system components including infrastructure, software, data
GE_DEMONSTRATES:
- k8s pod health monitoring
- Database connection monitoring
- Redis stream monitoring
- Application logging and alerting
EVIDENCE: monitoring dashboards, health check configurations

CC7.3 — Evaluation of security events¶

WHAT_AUDITORS_TEST:
- Events evaluated to determine if they are incidents
- Classification criteria documented
GE_DEMONSTRATES:
- mira (Incident Commander) classifies events
- Severity criteria: 3=warn, 5=escalate, 10=critical
- Documented classification matrix
EVIDENCE: classification procedure, event triage records

CC7.4 — Incident response¶

WHAT_AUDITORS_TEST:
- Incident response procedures exist and are followed
- Incidents contained, eradicated, recovered
GE_DEMONSTRATES:
- Incident response plan with playbooks
- mira coordinates response
- Post-incident review feeds learning cycle
EVIDENCE: incident response plan, incident records, post-incident reviews
SEE_ALSO: domains/incident-response/index.md

CC7.5 — Recovery from incidents¶

WHAT_AUDITORS_TEST:
- Recovery procedures exist
- System restored to normal operations
- Root cause identified
GE_DEMONSTRATES:
- Recovery procedures documented
- Backup restoration capability (monthly tested)
- Post-incident review includes root cause analysis
EVIDENCE: recovery procedures, backup test results, RCA reports

CC8 — CHANGE MANAGEMENT¶

PURPOSE: manage changes to infrastructure and software to prevent unintended consequences.

CC8.1 — Changes to infrastructure and software¶

WHAT_AUDITORS_TEST:
- Change management process exists
- Changes authorized, tested, approved, and documented
- Emergency change process defined
GE_DEMONSTRATES:
- All changes via git PRs
- marta (GitHub Goalkeeper) enforces branch protection
- koen/eric perform code review
- CI/CD pipeline runs automated tests
- leon (Deployment Coordinator) manages releases
- Emergency: hotfix developers (sandro, tobias) with expedited review
EVIDENCE: PR history, review records, CI/CD logs, deployment records
CONTINUOUS_MONITORING: every change tracked in git, deployment logs

RULE: no direct production changes without PR and review
RULE: never use kubectl cp — always rebuild container image
IF emergency change THEN expedited review by koen/eric, post-hoc documentation within 24h

CC9 — RISK MITIGATION¶

PURPOSE: identify, select, and develop risk mitigation activities.

CC9.1 — Risk mitigation activities¶

WHAT_AUDITORS_TEST:
- Risk mitigation activities aligned with risk assessment
- Vendor/supplier risk managed
- Business disruption risk managed
GE_DEMONSTRATES:
- Risk treatment plan derived from risk assessment
- Supplier security assessments (Anthropic, OpenAI, Google, Hetzner)
- Business continuity planning (otto)
- Cost gates prevent runaway costs
EVIDENCE: risk treatment plan, supplier assessments, BCP, cost gate configuration

CC9.2 — Vendor and business partner risk¶

WHAT_AUDITORS_TEST:
- Due diligence on vendors
- Ongoing monitoring of vendor risk
GE_DEMONSTRATES:
- LLM provider security assessment and monitoring
- Infrastructure provider (Hetzner) ISO 27001 verified
- Contractual security requirements
EVIDENCE: vendor assessments, Hetzner certifications, contracts

A1 — AVAILABILITY CRITERIA¶

PURPOSE: the system is available for operation and use as committed or agreed.

A1.1 — Planning for availability¶

WHAT_AUDITORS_TEST:
- Availability commitments defined
- System design supports availability requirements
GE_DEMONSTRATES:
- RTO/RPO defined per system component
- Multi-replica deployments for critical workloads
- Health monitoring with automated recovery
EVIDENCE: availability requirements, architecture documentation, RTO/RPO documentation

A1.2 — Environmental protections¶

WHAT_AUDITORS_TEST:
- Environmental threats (power, cooling, connectivity) managed
GE_DEMONSTRATES:
- Hetzner datacenter environmental controls
- k3s auto-recovery for pod failures
EVIDENCE: Hetzner documentation, k8s recovery configuration

A1.3 — Recovery from disruptions¶

WHAT_AUDITORS_TEST:
- Recovery procedures tested
- Backups exist and are tested
GE_DEMONSTRATES:
- Monthly backup restore tests (otto)
- k3s recovery procedures
- Database recovery procedures
EVIDENCE: restore test results, recovery procedure documentation

C1 — CONFIDENTIALITY CRITERIA¶

PURPOSE: information designated as confidential is protected as committed or agreed.

C1.1 — Identification of confidential information¶

WHAT_AUDITORS_TEST:
- Confidential information identified and classified
- Classification scheme documented
GE_DEMONSTRATES:
- Information classification scheme (PUBLIC/INTERNAL/CONFIDENTIAL/RESTRICTED)
- Client data classified as CONFIDENTIAL minimum
- Secrets classified as RESTRICTED
EVIDENCE: classification policy, classified asset inventory

C1.2 — Disposal of confidential information¶

WHAT_AUDITORS_TEST:
- Confidential information disposed of securely when no longer needed
GE_DEMONSTRATES:
- Retention policies with automated deletion
- Secure deletion for classified data
- Client data deletion per contract/GDPR
EVIDENCE: retention policy, deletion logs, secure deletion verification

PI1 — PROCESSING INTEGRITY CRITERIA¶

PURPOSE: system processing is complete, valid, accurate, timely, and authorized.

PI1.1 — Definitions of processing integrity¶

WHAT_AUDITORS_TEST:
- Processing integrity defined for the system
- Inputs, processing, and outputs validated
GE_DEMONSTRATES:
- anna (Formal Specification) defines expected processing behavior
- antje (TDD) writes tests before code
- jasper (Test Reconciliation) verifies spec vs result
- jaap (SSOT Enforcer) ensures data consistency
EVIDENCE: formal specifications, test suites, reconciliation reports, SSOT checks

PI1.2 — Processing accuracy¶

WHAT_AUDITORS_TEST:
- Outputs complete and accurate
- Error detection and correction
GE_DEMONSTRATES:
- Anti-LLM pipeline: anna→antje→devs→koen→marije→jasper→marco→ashley→jaap→marta
- Each stage validates previous stage output
- Errors caught by independent review at multiple gates
EVIDENCE: pipeline execution records, review outcomes, error correction logs

PI1.3 — System inputs¶

WHAT_AUDITORS_TEST:
- Inputs validated for completeness and accuracy
GE_DEMONSTRATES:
- Input validation in all API endpoints (Zod schema validation)
- Work package validation before assignment
- aimee (Scope Architect) validates client requirements
EVIDENCE: validation configuration, input rejection logs

PI1.4 — System outputs¶

WHAT_AUDITORS_TEST:
- Outputs reviewed for completeness and accuracy
GE_DEMONSTRATES:
- Code review (koen/eric) validates output quality
- Testing (marije/judith) validates functional correctness
- ashley (Adversarial) validates security
- jaap (SSOT) validates consistency
EVIDENCE: review records, test results, adversarial test results, SSOT check results

SOC_2_VS_ISO_27001_CROSSWALK¶

SOC 2 Criteria	ISO 27001 Equivalent
CC1 Control Environment	Clauses 5 (Leadership), 7 (Support)
CC2 Communication	Clause 7.4
CC3 Risk Assessment	Clause 6.1
CC4 Monitoring	Clause 9.1
CC5 Control Activities	Clause 8, Annex A
CC6 Logical Access	A.5.15-A.5.18, A.8.2-A.8.5
CC7 System Operations	A.5.24-A.5.28, A.8.15-A.8.16
CC8 Change Management	A.8.32-A.8.33
CC9 Risk Mitigation	Clause 6.1.3, A.5.19-A.5.22
A1 Availability	A.5.29-A.5.30, A.8.13-A.8.14
C1 Confidentiality	A.5.12-A.5.13, A.8.10-A.8.12
PI1 Processing Integrity	A.8.25-A.8.29

RULE: maintain ONE set of controls, map to BOTH frameworks
GE_APPROACH: implement controls per ISO 27001 Annex A, produce SOC 2 evidence from same controls

SEE_ALSO: soc2-type2-continuous.md, iso27001-overview.md, iso27001-annex-a.md, compliance-automation.md