CHAPTER 5: PRIVACY AND REGULATORY CONCERNS
Alongside security, compliance with legislative and regulatory requirements ranks as one of the most commonly cited concerns by those considering a move to Cloud computing.
This chapter provides a brief overview of the data privacy concerns impacting adoption of Cloud services, primarily those imposed by the EU through the GDPR. There is also a brief discussion of mechanisms to achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS) when operating in the Cloud.
This chapter is not intended to provide comprehensive advice on the legality or compliance status of any particular Cloud solution – organisations should always consult their own legal counsel prior to storing or processing personal data, or other regulated data, using a Cloud service.
Data protection issues
The area of privacy and data protection is commonly viewed as a major concern by those considering a move to Cloud computing. Where there is a requirement to keep personal data within specific geographical borders, it's not unreasonable to be concerned when that data seems to disappear into a globally diverse Cloud. Similarly, if you are worried about certain unfriendly governments gaining access to your data, then again you will be concerned that your data may find its way into their jurisdictions once it is within 'the Cloud'. This section considers the implications of the EU GDPR.55 Whilst the GDPR is a regulation, and so directly applicable across all member states without transcription into national law, the regulation does contain a set of derogations whereby member states have scope to make their own provisions, e.g. in the processing of special categories of data. I am not a lawyer, and organisations should consult their own legal advisors before placing personal data into the Cloud. Once it is gone, it is gone.
I will start with a quick overview of the jurisdiction of the GDPR as there are some important scoping issues worthy of discussion. The protections offered by the GDPR apply to "natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data".56 The scope is also extraterritorial, as outlined in the following extracts57:
Any processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union should be carried out in accordance with this Regulation, regardless of whether the processing itself takes place within the Union[.]
[P]rocessing of personal data of data subjects who are in the Union by a controller or a processor not established in the Union should be subject to this Regulation where the processing activities are related to offering goods or services to such data subjects[.]
The processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union should also be subject to this Regulation when it is related to the monitoring of the behaviour of such data subjects in so far as their behaviour takes place within the Union[.]
There is an exemption in the scope of the Regulation that is relevant to consumer Cloud computing: the 'household' exemption. This excludes data processing carried out by individuals in the course of purely personal or household activity. This exemption is clearly defined in the following passage58:
This Regulation does not apply to the processing of personal data by a natural person in the course of a purely personal or household activity and thus with no connection to a professional or commercial activity. Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. However, this Regulation applies to controllers or processors which provide the means for processing personal data for such personal or household activities[.]
In other words, those using Facebook to manage groups, such as family groups, are exempt from the Regulation; however, Facebook themselves are not.
As a starting point, we need to define some common terms used in data protection discussions, the definitions below are taken from Article 4 of the GDPR:
Controller:
“the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law”.
Processor:
“a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”.
Personal Data:
“any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.
In most circumstances, a Cloud consumer storing or processing the personal data of their staff or customers in a Cloud solution would be the data controller. The Cloud provider would typically be viewed as a data processor. However, this may not always be the case. The EU Data Protection Supervisor has argued in the past that, dependent upon the level of control of processing offered, Cloud providers could also be acting as data controllers. This is particularly applicable to SaaS providers who more or less dictate how their customers can process personal data through the services that they offer. This interpretation is yet to be tested in the courts.
For now, we will work with the assumption that Cloud providers are data processors and Cloud consumers are data controllers.
Cloud consumers are, therefore, obligated to protect the personal data that they wish to store or process in the Cloud in line with their relevant data protection legislation. The GDPR has seven key principles:
1.Lawfulness, fairness and transparency
2.Purpose limitation
3.Data minimisation
4.Accuracy
5.Storage limitation
6.Integrity and confidentiality (security)
7.Accountability
The GDPR describes these principles in the following way59:
(a) processed lawfully, fairly and in a transparent manner in relation to individuals (‘lawfulness, fairness and transparency’);
(b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall not be considered to be incompatible with the initial purposes (‘purpose limitation’);
(c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);
(d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);
(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes subject to implementation of the appropriate technical and organisational measures required by the GDPR in order to safeguard the rights and freedoms of individuals (‘storage limitation’);
(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
The accountability principle is defined in Article 5(2), which states,
The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).
In contrast with the previous iteration of data protection law in the European Union, there is no specific principle relating to the transfer of personal data outside of the European Economic Area. This does not mean that the GDPR does not concern itself with such transfers, rather that there is now an entire Chapter (Chapter V) dedicated to transfers of personal data to third countries or international organisations.
I am only going to discuss those elements of the GDPR that are directly impacted by a move to Cloud computing services, i.e. Principle (f) (on data security) and Chapter V (on the international transfers of data). Other elements of the regulation are no less important but they should already have been considered by any existing processing of personal data. Principle (f) compels data controllers to implement good practice with regard to the security of the personal data that they hold. Cloud consumers should ensure that they consider this legal obligation when they are conducting their due diligence activities in relation to their choice of Cloud provider. Cloud consumers should be able to convince themselves (and others) that their chosen Cloud providers have sufficient security controls in place to satisfy the good practice requirements of Principle (f).
The most obviously relevant articles of the GDPR to Cloud computing are those contained with Chapter V. The GDPR forbids the transfer of personal data to countries that do not provide a similar level of legislative protection to personal data to that of the EU unless some form of compensating arrangement is in place. Personal data can be transferred freely within the European Economic Area (EEA) and also to a number of countries that the EU has approved as having adequate60 data protection controls – this list currently consists of Andorra, Argentina, Canada, Faroe Islands, Guernsey, Isle of Man, Israel, Japan, Jersey, New Zealand, Switzerland, Uruguay and the US (limited to the Privacy Shield framework). EU-based Cloud consumers sending data to other countries must implement one of the approved routes for international data transfer before storing or processing data within Clouds hosted outside of the EEA.
There are a number of available options for enabling the international transfer of data outside of the EEA including:
•The use of Binding Corporate Rules (BCRs);
•The use of model, standard contract clauses provided by the EU61; and
•An in-house assessment of adequacy.
Organisations wishing to use US-based Cloud providers could also consider making use of a Cloud provider that has signed up to the provisions of the Privacy Shield framework agreed between the US Department of Commerce and the European Commission. The Privacy Shield framework acts as a mechanism for those organisations signing up to the framework to achieve adequacy from a GDPR perspective. There is a sister agreement between the US and Switzerland that provides a similar route towards adequacy. However, organisations looking to make use of the Privacy Shield framework should remember that certain industries (e.g. financial services) are excluded from the provisions of Privacy Shield. Privacy Shield is enforced by the US Federal Trade Commission (FTC) and the Department of Transportation (DOT). The financial services sector and law firms are not within the jurisdiction of either the FTC or the DOT and, consequently, they cannot take advantage of the Privacy Shield agreement. US organisations signing up to the Privacy Shield self-certify that they adhere to the framework’s requirements and they must also publicly commit to abiding by those requirements. Signing up to the framework is optional; however, once an organisation has signed up to the framework, and made their public commitment, that commitment becomes enforceable under US law.
EU or EEA organisations wishing to use the Privacy Shield framework should also remember that the US Patriot Act and the CLOUD Act trump the requirements of the framework; consequently, if those organisations view US government access as undesirable, they should not rely upon the Privacy Shield to provide reliable protection.
Payment card industry issues
Another common compliance requirement often raised in the Cloud context relates to the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS62 aims to set a minimum baseline of security controls (documented as 12 high level requirements and significantly more low level requirements) necessary to adequately secure payment card account data within an organisation. This standard is subject to regular updates as deemed suitable by the PCI DSS Council.
Each payment card issuer (e.g. Visa, MasterCard and American Express) defines different tiers of merchants, usually categorised by the numbers of payment card transactions performed per year. Each merchant level is subject to different specific audit and reporting requirements. Level 1 tends to be the top tier across the issuers, and so Level 1 merchants face the most stringent audit and reporting requirements. Merchants processing more than 6 million payment card transactions annually are categorised as Level 1 by Visa and MasterCard.63 American Express set the bar significantly lower at 2.5 million transactions per year, whilst JCB is even lower at 1 million. American Express64 also only have 3 levels of merchants compared to the 4 levels of Visa and MasterCard. Some of the PCI DSS requirements that can cause issues in Cloud deployments include requirements for regular vulnerability assessments and an ability to conduct a physical audit of the hosting environment. Penalties for breach of compliance can include substantial fines (e.g. $500,000 per incident) through to possible removal of a non-compliant merchant's ability to process cards issued by the affected card issuer(s).
A number of Cloud service providers now claim compliance with PCI DSS65; accordingly, consumers using such services can have some confidence that those providers will operate in line with the relevant requirements. However, consumers must ensure that they have complete knowledge of the scope of the provider's compliance so that a cohesive and demonstrably compliant consumer solution can be implemented. The PCI Security Standards Council have published a useful supporting guide discussing Cloud aspects of PCI compliance over at:
www.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf.
Organisations could also explore alternative options to the storage of payment card information such as the use of third-party payment providers. This can remove most of the PCI DSS burden from the organisation itself as it never actually has sight of the data in-scope for PCI DSS.
This book does not set out to develop a generic solution that evidences compliance with PCI DSS. Rather I'll be showing how security architecture methodologies can be used to result in production of an architecture that takes account of requirements sourced from PCI DSS.
Financial services and the Cloud
A wide range of organisations look to the financial services sector for guidance on what is and what is not reasonable from a security perspective. The rationale for this is that if a service is secure enough for banking it must be good enough for most other sectors. This may be a reasonable assumption for those sectors that do not have particularly strict regulatory requirements. Within the UK, a number of financial services organisations are now enthusiastically adopting Cloud services, whilst the main regulator, the Financial Conduct Authority, is itself a major user of Cloud-based solutions. The FCA issued its guidance on the usage of Cloud computing in 201666 and this encouraged a wider take-up of Cloud services across the sector. UK financial institutions adopting such services must also consider the wider requirements of the FCA Handbook, particularly the SYSC867 controls on material outsourcing. The European Banking Authority (the EBA) released its own draft Cloud recommendations in 2016, with the final draft of those recommendations68 coming into effect on 1 July 2018 – from a UK perspective, this deprecated the FG16/5 guidance previously issued by the FCA for those firms within the EBA’s scope.
The FCA and EBA recommendations are broadly similar and are, in general, pragmatic in terms of recognising the wider shift towards the usage of Cloud services. However, there are areas of the guidance that are unclear and potentially problematic. One long-standing area of concern surrounds the issue of right to access and audit, for both the institutions themselves and their supervisory authorities. It is still uncertain whether the EBA expects Cloud consumers to require providers to contractually guarantee access to data centres in the event of an incident. The practicality of acting on such a right is unclear given the distributed nature of Cloud services, and it is also unlikely that Cloud consumers would wish to see representatives of other Cloud provider clients having access to the underlying physical hardware. Some major Cloud providers do offer their financial services clients additional contract terms and conditions, with a view to addressing the requirements of the relevant regulators. We are still awaiting a firm precedent with respect to the scope of the access rights requirements.
Another area of potential concern in the EBA recommendations relates to the contingency planning and exit strategy requirements. For example, recommendation 27 states:
An outsourcing institution should also ensure that it is able to exit cloud outsourcing arrangements, if necessary, without undue disruption to its provision of services or adverse effects on its compliance with the regulatory regime and without detriment to the continuity and quality of its provision of services to clients. To achieve this, an outsourcing institution should:
(a) develop and implement exit plans that are comprehensive, documented and sufficiently tested where appropriate;
(b) identify alternative solutions and develop transition plans to enable it to remove and transfer existing activities and data from the cloud service provider to these solutions in a controlled and sufficiently tested manner, taking into account data location issues and maintenance of business continuity during the transition phase;
(c) ensure that the outsourcing agreement includes an obligation on the cloud service provider to sufficiently support the outsourcing institution in the orderly transfer of the activity to another service provider or to the direct management of the outsourcing institution in the event of the termination of the outsourcing agreement.
Given the difficulties associated with Cloud portability we have already discussed, meeting these requirements for sufficiently tested cross-provider contingency solutions can prove to be expensive if full replication is required. This is an area in which financial services firms currently seem to be taking a more pragmatic interpretation of ‘sufficiently tested’.
However, Cloud is, overall, an increasingly popular option in the financial services sector, with many of the challenger banks being Cloud-native, and some of the better known asset management firms being enthusiastic adopters of the SaaS-First model.
Others
This chapter has briefly touched upon the Cloud-relevant issues relating to data privacy, PCI DSS and financial services regulation. This is not an exhaustive set of regulatory or legislative compliance requirements. I believe that the subject of regulation would be worthy of a series of books in its own right. For example, see the Bloor Report available for download at:
www.bloorresearch.com/research/eu-compliance-and-regulations-it-pro/.
This report discusses 33 different sources of regulatory and compliance requirements relevant to IT delivery, which only encompass those which were relevant to the EU in 2010. The situation has certainly not become any simpler in the years since this report was issued.
Government organisations must also be aware of any specific compliance requirements that have been devised by their specific home governments. The US government, for example, have set up the FedRAMP69 initiative for Cloud providers looking to service the US administration, whilst the UK National Cyber Security Centre (NCSC) has published a set of Cloud Security Principles, which Cloud consumers within the UK public sector must seek to deliver.70
The best advice is to consult with your legal counsel and compliance colleagues to ensure that all relevant sources of requirements have been considered and adequately implemented (in line with your organisational appetite for risk) prior to launching new services.
55 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016R0679.
56 Ibid.
57 Ibid.
58 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016R0679.
59 https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/.
60 https://ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en.
61 https://ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en.
62 www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf.
63 www.visaeurope.com/receiving-payments/security/merchants; www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html.
64 www.americanexpress.com/uk/merchant/support/data-security/information.html.
65 For example, AWS: https://aws.amazon.com/compliance/pci-dss-level-1-faqs/; Azure: www.microsoft.com/en-us/trustcenter/compliance/pci; GCP: https://cloud.google.com/security/compliance/pci-dss/.
66 www.fca.org.uk/publication/finalised-guidance/fg16-5.pdf.
67 www.handbook.fca.org.uk/handbook/SYSC/8/1.html.
68 https://eba.europa.eu/documents/10180/2170121/Final+draft+Recommendations+on+Cloud+Outsourcing+%28EBA-Rec-2017-03%29.pdf.
70 www.ncsc.gov.uk/guidance/implementing-cloud-security-principles.