Skip to main content

Guidance on public cloud connectivity to HSCN

The Health and Social Care Network (HSCN) programme delivers new and significantly different network services for health and social care as part of its remit to provide successor services to the current N3 network. The HSCN will create the effect of a single network across health and social care providers and their partners. All health and social care organisations (in England) are within scope of the HSCN solution, which supports greater integration of care delivery

The UK Government introduced a ‘cloud first’ policy for public sector IT in 2013. The use of cloud services was also endorsed in the National Information Board’s Personalised Health and Care 2020 framework, published in November 2014.

Services and systems are being developed and deployed into Public Cloud infrastructure to enable organisations to take advantage of the benefits that the Public Cloud can provide. (for example cost savings, scalability, reliability).

These guidelines define how Public Cloud provisioned services should be accessed by HSCN connected organisations and consumers, and how those Public Cloud services interact with other services currently provisioned on HSCN.

HSCN was intentionally designed as a hybrid network to support both private and public connectivity.  HSCN consumers typically purchase their, internet, Cloud and wide area connectivity from a single Consumer Network Service Provider (CNSP), moving away from historic approaches of multiple services from multiple providers. 

Strategy

NHS Digital strongly recommend that organisations have a clear cloud strategy defined before designing their network connectivity. This is to ensure this can be implemented correctly and allows for scale to accommodate cloud transformation and other future demands placed on the network.

Intention

This guidance advises on the policies and procedures that should be adhered to when connecting Public Cloud infrastructure-based services to HSCN.

The intended audience is

  • HSCN Consumer Network Service Providers (CNSPs)
  • Cloud Service providers (CSPs)
  • IT Service Providers (ITSPs), and
  • HSCN Consumers- End users wishing to interact or provision a service for HSCN/NHS Users/Services from the Public Cloud.

NHS Digital recommends reading this guidance alongside the existing published and maintained policies and procedures that should be adhered to for accessing HSCN and NHS data.  These are detailed below and depend upon the role of the organisation in the provisioning of the defined use cases.

Roles

We have defined five roles in relation to the provisioning of public cloud access to health and social care organisations on HSCN.

NHS Digital have defined five roles in relation to the provisioning of Public Cloud access to Health and Social Care organisations on HSCN.

An IT Service Provider (ITSP) - The organisation provisioning the public cloud-based service.

A CSP - Cloud Service Provider (CSP) as defined in HSCN CSP policy. 

A CNSP - Consumer Network Service Provider

A HSCN consumer - End users wishing to interact or provision a service for HSCN/NHS Users/Services from the Public Cloud

Public cloud provider - Such as AWS, Azure, GCP  etc. 

We have set out guidance on the standards/policies/obligations within this document that each role will agree to abide by.

GDPR roles

In addition to these roles the data controller and data processor roles have General Data Protection Regulations (GDPR) responsibilities. 

Data controller

A data controller is: “a natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of processing of personal data.”

Data processor 

A data processor, processes personal data on behalf of the controller.

Any organisation which uses a cloud provider (a processor) retains overall responsibility for legal compliance (for personal data) including adequate security.  

There are some responsibilities under GDPR that fall direct to the processor e.g. fails to meet its obligations, or acts outside or against the controller’s instructions, then it will be liable to pay damages in legal proceedings or be subject to fines or other penalties.

Therefore, organisations should not just rely on the cloud provider’s advice or security arrangements, as that may leave the organisation with the risks. We recommend that an organisation assigns the responsibilities (where appropriate) to the cloud provider in the contract and transfers the risk from the controller to the processor.

The Information Commissioner's Office (ICO) is the UK regulator for data protection.  It is the ICO’s intention to update the Data Protection Act 1998 guidance to explain the requirements of the GDPR, but in the meantime the general principles still apply. 

Assumptions

