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.

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.

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.