DOMAIN:ISO27001_CONTROLS¶
OWNER: julian
UPDATED: 2026-03-24
SCOPE: ISO 27001:2022 Annex A controls mapped to GE operations
SERVES: julian (compliance officer), amber (auditor)
ALSO_USED_BY: boris (DB evidence), rutger (production compliance), koen (secure coding)
OVERVIEW¶
ISO 27001:2022 defines 93 controls across 4 themes.
GE operates as a software development agency with a multi-agent architecture.
Controls are mapped to: which agent owns compliance, how evidence is generated, where evidence is stored.
THREE_ZONE_ARCHITECTURE:
- ZONE_PUBLIC: Dima (intake), client-facing endpoints, DNS, CDN
- ZONE_SHARED: Aimee, Anna, Antje, Alexander, Julian, and shared service agents
- ZONE_TEAM: Alpha (Faye PM) and Beta (Sytske PM), isolated per-client work
EVIDENCE_SSOT: PostgreSQL compliance_evidence table
EVIDENCE_HUMAN: wiki at ge-ops/wiki/docs/domains/compliance-frameworks/
AUDIT_CYCLE: internal audit quarterly (Amber), external audit annually
THEME_A5 — ORGANIZATIONAL CONTROLS (37 controls)¶
A.5.1 — Policies for Information Security¶
TAG:A.5.1 TAG:ISMS_POLICY
REQUIRES: management-approved information security policy, communicated to all personnel
HOW_GE_SATISFIES:
- Constitution v2 (config/constitution.md) defines security principles for all agents
- Principle 3 (Enterprise-Grade From Day One) mandates security by default
- Principle 5 (Observable By Default) mandates traceability
- Agent identity documents include security responsibilities per role
OWNER: julian (policy authoring), ron (enforcement monitoring)
EVIDENCE_FORMAT: versioned policy document in wiki, acknowledgement logs per agent
EVIDENCE_LOCATION: wiki/docs/company/identity/ + config/constitution.md
REVIEW_FREQUENCY: annual or on significant change
A.5.2 — Information Security Roles and Responsibilities¶
TAG:A.5.2 TAG:ROLES
REQUIRES: defined and allocated information security roles
HOW_GE_SATISFIES:
- AGENT-REGISTRY.json defines every agent's role, team, and capabilities
- Julian: Compliance Officer — policy, controls, certifications
- Amber: Participation Auditor — internal audit, control effectiveness
- Ron: System Integrity Monitor — runtime enforcement
- Mira: Incident Commander — security incident response
- Boris: Database Administrator — data security, access controls
- Koen: Code Reviewer — secure coding enforcement
- Ashley: Adversarial Agent — pre-deployment security testing
OWNER: julian (role definition), jaap (SSOT enforcement)
EVIDENCE_FORMAT: AGENT-REGISTRY.json entries with role descriptions
REVIEW_FREQUENCY: on agent onboarding or role change
A.5.3 — Segregation of Duties¶
TAG:A.5.3 TAG:SOD
REQUIRES: conflicting duties separated to reduce fraud/error risk
HOW_GE_SATISFIES:
- Anti-LLM pipeline enforces separation: Anna(spec) -> Antje(TDD) -> Devs -> Koen(linting) -> Marije(test) -> Jasper(reconcile) -> Marco(conflict) -> Ashley(adversarial) -> Jaap(SSOT) -> Marta(merge)
- No agent both writes and approves code
- No agent both deploys and monitors
- Amber audits but does not implement controls
- Executor capability restrictions prevent role boundary violations
OWNER: julian (policy), amber (verification)
EVIDENCE_FORMAT: pipeline execution logs showing distinct agent per phase
ZONE_MAPPING: applies across all three zones — team agents cannot merge their own PRs
A.5.7 — Threat Intelligence¶
TAG:A.5.7 TAG:THREAT_INTEL TAG:NEW_2022
REQUIRES: collect, analyze, and use threat intelligence
HOW_GE_SATISFIES:
- Annegreet (Knowledge Curator) monitors security advisories and CVE feeds
- Eltjo (Cross-Session Learning) extracts security patterns from agent sessions
- Trivy scanning produces vulnerability intelligence per container image
- Dependency scanning (SBOM) identifies supply chain threats
- Wiki brain aggregates threat context across sessions
OWNER: julian (threat assessment), annegreet (intelligence collection)
EVIDENCE_FORMAT: threat intelligence reports in wiki, Trivy scan results, CVE tracking
REVIEW_FREQUENCY: continuous (automated), monthly (human review of trends)
A.5.8 — Information Security in Project Management¶
TAG:A.5.8 TAG:PROJECT_SECURITY
REQUIRES: integrate information security into project management
HOW_GE_SATISFIES:
- Delivery pipeline includes security gates: Antje(TDD with security cases), Ashley(adversarial testing)
- Aimee (Scoping) assesses security requirements during project intake
- Anna (Formal Specification) includes security requirements in every spec
- Faye/Sytske (Project Managers) track security work items in DAG
- Regulatory assessment framework applied to every new client project (see eu-regulation/index.md)
OWNER: julian (security requirements template), faye/sytske (integration into project plan)
EVIDENCE_FORMAT: project security assessment records, security work items in DAG
A.5.9 — Inventory of Information and Associated Assets¶
TAG:A.5.9 TAG:ASSET_INVENTORY
REQUIRES: identify, inventory, and assign ownership to information assets
HOW_GE_SATISFIES:
- AGENT-REGISTRY.json inventories all computational agents
- k8s resource inventory via scripts/k8s-health-dump.sh
- PostgreSQL schema tracks all data assets (tables, columns, sensitivity classification)
- Client project assets tracked per-project in work packages
- SBOM generation for software dependencies
OWNER: jaap (SSOT enforcement), boris (data assets), rutger (infrastructure assets)
EVIDENCE_FORMAT: AGENT-REGISTRY.json, k8s manifests, SBOM files, DB schema documentation
REVIEW_FREQUENCY: continuous (automated inventory), quarterly (completeness review)
A.5.10 — Acceptable Use of Information¶
TAG:A.5.10 TAG:ACCEPTABLE_USE
REQUIRES: rules for acceptable use of information and assets
HOW_GE_SATISFIES:
- Constitution v2 defines acceptable behavior for all agents
- CODEBASE-STANDARDS.md defines file allocation, forbidden actions
- Token burn prevention rules define resource usage limits
- Cost gate enforces budget limits ($5/session, $10/agent/hr, $100/day)
OWNER: julian (policy), ron (enforcement)
EVIDENCE_FORMAT: constitution document, cost gate logs, policy violation alerts
A.5.14 — Information Transfer¶
TAG:A.5.14 TAG:DATA_TRANSFER
REQUIRES: rules, procedures, and agreements for information transfer
HOW_GE_SATISFIES:
- Agent communication exclusively via Redis Streams (encrypted in transit)
- No direct agent-to-agent communication outside defined channels
- Client data never leaves k3s cluster except via defined API endpoints
- TLS 1.3 on all external endpoints
- ZONE_PUBLIC to ZONE_TEAM transfer requires authentication through pipeline
OWNER: julian (transfer policy), boris (data transfer controls)
EVIDENCE_FORMAT: Redis stream configuration, TLS certificates, network policy manifests
A.5.23 — Information Security for Cloud Services¶
TAG:A.5.23 TAG:CLOUD_SECURITY TAG:NEW_2022
REQUIRES: manage cloud service security including acquisition, use, management, exit
HOW_GE_SATISFIES:
- k3s single-node cluster on controlled infrastructure (not public cloud dependency)
- LLM provider assessment: Anthropic (GPAI Code of Practice signatory), OpenAI, Google
- Provider configuration in config/providers/*.yaml
- Data processing agreements with all LLM providers
- No client PII sent to LLM providers (data masking pre-processing)
OWNER: julian (cloud security policy), rutger (infrastructure security)
EVIDENCE_FORMAT: vendor security assessments, DPAs, data flow diagrams
REVIEW_FREQUENCY: annual vendor review, on provider change
A.5.24 — Information Security Incident Management Planning¶
TAG:A.5.24 TAG:INCIDENT_PLANNING
REQUIRES: planned and documented approach to incident management
HOW_GE_SATISFIES:
- Full incident lifecycle documented at domains/incident-response/index.md
- Mira as designated Incident Commander
- Severity classification (SEV1-4) with defined SLAs
- Communication templates for internal and client-facing notifications
- Post-mortem template with mandatory action items
OWNER: mira (incident management), julian (compliance alignment)
EVIDENCE_FORMAT: incident procedure documents, incident records in PostgreSQL
CROSS_REF: domains/incident-response/index.md
A.5.25 — Assessment and Decision on Information Security Events¶
TAG:A.5.25 TAG:EVENT_ASSESSMENT
REQUIRES: assess security events and decide if they are incidents
HOW_GE_SATISFIES:
- Ron (System Integrity Monitor) performs first-pass assessment
- Health escalation thresholds: 3=warn, 5=escalate to mira, 10=critical
- Classification criteria defined per severity level
- Two-signal verification before escalation (prevents false positive fatigue)
OWNER: ron (detection), mira (classification decision)
EVIDENCE_FORMAT: event assessment logs, classification decisions with rationale
A.5.26 — Response to Information Security Incidents¶
TAG:A.5.26 TAG:INCIDENT_RESPONSE
REQUIRES: respond to incidents per documented procedures
HOW_GE_SATISFIES:
- First 5 minutes: acknowledge, classify, page responders
- First 15 minutes: gather data, form hypothesis, decide action
- First hour: mitigate or escalate
- Rollback-first philosophy (fastest mitigation)
- All actions timestamped in incident record (compliance evidence)
OWNER: mira (response coordination)
EVIDENCE_FORMAT: incident timeline records with timestamped actions
CROSS_REF: domains/incident-response/index.md RESPOND section
A.5.27 — Learning from Information Security Incidents¶
TAG:A.5.27 TAG:INCIDENT_LEARNING
REQUIRES: use incident knowledge to strengthen controls
HOW_GE_SATISFIES:
- Mandatory blameless post-mortem within 48 hours
- Every SEV1/SEV2 produces at least one wiki brain learning
- Eltjo (Cross-Session Learning) extracts patterns across incidents
- Action items require owners, deadlines, and tracking to closure
- Knowledge synthesizer (6-hourly) detects cross-incident patterns
OWNER: mira (post-mortem), eltjo (pattern extraction), julian (control updates)
EVIDENCE_FORMAT: post-mortem documents, action item closure records, updated controls
A.5.29 — Information Security During Disruption¶
TAG:A.5.29 TAG:BUSINESS_CONTINUITY
REQUIRES: maintain security during disruptions
HOW_GE_SATISFIES:
- ge-orchestrator runs 2 replicas with HA consumer group
- PodDisruptionBudget prevents simultaneous pod termination
- Recovery phase: startup drain + 2-phase orphan claiming + stale consumer cleanup
- Circuit breaker prevents cascading failures
- Cost gate prevents token burn during recovery
OWNER: rutger (infrastructure continuity), mira (incident continuity)
EVIDENCE_FORMAT: PDB configurations, HA test results, recovery procedure documentation
A.5.30 — ICT Readiness for Business Continuity¶
TAG:A.5.30 TAG:ICT_CONTINUITY TAG:NEW_2022
REQUIRES: ICT services ready to support business continuity
HOW_GE_SATISFIES:
- k3s cluster with automated recovery
- PostgreSQL as SSOT with backup procedures
- Redis Streams with consumer group failover
- Agent registry enables rapid agent re-provisioning
- Container images stored locally (no external registry dependency)
OWNER: rutger (ICT readiness), boris (database continuity)
EVIDENCE_FORMAT: backup test results, recovery time measurements, BIA documentation
THEME_A6 — PEOPLE CONTROLS (8 controls)¶
A.6.1 — Screening¶
TAG:A.6.1 TAG:SCREENING
REQUIRES: background verification on candidates before joining
GE_CONTEXT: agents are AI, not humans — screening = identity commissioning
HOW_GE_SATISFIES:
- Agent Commissioning process (AGENT-COMMISSIONING.md) — Dirk-Jan reviews EVERY agent
- Tiered identity: CORE + ROLE + REFERENCE verified per agent
- Agent profiling pipeline ensures alignment before activation
OWNER: julian (commissioning compliance), dirk-jan (human approval)
A.6.3 — Information Security Awareness, Education and Training¶
TAG:A.6.3 TAG:AWARENESS
REQUIRES: ongoing security awareness program
HOW_GE_SATISFIES:
- Constitution v2 injected on every agent boot (JIT learning)
- Wiki brain provides domain-specific security knowledge per task
- Session learnings include security findings
- Annegreet curates security knowledge for wiki brain
OWNER: julian (training content), annegreet (knowledge curation)
EVIDENCE_FORMAT: constitution acknowledgement logs, wiki access logs
THEME_A7 — PHYSICAL CONTROLS (14 controls)¶
NOTE: GE operates on a single physical node (192.168.1.85). Physical controls are minimal but documented.
A.7.1 — Physical Security Perimeters¶
TAG:A.7.1 TAG:PHYSICAL
REQUIRES: defined and protected physical security perimeters
HOW_GE_SATISFIES:
- Server located in physically secured premises
- No public datacenter — single controlled location
- Physical access restricted to Dirk-Jan
OWNER: dirk-jan (physical security)
EVIDENCE_FORMAT: physical access log (manual), location documentation
THEME_A8 — TECHNOLOGICAL CONTROLS (34 controls)¶
A.8.1 — User Endpoint Devices¶
TAG:A.8.1 TAG:ENDPOINTS
REQUIRES: protect information on user endpoint devices
HOW_GE_SATISFIES:
- Agents run in containers (isolated execution environments)
- No persistent storage on agent containers (stateless execution)
- Admin-UI accessed via WebAuthn (hardware key authentication)
- No shared credentials between agents
OWNER: rutger (container security), julian (endpoint policy)
EVIDENCE_FORMAT: container security scan results, WebAuthn configuration
A.8.2 — Privileged Access Rights¶
TAG:A.8.2 TAG:PRIVILEGED_ACCESS
REQUIRES: restrict and manage privileged access
HOW_GE_SATISFIES:
- k8s RBAC restricts agent capabilities per role
- Executor capability restrictions prevent privilege escalation
- Vault stores secrets with per-agent access policies
- Admin-UI requires WebAuthn — no password-based admin access
- Database access restricted to boris (DBA) and admin-ui service account
OWNER: julian (access policy), rutger (RBAC implementation)
EVIDENCE_FORMAT: RBAC manifests, Vault policy documents, access review logs
REVIEW_FREQUENCY: quarterly access review
A.8.3 — Information Access Restriction¶
TAG:A.8.3 TAG:ACCESS_RESTRICTION
REQUIRES: restrict access to information per access control policy
HOW_GE_SATISFIES:
- Three-zone architecture enforces information boundaries
- ZONE_PUBLIC agents (Dima) have zero internal knowledge by design
- ZONE_TEAM agents access only their team's client data
- Network policies in k3s enforce zone boundaries
- Client data isolation: per-client database schemas or row-level security
OWNER: julian (access policy), boris (database access controls)
EVIDENCE_FORMAT: network policy manifests, database permission matrices
ZONE_MAPPING: critical — this control IS the three-zone architecture
A.8.5 — Secure Authentication¶
TAG:A.8.5 TAG:AUTHENTICATION
REQUIRES: secure authentication technologies and procedures
HOW_GE_SATISFIES:
- Admin-UI: WebAuthn (FIDO2 hardware keys) — no passwords
- Agent-to-service: internal API tokens via Vault
- Inter-service: mTLS within k3s cluster
- Client applications: OAuth 2.0 / OIDC recommended architecture
OWNER: julian (auth policy), rutger (implementation)
EVIDENCE_FORMAT: WebAuthn configuration, Vault token policies, TLS certificate inventory
PITFALL: challenge MUST be in httpOnly cookie between /api/auth/challenge and /api/auth/verify
A.8.7 — Protection Against Malware¶
TAG:A.8.7 TAG:MALWARE
REQUIRES: protection against malware
HOW_GE_SATISFIES:
- Container images built from controlled base images
- Trivy scanning on all container images
- No arbitrary code execution from external sources
- Agent executor runs in sandboxed containers
- Supply chain security via SBOM and dependency scanning
OWNER: julian (malware policy), rutger (scanning implementation)
EVIDENCE_FORMAT: Trivy scan reports, SBOM manifests, container build logs
A.8.8 — Management of Technical Vulnerabilities¶
TAG:A.8.8 TAG:VULNERABILITY_MANAGEMENT
REQUIRES: identify, evaluate, and manage technical vulnerabilities
HOW_GE_SATISFIES:
- Trivy scanning with severity thresholds (critical/high/medium/low)
- Patch SLAs: critical=24hr, high=7d, medium=30d, low=90d
- Dependency tracking via SBOM
- Semgrep rules for code-level vulnerabilities
- Koen (Code Reviewer) enforces secure coding standards
OWNER: julian (vuln management policy), koen (code vulnerabilities), rutger (infrastructure vulnerabilities)
EVIDENCE_FORMAT: Trivy reports, patch tracking records, Semgrep scan results
REVIEW_FREQUENCY: continuous (automated), weekly (triage of findings)
A.8.9 — Configuration Management¶
TAG:A.8.9 TAG:CONFIG_MANAGEMENT TAG:NEW_2022
REQUIRES: manage security configurations for hardware, software, services, networks
HOW_GE_SATISFIES:
- Constitution Principle 1: "Config Is King" — all config in version-controlled files
- config/ports.yaml, config/dolly-routing.yaml, config/agent-execution.yaml
- GitOps: infrastructure-as-code for k8s manifests
- kube-bench for CIS Kubernetes Benchmark compliance
- Config drift detection via reconciliation
OWNER: jaap (SSOT enforcement), rutger (infrastructure config)
EVIDENCE_FORMAT: git commit history for config files, kube-bench reports, config audit logs
A.8.10 — Information Deletion¶
TAG:A.8.10 TAG:DATA_DELETION TAG:NEW_2022
REQUIRES: delete information when no longer needed
HOW_GE_SATISFIES:
- Data retention policies per data classification
- Automated retention enforcement in PostgreSQL
- Client data deletion on project completion or client request (GDPR right to erasure)
- Log rotation with defined retention periods
- Redis stream MAXLEN prevents unbounded data accumulation
OWNER: boris (database deletion), julian (retention policy)
EVIDENCE_FORMAT: retention policy document, deletion execution logs, MAXLEN configurations
A.8.11 — Data Masking¶
TAG:A.8.11 TAG:DATA_MASKING TAG:NEW_2022
REQUIRES: mask personal and sensitive data per policy
HOW_GE_SATISFIES:
- PII masking before sending data to LLM providers
- Semgrep rules detect PII in logs and code
- Data classification guides masking requirements
- Test environments use masked/synthetic data
OWNER: julian (masking policy), boris (database masking implementation)
EVIDENCE_FORMAT: masking rule configurations, PII detection scan results
A.8.12 — Data Leakage Prevention¶
TAG:A.8.12 TAG:DLP TAG:NEW_2022
REQUIRES: apply DLP measures to systems and networks
HOW_GE_SATISFIES:
- Secrets scanning in CI/CD pipeline
- No client PII transmitted to external LLM APIs
- Network policies restrict data egress from team zones
- Dima (public-facing) is stateless — zero internal knowledge, unhackable by design
- Agent executor containers have no outbound internet access except to LLM APIs
OWNER: julian (DLP policy), ron (runtime monitoring)
EVIDENCE_FORMAT: secrets scan results, network policy manifests, data flow diagrams
A.8.15 — Logging¶
TAG:A.8.15 TAG:LOGGING
REQUIRES: produce, store, protect, and analyze logs
HOW_GE_SATISFIES:
- PTY capture produces structured traces of all agent sessions
- k8s audit logging for API server events
- PostgreSQL audit trails for data access
- Centralized logging via Loki
- Log integrity protection (append-only, tamper-evident)
OWNER: ron (log monitoring), rutger (log infrastructure), julian (log policy)
EVIDENCE_FORMAT: logging configuration, log retention records, sample audit queries
A.8.16 — Monitoring Activities¶
TAG:A.8.16 TAG:MONITORING TAG:NEW_2022
REQUIRES: monitor for anomalous behavior
HOW_GE_SATISFIES:
- Ron (System Integrity Monitor) performs continuous monitoring
- Health escalation: 3=warn, 5=escalate to mira, 10=critical
- Grafana dashboards for system metrics
- Loki for log aggregation and alerting
- Cost gate monitors for abnormal token consumption
- Agent execution dedup prevents double-delivery
OWNER: ron (operational monitoring), mira (incident detection)
EVIDENCE_FORMAT: monitoring configuration, alert rules, escalation records
A.8.23 — Web Filtering¶
TAG:A.8.23 TAG:WEB_FILTERING TAG:NEW_2022
REQUIRES: manage access to external websites
HOW_GE_SATISFIES:
- k3s network policies restrict external access
- Agent containers have limited egress (LLM APIs, package registries)
- No general internet browsing from agent containers
- DNS-level filtering for known malicious domains
OWNER: rutger (network policy), julian (filtering policy)
EVIDENCE_FORMAT: network policy manifests, egress rule documentation
A.8.24 — Use of Cryptography¶
TAG:A.8.24 TAG:CRYPTOGRAPHY
REQUIRES: define and implement rules for cryptography
HOW_GE_SATISFIES:
- TLS 1.3 for all external communications
- AES-256 for data at rest
- Vault for secrets management (key lifecycle)
- WebAuthn uses public-key cryptography (no shared secrets)
- PostgreSQL SSL connections enforced
OWNER: julian (crypto policy), rutger (implementation)
EVIDENCE_FORMAT: TLS configuration, Vault seal status, encryption configuration
A.8.25 — Secure Development Life Cycle¶
TAG:A.8.25 TAG:SDLC
REQUIRES: establish rules for secure development
HOW_GE_SATISFIES:
- Anti-LLM pipeline: 10-stage pipeline with security gates at multiple points
- Antje: TDD with security test cases
- Koen: secure code review with Semgrep rules
- Ashley: adversarial pre-deployment testing
- Marije: testing lead ensures security test coverage
- CODEBASE-STANDARDS.md defines secure coding requirements
OWNER: julian (SDLC policy), koen (secure coding standards)
EVIDENCE_FORMAT: pipeline execution logs, code review records, security test results
A.8.26 — Application Security Requirements¶
TAG:A.8.26 TAG:APP_SECURITY_REQ
REQUIRES: identify, specify, and approve security requirements for applications
HOW_GE_SATISFIES:
- Anna (Formal Specification) includes security requirements in every spec
- OWASP ASVS Level 1 as minimum baseline for all client projects
- Regulatory assessment framework identifies sector-specific requirements
- Security requirements tracked as work items in DAG
OWNER: anna (specification), julian (security requirement templates)
EVIDENCE_FORMAT: specification documents with security sections, ASVS compliance checklists
A.8.28 — Secure Coding¶
TAG:A.8.28 TAG:SECURE_CODING TAG:NEW_2022
REQUIRES: apply secure coding principles
HOW_GE_SATISFIES:
- Semgrep rules mapped to OWASP ASVS requirements
- Koen (Code Reviewer) enforces secure coding in every review
- CODEBASE-STANDARDS.md defines forbidden patterns
- Constitution Principle 8 (Idempotent By Design) prevents race conditions
- Constitution Principle 10 (No Hardcoded Values) prevents secret leakage
- Input validation, output encoding, parameterized queries enforced by linting
OWNER: koen (enforcement), julian (standards definition)
EVIDENCE_FORMAT: Semgrep scan results, code review records, linting reports
A.8.31 — Separation of Development, Test, and Production¶
TAG:A.8.31 TAG:ENV_SEPARATION
REQUIRES: separate development, testing, and production environments
HOW_GE_SATISFIES:
- k3s namespaces separate environments
- Production data never used in development/test (synthetic data policy)
- Deployment pipeline enforces promotion path: dev -> staging -> production
- Marta (GitHub Goalkeeper) controls production merges
OWNER: rutger (environment infrastructure), marta (merge control)
EVIDENCE_FORMAT: namespace configurations, deployment pipeline logs, merge approval records
A.8.32 — Change Management¶
TAG:A.8.32 TAG:CHANGE_MANAGEMENT
REQUIRES: manage changes to information processing facilities and systems
HOW_GE_SATISFIES:
- Git-based change tracking with feature branches
- Anti-LLM pipeline enforces review before merge
- Marta (GitHub Goalkeeper) controls what reaches production
- Constitution Principle 6 (Blast Radius Awareness) requires impact analysis
- Container image rebuild required for all code changes (no hot-patching)
OWNER: marta (change control), julian (change management policy)
EVIDENCE_FORMAT: git history, PR review records, deployment logs
CROSS_REF: soc2-criteria.md CC8 section
CONTROL_EVIDENCE_SUMMARY¶
| Control | Owner Agent | Evidence Type | Automation Level |
|---|---|---|---|
| A.5.1 | julian | Policy documents | Manual (annual review) |
| A.5.2 | julian | AGENT-REGISTRY.json | Automated (registry) |
| A.5.3 | julian, amber | Pipeline execution logs | Automated (pipeline) |
| A.5.7 | annegreet | Trivy/CVE reports | Automated (scanning) |
| A.5.8 | faye/sytske | Project security assessments | Semi-automated |
| A.5.9 | jaap | Asset inventories | Automated (k8s + registry) |
| A.5.23 | julian | Vendor assessments, DPAs | Manual (annual) |
| A.5.24 | mira | Incident procedures | Manual (review) |
| A.8.2 | julian | RBAC manifests, Vault policies | Automated (k8s) |
| A.8.3 | boris | Network policies, DB permissions | Automated (k8s) |
| A.8.5 | julian | WebAuthn config, token policies | Automated |
| A.8.8 | koen, rutger | Trivy + Semgrep reports | Automated (CI/CD) |
| A.8.9 | jaap | Git history, kube-bench | Automated |
| A.8.15 | ron | Logging config, audit queries | Automated |
| A.8.16 | ron | Alert rules, dashboards | Automated |
| A.8.25 | koen | Pipeline logs, review records | Automated (pipeline) |
| A.8.28 | koen | Semgrep + linting results | Automated (CI/CD) |
| A.8.32 | marta | Git history, PR records | Automated (git) |
CERTIFICATION_APPROACH¶
PHASE_1 (current): implement controls, generate evidence, internal audit (Amber)
PHASE_2: gap analysis against full Annex A
PHASE_3: engage external auditor for Stage 1 (documentation review)
PHASE_4: remediate findings
PHASE_5: Stage 2 audit (implementation effectiveness)
PHASE_6: certification issued (3-year cycle, annual surveillance)
SCOPE_OF_CERTIFICATION: GE multi-agent software development platform and client project delivery
STATEMENT_OF_APPLICABILITY: document which controls apply and which are excluded with justification
READ_ALSO: soc2-criteria.md, gdpr-implementation.md, evidence-automation.md, domains/security/index.md