So the revised TSA Code of Practice has been published and came into effect on the 14th July 2026. This resulted in a number of changes, one of the most important is dedicated guidance on how to manage Cloud Service Providers. This is contained within the Key Concepts in paragraphs 6.22-6.30, and what we shall cover today.

Introduction

The sections starts with Paragraph 6.22, which states that:

6.22(a) If a public telecoms provider wishes to use a cloud provider for any part of its PECN/PECS provision, it will be essential to have contractual arrangements in place that ensure security controls are applied correctly.

6.22(b) Public telecoms providers must recognise that the cloud environment is significantly different from the traditional model and therefore a simple ‘lift and shift’ of their current environment will not deliver the necessary control or functionality.

6.22(c) There are several risks that shall be assessed and taken into consideration, including:

The first area is sensible, and essentially means that providers using Cloud services as part of the Public Electronic Communications Network or Service (PECN/PECS) have appropriate security controls which are underpinned by contracts – although it must be said that most major Cloud Service Providers (CSPs) do not enter into bespoke contractual agreements.

The second area is essentially tied to existing guidance from the National Cyber Security Centre (NCSC) on their Cloud Security Principles where their shared responsibility model talks about On Premise and then the three NIST Cloud Service Models of:

Infrastructure-as-a-Service (IaaS)
Platform-as-a-Service (PaaS)
Software-as-a-Service (SaaS)

Whilst I understand the intention, it is commonplace within Telecoms Providers for them to have a level of virtualisation (if not complex Telecommunications Cloud deployments to host services – often called Telco Cloud), so the ‘traditional model’ might be more aligned to public Cloud service deployments already (as shown below in Figure 1), albeit the point in 6.22(a) still stands.

Fig 1 – Modified Cloud Security Shared Responsibility Model

The third part is editorially misplaced as it makes no sense without the risks in the remainder of paragraphs 6.23-6.30 (if indeed any or all of them are indeed risks – as we shall discuss now).

What are the risks to be managed?

Looking at the remainder of the paragraphs in turn will provide some further understanding.

6.23 Typically, the cloud provider will administer the underlying capabilities (such as physical infrastructure and virtualisation fabric) to be used in the PECN/PECS provision, while the public telecoms provider administers its own telecoms-specific software. The cloud provider may also provide additional cloud services used in the PECN/PECS provision.

6.24 Under this model, cloud providers shall be considered as 3PAs, as well as third party suppliers, at least as regards their physical infrastructure and virtualisation fabric and any additional cloud services provided.

Ok, I lied – I’m joining the two paragraphs together and commenting on them. Neither of the above paragraphs are risks in themselves, but both link into one of the seven risks to be reviewed annually in Regulation 11(b) – which is Regulation 7(1), and this states:

A network provider or service provider must take such measures as are appropriate and proportionate to identify and reduce the risks of security compromises occurring in relation to the public electronic communications network or public electronic communications service as a result of things done or omitted by third party suppliers.

So, whilst not expressly mentioned in this paragraph – it is required to understand the risks of things done or omitted by those suppliers running the Cloud service.

Gaining assurance of the Virtualisation Fabric

So we have identified one risk to be managed, but the points discussed in Paragraphs 6.22(a) and (b) are explored further in the next two paragraphs:

6.25 Public telecoms providers retain responsibility and accountability for management and oversight when third parties are involved and must ensure that the physical infrastructure, virtualisation fabric and services provided and used in the PECN/PECS provision are architected and managed in accordance with the principles described in the Code of Practice and that security controls are applied correctly. Public telecoms providers also remain responsible for the administration of their own telecoms-specific software.

6.26 The configuration and integrity of the virtualisation fabric is critical, as is the security of the underlying physical infrastructure and particular attention shall be paid to virtualisation measures.

The areas above are linked to Regulation 7(1), but also to the principles explored in Paragraph 6.7

It should also be noted that public telecoms providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third-parties. Where providers do outsource aspects of operations to a third-party, responsibility to comply with the obligations contained within sections 105A-D of the Communications Act 2003, and the obligations set out in the regulations, remain with the provider. The provider therefore needs to have sufficient internal capacity to meet those obligations.

