ISO 27001 Preparedness

[valentinyanakiev]

Description

Achieve readiness for ISO/IEC 27001:2022 certification by establishing the required information security management system (ISMS) controls across the Alkemio platform. This epic covers the technical and process groundwork needed to pass a Stage 1 (documentation review) and Stage 2 (implementation audit) assessment by end of Q3 2026.

ISO 27001 is increasingly required by enterprise and public sector partners. Preparedness signals trust, enables procurement, and formalises the security practices we already follow.

The primary job to be done is:

• As an organisation, we want to demonstrate ISO 27001-level security maturity so that partners and customers can trust the platform with their data and meet their own compliance requirements.

Secondary:

• As a developer, I want clear security policies and tooling so that secure-by-default is part of my daily workflow, not an afterthought.

ISO 27001:2022 — Annex A Control Areas & Alkemio Status

A.5 — Organisational Controls

Control	Description	Status	Action Needed
A.5.1	Information security policies	Gap	Draft ISMS policy document, acceptable use policy
A.5.2	Information security roles & responsibilities	Partial	Formalise RACI for security roles
A.5.7	Threat intelligence	Gap	Establish process for monitoring CVEs, advisories
A.5.8	Information security in project management	Partial	Add security checkpoints to sprint/release process
A.5.23	Information security for cloud services	Partial	Document cloud security posture (Azure/K8s)
A.5.29	Information security during disruption	Gap	Business continuity / disaster recovery plan
A.5.30	ICT readiness for business continuity	Gap	DR testing, RTO/RPO definitions

A.6 — People Controls

Control	Description	Status	Action Needed
A.6.1	Screening	Gap	Background check process for team members
A.6.3	Information security awareness & training	Gap	Security training programme for all staff
A.6.6	Confidentiality agreements	Partial	Review NDAs / contractor agreements

A.7 — Physical Controls

Control	Description	Status	Action Needed
A.7.1-7.14	Physical security	N/A (cloud-native)	Document reliance on Azure physical controls

A.8 — Technological Controls

Control	Description	Status	Related Issues
A.8.1	User endpoint devices	Partial	Document device security policy
A.8.5	Secure authentication	Partial	Ory Kratos — review MFA, session management
A.8.8	Management of technical vulnerabilities	In progress	alkemio#1782 — OSS scanning tools evaluation
A.8.9	Configuration management	Partial	Document baseline configs for K8s, services
A.8.15	Logging	Partial	Elastic APM in place; formalise log retention policy
A.8.16	Monitoring activities	Partial	Sentry, APM in place; need alerting runbooks
A.8.20	Network security	Partial	K8s network policies — audit and document
A.8.23	Web filtering	Gap	Evaluate egress controls
A.8.25	Secure development lifecycle	In progress	infra-ops#2059 — Distroless migration
A.8.26	Application security requirements	Partial	server#5495 — Authorization audit trail
A.8.27	Secure system architecture	Partial	Document architecture security decisions
A.8.28	Secure coding	Partial	Linting, type safety; need SAST tooling
A.8.29	Security testing in development & acceptance	In progress	infra-ops#1900 — External penetration testing
A.8.31	Separation of environments	Partial	Dev/staging/prod exist; document access controls
A.8.32	Change management	Partial	PR reviews, CI/CD; formalise change advisory process

Existing Related Work

Issue	Description	Status
alkemio#1782	Evaluate OSS license, vulnerability & security scanning tools	Open
infra-ops#1900	External penetration testing	Open
infra-ops#2059	Secure & minimal artifacts (Distroless migration)	Open
server#5495	Authorization forest changelog & structural audit trail	Open

Must Have Scope (by end Q3 2026)

Documentation & Policies

• ISMS scope statement and information security policy
• Risk assessment methodology and risk register
• Statement of Applicability (SoA) — map all Annex A controls
• Asset inventory (services, data stores, infrastructure)
• Acceptable use policy
• Access control policy
• Incident response plan and playbook
• Business continuity / disaster recovery plan (RTO/RPO for each service)
• Secure development lifecycle (SDLC) policy
• Data classification scheme (public, internal, confidential, restricted)
• Supplier/third-party security assessment process

Technical Controls