In setting out this guidance, NHS Digital has made the following assumptions: 

  • all access connectivity to HSCN is protected by appropriate firewall implementation
  • HSCN Consumers have implemented suitable perimeter controls including firewall provision as required as part of their HSCN Connection Agreement.  (This may be included as a managed service within their HSCN access connectivity service)
  • Guidance on selecting an appropriate firewall, and applying suitable perimeter security includes:
  • CNSPs protect HSCN by implementing their own perimeter security between the HSCN connectivity services they provide and any Public Cloud provider(s) or approved external networks.  Is specified in the Health and social care cloud security – good practice guide
  • each individual service provided by the ITSP are logically separated so that individual service's traffic can be identified.
  • controls have been implemented by the ITSP and the CSP/CNSP to ensure appropriate controls are in place to stop Cloud access being used as inbound internet traffic onto HSCN
  • IP addresses in use have been obtained from NHS Digital via the HSCN IP address management process and are registered with the consuming organisation
  • CSPs, and where appropriate CNSPs, manage access to the dedicated network links into the cloud services. This includes logging, blocking, filtering and Access Controls List (ACL) capabilities in conjunction with already specified obligations.  
  • it should not be assumed that all HSCN connected users have internet access provided by their CNSP 
  • the Security Operations Centre (SOC) will review NAS reports and IPFix data, to identify any IP addresses which aren’t registered within NHS Digital's IP Address Management (IPAM) records will be tracked down and the appropriate CNSPs will be contacted to identify owners and ensure all IP addresses are registered appropriately.

Internet First

The NHS Internet First policy sets out the vision to make digital service available over the internet instead of over private networks.  The Internet First policy and guidance provides industry best practice, standards and guidelines for creating services provisioned to the internet. 

“The Government Digital Services Technology Leaders Network reviewed the positioning of centralised private networks in January 2017 and confirmed that, for the vast majority of public services, the internet is OK. They say that new services should be made available on the internet, secured appropriately using the best available standards-based approaches. When we are updating or changing services, we should take the opportunity to move them to the internet. The Government Transformation Strategy February 2017 extended the digital agenda from the citizen to maximising the benefit of collaboration and flexibility across departments and government bodies.

Encryption and VPN standards

Solutions available to meet the capabilities described in this document adopt and utilise the following standards within any implementation.

NCSC standards: Encryption using IPsec, Prime and foundation profiles:

NCSC Standards: TLS to protect data  TLS 1.2 or 1.3 should be used (At the time of publication).

HSCN VPN services:

Existing services

Any existing transport encryption and/or security requirements for existing services will be maintained for any traffic on HSCN.  These policies and guidance do not impact or change the security requirements of those services.

Use cases

Four cloud connectivity use cases have been identified:

  1. Outbound access from end user or system to a cloud-based service (over the internet)
  2. Outbound access from end user or system to a cloud-based service (over HSCN)
  3. Inbound access from system to an organisation over the internet (locally implemented internet provision)
  4. Inbound access from Public-Cloud based systems to HSCN connected end users or systems

Different obligations and agreements apply for each of these use-cases, depending upon the role taken within the service provision.

1. Outbound access from end user or system to a cloud-based service (over the internet)

Outbound access from end user or system to a cloud-based service (over the internet).

 

Description of diagram 1

This diagram consists of two NHS or health and social care organisations connected to HSCN via different CNSPs.  The CNSPs are connected via the Peering Network (PN) and the CNSPs are obligated to route the Internet outbound traffic via the HSCN ANM (Advanced Network Monitoring) / NHS Secure Boundary service.  The diagram shows the traffic destined for the public cloud being routed via the organisation's CN-SP and through ANM / NHS Secure Boundary to the internet and to the public cloud service.  

The diagram shows the points of control being:  The consuming organisation's perimeter. The CN-SP’s connection to ANM / NHS Secure Boundary; ANM / NHS secure boundary and the internet gateway configured in the public cloud provider's environment.

In this use case the public cloud service is internet facing and the consumer accesses the service via the public internet, either via an immediate break-out from the consumers local site to the internet, or via internet access procured from their chosen CNSP and routed through the HSCN Advanced Network Monitoring (ANM)  or NHS Secure Boundary service.

Typically, this design does not use Direct Connect, ExpressRoute, Google Cloud Interconnect or similar infrastructure.

Points of control and their ownership are shown in numbered black squares in the diagram are: 

  1. Consuming organisations' perimeter – Consumers responsibility
  2. CNSPs connection to ANM / NHS Secure Boundary – CNSPs responsibility
  3. ANM / NHS Secure Boundary (e.g. ANM, Perimeter Security) – NHS Digital Data Security Centre (DSC) responsibility
  4. The internet gateway configured in the public cloud provider's environment – service providers responsibility.

Examples include:

  • accessing a national internet facing “directory of services” service
  • Virtual Private Network (VPN) between cloud provider and organisation. 

2. Outbound access from end user or system to a cloud-based service (over HSCN)

Outbound access from end user or system to a cloud-based service (over HSCN).

Description of diagram 2