and also Technical Guidance Measure M2.06

The infrastructure used to support a public telecoms provider’s network shall be the responsibility of the public telecoms provider, or another entity that adheres to the regulations, measures and oversight as they apply to the public telecoms provider (such as a third party supplier with whom the public telecoms provider has a contractual relationship). Where the public telecoms provider or other entity adhering to the regulations has responsibility, this responsibility shall include retaining oversight of the management of that infrastructure (including sight of management activities, personnel granted management access, and management processes).

In practice, this means that the entirety of Technical Guidance Measures M13.01-28 and M19.01-07 are to be taken into consideration (including Paragraphs 2.34 and 2.40-2.72 as supporting guidance) as to whether the Cloud Service Provider can provide evidence that the appropriate controls are deployed to manage the Cloud service being provided (and therefore the risks in Regulation 7(1).

Controlling the management of the Cloud service

We now come to areas relating to the management of the Cloud service itself

6.27 Paragraphs 6.13 and 6.14 above explain the potential threat posed by an MSP or 3PA that provides services to multiple organisations. Should 3PA systems be compromised, or a 3PA be malicious, multiple UK networks could be exploited or disrupted simultaneously and it is for this reason that measures relating to the MSP or 3PA itself and how it architects its administration have been included in the Code.

This refers to the threat that Third Party Administrators (3PAs) and Managed Service Providers (MSPs) can pose to multiple networks and services through the malicious action of a third party (or compromise of the 3PA/MSP systems themselves). Examples are provided in the references from December 2018 to the APT10 “Operation Cloud Hopper”.

6.28 Some of the measures relevant to MSPs (M10.26, M10.29 and M10.30) may need an alternative approach that is appropriate and proportionate to address the risk in a cloud environment.

This is an interesting point, where 3PAs within CSPs are deemed to use Privileged Access architectures which are not aligned to the outcomes recommended within the TSA Code of Practice (the referenced measures relate to the segmentation of management environments per customer – including independent admin domains and accounts per customer and logically-independent Privileged Access Workstations).

This will require an approach where these Measures will likely require different evidence of implementation of supply chain assurance for Cloud Service Providers. It aligns to the requirement of Regulation 7(1), which itself links to:

Regulation 7(3)(a) The risks referred to in paragraph 7(1) include those arising during the formation, existence or termination of contracts with third party suppliers

and

Regulation 7(3)(b) The risks referred to in paragraph 7(1) include those arising from third party suppliers with whom the network provider or service provider has a contractual relationship contracting with other persons for the supply, provision or making available of any goods, services or facilities for use in connection with the provision of the public electronic communications network or public electronic communications service.

Resilience matters

The final paragraphs relating to CSPs are regarding the Resilience of the Cloud service relating to the PECN/PECS

6.29 Public telecoms providers choosing to make use of a cloud provider for any part of its PECN/PECS provision shall also consider carefully Regulation 3(3)(f) on resilience (explained further in sections 2.102 – 2.108)

This is much more detailed than you might initially think, especially when we look at Regulation 3(3)(f) in detail (I’ve done some word merging to aid with presentation):

Regulation 3(3)(f)(i) The duty in paragraph 3(1) includes in particular a duty to take such measures as are appropriate and proportionate to ensure that the network provider is able, without reliance on persons, equipment or stored data located outside the United Kingdom, to identify the risks of security compromises occurring,

Regulation 3(3)(f)(ii) The duty in paragraph 3(1) includes in particular a duty to take such measures as are appropriate and proportionate to ensure that the network provider is able to identify any risk that it may become necessary to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom, and

Regulation 3(3)(f)(iii) The duty in paragraph 3(1) includes in particular a duty to take such measures as are appropriate and proportionate to ensure that the network provider, if it should become necessary to do so, would be able to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom.

It’s clear that the intention of the guidance is that any use of Cloud services isn’t just the risk of things done or omitted by third parties, but also the risk of not being able to operate the PECN/PECS in the event that non-UK Cloud services are unavailable.

Of course, Regulation 3(1) requires that:

New PECN/PECS which came into operation after October 2022 are designed in a manner which reduces the risks of security compromise (remember that Security compromise isn’t just confidentiality impact, but also from unauthorised changes or loss of availability)
Existing networks are redesigned to reduce the risk of security compromises occurring (to the PECN and PECS)
The PECN/PECS is maintained in a manner which reduces the risk of compromise

Now Paragraphs 2.102-2.108 add additional detail to the scope of risks to be assessed, with 2.102 setting the scene:

2.102 Regulation 3(3)(f) imposes certain requirements for national resilience. In particular, regulation 3(3)(f)(iii) requires network providers to take appropriate and proportionate measures to ensure that they would be able to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom if it should become necessary to do so. In addition, the location of equipment performing each particular function, or type of function, or storing data relating to the function is one of the matters to be considered as part of providers’ risk assessments under Regulation 3(3)(a).

The last sentence in bold completes the picture of risks to be managed, as it brings Regulation 3(3)(a) into play and states:

Regulation 3(3)(a)(i) The duty in paragraph 3(1) includes in particular a duty to identify and reduce the risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed, having appropriate regard to whether the function contains sensitive data,

Regulation 3(3)(a)(ii) The duty in paragraph 3(1) includes in particular a duty to identify and reduce the risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed, having appropriate regard to whether the function is a security critical function,

Regulation 3(3)(a)(iii) The duty in paragraph 3(1) includes in particular a duty to identify and reduce the risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed, having appropriate regard to the location of the equipment performing the function or storing data related to the function, and

Regulation 3(3)(a)(iv) The duty in paragraph 3(1) includes in particular a duty to identify and reduce the risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed, having appropriate regard to the exposure of the function to incoming signals,

Essentially, the above means that when using a Cloud service, you need to understand:

If it can impact other PECN or PECS elsewhere
If it contains sensitive data
If it operates Security Critical Functions
Where the functions or data are stored geographically (including if the CSP can move the service into another region without the customer knowing)
If the function is exposed to incoming signals (not just signalling traffic, but any communication)

The remainder of paragraphs 2.103-2.108 are concerned with:

Ensuring a minimum level of knowledge/expertise, data and functions are available from within the UK at all times
Security competence is aligned to requirements from areas such as the UK Cyber Security Council (a new requirement)
Being able to operate key services (i.e. fixed/mobile data or mobile voice/messaging) from within the UK for a month in the event the international connectivity fails
Being able to transfer functions back into the UK in the event that international connections fail (which is governed by guidance on Business Continuity Plans in Paragraph 2.106)
Ensuring a UK-based capability to assess risks of security compromise (e.g. keeping security/audit logs outside of the UK, approving procurement decisions using offshore staff, the reliance on staff/functions/services outside of the UK and the reliance on third parties for 1st and 2nd line support)
Reassessing existing risks when the threat or global political environment changes

These areas can be particularly challenging when using Cloud services, as data residency does not necessarily provide operational sovereignty, and providers may remain dependent on overseas control planes, personnel, support functions, infrastructure or corporate decision-making. Most Cloud service terms and conditions also restrict their suitability for high-risk or critical uses, which providers need to consider alongside the service architecture and assurance available (something discussed in a previous article on the subject of TSA and Cloud).

We have already seen the challenges of using AI in key security controls, and the impact that the whims of foreign governments can have on the access to them. As we pursue a path of Open Radio Access Networks (ORAN), 5G Advanced and ultimately 6G (which all use microservices and Cloud-first service delivery models), the temptation to move to the Cloud is unbearable in terms of its attractiveness. It is therefore understandable that Providers who choose this path try to objectively identify and manage the risks associated with those strategies.

Understanding the reliance of Cloud services on their control plane

On top of the above (very long, but necessary) discussion on resilience, paragraph 6.30 adds a final consideration on resilience – the ability of the Cloud service to be maintained if the control plane loses connectivity:

6.30 Cloud services typically have a control plane component responsible for managing the service. Public telecoms providers shall ensure that they have a deep understanding of the impact on their ability to operate if their cloud environment loses connectivity to its control plane.

This creates a slightly different risk from complete loss of the Cloud service. The underlying workloads may remain operational, but the provider could lose the ability to administer, reconfigure, recover or otherwise control them. This is especially true for ‘on premise’ security controls which are reliant on the control plane being accessible to modify them. Providers therefore need to understand which functions remain available without the Cloud control plane, how long they can continue in that state, and how control could be restored.

So what does this all mean?

Whilst I’ll be the first to admit that paragraphs 6.22-6.30 are unclear, they do present a sound approach to managing Cloud Services when you read through the linked regulations. What I would say is that the regulations and linked parts of the CoP align to setting out the following principles (NB – These are the result of my assessment of the above, and have no legal basis for compliance. But can be used as a starting point if you choose to reference me as the source) :

Principle 1 – Understand the Cloud service

Providers are expected to understand what the Cloud service is used for, including:

If it stores or processes sensitive data
Whether it hosts Security Critical Functions, Network Oversight Functions, or other functions necessary for the provision of the PECN or PECS
What its impact on the wider PECN/PECS in the provider is in the event of a breach, unauthorised change or loss of access to it
If it impacts fixed/mobile data or mobile voice/messaging
The locations where the Cloud service is storing data (or processing data from)

Principle 2 – Understand your reliance on the Cloud service

Understand how dependent your PECN/PECS is on the Cloud service, this includes understanding:

Whether key communications services could continue to operate if the Cloud service became unavailable.
Whether key services can continue operating safely if connectivity to its control plane is lost.
Which administrative, recovery and configuration capabilities would be unavailable if the services lost connectivity to its control plane.
Whether the service relies upon overseas people, systems or data.
Whether key services could continue to operate for one month without international dependencies.
Whether the function could be repatriated to the UK within a month.
Whether sufficient UK-based knowledge, capability and information exists to continue secure operation.

Principle 3 – Understand who is responsible for securing the Cloud

Cloud changes who might implement security controls, but not who is accountable for security – and this can be multiple suppliers dependant on service model.

Providers should understand:

Which controls they implement.
Which controls are implemented by the Cloud provider.
Which controls are implemented by other suppliers within the hosting chain.
Where responsibilities are shared.
How those responsibilities are governed contractually.

The Shared Responsibility Model should be understood regardless of whether the service is delivered as IaaS, PaaS or SaaS.

Principle 4 – Manage the risks of using the Cloud

The use of Cloud may introduce or concentrate risks which must be identified, assessed and managed throughout the supply chain.

These include risks arising from:

Third-party suppliers.
Subcontracted supply chains (where a SaaS provider is reliant on a different hosting CSP).
Privileged administration.
Loss of connectivity to the Cloud service or its control plane.
Failures where several services or providers depend on the same CSP, region, control plane or underlying component.
Geographic location of services and data.
Changes in the geopolitical environment.

Risk assessments should consider both the Cloud service itself and the function it supports.

Principle 5 – Obtain assurance that the hosting fabric is secure

Providers remain responsible for demonstrating that the physical infrastructure supporting the Cloud service is operated securely.

This means obtaining evidence that:

The physical infrastructure is appropriately secured.
The virtualisation fabric is securely administered.
Appropriate management controls are implemented.
Security monitoring is effective.
Privileged access is appropriately controlled.
The applicable measures described in M13.x and M19.x are implemented by the organisation responsible for each part of the physical infrastructure or virtualisation fabric, with sufficient evidence passed through the hosting chain.

The evidence may come directly from the CSP, from another supplier within the hosting chain, or through independent assurance.

TSA doesn’t stop you using the Cloud – but Cloud needs handling with care

The TSA does not prevent providers from using Cloud services, but neither does it allow the Cloud to become a black box. Providers must understand the functions being hosted, their operational and international dependencies, where shared responsibility sits, the risks that result, and the evidence that the underlying infrastructure and virtualisation fabric are being operated securely.

Cloud may change who implements the controls, but it does not change who remains accountable for the security and resilience of the PECN or PECS.

What the CoP – What is new for managing Cloud services in the TSA?