Use Cases

• AP: App on a Cloud

• SD: Processing Sensitive Data

• DI: Data Integrity

• HA: High Availability

There are lot of start-ups and SMEs that are active in the Fintech industry (where the financial services meet new technologies and business models) with an operational and business plan to develop and exploit cloud-based services to their customers and end-users. For this, most will consider procuring either IaaS or PaaS from respective CSPs that offer these cloud services, which will be used as basis to develop, rely, and exploit their own PaaS respectively SaaS. This Use Case focusses on a Fintech company procuring IaaS from major IaaS CSP.

IaaS CSP as vendor. Fintech Early Stage company as customer, with the intent to build and exploit their own SaaS to its own customers which in this use case are financial institutions that wish their bank account holders to give access to said SaaS.

Acquisition

Before looking for appropriate IaaS CSPs, and finding and assessing the terms and conditions (including SLA) that may be applicable in the relationship between such IaaS CSP and the Fintech Early Stage company, first, this Fintech Early Stage company (with founders and management with university degrees) maps the main legal compliance criteria it deems relevant in the initial phase.

(1) The Fintech Early Stage company and its customer (bank) as well as its customers are based in The Netherlands.

(2) Furthermore, FSI is high-regulated, including special requirements for vendors (including without limitation any CSPs), which include the right of the bank authority to be able to audit the vendors in the respective supply chain.

(3) Personal data is involved, so the data protection regulation and legislation is applicable as well. These three main legal criteria are known to this Fintech Early Stage company.

(4) Its prospective customers (banks) are known for their strict procurement, including information security requirements, and high level of expectation of service delivery.

(5) There are no particular needs on IaaS, expect for that it should be relatively (a) cheap and (b) easy to develop, exploit and maintain its own SaaS on top of the IaaS of the selected CSP.

The security requirements that are generally requested by prospective customers (banks) – to the extent known beforehand – and that are known to be common practice in the relevant market are taken into account.

CSP Vendor pre-selection. After doing their internal desk research on the above, this Fintech Early Stage company starts with landscaping the results and based on that it starts its pre-assessing of which IaaS CSP would be able to deliver, and on what conditions. With that, it will request proposals of the pre-selected CSPs.

Assessment. Without some reasonable assessment, it is impossible to procure cloud services. This basically goes for generally all procurement but it is especially relevant as there are many types of cloud services, services models, deployment models, and even in the right category there is a lot of variety in offerings and terms. This Use Case shows that without diligence and proper assessment and pre-selection landscaping – which could be a bit less comprehensive than in the Use Case described above –, even a reasonably informed CSC is not able to start procuring the right cloud services.