This diagram consists of two NHS or health and social care organisations connected to HSCN via different CNSPs.  The CNSPs are inter-connected via the Peering Network (PN).  

The diagram shows the public cloud environments connected via a dedicated infrastructure (such as AWS DirectConnect, Azure's ExpressRoute, or Google's Cloud Connect) directly with a single CNSP. 

Traffic destined for this Cloud provisioned service is directed via this CN-SP to the cloud environments.  If consuming organisations aren't on the same CN-SP, then their traffic would be routed via their CN-SP, through the Peering Network (PN) and onto the connected CN-SP.

In this situation, the traffic isn't routed to the internet to get to the cloud providers and so traffic isn't routed via Advanced Network Monitoring (ANM) / NHS Secure Boundary but is instead routed to the organisations' environment in the public cloud. The diagram shows the points of control being:  The consuming organisations' perimeter.  The CN-SP’s connection to the public cloud providers dedicated connectivity infrastructure and the gateway configured in the public cloud providers environment. 

In this use case the public cloud service is directly connected to HSCN via a cloud service provider/CN-SP.

The consumer (ORG B) accesses the Public Cloud service via HSCN and traffic will traverse the consumers CNSP (CN-SP-N), the HSCN PN (Peering Network) and the CNSP used to provide HSCN connectivity to the service (CN-SP-1).

This use case demonstrates a connection to external systems initiated from within HSCN.  Typically, this design uses Direct Connect, ExpressRoute, Google cloud Interconnect or similar infrastructure.

The points of control within the above diagram are:

  1. Consuming organisations' perimeter – consumers responsibility
  2. CNSPs connection between itself and cloud providers – CN-SPs responsibility
  3. The internet gateway configured in the public cloud providers environment – IT service providers responsibility.

Use case 2 requires adherence to Obligation S08 and pre-approval by NHS Digital (DSC) Data Security Centre. 

To do this, please raise a call with the NHS National Service Desk by email at ssd.nationalservicedesk@nhs.net, or by telephone on 0300 303 5035.  Calls should be raised with the HSCN service, defined that this is regarding Security Obligation S08 and marked for attention of the Data Security Centre.

Examples include

  • accessing eRS (both over HSCN and internet facing)
  • accessing a regional service from organisations connected to different CN-SP’s. In the example shown Organisation B (yellow) doesn’t use any capacity of Organisations A’s (red) HSCN connection.  They share the usage of the cloud connectivity service provided by a CN-SP for that regional service.  Consideration for the distribution of your client’s access is key to delivering a successful network design.

3. Inbound access from system to an organisation over the internet (locally implemented internet provision)

Inbound access from system to an organisation over the internet (locally implemented internet provision).

Description of diagram 3

This diagram consists of two NHS or health and social care organisations connected to HSCN via different CNSPs.  The CNSPs are inter-connected via the Peering Network (PN).   The diagram shows the Public cloud environments connected via a dedicated infrastructure (such as AWS DirectConnect, Azure's ExpressRoute, or Google's Cloud Connect) directly with the end customer site (Just organisation A in this diagram).

In this situation, the connectivity isn't provisioned using HSCN infrastructure and is delivered locally to the customer site. The diagram shows the points of control being:  The consuming organisations' perimeter and the gateway configured in the public cloud providers environment.

This use case represents locally implemented cloud connectivity where traffic is not routed over HSCN but is being kept locally to that organisations network. This could also include any locally provisioned cloud connectivity services (ExressRoute/Direct Connect, Google cloud Interconnect etc.)

The points of control within this diagram are:

  1. Organisation A perimeter – customers responsibility
  2. The internet gateway configured in the public cloud providers environment – service providers responsibility.

Examples include:

  • Hybrid Private cloud deployments
  • Azure Application Peering over ExpressRoute (Office 365 etc). 

A similar implementation pattern exists where traffic is routed over the connecting organisations HSCN access circuits, but access is limited to only users/endpoints within that organisations network and the traffic isn’t exposed to any other HSCN consumers.  This diagram consists of two NHS or health and social care organisations connected to HSCN via different CNSPs. 

Description of diagram 4

This diagram consists of two NHS or health and social care organisations connected to HSCN via different CNSPs.  The CNSPs are inter-connected via the Peering Network (PN).   The diagram shows the public cloud environments connected via a dedicated infrastructure (such as AWS DirectConnect, Azure's ExpressRoute, or Google's Cloud Connect) and delivered by a CNSP.  In this situation, the connectivity is using HSCN access circuits but is only accessible by Organisation A).  The diagram shows the points of control being:  The Consuming organisations' perimeter; the gateway configured in the Public Cloud providers environment, and the CNSP’s connection to the public cloud providers dedicated connectivity infrastructure. 

