Risk Register Summary

1. Purpose

CompleteFlow Ltd maintains an internal risk register covering information security, data protection, operational, and commercial risks. This document is an external-facing summary of the top information security and privacy risks for customers, the controls that manage them, and the direction of travel.

It is not the full register. Full details are available to customers and regulators under appropriate confidentiality arrangements.

2. Scoring

Risks are scored on likelihood and impact (both 1–5), yielding a score from 1–25:

• Low (1–5), residual risk is acceptable under current control set
• Medium (6–12), monitored, with defined actions where improvement is planned
• High (13–19), active treatment plan with owner and target date
• Critical (20–25), escalation to the Director and immediate treatment

Each risk below shows inherent rating (before controls) and residual rating (after controls).

3. Top security and privacy risks

3.1 Unauthorised access to customer data

Key controls: dedicated-subscription-per-customer architecture; customer-owned Azure tenancy; PIM-based just-in-time access; MFA on all privileged operations; database-layer tenancy isolation; policy-engine-enforced application authorisation; comprehensive audit logging in the customer subscription.

Actions: Cyber Essentials Plus certification (in preparation); ISO 27001 programme starting after CE+.

3.2 Cross-tenant data leakage

Key controls: each customer deployment sits in its own Azure subscription, with its own storage accounts, database, Key Vault, and compute, there is no shared multi-tenant data plane; subscription-level network isolation; separate Azure OpenAI Service instances per customer.

3.3 AI model use of customer data

Key controls: use of Azure OpenAI Service only (contractually excluded from Microsoft model training); no integration with public/consumer AI services by design; Limited Access Program available to customers to remove abuse-monitoring retention; no fine-tuning on customer data by default.

3.4 Prompt injection leading to unintended action or data disclosure

Key controls: typed, structured outputs rather than free-form tool calls; blast-radius limits on tool invocation; policy-enforced authorisation on every tool call (model output does not bypass policy); approval gates on sensitive actions; separation of retrieved content from instructions in RAG prompts.

Actions: continuing research into defence-in-depth techniques (content-type signalling, provenance tracking); addition of specific prompt-injection detection to monitoring.

3.5 Supplier compromise (Microsoft)

Key controls: supplier due diligence under CF-POL-007; contractual breach notification alignment; monitoring of Microsoft Trust Center, service health, and security advisories; fallback posture for critical Azure services documented in CF-PLAN-002.

3.6 Loss of availability (platform)

Key controls: Azure's regional and zonal resilience; PostgreSQL point-in-time restore (35 days); geo-redundant storage option; documented DR runbooks (CF-PLAN-002); annual DR exercise.

3.7 Loss or corruption of customer data

Key controls: automated backups; soft-delete on Blob; point-in-time restore on PostgreSQL; infrastructure as code for rebuild from source; customer-configurable retention windows.

3.8 Insider risk

Key controls: least privilege via PIM; application-layer RBAC; audit logging; background checks for personnel accessing customer data (BPSS as baseline); separation of duties across code review, deployment, and production access; no persistent admin access.

3.9 Vulnerabilities in dependencies or container images

Key controls: SAST in CI; container and dependency vulnerability scanning; automated dependency monitoring with grouped PRs; AI-assisted PR security review; defined patch SLAs (Critical 24h, High 72h); locked-down base images.

3.10 Regulatory change (UK data protection, AI regulation, sectoral)

Key controls: tracking of ICO guidance, UK AI Regulation white paper outputs, EU AI Act developments (relevant for customers with EU exposure), FCA and SRA guidance on AI and outsourcing; policies drafted with forward-looking compliance posture; designed for the Nuclear-Assured model described in CF-POL-008.

3.11 Phishing and account compromise

Key controls: FIDO2-first MFA; SMS MFA disabled; conditional access on Entra ID; anti-phishing training; simulated phishing campaigns; session and token revocation playbooks.

3.12 Loss of key personnel

Key controls: named deputies for critical roles; documented runbooks; infrastructure as code reduces dependence on individual tacit knowledge; break-glass account processes.

Actions: continued operational depth as the team scales; formalised succession planning as part of CompleteFlow's organisational development.

4. Risks relating to customers and their deployments

CompleteFlow also tracks risks that are primarily borne by the customer but which CompleteFlow is positioned to support:

• Customer misconfiguration (for example, over-permissive Entra ID role assignment, disabling of MFA requirements), mitigated through deployment standard, documented baseline, and monitoring alerts shared with the customer
• Customer data quality: RAG quality depends on customer source material; addressed through customer onboarding and through feedback mechanisms in the platform
• Customer third-party integrations: onboarded through the platform's integration framework with explicit customer sign-off

5. Review cadence

• Full risk register review: quarterly
• External summary update (this document): quarterly or on material change
• Emergency update: on any Sev 1 incident, change in supplier base, or material regulatory development

6. Document control