Neither the prospective customers (banks) nor the bank authorities have the standards or best practices that are commonly used, this as for instance the banks have their own (without an FSI industry best practice being available regarding cloud services. And because the bank authorities do not see it as its task to provide such standard, guidelines or the like.

• AP: App on a Cloud

• HA: High Availability

• DI: Data Integrity

In 2013, the Government of Estonia took the first steps to deploy a Gov Cloud with three main principles guiding its development:

• Using Cloud solutions located within Estonia’s national borders,

• Using international private Cloud resources, and

• Using Data Embassies (cloud storage).

The Estonian government has built the foundation of a highly developed information society, and its ICT development has taken Estonia to a stage where many registers and services only exist in digital form. This development requires a flexible and secure Govt. Cloud solution. Sufficient flexibility has to be planned in advance. The State Infocommunication Foundation leads the Gov-Cloud development, which is responsible for the consolidation of server resources and provision of high-quality server hosting services within Estonia’s national borders. The Estonian Public Administration (PA) is the main cloud customer of the national Gov Cloud. In some cases PAs are provisioned with IaaS resources (e.g., virtual machines), but also PAs provision Gov cloud-based services to citizens. The Gov Cloud system does not store personal identifiable data.

List of involved actors/stakeholders:

• Cloud Service Providers, which provision their services to the Gov Cloud according to the requirements specified by the Cloud Owner (Estonian Government), and usually described on Service Level Agreements (SLA) and other contracts.

• Cloud Service Customer: the Public Administrations using Gov Cloud services

This use case defines an additional actor namely the Gov Cloud Owner, which relates to the organization that legally owns the Gov Cloud and defines policies and requirements. The analysis of this use case considers that the Gov Cloud Owner is the actor offering an SLA to the cloud customers (PAs). The offered SLA already takes into account the capabilities from participant CSPs.

This use case is based on the Operation phase of the Gov Cloud.

The Gov Cloud does not manage any PII data from the citizens. Legal compliance criteria are defined b the Estonian Public Procurement Act.

The following standards and best practices are being leveraged by the Estonian Gov Cloud: ISO 27001, ISO 27002, BSI IT, and the Estonian ISKE security framework.

High availability is a main concern in this use case, in order to guarantee continuous provision of PA services to the citizens.

• AP: App on a Cloud

• SD: Processing Sensitive Data

• DI: Data Integrity

From ENISA’s report: “ConsultLess is a small consultancy firm in the EU that has 20 employees (mostly legal and management experts). One of the employees is partner and also the Chief Information Officer (CIO) of the firm. ConsultLess decides to procure office software as a service (SaaS) for use by its employees: the cloud service offers document storage/editing, email and calendar. This cloud service should replace an internal mail-server and office software installed on computers.”

Compliance is a critical factor in this use case. Furthermore, some (not all) of the data stored and processed is sensitive, and data leaks could have a severe impact on the reputation/business of the firm.

List of involved actors/stakeholders:

• Cloud Service Provider, which provisions the storage/editing, email and calendar SaaS to ConsultLess. This is a public CSP. .

• Cloud Service Customer, is the ConsultLess SME using the CSP SaaS.

This use case focuses on the Acquisition stage of the public SaaS.

Process of sensitive data by ConsultLess should be compliant with applicable EU legislations.

The following security and privacy requirements apply to ConsultLess:

• Physical security of the cloud assets should be guaranteed by the CSP.

• Timely patching and updating, adequate backups, and security as a service are all required by ConsultLess.

• The CSP should demonstrate compliance through those certifications required by ConsultLess.

• ConsultLess wants to avoid vendor lock-in issues.

ConsulLess is an established SMEs that currently provisions in-house the ICT services being procured from the public SaaS.

 

Not being SLA savvy, ConsultLess CIO relays on the C-SIG SLA Guidelines for procuring its SaaS.

ConsultLess is not subject to any specific legal requirements about cross-border processing or data transfers.

• AP: App on a Cloud

• SD: Processing Sensitive Data

• DI: Data Integrity

• HA: High Availability

The SME is already using certain SaaS. At the time of procuring it, it was not felt to be that mission critical for the SME’s business. Upon the plans made to shift from the existing SaaS CSP to a new SaaS CSP the cloud services used and to be used, the SME founds out that the use of this SaaS has become quite mission critical for the survival and success of the SME.

The existing SaaS CSP as vendor, as well as the new SaaS CSP. SME as customer, with the intent to update and restructure the way the particular SaaS is used ad integrated in the organization of the SME.

Termination & Consequences of Termination

As quite common, the SME that is already using cloud services, in this case SaaS, finds out that when it wishes to change, amend or in this case terminate the respective cloud services it is bound by the standards terms and conditions of the CSP, including the SLA. To start with, the SME does not know which version of the terms and conditions it has accepted in the past (and the CSP generally does not know as well as per immature administration recording practices). Besides, most CSPs do not make or keep available the previous versions of its terms and conditions. In most cases, the CSP will refer to its recent standards terms and conditions of the CSP, applicable at the time of the request of the SME. So, regarding the first 14 of the 22+ CRM requirements, almost none are met automatically, meaning without the SME acting itself. This means that the SME has a huge disadvantage in terms of its legal position, negotiation power and has no alternative but to adhere to the terms and conditions provided by the CSP.

Secondly, and regarding all 26 CRM requirements, the SME finds out that he does not have specific, tailored options beneficial for his needs to terminate the agreement with the CSP in a way that ascertain the business continuity of that SaaS, the assistance needed to migrate process flows, data (including metadata where necessary) to another SaaS CSP environment, and adequately and cost-effectively wind-down and discontinue the SaaS provided by the former CSP.

In short, the former CSP is in full control, and the SME has a very weak bargaining position. It is a hard and expensive lesson-learned exercise for the SME, which in this use case the SME has used to the intent to improve his way of procuring cloud services and follow the CRM where important for his business and business continuity. Depending on the CSP the SME chooses, the SME may be able to succeed to some extent in these goals and approach, this as per the current immature nature of cloud SLAs and offerings of CSP. In any case, with the experience obtained and the CRM, the SME s now ready to make an informed decision what to choose.

Non-applicable, as per this use case. However, for this type of SME customary requirements has been taken into account while procuring the subsequent cloud services. No particulars to mention in this case.

Non-applicable, as per this use case. However, for this type of SME customary preconditions and requirements have been taken into account while procuring the subsequent cloud services. No particulars to mention in this case.

 

Non-applicable, as per this use case. However, for this type of SME customary best practices has been taken into account while procuring the subsequent cloud services. No particulars to mention in this case.

SMEs generally do not spend time or other resources on procuring cloud services, until they find out it is worthwhile doing so.

As explained above, SMEs generally do not spend time or other resources on procuring cloud services, until they find out it is worthwhile to do so. This hampers their development and business opportunities, which SMEs find out when it may be too late already for them to change course, but it is also their moment to improve and pay more attention to procurement in general, and procuring cloud services in specific.