Google Cloud platform

Service scope

Service constraints: N/A
System requirements: N/A

User support

Email or online ticketing support: Email or online ticketing
Support response times: S1 The production system cannot be used. No users are able to work in the production system. 24x7x365 <= 30 mins <= 2 h 95% 1,2
S2 Users can access the production system but a critical part of the application is unavailable or degraded.24x7x365 <=60 mins. <= 4 h 90% 1,2
S3 Users can access the production system and work but experience periodic problems.

S4 Low impact for the user.The users can work normaly. <= 24 h <= 48 h 90% 1,2
User can manage status and priority of support tickets: Yes
Online ticketing support accessibility: None or don’t know
Phone support: Yes
Phone support availability: 9 to 5 (UK time), Monday to Friday
Web chat support: No
Onsite support: Yes, at extra cost
Support levels: We offer support in either 24x7 and 9x5 modes.
Cost varies by the amount of services deployed
The service has a preventative component, with periodic maintenance, monthly reporting and continuous improvement of the infrastructure, and a corrective component, when problems occur in the system covered by this support contract.
Once an issue has been received by The Server Labs, the procedure takes the following steps.

• Verification of the issue and escalation to second level support.
• Communication to customer of the solution to be undertaken.
• Restoration of any service lost working with the DBA and or engineer assigned to the project.
• Restoration of any data lost working with the DBA assigned to the project.
• Update of the system documentation if necessary.
• Closeout of the issue with description of actions undertaken.
Support available to third parties: Yes

Onboarding and offboarding

Getting started: Google provides a range of resources to help customers get started on our services. These include: comprehensive documentation (in multiple formats), introductory videos, hands-on labs, online and in-person training, access to a large ecosystem of partners and support from the public sector account team.
Service documentation: Yes
Documentation formats: HTML

PDF
End-of-contract data extraction: Data may be copied out using OS-level tools (such as xopy, scp, ftp or rsync).
End-of-contract process: "Buyer may terminate the relationship with Supplier for any reason by (i) providing Supplier with notice and (ii) closing Buyers account for all services for which Supplier provide an account closing mechanism.

Buyers pay for the services they use to the point of account termination.

Supplier customers retain control and ownership of their data. Supplier will not erase customer data for 30 days following an account termination. This allows customers to retrieve content from Supplier services so long as the customer has paid any charges for any post-termination use of the service offerings and all other amounts due.
"

Using the service

Web browser interface: Yes
Using the web interface: Manage and deploy services via the Google Cloud Portal. See https://cloud.google.com/products/

WCAG 2.1 AA or EN 301 549

GCP works best in Chrome and can benefit from accesibility add-ons.
Web interface accessibility standard: WCAG 2.1 AA or EN 301 549
Web interface accessibility testing: None
API: Yes
What users can and can't do using the API: Users are able to utilise the GCP APIs for each service within the platform. Anything that can be done through the console can be done via the API. https://cloud.google.com/apis/docs/overview As well as REST APIs, Language SDKs exist for C#,Go,Java,Node.js,PHP,Python and Ruby
API automation tools: Ansible

Chef

SaltStack

Terraform

Puppet

Other
Other API automation tools: Wide range of 3rd party services hook into GCP APIs.

SDKs for Python, Ruby, PHP, JavaScript, Java, .NET, Node.js.
API documentation: Yes
API documentation formats: HTML

PDF

Other
Command line interface: Yes
Command line interface compatibility: Linux or Unix

Windows

MacOS
Using the command line interface: The Google Cloud SDK https://cloud.google.com/sdk/ provides a powerful command line that can work with the following platform services: Compute Engine Kubernetes Engine Deployment Manager Cloud DNS Cloud IAM Cloud Storage App Engine Cloud ML Engine Cloud SQL Cloud Dataproc Cloud Logging BigQuery Cloud Dataflow Resource Manager Source Repositories

Scaling

Scaling available: Yes
Scaling type: Automatic
Independence of resources: Customer environments are logically segregated to prevent users and customers from accessing resources not assigned to them.

Services which provide virtualized operational environments to customers ensure that customers are segregated via security management processes/controls at the network and hypervisor level.

