ISO/IEC 27001:2022 Annex A mapping (hosted edition) ​
Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.
This document maps the 93 controls of ISO/IEC 27001:2022 Annex A to the hosted (Enterprise) edition of CodeLotse as operated by Quavon UG (haftungsbeschränkt). The hosted edition is not in operation yet; hosted operations are planned. Self-hosted customers operate their own ISMS and can reuse the rows that describe product controls (code, tests and configuration in this repository) as evidence for their own Statement of Applicability. This is a readiness mapping, not a Statement of Applicability, and no certification exists. Owners are roles, not named persons.
Legend ​
- Applicable: Yes / No for the hosted edition.
- Status:
implemented(the control is met and evidence exists),partial(some evidence exists, gaps are named),planned(no evidence yet),not applicable(reason given). - Evidence: a repository file or test, or "ISMS record (to create)" for organisational evidence that lives outside the repository.
- "Defined in CI" means the check is configured in the CI workflow; the pipeline has not run on a hosted Git remote yet. The same checks run locally through
pnpmscripts.
5 Organizational controls (37) ​
| Control | Title | Applicable | Status | Implementation and evidence | Owner role |
|---|---|---|---|---|---|
| 5.1 | Policies for information security | Yes | planned | No approved information security policy set yet. Contributor security rules exist in AGENTS.md. ISMS record (to create): policy set approved by management. | ISMS owner |
| 5.2 | Information security roles and responsibilities | Yes | partial | Product security incident roles are defined in psirt.md. ISMS roles (ISMS owner, DPO) are not yet appointed. ISMS record (to create): role assignment. | HR / management |
| 5.3 | Segregation of duties | Yes | partial | The product separates instance administration from tenant administration, keeps the write-capable Fixer app separate and opt-in, and requires approval for draft PRs by default (ADR-0006, ADR-0007). Organisational segregation for hosted operations is not defined. ISMS record (to create). | ISMS owner |
| 5.4 | Management responsibilities | Yes | planned | ISMS record (to create): management commitment and resourcing. | HR / management |
| 5.5 | Contact with authorities | Yes | partial | CRA reporting via ENISA's Single Reporting Platform and GDPR Art. 33 notification paths are described in psirt.md. Contact list for authorities: ISMS record (to create). | PSIRT lead |
| 5.6 | Contact with special interest groups | Yes | planned | ISMS record (to create): memberships and subscriptions (for example CERT advisories, ecosystem security lists). | ISMS owner |
| 5.7 | Threat intelligence | Yes | partial | Dependency and image vulnerability data from OSV-Scanner and grype (defined in ci.yml), weekly update proposals via dependabot.yml, threat model reviewed with every change that adds an entry point, write path or agent capability (threat-model.md). No structured threat intelligence process for hosted operations yet. | PSIRT lead |
| 5.8 | Information security in project management | Yes | partial | Each change that adds an entry point, write path or agent capability updates the threat model; design decisions are recorded as ADRs (for example ADR-0002, ADR-0012). A project-management procedure for non-engineering projects is not defined. | Engineering lead |
| 5.9 | Inventory of information and other associated assets | Yes | partial | Data and stores are listed in data-inventory.md; security-relevant assets in threat-model.md §2. Hosted infrastructure asset register: ISMS record (to create). | Operations lead |
| 5.10 | Acceptable use of information and other associated assets | Yes | planned | ISMS record (to create): acceptable use policy for staff and systems. | ISMS owner |
| 5.11 | Return of assets | Yes | planned | ISMS record (to create): offboarding checklist covering devices, credentials and access. | HR / management |
| 5.12 | Classification of information | Yes | partial | data-inventory.md identifies personal data and secrets per store. No formal classification scheme. ISMS record (to create). | ISMS owner |
| 5.13 | Labelling of information | Yes | planned | ISMS record (to create): labelling rules derived from the classification scheme. | ISMS owner |
| 5.14 | Information transfer | Yes | partial | TLS termination by Caddy (Caddyfile); webhook HMAC verification (webhooks.int.test.ts); signed sandbox jobs and AES-256-GCM encrypted snapshot transport (ADR-0012). Transfer agreements with customers: dpa-art28.md (template). | Engineering lead |
| 5.15 | Access control | Yes | partial | Product: every route declares a permission and the API refuses to start otherwise (contract.test.ts); tenant isolation with forced RLS (rls.int.test.ts). Access control policy for hosted infrastructure: ISMS record (to create). | ISMS owner |
| 5.16 | Identity management | Yes | partial | User identities come from the git provider, unique per provider, host and external id; no local passwords (ADR-0007, auth.int.test.ts). Identity lifecycle for operator staff accounts: ISMS record (to create). | Operations lead |
| 5.17 | Authentication information | Yes | partial | Only SHA-256 hashes of session, CSRF and setup tokens are stored; provider tokens are encrypted; setup and break-glass links are single use (ADR-0007, setup.int.test.ts). Rules for operator credentials: ISMS record (to create). | Engineering lead |
| 5.18 | Access rights | Yes | partial | Grants are derived from GitHub roles, cached per tenant and repository and re-checked for mutations (ADR-0007, routes.int.test.ts). Periodic access review for operator accounts: ISMS record (to create). | Operations lead |
| 5.19 | Information security in supplier relationships | Yes | planned | No supplier register yet. Draft subprocessor list: subprocessors.md. ISMS record (to create): supplier register and risk assessment (hosting provider netcup, model providers chosen by tenants). | ISMS owner |
| 5.20 | Addressing information security within supplier agreements | Yes | planned | ISMS record (to create): reviewed agreements with suppliers. Customer-facing template: dpa-art28.md. | DPO (to appoint) |
| 5.21 | Managing information security in the ICT supply chain | Yes | partial | License gate (policy.yaml, licenses.test.ts), pinned exact versions (AGENTS.md), base images pinned by digest (Dockerfile), CycloneDX SBOM via syft and grype image scan defined in ci.yml, SBOM delivery in sbom-delivery.md. Supplier assessments for services: ISMS record (to create). | Engineering lead |
| 5.22 | Monitoring, review and change management of supplier services | Yes | planned | ISMS record (to create): periodic supplier reviews and change tracking. | Operations lead |
| 5.23 | Information security for use of cloud services | Yes | planned | ISMS record (to create): cloud service policy covering acquisition, use, management and exit for the hosting provider. | Operations lead |
| 5.24 | Information security incident management planning and preparation | Yes | partial | Intake, triage, CRA deadlines and roles in psirt.md; reporting channel in SECURITY.md; vulnerability handling in vulnerability-handling.md. Tabletop exercise and hosted incident runbook not done. | PSIRT lead |
| 5.25 | Assessment and decision on information security events | Yes | partial | Severity assessment (CVSS v4), exploitation and severe-incident questions in psirt.md. Event triage for hosted operations is not defined. | PSIRT lead |
| 5.26 | Response to information security incidents | Yes | partial | Fix, advisory and release steps, including "deploy the fix to the hosted edition before or at publication", in psirt.md. Not yet exercised. | PSIRT lead |
| 5.27 | Learning from information security incidents | Yes | partial | Post-incident review within 10 business days and threat-model updates required by psirt.md. No incidents recorded yet. | PSIRT lead |
| 5.28 | Collection of evidence | Yes | partial | Append-only, hash-chained audit log with verification (audit.int.test.ts); awareness time recorded in advisories (psirt.md). Forensic evidence procedure for hosted systems: ISMS record (to create). | PSIRT lead |
| 5.29 | Information security during disruption | Yes | planned | ISMS record (to create): continuity plan that keeps security controls in place during disruption. | Operations lead |
| 5.30 | ICT readiness for business continuity | Yes | planned | No backup or restore command yet (ADR-0009); recovery objectives and restore drills open. ISMS record (to create). | Operations lead |
| 5.31 | Legal, statutory, regulatory and contractual requirements | Yes | partial | CRA reporting (psirt.md), proposed GDPR legal bases (data-inventory.md), TOMs (toms.md), AI literacy (art4-ai-literacy.md). Register of legal requirements: ISMS record (to create). | DPO (to appoint) |
| 5.32 | Intellectual property rights | Yes | implemented | Allowed licenses in policy.yaml, enforced by licenses.test.ts (pnpm verify:licenses, defined in CI); commit attribution checks (no tool co-authors or generated-by footers) and DCO sign-off (attribution.test.ts); rules in AGENTS.md. | Engineering lead |
| 5.33 | Protection of records | Yes | partial | Audit log is append-only for all database roles and hash-chained (audit.int.test.ts, ADR-0002). Audit log retention is not decided (ADR-0008); record retention schedule: ISMS record (to create). | DPO (to appoint) |
| 5.34 | Privacy and protection of PII | Yes | partial | data-inventory.md, toms.md, retention jobs (maintenance.int.test.ts), assignment privacy gates (ADR-0014). Per-person export and deletion (quavon dsar) is not implemented yet; DPO not appointed. | DPO (to appoint) |
| 5.35 | Independent review of information security | Yes | planned | No independent review or penetration test yet (threat-model.md §5). ISMS record (to create): review plan. | ISMS owner |
| 5.36 | Compliance with policies, rules and standards for information security | Yes | partial | Contributor rules in AGENTS.md are checked by lint, secret, license, attribution, migration and vulnerability gates defined in ci.yml. Compliance reviews for hosted operations: ISMS record (to create). | ISMS owner |
| 5.37 | Documented operating procedures | Yes | partial | Self-hosted procedures: install.md, operations.md, doctor.md, sandbox.md. Hosted-edition runbooks do not exist yet. | Operations lead |
6 People controls (8) ​
| Control | Title | Applicable | Status | Implementation and evidence | Owner role |
|---|---|---|---|---|---|
| 6.1 | Screening | Yes | planned | ISMS record (to create): background verification proportionate to access to customer data. | HR / management |
| 6.2 | Terms and conditions of employment | Yes | planned | ISMS record (to create): security responsibilities in employment and contractor agreements. | HR / management |
| 6.3 | Information security awareness, education and training | Yes | partial | AI literacy measures in art4-ai-literacy.md; contributor security rules in AGENTS.md. General security awareness programme and training records: ISMS record (to create). | ISMS owner |
| 6.4 | Disciplinary process | Yes | planned | ISMS record (to create): communicated disciplinary process for policy violations. | HR / management |
| 6.5 | Responsibilities after termination or change of employment | Yes | planned | ISMS record (to create): post-employment confidentiality duties and access removal. | HR / management |
| 6.6 | Confidentiality or non-disclosure agreements | Yes | planned | ISMS record (to create): signed NDAs for staff and contractors. | HR / management |
| 6.7 | Remote working | Yes | planned | ISMS record (to create): remote working policy (devices, networks, storage). | ISMS owner |
| 6.8 | Information security event reporting | Yes | partial | External reporting channel in SECURITY.md; internal detection is an intake path in psirt.md. Internal staff reporting procedure: ISMS record (to create). | PSIRT lead |
7 Physical controls (14) ​
netcup (Germany) is the confirmed hosting provider of the hosted edition; the data centre location is to be confirmed from the contract. Data-centre controls are inherited from that provider; supplier evidence (certificates, audit reports, contract terms) still has to be collected and assessed. Controls that concern Quavon's own workplaces and devices need internal ISMS records.
| Control | Title | Applicable | Status | Implementation and evidence | Owner role |
|---|---|---|---|---|---|
| 7.1 | Physical security perimeters | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.2 | Physical entry | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.3 | Securing offices, rooms and facilities | Yes | planned | Data centre inherited from netcup; Quavon workplaces covered by ISMS record (to create). | ISMS owner |
| 7.4 | Physical security monitoring | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.5 | Protecting against physical and environmental threats | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.6 | Working in secure areas | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.7 | Clear desk and clear screen | Yes | planned | ISMS record (to create): clear desk and clear screen rules for staff. | ISMS owner |
| 7.8 | Equipment siting and protection | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.9 | Security of assets off-premises | Yes | planned | ISMS record (to create): rules for staff devices outside the workplace. | ISMS owner |
| 7.10 | Storage media | Yes | planned | Server storage inherited from netcup; removable media rules for staff in ISMS record (to create). | Operations lead |
| 7.11 | Supporting utilities | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.12 | Cabling security | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.13 | Equipment maintenance | Yes | planned | Inherited from netcup data centre. ISMS record (to create): supplier evidence. | Operations lead |
| 7.14 | Secure disposal or re-use of equipment | Yes | planned | Server media inherited from netcup; staff devices covered by ISMS record (to create). Encrypted columns limit exposure of stored secrets on disposed media (encrypted-columns.test.ts). | Operations lead |
8 Technological controls (34) ​
| Control | Title | Applicable | Status | Implementation and evidence | Owner role |
|---|---|---|---|---|---|
| 8.1 | User end point devices | Yes | planned | ISMS record (to create): device policy (disk encryption, updates, screen lock) for staff devices. | ISMS owner |
| 8.2 | Privileged access rights | Yes | partial | Product: instance_admin separate from tenant roles; break-glass is a server-side CLI with single-use 15 min links and 1 h sessions, audited (operations.md, contract.test.ts); BYPASSRLS only via named system operations with an import allowlist (ADR-0006, eslint.config.js). Privileged access to hosted servers: ISMS record (to create). | Operations lead |
| 8.3 | Information access restriction | Yes | implemented | Row-level security ENABLE + FORCE on every tenant table with withTenant (ADR-0002, rls.int.test.ts); per-route permissions (contract.test.ts, routes.int.test.ts). | Engineering lead |
| 8.4 | Access to source code | Yes | partial | Commit attribution checks (no tool co-authors or generated-by footers) and DCO sign-off (attribution.test.ts); secret scanning (secrets.test.ts). Repository hosting, branch protection and access reviews are not set up yet. | Engineering lead |
| 8.5 | Secure authentication | Yes | implemented | Sign-in via the git provider with state and PKCE S256, opaque rotated session cookies (HttpOnly, Secure, SameSite=Lax), CSRF double submit, 8 h cap, rate limits on auth endpoints (ADR-0007, auth.int.test.ts, security.int.test.ts). Multi-factor authentication is delegated to the git provider. | Engineering lead |
| 8.6 | Capacity management | Yes | partial | Per-tenant and per-repository model budgets, tool-loop limits, queue fairness and rate limits (threat-model.md §4, security.int.test.ts). Capacity planning and monitoring for hosted infrastructure: ISMS record (to create). | Operations lead |
| 8.7 | Protection against malware | Yes | partial | Untrusted repository code runs only in the gVisor sandbox runner without tokens or network (ADR-0012, escape.int.test.ts); hardened checkout (checkout.test.ts); image scan with grype defined in ci.yml. Malware protection for staff devices and hosts: ISMS record (to create). | Engineering lead |
| 8.8 | Management of technical vulnerabilities | Yes | partial | OSV-Scanner with allowlist (vulnerabilities.yaml, vulns.test.ts), grype image scan and Dependabot (dependabot.yml), handling in vulnerability-handling.md and psirt.md. Defined in CI, not yet running; host patching for the hosted edition not defined. | PSIRT lead |
| 8.9 | Configuration management | Yes | partial | Declarative Compose configuration with read_only, cap_drop: [ALL] and no-new-privileges (docker-compose.yml); configuration checks by quavon doctor (doctor.md). Hosted infrastructure baseline and drift control: ISMS record (to create). | Operations lead |
| 8.10 | Information deletion | Yes | partial | Daily retention task for webhook payloads, outbox rows, sessions, tokens and prompt logs (ADR-0008, maintenance.int.test.ts). Per-person deletion (quavon dsar) not implemented; audit log retention undecided. | Engineering lead |
| 8.11 | Data masking | Yes | implemented | Stored secrets are returned only masked and never logged (ADR-0007, routes.int.test.ts); redact() before logs and prompt logs (redact.test.ts); public repositories get counts only in check-run output (threat-model.md I2). | Engineering lead |
| 8.12 | Data leakage prevention | Yes | implemented | Outgoing bodies are secret-scanned and blocked by the publisher (secrets.test.ts); markdown sanitised and link hosts allowlisted (sanitize.test.ts); sandbox egress denied by default (escape.int.test.ts); gitleaks on commits (secrets.test.ts). Redaction is pattern-based (threat-model.md §5). | Engineering lead |
| 8.13 | Information backup | Yes | planned | No backup or restore command yet (ADR-0009). Backup policy, encrypted off-site copies and restore drills: ISMS record (to create). | Operations lead |
| 8.14 | Redundancy of information processing facilities | Yes | planned | Single-server Compose design (ADR-0009). Redundancy for the hosted edition: ISMS record (to create). | Operations lead |
| 8.15 | Logging | Yes | partial | Every mutation writes a hash-chained audit entry with actor, action, target and IP (audit.int.test.ts); structured pino logs with redaction and OpenTelemetry export (telemetry.test.ts); proxy logs strip query strings and referrers (Caddyfile). Central log storage, protection and retention for hosted operations: ISMS record (to create). | Operations lead |
| 8.16 | Monitoring activities | Yes | partial | OpenTelemetry traces and metrics, health and readiness endpoints, runner health records and quavon doctor (doctor.md, ADR-0012). Alerting and on-call for the hosted edition not set up. | Operations lead |
| 8.17 | Clock synchronization | Yes | planned | Containers use host time. ISMS record (to create): NTP configuration of hosted servers. | Operations lead |
| 8.18 | Use of privileged utility programs | Yes | implemented | Runtime image is distroless without shell or package manager (ADR-0009, Dockerfile); admin actions only through named CLI commands (operations.md); key rotation and break-glass are audited (keys.int.test.ts). | Engineering lead |
| 8.19 | Installation of software on operational systems | Yes | partial | Images pinned by digest, no package manager at runtime, sandbox images from a lock file with tags refused (ADR-0009, ADR-0012, image.test.ts). Host operating system software control: ISMS record (to create). | Operations lead |
| 8.20 | Networks security | Yes | partial | Only Caddy publishes ports; Postgres and Valkey are on an internal network; Valkey ACL users per component (docker-compose.yml, valkey-users.acl). Hosted firewall and network design: ISMS record (to create). | Operations lead |
| 8.21 | Security of network services | Yes | implemented | TLS by Caddy, CSP, frame-ancestors 'none', Referrer-Policy: no-referrer, nosniff (Caddyfile); webhook HMAC verification (webhooks.int.test.ts); body limits and rate limits (security.int.test.ts); SSRF guard for configurable endpoints (endpoint-guard.test.ts). | Engineering lead |
| 8.22 | Segregation of networks | Yes | partial | Internal data network, sandbox runner without inbound port and with egress none by default (ADR-0012, escape.int.test.ts). Dedicated runner nodes for the hosted edition are planned. | Operations lead |
| 8.23 | Web filtering | Yes | partial | Server-side outbound filtering: the enterprise edition refuses private, loopback, link-local, CGNAT and metadata addresses (endpoint-guard.test.ts); sandbox egress only via a per-job proxy during setup (ADR-0012). Web filtering for staff: ISMS record (to create). | ISMS owner |
| 8.24 | Use of cryptography | Yes | implemented | AES-256-GCM envelope encryption with context binding and key ids (crypto.test.ts); registry of encrypted columns (encrypted-columns.test.ts); key rotation procedure and command (ADR-0008, keys.int.test.ts); TLS at the edge. | Engineering lead |
| 8.25 | Secure development life cycle | Yes | implemented | Threat model kept current with every change that adds an entry point, write path or agent capability (threat-model.md), ADRs, mandatory tests and CI gates for lint, types, tests, secrets, licenses, attribution, migrations and vulnerabilities (AGENTS.md, ci.yml; defined in CI, runnable locally). | Engineering lead |
| 8.26 | Application security requirements | Yes | implemented | zod validation at every trust boundary and permission declaration per route (AGENTS.md, contract.test.ts); OWASP LLM risks mapped in threat-model.md §4. | Engineering lead |
| 8.27 | Secure system architecture and engineering principles | Yes | implemented | Trust zones, least privilege and fail-closed defaults (threat-model.md §1); writes only through the publisher, transactional outbox, separate sandbox runner (ADR-0002, ADR-0006, ADR-0012, fix-agent-and-sandbox.md). | Engineering lead |
| 8.28 | Secure coding | Yes | implemented | TypeScript strict, lint rules including the system-database import allowlist (eslint.config.js), coding rules in AGENTS.md, untrusted-content handling and output sanitising (sanitize.test.ts). | Engineering lead |
| 8.29 | Security testing in development and acceptance | Yes | partial | Security test suites: rls.int.test.ts, security.int.test.ts, auth.int.test.ts, escape.int.test.ts, chaos.int.test.ts. No independent penetration test yet. | Engineering lead |
| 8.30 | Outsourced development | No | not applicable | No development is outsourced. All contributors, including external ones, are bound by AGENTS.md and the same CI gates. Re-assess if development is outsourced. | Engineering lead |
| 8.31 | Separation of development, test and production environments | Yes | partial | Separate development stack bound to 127.0.0.1 (docker-compose.dev.yml); the insecure sandbox backend is refused in production and the enterprise edition (ADR-0012). Hosted production and staging environments do not exist yet. | Operations lead |
| 8.32 | Change management | Yes | partial | Conventional commits, required CI gates, expand/contract migration lint (verify-migrations.test.ts), grouped dependency updates (dependabot.yml). Review and approval rules on the remote and a hosted release procedure are not set up. | Engineering lead |
| 8.33 | Test information | Yes | implemented | Test fixtures use throwaway keys generated at test runtime and recorded provider fixtures with secrets scrubbed (AGENTS.md); no production data in tests. | Engineering lead |
| 8.34 | Protection of information systems during audit testing | Yes | planned | ISMS record (to create): rules for audit and penetration tests against hosted systems (scope, test tenants, timing). | ISMS owner |
Summary ​
| Theme | Implemented | Partial | Planned | Not applicable | Total |
|---|---|---|---|---|---|
| 5 Organizational | 1 | 23 | 13 | 0 | 37 |
| 6 People | 0 | 2 | 6 | 0 | 8 |
| 7 Physical | 0 | 0 | 14 | 0 | 14 |
| 8 Technological | 12 | 16 | 5 | 1 | 34 |
| Total | 13 | 41 | 38 | 1 | 93 |
Open items for the ISMS owner ​
- Appoint the ISMS owner and a DPO; define ISMS scope, risk assessment method and risk treatment plan.
- Write and approve the information security policy set (access control, acceptable use, classification, devices, remote working, cloud services).
- Create a supplier register and assess suppliers, starting with the hosting provider netcup and the model providers tenants can configure.
- Collect supplier evidence for physical controls inherited from the netcup data centre (certificates, audit reports, contract terms).
- Implement backup and restore, define recovery objectives and run restore drills.
- Run an independent penetration test and a PSIRT tabletop exercise.
- Implement per-person data export and deletion (
quavon dsar) and decide the audit log retention period with counsel. - Run the CI pipeline on the hosted Git remote and enable branch protection and review rules.
- Build hosted-edition operations: production and staging environments, dedicated sandbox runner nodes, monitoring and alerting, central logging, host hardening, time synchronisation and runbooks. The hosted edition is not in operation yet.
- Set up HR controls: screening, employment terms, NDAs, awareness training, disciplinary and offboarding processes.