• Vulnerability scanning tooling deployed (alkemio#1782)
• SBOM generation for all production artifacts
• SAST/DAST integrated into CI/CD pipeline
• External penetration test completed with findings addressed (infra-ops#1900)
• Distroless container images for all production services (infra-ops#2059)
• Centralised logging with defined retention policy (Elastic)
• Monitoring & alerting runbooks for critical services
• Secret management audit (Kubernetes secrets, Vault, environment variables)
• MFA enforcement for all infrastructure access (Azure, K8s, GitHub)
• Network policy audit for Kubernetes namespaces
• Backup & restore testing documented

Process & People

• Security awareness training for all team members
• Security champion identified per team
• Incident response drill / tabletop exercise completed
• Change advisory board (CAB) or lightweight change approval process
• Regular (quarterly) risk review cadence established

Nice to Have

• Internal audit programme (can be simplified for initial certification)
• Automated compliance dashboard
• SOC 2 Type I alignment (overlapping controls)

Success Metrics

• Stage 1 audit (documentation review) — zero critical non-conformities
• Stage 2 audit (implementation) — zero major non-conformities, minor findings acceptable
• All critical/high CVEs in production addressed within SLA (critical: 48h, high: 7 days)
• 100% of team members completed security training
• Penetration test findings: zero critical, all high findings remediated

Stakeholders

• Engineering — implement technical controls, secure development practices
• DevOps/SRE — infrastructure security, monitoring, DR
• Product — data classification, feature security requirements
• Management — ISMS ownership, risk acceptance decisions
• Legal — NDAs, data processing agreements, GDPR alignment
• External auditor — Stage 1 & 2 assessment

Relationship to Other Milestones

This milestone complements the Server Stack Modernization milestone:

• Keeping dependencies current (NestJS 11, Apollo 5, Node 24) addresses A.8.8 (vulnerability management)
• Distroless migration addresses A.8.25 (secure development lifecycle)
• Authorization audit trail addresses A.8.26 (application security requirements)
• OSS scanning tools address A.8.8 and A.8.28 (secure coding)

Design

Figma file: N/A — This Epic is process and infrastructure work.

[valentinyanakiev]

Two findings relevant to this epic's A.8 Technological Controls, surfaced while investigating a production Collabora incident:

• alkem-io/infrastructure-operations#2460 — [P1] Collabora processes untrusted user-uploaded documents with no chroot jail and no seccomp (container has CapEff: 0, so mount_jail_tree can't work and coolwsd falls back to --nocaps --noseccomp). Compounding it, the default ServiceAccount that Collabora mounts is bound to a pod-reader ClusterRole granting cluster-wide pods, pods/log and pods/exec — verified "allowed": true via SelfSubjectAccessReview from inside the pod. 48 pods in default share that SA. Net effect: one malicious uploaded document ⇒ RCE ⇒ exec into any pod including postgres/kratos/hydra.
  Maps to A.8.20 (network security), A.8.22 (segregation of networks), A.8.31 (separation of environments). Overlaps infrastructure-operations#2382.

• Also worth noting for A.8.20: the production cluster currently has exactly one NetworkPolicy (chromadb). The "Network policy audit for Kubernetes namespaces" checkbox above is effectively at zero coverage.

All probes were read-only; pods/exec was confirmed via the authorization API rather than by exec'ing into another pod.

[valentinyanakiev]

Ground-truth status update — 2026-08-14

Full re-verification of this epic's claims against infrastructure-operations (develop + main), infrastructure-provisioning, all 18 application repos, and the live clusters' GitOps trail. The authoritative, continuously-maintained control tracker is now the organisation vault (vault/Operations/Compliance/ISO 27001/, 69 working controls ← 123 requirements); latest update: organisation#137 (draft). This comment reconciles the epic's A.8 table with reality.

Landed since this epic was written (the table understates these)

Epic says	Ground truth
A.8.20 "Partial — K8s network policies: audit and document"	Enforced. Default-deny CiliumNetworkPolicies across all five workload namespaces on both clusters — acceptance-v3 2026-08-07, production-v3 2026-08-14 (release 71 [infra-ops#2560] delivered the flow-evidence-proven allowlists; per-namespace human-gated enforcement followed). Negative test holds: an unlisted pod can no longer reach Postgres/Redis/RabbitMQ or the unauthenticated Kratos/Hydra admin APIs. Hubble flow observability live on both. Finding K8S-2 closed: infra-ops#2381. Residuals: kube-system/elastic-system deliberately unenforced this iteration; written production evidence set (spec T034) still to be captured.
A.8.8 "In progress — OSS scanning tools evaluation (#1782)"	Evaluation is over — daily Trivy scanning of every live acc+prod image is running since 2026-08-05 (infra-ops#2494), evidence committed as signed dated bundles, freshness check on production promotion PRs. The register's contents are now the work item: 2026-08-11 bundles show 221 critical / 3092 high across 32 images (infra-ops#2516).
A.8.25 "In progress — Distroless (#2059)"	Wave 1 live on production (4 images, non-root + read-only rootfs, SA-token mount removed from web client — infra-ops#2528/#2530/#2531/#2538); Wave 2 in flight (#2499), Phase 3 tail (#2540).
(not in table)	Privileged access is now enforced, not documented: 3-tier IAM (read-only/operator/admin) + keyless break-glass on the v3 clusters (infra-provisioning#28), and since 2026-08-08 a least-privilege CI deployer identity (infra-provisioning#34, infra-ops#2539) with per-repo grant procedure + time-bound-credential runbook.
(not in table)	90-day native Kubernetes API audit retention live and verified on both v3 clusters; private worker nodes, NAT egress.

Still true, and the epic's own scope checklist should not be read as closer than it is

• "MFA enforcement for all infrastructure access" — no Kratos second factor / AAL2 exists (infra-ops#2393); leak_sensitive_values: true still set in base Kratos/Oathkeeper values.
• "Secret management audit" — worse than unaudited: ~25 live secrets are committed in git in infra-ops (plus #2419, #2407); no sealed-secrets/SOPS/ESO/Vault anywhere.
• "SAST/DAST in CI" — no repo has blocking SAST; no application repo has any Dependabot/Renovate config (verified across all 18 on 2026-08-12; only infra-ops runs Renovate). The epic's premise that dependency scanning exists is wrong.
• CI is not merge-blocking — empty required-status-checks on infra-ops develop and main; even the new Trivy freshness gate is advisory until a required check makes it real (#2401).
• Drift-check gate still non-blocking (continue-on-error: true since 2026-07-01, blocked on infra-ops#2523).
• The epic body still says Azure throughout — actual estate is Scaleway (+ Hetzner sandbox) and has been for some time.

Governance reality check

The org-vault tracker stands at 36 of 69 working controls with something in place, 0 Implemented, journey stage scoping. The ICTU-committed Q3 2026 Annex A gap analysis is due this quarter and not started — its prerequisites (ISMS scope A.03, risk assessment process A.06) are the critical path, and they are governance documents, not engineering. The technical trajectory above is strong; the documentation layer this epic's "Must Have Scope" lists is where nothing has moved.

Produced with the same verification discipline as organisation#136/#137: claims checked against committed state and live deploy runs, not against prior notes.