Google continuously monitors service usage to project infrastructure needs to support availability commitments/requirements. Google maintains a capacity planning model to assess infrastructure usage and demands at least monthly, and usually more frequently. In addition, the Google capacity planning model supports the planning of future demands to acquire and implement additional resources based upon current resources and forecasted requirements.
Usage notifications: Yes
Usage reporting: API

Email

SMS

Other

Analytics

Infrastructure or application metrics: Yes
Metrics types: CPU

Disk

HTTP request and response status

Memory

Network

Number of active instances

Other
Other metrics: Custom metrics generated by customers’ applications and services

Metrics associated with log files generated by the application
Reporting types: API access

Real-time dashboards

Resellers

Supplier type: Not a reseller

Staff security

Staff security clearance: Conforms to BS7858:2019
Government security clearance: Up to Developed Vetting (DV)

Asset protection

Knowledge of data storage and processing locations: Yes
Data storage and processing locations: United Kingdom
User control over data storage and processing locations: Yes
Datacentre security standards: Supplier-defined controls
Penetration testing frequency: At least every 6 months
Penetration testing approach: Another external penetration testing organisation
Protecting data at rest: Other
Other data at rest protection approach: Google adheres to independently validated privacy, data protection, security protections and control processes. (Listed under “certifications”).

Google is responsible for the security of the cloud; customers are responsible for security in the cloud. Google enables customers to control their content (where it will be stored, how it will be secured in transit or at rest, how access to their Google environment will be managed).

Wherever appropriate, Google offers customers options to add additional security layers to data at rest, via scalable and efficient encryption features. Google offers flexible key management options and dedicated hardware-based cryptographic key storage.
Data sanitisation process: Yes
Data sanitisation type: Explicit overwriting of storage before reallocation

Deleted data can’t be directly accessed

Hardware containing data is completely destroyed
Equipment disposal approach: In-house destruction process

Backup and recovery

Backup and recovery: Yes
What’s backed up: Machine image

Volumes

Cross-region replication; bucket versioning, lifecycle rules

Swagger export

Code download

Tables and Data

Logs

Emails

Disk snapshots
Backup controls: Manual or scheduled API call
Datacentre setup: Multiple datacentres with disaster recovery
Scheduling backups: Users schedule backups through a web interface
Backup recovery: Users can recover backups themselves, for example through a web interface

Data-in-transit protection

Data protection between buyer and supplier networks: Private network or public sector network

TLS (version 1.2 or above)

IPsec or TLS VPN gateway

Other
Other protection between networks: Network devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services.

ACLs, or traffic flow policies, are established on each managed interface, which manage and enforce the flow of traffic. ACL policies are approved by Google Information Security.
Data protection within supplier network: Other
Other protection within supplier network: Customer environments are logically segregated to prevent users and customers from accessing resources not assigned to them. Google gives customers ownership and control over their content by design through simple, but powerful tools that allow customers to determine how their content will be secured in transit.
Google enables customers to open a secure, encrypted channel to Google Cloud Platform services using TLS/SSL, and/or IPsec or TLS VPN (if applicable), or other means of protection the customer wish to use.
API calls can be encrypted with TLS/SSL to maintain confidentiality; the Google Console connection is encrypted with TLS.

Availability and resilience

Guaranteed availability: Google currently provides SLAs for several services. Due to the rapidly evolving nature of Google product offerings, SLAs are best reviewed directly on our website via the link below:

https://cloud.google.com/s/results/?q=sla&hl=en

Well-architected solutions on Google that leverage Google Service SLA’s and unique Google capabilities such as multiple Availability Zones, can ease the burden of achieving specific SLA requirements.
Approach to resilience: The Google Business Continuity plan details the process that Google follows in the case of an outage, from detection to deactivation. Google has developed a three-phased approach: Activation and Notification Phase, Recovery Phase, and Reconstitution Phase. This approach ensures that Google performs system recovery and reconstitution efforts in a methodical sequence, maximizing the effectiveness of the recovery and reconstitution efforts and minimizing system outage time due to errors and omissions.

Google maintains a ubiquitous security control environment across all regions. Each data centre is built to physical, environmental, and security standards in an active-active configuration, employing an n+1 redundancy model, ensuring system availability in the event of component failure. Components (N) have at least one independent backup component. All data centres are online and serving traffic. In case of failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.

