HOW CLOUD GATEWAY WORKS
One operating model across
network, security and service assurance.
Cloud Gateway combines managed connectivity, security controls, telemetry and governed operations within a single service boundary.
A contract is not convergence.
The operating model makes the difference.
Bundling circuits, firewalls and dashboards under one contract does not make them operate together. The hard work is in the joins: how routes meet controls, how identity and device context influence access, how changes are coordinated safely, how signals map to services, and how ownership transfers when a dependency fails. Cloud Gateway is built around those operational joins.
- Technology convergence matters. Operational convergence makes it usable.
Five layers, one explicit
responsibility model.
Experience layer
Where released for the contracted service, the Cloud Gateway Control Centre provides approved service views, reports, support routes and federated access. Current functions, tenant scope, role and entitlement are shown explicitly; roadmap functions are not presented as live.
Connectivity fabric
A managed set of routes between sites, users, cloud, data centres, internet, HSCN, PSN and partner networks. Underlay circuits, overlays, segmentation, routing policy and resilience are designed as one service pattern.
Security enforcement
Secure Access, Managed Firewall and Application Security place controls on user-to-internet, user-to-application, network and application traffic. Capabilities use approved Cloud Gateway and partner technologies; each Service Definition names the enforcement platform, Cloud Gateway’s operational role and the partner’s product responsibility.
Observability & assurance
Approved metrics, logs, events, source status, incidents and changes are mapped to the customer and service context. Standard views and reports show what the available evidence says about health, activity and delivery – including where coverage is incomplete.
Automation & integration
Standard templates and governed workflows reduce configuration variance and create repeatable change evidence. Some capabilities, such as customer APIs, advanced correlation, AI-assisted analysis and automated workflows, are in development, pilot or planned.
Start with the pressure point.
Build towards the operating model.
Modular
Adopt the capability needed now, then extend the same operating model across additional services.
Interoperable
Integrate with useful customer and partner systems rather than requiring every component to be replaced.
Standardised
Use approved architecture patterns, configuration baselines and change paths to make delivery repeatable.
Observable
Define the service signals and evidence model as part of design, not after deployment.
Tenant-isolated
Separate customer configuration, data and access through the controls applicable to each platform component.
Governed
Attach authority, approval, audit and rollback to change – whether performed by Cloud Gateway or an authorised customer team.
Change one layer
without losing sight of the service.
Begin with cloud connectivity, an HSCN or PSN path, SD-WAN, Secure Access, Managed Firewall or Observe Essentials. Cloud Gateway maps the new capability into the wider service boundary, dependency model and operating process so future expansion does not become another isolated project.
The service is explicit about who owns what.
Cloud Gateway operates the contracted managed-service layer. The customer retains responsibility for business policy intent, authorised users, application ownership, customer-controlled dependencies and timely approvals. Technology and carrier partners remain responsible for their underlying products and services. Those boundaries are documented before go-live and used during incident and change handling.
Every service should be able to explain itself.
A supportable service needs more than uptime. It needs current inventory, defined telemetry, known data gaps, incident and change history, configuration and policy ownership, service-level evidence and a route from signal to action. That evidence model is part of Cloud Gateway’s service design.
The time taken to provision a new platform tenant on Cloud Gateway, down from a traditional provider’s typical 90 days.
Read how HMCTS use this on the justice reform programme →
Platform operational availability delivered to customers operating across PSN, HSCN and multicloud environments.
Defra maintained continuity during legacy migration →
The population served by a single Cloud Gateway HSCN connection, provisioned in three days from first engagement.
Read how Hampshire and Isle of Wight ICS came online →
Customers trust Cloud Gateway to run their mission critical infrastructure, including NHS, policing and central government.
Read our case studies to learn how we help organisations like yours →
Solving our
customers' problems
Proprietary,
not open
Closed ecosystems from legacy vendors lock you in, making every change slow and costly.
Every time we try to change supplier, we find out how much has been built around them. The switching cost is enormous.”
Disjointed
solutions
Siloed tools mean teams waste time assigning blame instead of fixing the problem.
I’ve lost track of what’s connected to what. Every time something breaks, it takes days to work out where the problem sits.”
Dashboards
and data
Plenty of dashboards and data, but zero clarity, leaving you drowning in alerts.
We have monitoring tools. We don’t have the ability to connect the dots across network & security in one place.”
Compliance
evidence
Piecing together logs from disparate tools creates gaps and admin overhead.
Our regulator expects continuous evidence, not just an annual report. We don’t have the capacity to collate it manually.”
Execution
drag
Complex deployments delay timelines and risk breaking your live services.
I need to deliver change without breaking what’s running. We can’t afford downtime on services people depend on.”
Map the operating model to your estate.
A useful architecture session starts with endpoints, destinations, trust boundaries, dependencies and operational ownership - then identifies the smallest supportable place to begin.