The points of control within this diagram are:

  1. Organisation A's perimeter - customers responsibity
  2. The internet gateway configured in the Public Cloud providers environment – Service providers responsibility. Onwards control of access to ensure only via the connectin
  3. CNSP’s connection between itself and the cloud providers. – CNSP’s responsibilit, with onwards control of access to ensure only accessible via the connecting organisation.

4. Inbound access from public cloud based systems to HSCN connected end users or systems

This diagram consists of two NHS or health and social care organisations connected to HSCN via different Consumer Network Service Provider (CNSPs). 

Description of diagram 5

This diagram consists of two NHS or health and social care organisations connected to HSCN via different Consumer Network Service Provider (CNSPs).  The CNSPs are inter-connected via the Peering Network (PN).  

The diagram shows the public cloud environments connected via a dedicated infrastructure (such as AWS DirectConnect, Azure's ExpressRoute, or Google's Cloud Connect) and delivered by a CNSP. 

In this situation, the connectivity is using HSCN  to get to the end points on the same or other CNSP's. If traffic needs to be routed to another CNSP to get to a specific HSCN endpoint, this will be achieved via the Peering network (PN). In this situation, the traffic is initiated in the Public cloud providers environment and is therefore inbound onto HSCN.  

The diagram shows the points of control being:  The Consuming organisation’s perimeter; the CNSP’s connection to the public cloud providers dedicated connectivity infrastructure, and the gateway configured in the Public Cloud providers environment. 

In this use case the public cloud service is directly connected to HSCN via a Cloud Service Provider or CNSP. Service providers or consumers have access via this dedicated connection, and traffic traverses the consumers CNSP, HSCN Peering Network (if applicable), and the CNSP used to provide HSCN connectivity to the service. 

Examples include suppliers connecting to a system/source/endpoint and the interactions are initiated externally to HSCN (e.g. within the Public Cloud environment).Typically, this design will use Direct Connect, ExpressRoute, Google cloud Interconnect or similar infrastructure.

This would potentially allow inbound internet access and would require adherence to the SO10 and SO10a obligations.

The points of control within this diagram are:

  1. Organisation A perimeter – customers responsibility
  2. Consumer Network Service Provider (CNSP’s) connection between itself and the cloud providers. – CNSPs responsibility. Onwards control of access to other endpoints (through peering to other CNSP customers)
  3. The internet gateway configured in the public cloud providers environment – service providers responsibility.

This use case requires adherence to obligations S08 pre-approval by NHS Digital Data Security Centre (DSC). 

This use case also requires providers and CN-SPs to adhere to the SO10 and SO10a obligations. To do this, please raise a call with the NHS National Service Desk by email at ssd.nationalservicedesk@nhs.net or by telephone on 0300 303 5035.  Calls should be raised with the HSCN service, and identified as regarding Security Obligations SO8 and SO10/SO10a, marked for the attention of the Data Security Centre.

Examples include: regional service accessing systems or data from organisations connected to different CNSPs. In the example shown Organisation B (yellow) doesn’t use any capacity of Organisations A’s (red) HSCN connection.  They share usage of the cloud connectivity service provided by a CNSP for that regional service.  Consideration for the distribution of your client’s access is key to delivering a successful network design.

Policies and guidance

These policies, guidelines and standards are defined by a number of different aspects:

  • use cases approval
  • IP Addressing
  • roles and responsibilities.
  • Public Cloud architecture design
  • Data Security Protection Toolkit
  • HSCN Connection Agreement
  • HSCN Obligations Framework
  • Health and Social Care cloud security good practice guide
  • Inbound internet Connectivity Risk Mitigation for CNSPs and HSCN consumers
  • Cloud service provider policy. 

Use case approval

Each of the use cases we have provided have been broken down into the table below.  

Automatically approved

Individual approval required
Use case 1

 
Use case 2   

✔ compliance with S08 

Use case 3  
Use case 4  

✔ compliance with S08 and S010/S010a.

Use case 1 and use case 3 are approved use cases subject to addressing isolation requirements. The roles defined each have different responsibilities regarding the provision of those types of service.

Use case 2 requires compliance with S08 and explicit approval for the routing of traffic.