Customers are responsible for implementing contingency planning, training and testing for their systems hosted on Google. Google provides customers with the capability to implement a robust continuity plan, including the utilization of frequent server instance back-ups, data redundancy replication, and the flexibility to place instances and store data within multiple geographic regions across multiple Availability Zones.
Outage reporting: Public dashboard; personalised dashboard with API and events; configurable alerting (email / SMS / messaging)

Identity and authentication

User authentication: 2-factor authentication

Identity federation with existing provider (for example Google apps)

Limited access network (for example PSN)

Dedicated link (for example VPN)

Username or password

Other
Other user authentication: Google controls access via unique user ID/password authentication. No actions are permissible without authentication. Remote access is multi-factor, login attempts are limited, remote administrative access attempts are logged and reviewed by Security. Suspicious activity initiates incident response procedures.

A session lock out policy that is systematically enforced: locks are retained until identification/authentication procedures are concluded.

Google Identity and Access Management (IAM) system controls access to Google services/resources. IAM facilitates the issuance of access permissions per user/group.
Access restrictions in management interfaces and support channels: IAM provides user access control to Google services, APIs and specific resources. Other controls include time, originating IP address, SSL use, and whether users authenticated via MFA devices.

API calls to launch/terminate instances, change firewalls, and perform other functions are signed by customers’ Secret Access Key. API calls cannot be made on customers’ behalf without access to customers’ Secret Access Key.

API calls can be encrypted with TLS/SSL for confidentiality and customers can use TLS/SSL-protected API endpoints.
Access restriction testing frequency: At least every 6 months
Management access authentication: 2-factor authentication
Devices users manage the service through: Dedicated device on a segregated network (providers own provision)

Audit information for users

Access to user activity audit information: Users have access to real-time audit information
How long user audit data is stored for: User-defined
Access to supplier activity audit information: You control when users can access audit information
How long supplier audit data is stored for: At least 12 months
How long system logs are stored for: At least 12 months

Standards and certifications

ISO/IEC 27001 certification: Yes
Who accredited the ISO/IEC 27001: EY CertifyPoint
ISO/IEC 27001 accreditation date: 11/11/2016
What the ISO/IEC 27001 doesn’t cover: N/A
ISO 28000:2007 certification: No
CSA STAR certification: Yes
CSA STAR accreditation date: 11/11/2016
CSA STAR certification level: Level 3: CSA STAR Certification
What the CSA STAR doesn’t cover: N/A
PCI certification: Yes
Who accredited the PCI DSS certification: Coalfire Systems Inc
PCI DSS accreditation date: 25/01/2018
What the PCI DSS doesn’t cover: N/A
Cyber essentials: Yes
Cyber essentials plus: Yes
Other security certifications: Yes
Any other security certifications: Cyber Essentials Plus

ISO 27017

ISO 27018

SOC 1/2/3

Security governance

Named board-level person responsible for service security: Yes
Security governance certified: Yes
Security governance standards: ISO/IEC 27001
Information security policies and processes: Cyber Essentials Plus; ISO 27017; ISO 27018; SOC 1/2/3

Operational security

Configuration and change management standard: Supplier-defined controls
Configuration and change management approach: Changes to Google services and features follow secure software development practices, including security risk reviews prior to launch. Developer access to production environments is via explicit access system requests, subject to owner review and authorisation.

Teams set bespoke change management standards per service, underpinned by standard Google guidelines.

All production environment changes are reviewed, tested and approved. Stages include design, documentation, implementation (including rollback procedures), testing (non-production environment), peer to peer review (business impact/technical rigour/code), final approval by authorised party.

Emergency changes follow Google incident response procedures. Exceptions to change management processes are documented and escalated to Google management.
Vulnerability management type: Supplier-defined controls
Vulnerability management approach: Google Security performs vulnerability scans on the host operating system, web applications, and databases in the Google environment. Approved 3rd party vendors conduct external assessments (minimum frequency: quarterly). Identified vulnerabilities are monitored and evaluated. Countermeasures are designed and implemented to neutralise known/newly identified vulnerabilities.

