31
controllers” in their own right; similarly, CSP clients are typically data
controllers. Article 32 of the GDPR requires the data controller and the
data processor “to implement appropriate technical and organisational
measures to ensure a level of security appropriate to the risk…[including]
measures to protect data from accidental or unlawful destruction, loss,
alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed”. Article 44 deals with transfers outside
the EU and only allows such data transfer subject to the GDPR. Under
the GDPR, the contract between a CSP and their client must stipulate that
the data processor will only act on the instructions from the data controller. One area of potential friction is that of security. The extent to which a
client can instruct a CSP on their security policies in a multi-tenant commoditized infrastructure is limited and CSPs have relied on adherence to
industry certifications or best practice frameworks to overcome client and
regulator concerns e.g. PCI-DSS, ISO27001, COBIT etc. At the same
time, CSPs, typically reserve the right to change their security policies
unilaterally (Leimbach et al. 2014). While such certifications are envisaged
by the GDPR under Article 42, they are not obligatory. Being ‘certified’
does not equate to GDPR compliance; it merely certifies that the aforementioned technical and organizational measures are in place. Indeed, the
issue of certification would seem to be an area still couched in ambiguity.
The European Data Protection Board only issued guidelines on GDPR
certification in June 2019 and it is unclear whether certification commonly
cited by CSPs meets these guidelines at the time of writing (EDPB 2019).
Data integrity is often referred to but poorly defined. For example,
there are ambiguities even between information and data integrity (Boritz
2005). Notwithstanding this, it is widely accepted that it is synonymous
with representational faithfulness. In contrast, data availability is the extent
to which an organisation’s full set of computational resources are accessible and usable (Jansen and Grance 2011). Extant pre-GDPR research suggests that, at least historically, CSPs attempted to place responsibility for
preserving data integrity and backup with the client (Bradshaw et al. 2011;
Hon et al. 2012). Article 32 (1) of the GDPR requires data controllers
and data processors to have the ability (1) to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; and (2) to restore the availability and access to personal data in a
timely manner in the event of a physical or technical incident. While the
GDPR applies to personal data, this does not guarantee the integrity and
availability of all data, for example non-personal business data, and only
applies to data within the definition of the GDPR. As such, care should be
2 DEAR CLOUD, I THINK WE HAVE TRUST ISSUES: CLOUD COMPUTING…
controllers” in their own right; similarly, CSP clients are typically data
controllers. Article 32 of the GDPR requires the data controller and the
data processor “to implement appropriate technical and organisational
measures to ensure a level of security appropriate to the risk…[including]
measures to protect data from accidental or unlawful destruction, loss,
alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed”. Article 44 deals with transfers outside
the EU and only allows such data transfer subject to the GDPR. Under
the GDPR, the contract between a CSP and their client must stipulate that
the data processor will only act on the instructions from the data controller. One area of potential friction is that of security. The extent to which a
client can instruct a CSP on their security policies in a multi-tenant commoditized infrastructure is limited and CSPs have relied on adherence to
industry certifications or best practice frameworks to overcome client and
regulator concerns e.g. PCI-DSS, ISO27001, COBIT etc. At the same
time, CSPs, typically reserve the right to change their security policies
unilaterally (Leimbach et al. 2014). While such certifications are envisaged
by the GDPR under Article 42, they are not obligatory. Being ‘certified’
does not equate to GDPR compliance; it merely certifies that the aforementioned technical and organizational measures are in place. Indeed, the
issue of certification would seem to be an area still couched in ambiguity.
The European Data Protection Board only issued guidelines on GDPR
certification in June 2019 and it is unclear whether certification commonly
cited by CSPs meets these guidelines at the time of writing (EDPB 2019).
Data integrity is often referred to but poorly defined. For example,
there are ambiguities even between information and data integrity (Boritz
2005). Notwithstanding this, it is widely accepted that it is synonymous
with representational faithfulness. In contrast, data availability is the extent
to which an organisation’s full set of computational resources are accessible and usable (Jansen and Grance 2011). Extant pre-GDPR research suggests that, at least historically, CSPs attempted to place responsibility for
preserving data integrity and backup with the client (Bradshaw et al. 2011;
Hon et al. 2012). Article 32 (1) of the GDPR requires data controllers
and data processors to have the ability (1) to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; and (2) to restore the availability and access to personal data in a
timely manner in the event of a physical or technical incident. While the
GDPR applies to personal data, this does not guarantee the integrity and
availability of all data, for example non-personal business data, and only
applies to data within the definition of the GDPR. As such, care should be
2 DEAR CLOUD, I THINK WE HAVE TRUST ISSUES: CLOUD COMPUTING…