Use case 4 also requires compliance with S08 and explicit approval for the routing of traffic, and, in addition, it requires compliance with SO10 and SO10a which relate to Inbound internet

Obligations SO10 and SO10a have specific guidance available read the Inbound internet connectivity guidelines for CNSPs and consumers.  

For adherence to obligation SO8, pre-approval by the NHS Digital Data Security Centre is required.

To do this, please raise a call with the NHS National Service Desk by emailing the NHS national service desk  or by telephone on 0300 303 5035.  Call should be raised with the HSCN service, defined that this is regarding Security Obligation S08 / SO10/10a and marked for attention of the data security centre.

IP addressing  

The very nature of public cloud services is that anyone can use them, including malicious actors who may use a public cloud service to initiate attacks and host or deliver malicious content. To mitigate the risk of malicious services hosted in public cloud, any public cloud service should always use addresses outside of the cloud providers public block.  It is therefore required that when connecting a public cloud provisioned service to HSCN, this must be using HSCN approved addresses. Each service should have its own HSCN approved address so that isolation is maintainable between those services.

In the event of a malicious attack from a public cloud service the HSCN authority may be required to block the IP addresses where malicious traffic is originating from.  Any service that uses public cloud addressing instead of HSCN approved addressing must ensure they mitigate the risks/ hazards associated with having their service blocked.

IP addresses need to be obtained from NHS Digital via the HSCN IP address management process and then be registered with the consuming organisation. 

It is the CNSPs responsibility to ensure that all IP addresses allocated to Inbound Cloud connections are registered on the NHS Digital IPAM (HSCN IP address management).

Roles and responsibilities 

We have provided a simple matrix of the associated standards and agreements and which roles are obliged to comply with which standards/agreements/policies/principles.

  Consumer  Cloud Service Provider (CSP) CNSP ITSP
National Cyber Security Centre (NCSC) Cloud Security Principles
Data Security and Protection Toolkit (DSPT)
HSCN ITSP connection on agreement    
HSCN Consumers connection agreement       
HSCN Obligations Framework       
Health and social care cloud security good practice guide 
HSCN Cloud Service Provider (CSP) policy       
Validate HSCN compliance and authority approval received  

Public cloud architecture design

Services in the Public Cloud should be designed in line with NCSC Cloud Security Principles and Center for Internet Security (CIS) critical security controls.

To support this some top tier cloud providers have created a template for deploying a solution in line with the NCSC and CIS and on how to deploy and secure dedicated network links.

Both the AWS and Azure architectures provide a responsibility matrix for the above security controls. Other suppliers may also have produced similar materials and guidance

The hosting policy sets out which locations are acceptable for hosting specific data types. If you are responsible for multi-region deployments, you should consider how Direct Connect/ExpressRoute/Google cloud Interconnect (or similar infrastructure) deployments can maintain service connectivity and resilience/availability.

Guidance includes: (others are available)

AWS direct connect resiliency recommendations

Microsoft ExpressRoute overview

Cloud dedicated interconnect overview.  

Platform As A Service (PAAS) and Software as a Service (SAAS)

PAAS and SAAS can be used on or over HSCN. We recommend you follow your chosen cloud providers guidance when implementing security managed Cloud based services.

AWS, Azure and Google Cloud security whitepapers and best practices are available in the next section below.”

AWS, Azure and Google security whitepapers and best practices are available for download in the Health and social care cloud security good practice guide section below.

Health and social care cloud security good practice guide

We have published a Health and Social Care Cloud Security Good Practice Guide which should be read alongside this guidance.

Interpretation of security principle 11, below, doesn’t preclude the use of IAAS, PAAS or SAAS.

“Ensure that the implemented design protects data by ensuring it is at least two ‘firewall’ hops from the external network, architected in such a way that the compromise of one firewall will not affect the other. “

Access Control Lists implemented within a Virtual Private Cloud (VPC)/Cloud environment would effectively provide the same separation. Therefore, maintaining the 2 hops between systems and a private network. HSCN Cloud suppliers are responsible for managing the HSCN end and the consumer/customer are responsible for managing the access controls within the cloud environment. 

Similarly, in the case of PAAS and SAAS usage, the security provided by the cloud managed service provider (AWS/Azure/Google etc) is one security boundary.  The shared responsibility aspects show that the managed service supplier is responsible for the security of that managed service. The other boundary would be provided by the CNSP cloud provider between the cloud infrastructure and HSCN