For more information on Google security, please refer to the following link: https://cloud.google.com/security?hl=en
Protective monitoring type: Supplier-defined controls
Protective monitoring approach: Google deploys (pan-environmental) monitoring devices to collect information on unauthorized intrusion attempts, usage abuse, and network/application bandwidth usage. Devices monitor:

• Port scanning attacks
• Usage (CPU, processes, disk utilization, swap rates, software-error generated losses)
• Application metrics
• Unauthorized connection attempts

Near real-time alerts flag potential compromise incidents, based on Google set thresholds.

For more information on google security, please go to the following link: https://cloud.google.com/security?hl=en
Incident management type: Supplier-defined controls
Incident management approach: Google adopts a three-phased approach to manage incidents:

1. Activation and Notification Phase
2. Recovery Phase
3. Reconstitution Phase

To ensure the effectiveness of the Google Incident Management plan, Google conducts incident response testing, providing excellent coverage for the discovery of defects and failure modes as well as testing the systems for potential customer impact.

The Incident Response Test Plan is executed annually, in conjunction with the Incident Response plan. It includes multiple scenarios, potential vectors of attack, the inclusion of the systems integrator in reporting and coordination and varying reporting/detection avenues.

Secure development

Approach to secure software development best practice: Independent review of processes (for example CESG CPA Build Standard, ISO/IEC 27034, ISO/IEC 27001 or CSA CCM v3.0)

Separation between users

Virtualisation technology used to keep applications and users sharing the same infrastructure apart: Yes
Who implements virtualisation: Supplier
Virtualisation technologies used: Other
Other virtualisation technology used: Google proprietary
How shared infrastructure is kept separate: Customer environments are logically segregated, preventing users and customers from accessing unassigned resources. Customers maintain full control over their data access. Services which provide virtualized operational environments to customers, ensure that customers are segregated and prevent cross-tenant privilege escalation and information disclosure via hypervisors and instance isolation.

Different instances running on the same physical machine are isolated from each other via the hypervisor. The Google firewall resides within the hypervisor layer, between the physical network interface and the instance's virtual interface. All packets pass through this layer. The physical random-access memory (RAM) is separated using similar mechanisms.

Energy efficiency

Energy-efficient datacentres: Yes
Description of energy efficient datacentres: https://sustainability.google/

Fighting climate change: Fighting climate change

TSL is a pure cloud and virtual organisation, we do not have offices, and we perform all work as much as is possible remotely, with face to face meetings involving transportation kept to an absolute minimum. This is our contribution to fight climate change
Covid-19 recovery: Covid-19 recovery

TSL are a pure cloud, virtual organisation, as such we have not been touched by Covid restrictions, we have not had to accept any government Covid support, and we respect the rights of our employees and clients in their desire to minimised direct contact and office working to avoid the potential exposure to Covid-19
Tackling economic inequality: Tackling economic inequality

All TSL staff require technical expertise, however, we do not have a focus on specific academic institutes and we employ staff based on their technical competence and no other criteria.
Equal opportunity: Equal opportunity

We are an equal opportunity employer, as an example our CEO and 33% of core staff overall being female.
Wellbeing: Wellbeing

TSL value the wellbeing of our staff, which is why we allow staff to choose were they work from, with all staff working from Home and with flexible working condition, including part time working encouraged.

Pricing

Price: £0.01 a unit
Discount for educational organisations: No
Free trial available: Yes
Description of free trial: Introductory 12 months free. Conditions apply.

Features

Benefits

Service documents

Framework

Service ID

Contact

Service scope

User support

Onboarding and offboarding

Using the service

Scaling

Analytics

Resellers

Staff security

Asset protection

Backup and recovery

Data-in-transit protection

Availability and resilience

Identity and authentication

Audit information for users

Standards and certifications

Security governance

Operational security

Secure development

Separation between users

Energy efficiency

Pricing

Service documents

Cookies on Digital Marketplace

Google Cloud platform

Features

Benefits

Pricing

Service documents

Framework

Service ID

Contact

Service scope

User support

Onboarding and offboarding

Using the service

Scaling

Analytics

Resellers

Staff security

Asset protection

Backup and recovery

Data-in-transit protection

Availability and resilience

Identity and authentication

Audit information for users

Standards and certifications

Security governance

Operational security

Secure development

Separation between users

Energy efficiency

Social Value

Pricing

Service documents