Shared Responsibility Model

Aridhia provides the DRE as a managed service, which is deployed in the cloud, either in Aridhia’s or in a customer’s Microsoft Azure tenancy.

Cloud services such as the DRE are subject to a shared responsibility model, whereby the underlying cloud provider (Microsoft Azure), the SaaS/PaaS provider (Aridhia) and the end customer each take ownership for different aspects of the service.

The following diagram summarises the different responsibilities for each party in a typical DRE deployment.

Aridhia Responsibilities

Set-up, Deployments, and Patching

Aridhia’s Ops team set-up the DRE in a dedicated subscription for our customers.

New software releases are performed each week, alternating between FAIR and Workspaces.

Most software releases require zero service downtime. If a release does require service downtime (e.g. due to a database upgrade), then this is arranged with our customers in advance.

Aridhia deploys OS patches to the core DRE service on a quarterly basis, and any critical OS patches are deployed as soon as possible.

Workspace VM patching is carried out to the following policy detailed on our Knowledge Base.

Vulnerability Management

Microsoft Azure Defender is used:

• during our SDLC to check for vulnerabilities – a JIRA ticket is automatically raised for vulnerabilities and assigned to our Dev team.
• for security monitoring and threat management on the Azure subscription where the DRE is deployed.

Aridhia’s InfoSec team performs:

• a daily check for alerts and a review of threat intelligence.
• a monthly review of Azure Defender recommendations – customer reports can be made available.

Penetration testing

Aridhia engages with third parties to carry out penetration tests on the DRE every year.

Customers can arrange for their own pen test to be done on the DRE – please discuss with your CSM.

Resilience

The DRE runs nightly back-ups – and operates to a Recovery Point Objective (RPO) of 24 hours.

Back-ups are taken on a rolling 14-day schedule – meaning the last point you can recover to is 14 days ago.

Back-ups can be to the local and remote Azure region (but still in the country), albeit remote back-ups are most expensive in Azure.

We have a Recovery Time Objective (RTO) target of 72 hours in restoring to a remote Azure region – this assumes that Azure resources are available in the remote region.

As part of the ISO and HiTRUST certifications that we hold, Aridhia runs quarterly Disaster Recovery and incident response exercises.

The Aridhia Service Desk can recover resources e.g. A workspace deleted by accident, if within the back-up schedule (14 days as standard).

Governance, data sharing and certifications

Aridhia acts as a Data Processor – typically the customer is acting as the Data Controller.

As standard, a Data Processing Agreement is put in place between Aridhia and the customer.

A sample DPA can be found here.

Additional data sharing agreements may be necessary if other data owners are involved.

Aridhia’s DPO and Information Security Manager can assist with questions on data sharing, governance, etc. Aridhia is responsible for maintaining and operating the Digital Research Environment to our certifications (ISO 27001/27701, HiTRUST, Cyber Essentials Plus, and NHS Digital Security and Protection Toolkit).

Aridhia adheres to the following Privacy Policy.

Support

Aridhia’s Service Desk is available during UK office hours. Further detail on raising tickets and target SLA can be found here.

Our Service Desk team is backed by an Operations team, a Development team, and a Data Engineering team, who deal with more complex support issues.

For underlying Azure issues, Aridhia engages directly with Microsoft (unless the DRE is hosted within the customer’s tenancy).

Aridhia is also responsible for paying Azure costs to Microsoft (and re-charging the customer), unless the DRE is hosted on a customer’s own tenancy, in which case the customer is responsible for paying Azure costs.

Customer responsibilities

Project & People

Projects – customers decide:

• Which projects will run on the DRE and for how long
• What resources are needed (workspaces, additional compute, etc.)
• Who the DRE workspace Administrator(s) will be (usually the PI for the project)
• Project budget
• Any terms and conditions or restrictions that apply to the project.

People – customer decide:

• Which users will join the DRE, including from other institutions
• What user approval/accreditation process is required
• What roles and permissions will be granted to DRE users within their organisation
• What user training must be done (technical, governance, etc.)

Individual users are responsible for ensuring that they follow the DRE usage terms and conditions.

Data & outputs

Customers are responsible for:

• Determining which datasets will be made available on the platform and what process should be configured in FAIR to deal with Data Access Requests
• Ensuring that suitable Data Sharing Agreements are in place - e.g. between the customer and any third parties who have either made data available or want access to data
• Ensuring that users understand their responsibilities relating to the use of Personally Identifiable Information within the DRE
• Ensuring that workspace administrators understand their responsibilities for input and output checking of data to the DRE, as per the inbound and outbound airlock.

Workspace Settings

Within DRE Workspaces, administrators determine:

• What hub-level and individual workspace IP allow list settings should be
• Whether additional VMs and Azure services can be provisioned for a workspace, in terms of cost, governance, etc.
• What 3rd party software can be installed and run on a Virtual Machine
• Maintenance and patching of all software (except for the OS)
• Input and output checking of data to the DRE (as per inbound and outbound airlock)