Guidance on doing this securely is available:

Data security protection toolkit

The Data Security Protection Toolkit (DSPT) has replaced the Information Governance Toolkit (IGT). All organisations that have access to NHS patient data and systems must use this toolkit to provide assurance that they are practicing good data security and that personal information is handled correctly.

All mandatory assertions must be completed within the DSPT.

 

HSCN Connection Agreement 

Every organisation that wishes to use HSCN must complete a Connection Agreement. By "use HSCN", we mean 'send or receive data across HSCN'. CNSPs shall ensure every organisation that wishes to use HSCN must complete a HSCN Connection Agreement.

Three distinct HSCN Connection Agreements are available.

  • standard Consumer Connection Agreement (CA)
  • organisations representing other Organisations. (such as CCG’s etc) Connection Agreement CA
  • IT Service provider (ITSP) Connection Agreement (CA). 

For each type of Connection Agreement, there are 2 parts.

  • part 1 – HSCN only
  • part 2 – HSCN and Transition Network (TN). 

A standard end user/consumer of HSCN services is required to sign a HSCN standard Consumer Connection Agreement.

A service provider (such as an application/Service or IAAS/PAAS service) is required to sign an ITSP Connection Agreement and is responsible for users/consumers of their service signing a standard Consumer Connection Agreement.

The organisation must confirm that you agree with the “Acceptable Use” statement and specify, at a high level, what sorts of services your organisation offers. Depending on the information which you submit you will either be automatically approved or your application to sign an HSCN Connection Agreement (and thereby gain access to HSCN) will be paused pending manual approval by the HSCN Authority. 

HSCN Obligations Framework 

The HSCN Obligations Framework describes the obligations that HSCN Suppliers shall adhere to for the supply, delivery and operation of HSCN Connectivity Services to HSCN Consumers:

Aspects of the Obligations Framework applicable to this policy are:

  • SO10 and SO10a are applicable to Inbound internet access, and guidance is available on inbound internet connectivity.  Use cases 2 and 4 will require adherence to SO10 and So10a
  • S08 requires specific approval to connect to external networks. A Consumers or ITSPs VPC or cloud environment is classed as an external network.  

Use cases 2 and 4 require adherence to obligations S08 /S010 /SO10a.

Obligations SO10 and SO10a have a specific guide available, listed in the section below.     

For adherence to Obligation S08, pre-approval by NHS Digital Data Security Centre is required. To do this, please raise a call with the NHS National Service Desk by email at ssd.nationalservicedesk@nhs.net, or by telephone on 0300 303 5035.  Call should be raised with the HSCN service, defined that this is regarding Security Obligation S08 / SO10/10a and marked for attention of the Data Security Centre.

CNSPs shall ensure all Inbound Cloud connections are recorded in the HSCN Estate Data in accordance with HSCN CNSP Service Provider Management Requirement Addendum.

CNSPs shall generate network monitoring data for all inbound cloud connections in accordance with HSCN obligation SO1: Network Analysis.

CNSPs shall record the following information for each inbound connection:

  • HSCN Consumer Organisation’s details
  • External Service Provider / Customer details
  • Source IP address(s), ports and protocols application or service details

CNSPs shall provide NHS Digital’s Data Security Centre (DSC) the aforementioned information upon request.   

Inbound internet connectivity guidance for CNSPs and consumers

The Health and Social Care Network (HSCN) Obligations Framework includes, where requested, the facility for consumers to receive service connections initiated from the internet. For example, if a consumer organisation is to receive application support remotely from an external service provider, via the internet, then they can request that their Consumer Network Service Provider (CNSP) facilitates the inbound internet connection:

HSCN Obligation SO10: “HSCN Suppliers shall provide access to HSCN consumer's business application services or other services (e.g. websites) from the internet - on request from the HSCN Consumer and after verifying that the HSCN Consumer has completed an HSCN Connection Agreement that includes their provision of external services.”

HSCN Obligation SO10a: “HSCN Suppliers shall ensure that attacks on the internet IP addresses of HSCN consumer business application services (or other services) available through the internet gateway do not disrupt the provision of outbound internet services across the internet gateway or the availability of the wider HSCN service.”

Downloads

To be a HSCN Cloud Service Provider you must comply with the HSCN CSP policy.

Public cloud provider specific documentation

Further Cloud specific documentation may become available in the future. For example, guidance on implementing Microsoft Application Peering and Office 365.

Last edited: 13 February 2020 11:19 am