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, owned by the customer; administrative access restricted to a single named individual with MFA on all privileged operations (see CF-POL-003 section 7); database-layer isolation controls as defence-in-depth; application-layer authorisation checks on every request; audit logging in the customer subscription.

Actions: Cyber Essentials Plus certification (in preparation); ISO 27001 certification (in preparation).

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 and testing schedule (CF-PLAN-002).

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 access model; application-layer RBAC; audit logging of all administrative activity in the customer subscription; background checks for personnel accessing customer data (BPSS as baseline); separation of code review and deployment duties.

3.9 Vulnerabilities in dependencies or container images

Key controls: SAST in CI; container and dependency vulnerability scanning; AI-assisted PR security review; defined patch SLAs (Critical within 7 days, High within 14 days, per CF-POL-009); 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 a forward-looking compliance posture; provider and deployer responsibilities assigned under CF-POL-008 so obligations can be met as regulation develops.

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: documented runbooks; infrastructure as code reduces dependence on individual tacit knowledge; break-glass account processes; customer-held audit trail and credentials mean the customer is never locked out of its own environment.

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