Cloudflare at CDS¶
Cloudflare is central to how CDS builds and secures digital services. We are the first organisation in EMEA to hold Cloudflare Authorised Service Delivery Partner status, and the most certified Cloudflare partner in EMEA. Our Cloudflare work spans edge delivery, application security, Zero Trust network access, and AI-enabled applications on the Cloudflare Developer Platform.
This page covers how we use Cloudflare in practice: our delivery framework, our IaC baseline, and the standards we apply across engagements.
What we use Cloudflare for¶
Edge delivery and performance — CDN, caching, DNS, and performance configuration for high-traffic services. Cloudflare sits in front of many of the services CDS builds and runs, including national-scale services handling tens of millions of requests.
Application security — WAF rules, DDoS protection, bot management, rate limiting, and SSL/TLS configuration. Every Cloudflare deployment CDS delivers includes a security baseline as standard, not as an optional extra.
Zero Trust network access — replacing legacy VPN with Cloudflare Tunnels, Gateway, and Warp, integrated with enterprise identity providers (Entra ID, Okta, Intune). We are the first EMEA ZTNA Authorised Service Delivery Partner.
Developer Platform — building applications on Workers, Pages, R2, D1, KV, and Workers AI. CDS uses the Cloudflare Developer Platform for edge compute, AI-enabled features, and serverless applications where performance and global distribution matter.
IaC estate management — moving large or complex Cloudflare estates under Terraform management, giving clients auditable, version-controlled configuration they can maintain and extend.
Our delivery framework¶
All Cloudflare engagements at CDS follow a consistent four-stage framework: Discover, Define, Design, Deliver. This applies whether the engagement is a two-week audit or a multi-month Zero Trust rollout. The scope changes; the rigour does not.
Discover — workshops with the client's technical team, review of existing documentation and configuration, current state assessment across relevant coverage areas. We understand the estate before we touch anything.
Define — compiled findings, agreed scope, and confirmed success criteria. The client knows exactly what the engagement will address before any implementation begins.
Design — architecture, configuration design, and IaC baseline tailored to the client's context. Peer-reviewed before implementation starts.
Deliver — implementation, validation against success criteria, client handover including the Terraform codebase (which the client owns), documentation, and a clear recommendation on next steps regardless of whether they continue with CDS.
The IaC/Terraform baseline¶
CDS maintains a pre-built, pen-tested Terraform baseline for Cloudflare application services. It encodes production patterns drawn from across our Cloudflare client base and is continuously updated against real-world threat intelligence.
Using the baseline as the starting point for every engagement means:
- Clients get a production-grade foundation from day one, not a configuration built from scratch
- Configuration is auditable, version-controlled, and peer-reviewable in the same way as application code
- Configuration drift — the gradual divergence between what a system is supposed to do and what it actually does — is dramatically reduced
- New zones can be deployed in under an hour; environment launches are measurably faster than manual configuration
The baseline covers WAF rules and firewall configuration, DDoS protection, SSL/TLS settings, bot management, rate limiting, caching and performance defaults, DNS hygiene, logging and alerting configuration, and account and user permission structure. Specific coverage is tailored to scope in the Define stage of each engagement.
Clients receive the Terraform codebase as a deliverable. They own it. The intent is always to leave the client in a position where they can manage, extend, and keep their Cloudflare estate current — with or without CDS.
Note
The IaC baseline is a shared CDS asset maintained by the Engineering practice. If you are starting a Cloudflare engagement, speak to the Engineering practice lead before scoping the configuration work to understand what is already available and what needs to be tailored.
Zero Trust¶
Zero Trust means never assuming that anything inside or outside the network perimeter can be trusted by default. Every user, every device, and every application is verified continuously — not once at login and then assumed safe.
CDS implements Zero Trust through Cloudflare's ZTNA stack: Tunnels for application connectivity, Gateway for DNS and HTTP filtering, and Warp for device-level access — integrated with enterprise identity providers and tailored to the client's access patterns.
Our approach to ZTNA rollouts is deliberate: pilot with a discrete user group first, validate the access model and user experience, then expand. This reduces the risk of a disruptive cutover and gives the client real evidence before committing to a full rollout.
Relevant standards¶
For public sector clients, Cloudflare deployments should be assessed against:
- NCSC Cloud Security Principles — particularly relevant for data in transit, identity and authentication, and operational security
- NCSC Zero Trust Architecture principles — the reference framework for ZTNA design decisions
- G-Cloud 15 — CDS lists services on G-Cloud; any Cloudflare work delivered through G-Cloud must align with the relevant service descriptions