Cloud Security (Domain1- 5)

CRITICAL AREAS OF
FOCUS IN CLOUD
COMPUTING
SOURCE: CLOUD SECURITY ALLIANCE
NIST Special Publication 800-145, ISO/IEC 17788 and ISO/IEC 17789
MAGANATHIN
VEERARAGALOO

DOMAIN 1 - CLOUD
COMPUTING
CONCEPTS AND
ARCHITECTURES

Defining Cloud Computing
Cloud computing is a new operational model and set of technologies for managing shared
pools of computing resources.
NIST defines cloud computing as:
• Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a
shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released with minimal management effort or service
provider interaction.
The ISO/IEC definition
• Paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual
resources with self-service provisioning and administration on-demand.
Definition: A cloud user is the person or organization requesting and using the resources,
and the cloud provider is the person or organization who delivers it. We also sometimes
use the terms client and consumer to refer to the cloud user, and service or simply cloud
to describe the provider.
NIST 500-292 uses the term “cloud actor” and adds roles for cloud brokers, carriers, and
auditors. ISO/IEC 17788 uses the terms cloud service customer, cloud service partner,
and cloud service provider.

Defining Cloud Computing
Cloud computing is a new operational model and set of technologies for managing
shared pools of computing resources.
NIST defines cloud computing as:
• Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a
shared pool of configurable computing resources (e.g., networks, servers, storage, applications,
and services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction.
The ISO/IEC definition
• Paradigm for enabling network access to a scalable and elastic pool of shareable physical or
virtual resources with self-service provisioning and administration on-demand.
Definition: A cloud user is the person or organization requesting and using the
resources, and the cloud provider is the person or organization who delivers it. We
also sometimes use the terms client and consumer to refer to the cloud user, and
service or simply cloud to describe the provider.
NIST 500-292 uses the term “cloud actor” and adds roles for cloud brokers, carriers,
and auditors. ISO/IEC 17788 uses the terms cloud service customer, cloud service
partner, and cloud service provider.

Definitional Model
The Cloud Security Alliance (CSA) uses the NIST model for cloud computing
as its standard for defining cloud computing.
The CSA also endorses the ISO/IEC model which is more in-depth, and
additionally serves as a reference model.
NIST’s publication is generally well accepted, and the Guidance aligns with
the NIST Working Definition of Cloud Computing (NIST 800-145) to bring
coherence and consensus around a common language to focus on use cases
rather than semantic nuances.

NIST defines cloud computing by describing five essential characteristics, three
cloud service models, and four cloud deployment models.

1. Essential Characteristics
These are the characteristics that make a cloud a cloud. If something has these
characteristics, we consider it cloud computing. If it lacks any of them, it is likely
not a cloud.
i. Resource Pooling is the most fundamental characteristic, as discussed above. The provider
abstracts resources and collects them into a pool, portions of which can be allocated to
different consumers (typically based on policies).
ii. Consumers provision the resources from the pool using on-demand self-service. They manage
their resources themselves, without having to talk to a human administrator.
iii. Broad Network Access means that all resources are available over a network, without any
need for direct physical access; the network is not necessarily part of the service.
iv. Rapid Elasticity allows consumers to expand or contract the resources they use from the pool
(provisioning and deprovisioning), often completely automatically. This allows them to more
closely match resource consumption with demand (for example, adding virtual servers as
demand increases, then shutting them down when demand drops).
v. Measured Service meters what is provided, to ensure that consumers only use what they are
allotted, and, if necessary, to charge them for it. This is where the term utility computing
comes from, since computing resources can now be consumed like water and electricity, with
the client only paying for what they use.

2. Service Models
a. Software as a Service (SaaS) is a full application that’s managed
and hosted by the provider. Consumers access it with a web
browser, mobile app, or a lightweight client app.
b. Platform as a Service (PaaS) abstracts and provides development
or application platforms, such as databases, application platforms
(e.g. a place to run Python, PHP, or other code), file storage and
collaboration, or even proprietary application processing (such as
machine learning, big data processing, or direct Application
Programming Interfaces (API) access to features of a full SaaS
application). The key differentiator is that, with PaaS, you don’t
manage the underlying servers, networks, or other infrastructure.
c. Infrastructure as a Service (IaaS) offers access to a resource pool
of fundamental computing infrastructure, such as compute,
network, or storage.

3. Deployment Models
Both NIST and ISO/IEC use the same four cloud deployment models. These are how the technologies
are deployed and consumed, and they apply across the entire range of service models:
a. Public Cloud. The cloud infrastructure is made available to the general public
or a large industry group and is owned by an organization selling cloud
services.
b. Private Cloud. The cloud infrastructure is operated solely for a single
organization. It may be managed by the organization or by a third party and
may be located on-premises or off- premises.
c. Community Cloud. The cloud infrastructure is shared by several
organizations and supports a specific community that has shared concerns
(e.g. mission, security requirements, policy, or compliance considerations). It
may be managed by the organizations or by a third party and may be located
on-premises or off-premises.
d. Hybrid Cloud. The cloud infrastructure is a composition of two or more clouds
(private, community, or public) that remain unique entities but are bound
together by standardized or proprietary technology that enables data and
application portability (e.g., cloud bursting for load balancing between
clouds). Hybrid is also commonly used to describe a non-cloud data centre
bridged directly to a cloud provider.

 Deployment models are defined based on the cloud user—that is, who uses the cloud. As the diagram below shows, the organization that owns and
manages the cloud will vary even within a single deployment model.
1 Management includes: governance, operations, security, compliance, etc...
2 Infrastructure implies physical infrastructure such as facilities, compute network and storage equipment
3 Infrastructure location is both physical relative to an organization’s management umbrella and speaks to ownership versus control
4 Trusted consumers of service are those who are considered part of an organization’s legal/contractual/ policy umbrella including employees, contractors, and business partners. Untrusted
consumers are those that may be authorized to consume some/all services but are not logical extensions of the organization.

Reference and Architecture Models
For an in-depth reference architectural model, we again
recommend ISO/IEC 17789 and NIST 500-292, which
complement the NIST definition model.
One way of looking at cloud computing is as a stack where
Software as a Service is built on Platform as a Service, which
is built on Infrastructure as a Service. This is not
representative of all (or even most) real-world deployments,
but serves as a useful reference to start the discussion.

Reference and
Architecture Models

1. Infrastructure as a Service
Physical facilities and infrastructure hardware form the foundation of IaaS.
With cloud computing we abstract and pool these resources, but at the most basic
level we always need physical hardware, networks, and storage to build on.
These resources are pooled using abstraction and orchestration.
Abstraction, often via virtualization, frees the resources from their physical
constraints to enable pooling.
Then a set of core connectivity and delivery tools (orchestration) ties these
abstracted resources together, creates the pools, and provides the automation to
deliver them to customers.
All this is facilitated using Application Programming Interfaces. APIs are typically
the underlying communications method for components within a cloud, some of
which (or an entirely different set) are exposed to the cloud user to manage their
resources and configurations. Most cloud APIs these days use REST
(Representational State Transfer), which runs over the HTTP protocol, making it
extremely well suited for Internet services.

In most cases, those APIs are both remotely accessible and wrapped into a
web-based user interface.
This combination is the cloud management plane, since consumers use it to
manage and configure the cloud resources, such as launching virtual
machines (instances) or configuring virtual networks.
From a security perspective, it is both the biggest difference from protecting
physical infrastructure (since you can’t rely on physical access as a control)
and the top priority when designing a cloud security program.
If an attacker gets into your management plane, they potentially have full
remote access to your entire cloud deployment.
Thus IaaS consists of a facility, hardware, an abstraction layer, an
orchestration (core connectivity and delivery) layer to tie together the
abstracted resources, and APIs to remotely manage the resources and deliver

A series of physical servers each run two components: a hypervisor (for
virtualization) and the management/orchestration software to tie in the servers and
connect them to the compute controller.
A customer asks for an instance (virtual server) of a particular size and the cloud
controller determines which server has the capacity and allocates an instance of the
requested size.
The controller then creates a virtual hard drive by requesting storage from the
storage controller, which allocates storage from the storage pool, and connects it to
the appropriate host server and instance over the network (a dedicated network for
storage traffic). Networking, including virtual network interfaces and addresses, is
also allocated and connected to the necessary virtual network.
The controller then sends a copy of the server image into the virtual machine, boots
it, and configures it; this creates an instance running in a virtual machine (VM),
with virtual networking and storage all properly configured. Once this entire process
is complete, the metadata and connectivity information is brokered by the cloud
controller and available to the consumer, who can now connect to the instance and
log in.

2. Platform as a Service
Of all the service models, PaaS is the hardest to definitively characterize due to both
the wide range of PaaS offerings and the many ways of building PaaS services.
PaaS adds an additional layer of integration with application development
frameworks, middleware capabilities, and functions such as databases, messaging,
and queuing.
These services allow developers to build applications on the platform with
programming languages and tools that are supported by the stack.
One option, frequently seen in the real world and illustrated in our model, is to build
a platform on top of IaaS.
A layer of integration and middleware is built on IaaS, then pooled together,
orchestrated, and exposed to customers using APIs as PaaS.
For example, a Database as a Service could be built by deploying modified database
management system software on instances running in IaaS.
The customer manages the database via API (and a web console) and accesses it
either through the normal database network protocols, or, again, via API.

In PaaS the cloud user only sees the platform, not the underlying
infrastructure.
In our example, the database expands (or contracts) as needed based on
utilization, without the customer having to manage individual servers,
networking, patches, etc.
Another example is an application deployment platform.
That’s a place where developers can load and run application code without
managing the underlying resources.
Services exist for running nearly any kind of application in any language on
PaaS, freeing the developers from configuring and building servers, keeping
them up to date, or worrying about complexities like clustering and load
balancing.
This simplified architecture diagram shows an application platform (PaaS)
running on top of our IaaS architecture:

3. Software as a Service
SaaS services are full, multitenant applications, with all the architectural
complexities of any large software platform.
Many SaaS providers build on top of IaaS and PaaS due to the increased
agility, resilience, and (potential) economic benefits.
Most modern cloud applications (SaaS or otherwise) use a combination of
IaaS and PaaS, sometimes across different cloud providers.
Many also tend to offer public APIs for some (or all) functionality.
They often need these to support a variety of clients, especially web browsers
and mobile applications.
Thus all SaaS tends to have an application/logic layer and data storage, with
an API on top.
Then there are one or more presentation layers, often including web
browsers, mobile applications, and public API access.

Reference and Architecture
Models
3. Software as a Service
The simplified architecture diagram below is taken from a
real SaaS platform, but generalized to remove references
to the specific products in use:

Logical Model
At a high level, both cloud and traditional computing
adhere to a logical model that helps identify different
layers based on functionality. This is useful to illustrate
the differences between the different computing models
themselves:
Infrastructure: The core components of a computing system:
compute, network, and storage. The foundation that
everything else is built on. The moving parts.
Metastructure: The protocols and mechanisms that provide
the interface between the infrastructure layer and the other
layers. The glue that ties the technologies and enables
management and configuration.
Infostructure: The data and information. Content in a
database, file storage, etc.
Applistructure: The applications deployed in the cloud and
the underlying application services used to build them. For
example, Platform as a Service features like message
queues, artificial intelligence analysis, or notification
services.

Logical Model
Different security focuses map to the different logical layers.
Application security maps to Applistructure, data security to
infostructure, and infrastructure security to infrastructure.
The key difference between cloud and traditional computing is the
Metastructure.
Cloud Metastructure includes the management plane components,
which are network-enabled and remotely accessible.
Another key difference is that, in cloud, you tend to double up on each
layer. Infrastructure, for example, includes both the infrastructure
used to create the cloud as well as the virtual infrastructure used and
managed by the cloud user.
In private cloud, the same organization might need to manage both;
in public cloud the provider manages the physical infrastructure
while the consumer manages their portion of the virtual

Logical Model
These layers tend to map to different teams, disciplines, and
technologies commonly found in IT organizations.
While the most obvious and immediate security management
differences are in Metastructure, cloud differs extensively from
traditional computing within each layer.
The scale of the differences will depend not only on the cloud
platform, but on how exactly the cloud user utilizes the
platform.
For example, a cloud-native application that makes heavy
utilization of a cloud provider’s PaaS products will experience
more applistructure differences than the migration of an

Cloud Security Scope, Responsibilities, and Models
1. Cloud Security and Compliance Scope and Responsibilities
It might sound simplistic, but cloud security and compliance includes
everything a security team is responsible for today, just in the cloud. All the
traditional security domains remain, but the nature of risks, roles and
responsibilities, and implementation of controls change, often dramatically.
Though the overall scope of security and compliance doesn’t change, the pieces
any given cloud actor is responsible for most certainly do. Think of it this way:
Cloud computing is a shared technology model where different organizations
are frequently responsible for implementing and managing different parts of
the stack. As a result security responsibilities are also distributed across the
stack, and thus across the organizations involved.
This is commonly referred to as the shared responsibility model. Think of it as a
responsibility matrix that depends on the particular cloud provider and
feature/product, the service model, and the deployment model.

 At a high level, security responsibility maps to the degree of control any given actor has over the architecture
stack:
a) Software as a Service: The cloud provider is responsible for nearly all security, since the
cloud user can only access and manage their use of the application, and can’t alter how the
application works. For example, a SaaS provider is responsible for perimeter security,
logging/ monitoring/auditing, and application security, while the consumer may only be able
to manage authorization and entitlements.
b) Platform as a Service: The cloud provider is responsible for the security of the platform,
while the consumer is responsible for everything they implement on the platform, including
how they configure any offered security features. The responsibilities are thus more evenly
split. For example, when using a Database as a Service, the provider manages fundamental
security, patching, and core configuration, while the cloud user is responsible for everything
else, including which security features of the database to use, managing accounts, or even
authentication methods.
c) Infrastructure as a Service: Just like PaaS, the provider is responsible for foundational
security, while the cloud user is responsible for everything they build on the infrastructure.
Unlike PaaS, this places far more responsibility on the client. For example, the IaaS provider
will likely monitor their perimeter for attacks, but the consumer is fully responsible for how
they define and implement their virtual network security, based on the tools available on the
service.

 These roles are further complicated when using cloud brokers or other intermediaries and partners.
 The most important security consideration is knowing exactly who is responsible for what in any given cloud
project. It’s less important if any particular cloud provider offers a specific security control, as long as you
know precisely what they do offer and how it works. You can fill the gaps with your own controls, or choose a
different provider if you can’t close the controls gap. Your ability to do this is very high for IaaS, and less so
for SaaS.

This is the essence of the security relationship between a cloud provider and
consumer.
What does the provider do?
What does the consumer need to do?
Does the cloud provider enable the consumer to do what they need to?
What is guaranteed in the contract and service level agreements, and what is
implied by the documentation and specifics of the technology?
This shared responsibility model directly correlates to two recommendations:
1. Cloud providers should clearly document their internal security
controls and customer security features so the cloud user can make an
informed decision. Providers should also properly design and
implement those controls.
2. Cloud users should, for any given cloud project, build a responsibilities
matrix to document who is implementing which controls and how. This
should also align with any necessary compliance standards.

The Cloud Security Alliance provides two tools to help meet these
requirements:
a) The Consensus Assessments Initiative Questionnaire (CAIQ). A
standard template for cloud providers to document their security and
compliance controls.
b) The Cloud Controls Matrix (CCM), which lists cloud security controls
and maps them to multiple security and compliance standards. The
CCM can also be used to document security responsibilities.
Both documents will need tuning for specific organizational and project
requirements, but provide a comprehensive starting template and can be
especially useful for ensuring compliance requirements are met.

2. Cloud Security Models
Cloud security models are tools to help guide security decisions.
The term “model” can be used a little nebulously, so for our purposes we break out the
following types:
a) Conceptual Models or Frameworks include visualizations and descriptions used to
explain cloud security concepts and principles, such as the CSA logical model in
this document.
b) Controls Models or Frameworks categorize and detail specific cloud security
controls or categories of controls, such as the CSA CCM.
c) Reference Architectures are templates for implementing cloud security, typically
generalized (e.g. an IaaS security reference architecture).
i. They can be very abstract, bordering on conceptual, or quite detailed, down to
specific controls and functions.
d) Design Patterns are reusable solutions to particular problems. In security, an
example is IaaS log management.
i. As with reference architectures, they can be more or less abstract or specific,
even down to common implementation patterns on particular cloud platforms.
The lines between these models often blur and overlap, depending on the goals of the
developer of the model. Even lumping these all together under the heading “model” is
probably inaccurate, but since we see the terms used so interchangeably across different
sources, it makes sense to group them.

The CSA has reviewed and recommends the following models:
a) The CSA Enterprise Architecture
b) The CSA Cloud Controls Matrix
c) The NIST draft Cloud Computing Security Reference
Architecture (NIST Special Publication 500-299), which
includes conceptual models, reference architectures, and a
controls framework.
d) ISO/IEC FDIS 27017 Information technology – Security
techniques – Code of practice for information security
controls based on ISO/IEC 27002 for cloud services.

1. A Simple Cloud Security Process Model
While the implementation details, necessary controls, specific
processes, and various reference architectures and design models vary
greatly depending on the specific cloud project, there is is a relatively
straightforward, high-level process for managing cloud security:
i. Identify necessary security and compliance requirements, and
any existing controls.
ii. Select your cloud provider, service, and deployment models.
iii. Define the architecture.
iv. Assess the security controls.
v. Identify control gaps.
vi. Design and implement controls to fill the gaps.
vii. Manage changes over time.

Since different cloud projects, even on a single provider, will likely
leverage entirely different sets of configurations and technologies,
each project should be evaluated on its own merits. For example, the
security controls for an application deployed on pure IaaS in one
provider may look very different than a similar project that instead
uses more PaaS from that same provider.
The key is to identify requirements, design the architecture, and then
identify the gaps based on the capabilities of the underlying cloud
platform. That’s why you need to know the cloud provider and
architecture before you start translating security requirements into
controls.

Recommendations
 Understand the differences between cloud computing and traditional
infrastructure or virtualization, and how abstraction and automation
impact security.
 Become familiar with the NIST model for cloud computing and the CSA
reference architecture.
 Use tools such as the CSA Consensus Assessments Initiative Questionnaire
(CAIQ) to evaluate and compare cloud providers.
 Cloud providers should clearly document their security controls and
features and publish them using tools like the CSA CAIQ.
 Use tools like the CSA Cloud Controls Matrix to assess and document cloud
project security and compliance requirements and controls, as well as who
is responsible for each.
 Use a cloud security process model to select providers, design architectures,
identify control gaps, and implement security and compliance controls.

DOMAIN 2 -
GOVERNANCE AND
ENTERPRISE RISK
MANAGEMENT

1. Introduction
For security professionals, cloud computing impacts four areas of governance and risk
management:
a) Governance includes the policy, process, and internal controls that comprise how an
organization is run. Everything from the structures and policies to the leadership and other
mechanisms for management.
b) Enterprise Risk Management includes managing overall risk for the organization, aligned to
the organization’s governance and risk tolerance. Enterprise risk management includes all
areas of risk, not merely those concerned with technology.
c) Information Risk Management covers managing the risk to information, including information
technology. Organizations face all sorts of risks, from financial to physical, and information is
only one of multiple assets an organization needs to manage.
d) Information Security is the tools and practices to manage risk to information. Information
security isn’t the be-all and end-all of managing information risks; policies, contracts,
insurance, and other mechanisms also play a role (including physical security for non-digital
information). However, a - if not the - primary role of information security is to provide the
processes and controls to protect electronic information and the systems we use to access it.

1. Introduction
In a simplified hierarchy, information security is a tool of information risk management, which is
a tool of enterprise risk management, which is a tool of governance. The four are all closely related
but require individual focus, processes, and tools.

2. Overview
a) Governance
Cloud computing affects governance, since it either introduces a third party into the process (in
the case of public cloud or hosted private cloud) or potentially alters internal governance
structures in the case of self-hosted private cloud. The primary issue to remember when
governing cloud computing is that an organization can never outsource responsibility for
governance, even when using external providers. This is always true, cloud or not, but is useful
to keep in mind when navigating cloud computing’s concepts of shared responsibility models.
Cloud service providers try to leverage economies of scale to manage costs and enable
capabilities. This means creating extremely standardized services (including contracts and
service level agreements) that are consistent across all customers. Governance models can’t
necessarily treat cloud providers the same way they’d treat dedicated external service
providers, which typically customize their offerings, including legal agreements, for each client.
Cloud computing changes the responsibilities and mechanisms for implementing and managing
governance. Responsibilities and mechanisms for governance are defined in the contract, as
with any business relationship. If the area of concern isn’t in the contract, there are no
mechanisms available to enforce, and there is a governance gap. Governance gaps don’t
necessarily exclude using the provider, but they do require the customer to adjust their own
processes to close the gaps or accept the associated risks.

2. Overview
a) Governance
i. Tools of Cloud Governance
As with any other area, there are specific management tools used for governance. This list focuses more
on tools for external providers, but these same tools can often be used internally for private
deployments:
1) Contracts: The primary tool of governance is the contract between a cloud provider and a cloud
customer (this is true for public and private cloud). The contract is your only guarantee of any level
of service or commitment—assuming there is no breach of contract, which tosses everything into a
legal scenario. Contracts are the primary tool to extend governance into business partners and
providers.

2. Overview
a) Governance
As with any other area, there are specific management tools used for governance. This list focuses more
on tools for external providers, but these same tools can often be used internally for private
deployments:
2) Supplier (cloud provider) Assessments: These assessments are performed by the potential cloud
customer using available information and allowed processes/techniques. They combine contractual
and manual research with third-party attestations (legal statements often used
to communicate the results of an assessment or audit) and technical research. They are very similar
to any supplier assessment and can include aspects like financial viability, history, feature
offerings, third-party attestations, feedback from peers, and so on. More detail on assessments is
covered later in this Domain and in Domain 4.
3) Compliance reporting: Compliance reporting includes all the documentation on a provider’s internal
(i.e. self) and external compliance assessments. They are the reports from audits
of controls, which an organization can perform themselves, a customer can perform on a provider
(although this usually isn’t an option in cloud), or have performed by a trusted third party. Third-
party audits and assessments are preferred since they provide independent validation (assuming
you trust the third party).

2. Overview
a) Governance
Assessments and audits should be based on existing standards (of which there are many).
It’s critical to understand the scope, not just the standard used.
Standards like the SSAE 16 have a defined scope, which includes both what is assessed (e.g.
which of the provider’s services) as well as which controls are assessed.
A provider can thus “pass” an audit that doesn’t include any security controls, which isn’t
overly useful for security and risk managers.
Also consider the transitive trust required to treat a third-party assessment as equivalent to
the activities that you might undertake when doing your own assessment.
Not all audit firms (or auditors) are created equal and the experience, history, and
qualifications of the firm should be included in your governance decisions.
The Cloud Security Alliance STAR Registry is an assurance program and documentation
registry for cloud provider assessments based on the CSA Cloud Controls Matrix and
Consensus Assessments Initiative Questionnaire.
Some providers also disclose documentation for additional certifications and assessments
(including self-assessments).

2. Overview
b) Enterprise Risk Management
Enterprise Risk Management (ERM) is the overall management of risk for an organization.
As with governance, the contract defines the roles and responsibilities for risk management
between a cloud provider and a cloud customer. And, as with governance, you can never
outsource your overall responsibility and accountability for risk management to an external
provider.
Risk management in cloud is based on the shared responsibilities model.
The cloud provider accepts some responsibility for certain risks, and the cloud customer is
responsible for anything beyond that.
This is especially evident as you evaluate differences between the service models, where the
provider manages more risks in SaaS and the consumer more in IaaS. But, again, the cloud
user is ultimately responsible for ownership of the risks; they only pass on some of the risk
management to the cloud provider. This holds true even with a self-hosted private cloud;
in those situations an organizational unit is passing on some of their risk management to the
internal cloud provider instead of an external party, and internal SLAs and procedures
replace external contracts.

2. Overview
b) Enterprise Risk Management
 ERM relies on good contracts and documentation to know where the division of responsibilities and potential
for untreated risk lie.
 Whereas governance is nearly exclusively focused on contracts, risk management can delve deeper into the
technology and process capabilities of the provider, based on their documentation.
 For example, a contract will rarely define how network security is actually implemented.
 Review of the provider’s documentation will provide much more information to help with an effective risk
decision.
 Risk tolerance is the amount of risk that the leadership and stakeholders of an organization are willing to
accept.
 It varies based on asset and you shouldn’t make a blanket risk decision about a particular provider;
 rather, assessments should align with the value and requirements of the assets involved.
 Just because a public cloud provider is external and a consumer might be concerned with shared
infrastructure for some assets doesn’t mean it isn’t within risk tolerance for all assets.
 Over time this means that, practically speaking, you will build out a matrix of cloud services along with
which types of assets are allowed in those services.
 Moving to the cloud doesn’t change your risk tolerance, it just changes how risk is managed.

2. Overview
c) The Effects of Service Model and Deployment Model
 In considering the various options available not only in Cloud Service Providers but also in the fundamental
delivery of cloud services, attention must be paid to how the Service and Deployment models affect the ability
to manage governance and risk.
1. Service Models
i. Software as a Service
 In the majority of cases, SaaS presents the most critical example of the need for a negotiated
contract.
 Such a contract will protect the ability to govern or validate risk as it relates to data stored,
processed, and transmitted with and in the application.
 SaaS providers tend to cluster at either end of the size/capability spectrum
and the likelihood of a negotiated contract is much higher when dealing with a small SaaS
provider.
 Unfortunately, many small SaaS providers are not able to operate at a level of sophistication that
meets or exceeds customer governance and risk management capabilities. In concrete terms, the
entire level of visibility into the actual operation of the infrastructure providing the SaaS
application is limited to solely what is exposed in the user interface developed by the Cloud

2. Overview
 In considering the various options available not only in Cloud Service Providers but also in the fundamental delivery of cloud
services, attention must be paid to how the Service and Deployment models affect the ability to manage governance and risk.
1. Service Models
ii. Platform as a Service
 Continuing through the Service Models, the level of detail that is available (and the consequential
ability to self-manage governance and risk issues) increases.
 The likelihood of a fully negotiated contract is likely lower here than with either of the other
service models.
 That’s because the core driver for most PaaS is to deliver a single capability with very high
efficiency.
 PaaS is typically delivered with a rich API, and many PaaS providers have enabled the collection
of some of the data necessary to prove that SLAs are being adhered to.
 That said, the customer is still in the position of having to exercise a significant effort in
determining whether contract stipulations are effectively providing the level of control or support
required to enable governance or risk management.

2. Overview
1. Service Models
iii. Infrastructure as a Service
 Infrastructure as a Service represents the closest that Cloud comes to a traditional data centre (or
even a traditional outsourced managed data centre), and the good news is that the vast majority
of existing governance and risk management activities that organizations have already built and
utilize are directly transferable.
 There are, however, new complexities related to the underlying orchestration and management
layers, as described in Domain 1, that enable the infrastructure which are often overlooked.
 In many ways, the governance and risk management of that orchestration and management layer
is consistent with the underlying infrastructure (network, power, HVAC, etc.) of a traditional data
centre.
 The same governance and risk management issues are present, but the exposure of those systems
is sufficiently different that changes to the existing process are required. For example, controlling
who can make network configuration changes shifts from accounts on individual devices to the
cloud management plane.

2. Overview
i. Public
 Cloud customers have a reduced ability to govern operations in a public cloud since the
provider is responsible for the management and governance of their infrastructure,
employees, and everything else. The customers also often have reduced ability to
negotiate contracts, which impacts how they extend their governance model into the
cloud.
 Inflexible contracts are a natural property of multitenancy:
 Providers can’t necessarily adjust contracts and operations for each customer as
everything runs on one set of resources, using one set of processes.
 Adapting for different customers increases costs, causing a trade-off, and often that’s the
dividing line between using public and private cloud. Hosted private cloud allows full
customization, but at increased costs due to the loss of the economies of scale.

2. Overview
 In considering the various options available not only in Cloud Service Providers but also in the fundamental
delivery of cloud services, attention must be paid to how the Service and Deployment models affect the ability
to manage governance and risk.
i. Public
 This doesn’t mean you shouldn’t try to negotiate your contract, but recognize
that this isn’t always possible; instead, you’ll need to either choose a different
provider (which may actually be less secure), or adjust your needs and use
alternate governance mechanisms to mitigate concerns.
 To use an analogy, think of a shipping service.
 When you use a common carrier/provider you don’t get to define their
operations. You put your sensitive documents in a package and entrust them to
meet their obligations to deliver it safely, securely, and within the expected
Service Level Agreement.

2. Overview
 In considering the various options available not only in Cloud Service Providers but also in the fundamental delivery of cloud services, attention must be
paid to how the Service and Deployment models affect the ability to manage governance and risk.
ii. Private
 Public cloud isn’t the only model that impacts governance; even private cloud will have an effect. If an
organization allows a third party to own and/or manage the private cloud (which is very common), this is
similar to how governance affects any outsourced provider. There will be shared responsibilities with
obligations that are defined in the contract.
 Although you will likely have more control over contractual terms, it’s still important to ensure they cover the
needed governance mechanisms. As opposed to a public provider—which has various incentives to keep its
service well-documented and at particular standard levels of performance, functionality, and
competitiveness—a hosted private cloud may only offer exactly what is in
 the contract, with everything else at extra cost. This must be considered and accounted for in negotiations,
with clauses to guarantee that the platform itself remains up to date and competitive. For example, by
requiring the vendor to update to the latest version of the private cloud platform within a certain time period
of release and after your sign-off.
 With a self-hosted private cloud governance will focus on internal service level agreements for the cloud users
(business or other organizational units) and chargeback and billing models for providing access to the cloud.

2. Overview
ii. Hybrid & Community
 When contemplating hybrid cloud environments, the governance strategy must
consider the minimum common set of controls comprised of the Cloud Service
Provider’s contract and the organization’s internal governance agreements.
 The cloud user is connecting either two cloud environments or a cloud
environment and a data centre.
 In either case the overall governance is the intersection of those two models.
 For example, if you connect your data centre to your cloud over a dedicated
network link you need to account for governance issues that will span both
environments.

2. Overview
ii. Hybrid & Community
 Since community clouds are a shared platform with multiple organizations, but
are not public, governance extends to the relationships with those members of
the community, not just the provider and the customer.
 It’s a mix of how you would approach public cloud and hosted private cloud
governance, where the overall tools of governance and contracts will have some
of the economies of scale of a public cloud provider, but be tuneable based on
community consensus, as with a hosted private cloud.
 This also includes community membership relations, financial relationships,
and how to respond when a member leaves the community.

2. Overview
2. Cloud Risk Management Trade-Offs
 There are advantages and disadvantages to managing enterprise risk for cloud deployments.
These factors are, as you would expect, more pronounced for public cloud and hosted private
cloud:
1. There is less physical control over assets and their controls and processes. You don’t
physically control the infrastructure or the provider’s internal processes.
2. There is a greater reliance on contracts, audits, and assessments, as you lack day-to-day
visibility or management.
3. This creates an increased requirement for proactive management of relationship and
adherence to contracts, which extends beyond the initial contract signing and audits. Cloud
providers also constantly evolve their products and services to remain competitive and these
ongoing innovations might exceed, strain, or not be covered by existing agreements and
assessments.
4. Cloud customers have a reduced need (and associated reduction in costs) to manage risks
that the cloud provider accepts under the shared responsibility model. You haven’t
outsourced accountability for managing the risk, but you can certainly outsource the
management of some risks.

2. Overview
2. Cloud Risk Management Tools
The following processes help form the foundation of managing risk in cloud computing
deployments.
One of the core tenants of risk management is that you can manage, transfer, accept, or
avoid risks. But everything starts with a proper assessment.
The supplier assessment sets the groundwork for the cloud risk management program:
1. Request or acquire documentation.
2. Review their security program and documentation.
3. Review any legal, regulatory, contractual, and jurisdictional requirements for both the
provider and yourself. (See the Domain 3: Legal for more.)
4. Evaluate the contracted service in the context of your information assets.
5. Separately evaluate the overall provider, such as finances/stability, reputation, and
outsourcers.

2. Overview

2. Overview
Periodically review audits and assessments to ensure they are up to date:
i. Don’t assume all services from a particular provider meet the same audit/assessment
standards. They can vary.
ii. Periodic assessments should be scheduled and automated if possible.
iii. After reviewing and understanding what risks the cloud provider manages, what remains is
residual risk.
iv. Residual risk may often be managed by controls that you implement (e.g. encryption). The
availability and specific implementation of risk controls vary greatly across cloud providers,
particular
v. services/features, service models, and deployment models. If, after all your assessments and the
controls that you implement yourself there is still residual risk your only options are to transfer
it, accept the risk, or avoid it.
vi. Risk transfer, most often enabled by insurance, is an imperfect mechanism, especially for
information risks. It can compensate some of the financial loss associated with a primary loss
event, but won’t help with a secondary loss event (like loss of customers)—especially an
intangible or difficult to quantify loss, such as reputation damage. From the perspective of
insurance carriers, cyber-insurance is also a nascent field without the depth of actuarial tables
used for other forms of insurance, like those for fire or flooding, and even the financial
compensation may not match the costs associated with the primary loss event. Understand the
limits.

3. Recommendations
Identify the shared responsibilities of security and risk management based on the chosen cloud
deployment and service model. Develop a Cloud Governance Framework/Model as per relevant
industry best practices, global standards, and regulations like CSA CCM, COBIT 5, NIST RMF,
ISO/IEC 27017, HIPAA, PCI DSS, EU GDPR, etc.
Understand how a contract affects your governance framework/model.
• Obtain and review contracts (and any referenced documents) before entering into an agreement.
• Don’t assume that you can effectively negotiate contracts with a cloud provider—but this
• also shouldn’t necessarily stop you from using that provider.
• If a contract can’t be effectively negotiated and you perceive an unacceptable risk,
• consider alternate mechanisms to manage that risk (e.g. monitoring or encryption).
Develop a process for cloud provider assessments.
 This should include:
• Contract review.
• Self-reported compliance review.
• Documentation and policies.
• Available audits and assessments.
• Service reviews adapting to the customer’s requirements.
• Strong change-management policies to monitor changes in the organization’s use of
• the cloud services.

3. Recommendations
Cloud providers should offer easy access to documentation and
reports needed by cloud prospects for assessments.
 For example, the CSA STAR registry.
Align risk requirements to the specific assets involved and the risk
tolerance for those assets.
Create a specific risk management and risk acceptance/mitigation
methodology to assess the risks of every solution in the space
Use controls to manage residual risks.
• If residual risks remain, choose to accept or avoid the risks.
Use tooling to track approved providers based on asset type (e.g.
linked to data classification), cloud usage, and management.

DOMAIN 3 - LEGAL
ISSUES, CONTRACTS
AND ELECTRONIC
DISCOVERY

1. Introduction
Our overview here cannot address every potential legal situation.
To address your specific issues, you should consult with legal counsel in the jurisdiction(s) in
which you intend to operate and/or in which your customers reside. In addition, be aware that
laws and regulations change frequently, and thus you should verify the relevancy of information
contained in this domain before relying on it.
Domain3 is concerned primarily with the legal implications of public cloud computing and third
party- hosted private clouds.
Although this domain includes some aspects of data governance and audit/ compliance, those
topics are covered in more depth in domains 4 and 5.
Specific areas covered in this domain include the following:
a) Legal issues
b) Cloud service agreements (contracts)
c) Third-party access to electronic documents stored in the cloud

2. Overview
a) Legal Frameworks Governing Data Protection and Privacy.
Throughout the world, many countries have adopted legal frameworks requiring public and
private organizations to safeguard the privacy of personal data and the security of information
and computer systems.
Most of these laws are based in part on the fair information privacy principles developed in the
late 1960s and 1970s and later clarified and expanded in the Privacy and Security Guidelines of
the Organization for Economic Cooperation and Development (OECD).
Under these laws, the data controller (typically the entity that has the primary relationship with
an individual) is prohibited from collecting and processing personal data unless certain criteria
are met.
For example, if the data subject has consented to the collection and proposed uses of his or her
data, then the controller may collect and process data, according to the consent agreement.
These laws define numerous obligations, such as confidentiality and security obligations, for the
entities that access personal data.
When entrusting a third party to process data on its behalf (a data processor), a data controller
remains responsible for the collection and processing of that data.
The data controller is required to ensure that any such third parties take adequate technical and
organizational security measures to safeguard the data.

2. Overview
Despite a common theme, countries on all continents have developed data protection
regimes that occasionally conflict with each other.
As a result, cloud providers and cloud users operating in multiple regions struggle to
meet compliance requirements.
In many cases, the laws of different countries might apply concurrently, in accordance
with the following:
1. The location of the cloud provider
2. The location of the cloud user
3. The location of the data subject
4. The location of the servers
5. The legal jurisdiction of the contract between parties, which may be different than the
locations of any of the parties involved
6. Any treaties or other legal frameworks between those various locations

2. Overview
Applicable legal requirements will
vary tremendously based on the
various jurisdictions and legal
entities and frameworks involved.

2. Overview
b) Common Themes.
Many countries have adopted national or omnibus laws (applying to all categories of
personal data) or sectoral laws (applying to specified categories of data) that are intended
to protect the privacy of individuals.
1. Required Security Measures
These laws frequently contain provisions requiring the adoption of security measures,
acknowledging that ensuring the security of personal data is essential to ensuring the
protection of individual privacy.
Concurrently, companies may also be expected to adopt reasonable technical, physical, and
administrative measures in order to protect a wide range of data, including personal data,
financial data, trade secrets, and other sensitive company data from loss, misuse or alteration.

2. Overview
b) Common Themes.
Many countries have adopted national or omnibus laws (applying to all categories of personal data) or
sectoral laws (applying to specified categories of data) that are intended to protect the privacy of
individuals.
2. Restrictions to Cross-border Data Transfers
Many countries prohibit or restrict the transfer of information out of their borders.
In most cases, the transfer is permitted only if the country to which the data is transferred offers an
“adequate level of protection” (as defined in the relevant national law) of personal information and privacy
rights of affected individuals.
The purpose of this adequacy requirement is to ensure the individuals whose data is transferred across
borders will remain as protected as they were via policies afforded to them before the transfer of data.
Alternatively, the data importer and exporter may need to sign a contract ensuring the maintenance of
privacy rights for data subjects.
Depending on the country, the requirements for ensuring this adequate protection may be complex and
stringent.
In some cases, it may be necessary to obtain prior permission of the local Data Protection Commissioner
before transferring data in or out of the country.
In addition, some countries are beginning to require that certain data be stored within their territory.
This is the case, for example, with the new data localization laws of Russia and China, which require that
specified personal data pertaining to individuals residing in their countries be stored within the country’s
borders.

2. Overview
b) Common Themes.
Many countries have adopted national or omnibus laws (applying to all categories of personal
data) or sectoral laws (applying to specified categories of data) that are intended to protect the
privacy of individuals.
3. Regional Examples
i. ASIA PACIFIC REGION
a) Australia
In Australia, two key laws provide protection to consumers of cloud services:
1. the Privacy Act of 1988 (Privacy Act) and the Australian Consumer Law (ACL).
2. The Privacy Act includes 13 Australian Privacy Principles (APPs), which apply to
all private sector and not-for-profit organizations with an annual turnover of more
than AUD 3 million, all private health service providers, and some small
businesses.

2. Overview
b) Common Themes.
individuals.
b) China
1. Its 2017 Cyber Security Law governs the operations of network operators and critical
information infrastructure operators. In May 2017, proposed Measures on the Security
of Cross-Border Transfers of Personal Information and Important Data were published
by the Chinese government and are currently being evaluated for potential
implementation.
2. The 2017 Cyber Security Law requires network operators to comply with a series of
security requirements, including the design and adoption of information security
measures; the formulation of cyber security emergency response plans; and assistance
and support necessary to investigative authorities, where necessary, for protecting
national security and investigating crimes.

2. Overview
b) Common Themes.
 Many countries have adopted national or omnibus laws (applying to all categories of personal data) or sectoral laws
(applying to specified categories of data) that are intended to protect the privacy of individuals.
b) Japan
1. In Japan, the Act on the Protection of Personal Information (APPI) requires the private sector
to protect personal information and data securely. There are several other national laws, such
as the Law on the Protection of Personal Information Held by Administrative Organs and laws
pertaining to specific sectors, such as the healthcare industry. Profession-specific laws, such as
the Medical Practitioners’ Act; the Act on Public Health Nurses, Midwives and Nurses; and the
Pharmacist Act, require registered health professionals to maintain the confidentiality of
patient information.
2. Beginning in September 2017, amendments to the APPI law will limit the ability to
transfer personal data to third parties, with prior consent of the data subject generally
being required to transfer data to a third party. Consent to the transfer is not required if
the country of destination has an established framework for the protection of personal
information that meets the standard specified by the Personal Information Protection
Commission.

2. Overview
b) Common Themes.
Many countries have adopted national or omnibus laws (applying to all categories of personal
data) or sectoral laws (applying to specified categories of data) that are intended to protect the
privacy of individuals.
b) Russia
1. The Russian data protection laws contain significant restrictions on data
processing, including a requirement for consent for most forms of data
processing. However, the most important aspect of the Russian legal
framework regarding the handling of personal information is its data
localization law. Since September 2015, companies are required to store
personal data of Russian citizens within Russia. Roskomnadzor, the Russian
Data Protection regulator, has commenced enforcement of the law and has
already blocked access to one foreign social network, which did not have a
physical presence in Russia, but operated a Russian language version of its
website.

2. Overview
b) Common Themes.
individuals.
ii. EUROPEAN UNION AND EUROPEAN ECONOMIC AREA
1. The European Union (EU) adopted the General Data Protection Regulation (GDPR) in
2016, which is binding on all EU member states, as well as members of the European
Economic Area (EEA). The GDPR will become enforceable as of May 25, 2018. On that
date, Directive 95/46/EC on the Protection of Personal Data, which had been the legal
basis of the provisions of the national data protection laws of all EU and EEA member
states, will be repealed.
2. From a security standpoint, the Network Information Security Directive (NIS
Directive) is paving the way to more stringent security requirements. Adopted in 2016,
the NIS Directive requires EU/EEA member states to implement new information
security laws for the protection of critical infrastructure and essential services by May
2018. Cloud service providers and some cloud users are likely to be affected by the
national laws that will implement the overarching NIS Directive.

2. Overview
b) Common Themes.
Many countries have adopted national or omnibus laws (applying to all categories of
personal data) or sectoral laws (applying to specified categories of data) that are intended
to protect the privacy of individuals.
ii. EUROPEAN UNION AND EUROPEAN ECONOMIC
AREA
1. General Data Protection Regulation (GDPR)
The new GDPR is directly binding on any corporation that processes
the data of EU citizens, and will be adjudicated by the data supervisory
authorities or the courts of the member states that have the closest
relationship with the individuals or the entities on both sides of the

2. Overview
b) Common Themes.
a) Applicability:
 The GDPR applies to the processing of personal data in the context of the activities
of an establishment of a controller or processor in the EU/EEA, regardless of
whether the processing takes place in the EU/EEA or not.
 It also applies to the processing of personal data of data subjects who are in the
EU/EEA by a controller or a processor not established in the EU/EEA if the
processing relates to
 (a) the offering of goods or services irrespective of whether a payment by the
data subject is required; or
 (b) the monitoring of the behaviour of a data subject, when the behaviour takes
place within the EU/EEA.

2. Overview
b) Common Themes.
AREA
b) Lawfulness:
The processing of personal data is allowed only if
(a) the data subject has freely given specific, informed and
unambiguous indication of his/her consent to the processing of
his/her personal data, or
(b) the processing is authorized by a statutory provision.

2. Overview
b) Common Themes.
AREA
c) Accountability Obligations
The GDPR has created numerous obligations for companies. For
example, the GDPR requires companies to keep records of their data
processing activities. Certain categories of processing require a prior
“Privacy Impact Assessment.” Companies are expected to develop
and operate their products and services in accordance with “privacy

2. Overview
b) Common Themes.
AREA
d) Data Subjects’ Rights
Data subjects have rights to information regarding the processing of
their data: the right to object to certain uses of their personal data; to
have their data corrected or erased; to be compensated for damages
suffered as a result of unlawful processing; the right to be forgotten;
and the right to data portability. The existence of these rights

2. Overview
b) Common Themes.
e) Cross-border Data Transfer Restrictions
 The transfer of personal data outside the EU/EEA to a country that does not offer a
similar range of protection of personal data and privacy rights is prohibited.
To prove that it will be offering the “adequate level of protection” required, a
company may use one of several methods, such as executing Standard Contractual
Clauses (SCC), signing up to the EU-US Privacy Shield, obtaining certification of
Binding Corporate Rules (BCRs), or complying with an approved industry Code of
Conduct or approved certification mechanism. In rare cases, the transfer might be
effected with the explicit, informed, consent of the data subject, or if other
exceptions apply.

2. Overview
b) Common Themes.
f) Breaches of Security
 The GDPR requires companies to report that they have suffered a breach
of security.
 The reporting requirements are risk-based, and there are different
requirements for reporting the breach to the Supervisory Authority and to
the affected data subjects.
 Breaches must be reported within 72 hours of the company becoming aware
of the incident.

2. Overview
b) Common Themes.
AREA
g) Discrepancies among Member States
There are numerous instances where each member state may adopt
its own rules.
For example, Germany requires that a Data Protection Officer be
appointed if the company has more than nine employees.

2. Overview
b) Common Themes.
AREA
h) Sanctions
Violations of the GDPR expose a company to significant sanctions.
These sanctions may reach up to the greater of four percent of their
global turnover or gross income, or up to EUR 20 million.

2. Overview
b) Common Themes.
2. Network Information Security Directive (NIS Directive)
 The NIS Directive entered into force in August 2016, requiring each
EU/EEA member state to implement the Directive into its national
legislation by May 2018.
 The NIS Directive establishes a framework to enable networks and
information systems to resist, at a given level of confidence, actions that
compromise the availability, authenticity, integrity, or confidentiality of
stored, transmitted, or processed data, or the related services that are
offered by or accessible through those networks and information systems.

2. Overview
b) Common Themes.
 The NIS Directive requires that member state’s national laws impose
network and information security requirements on operators of essential
services, i.e., entities that provide a service essential for the maintenance of
critical societal and/or economic activities;
 and where an incident to the network and information systems of that
service would have significant disruptive effects on the provision of that
service.
 The requirements to be implemented into national laws include the
following:

2. Overview
b) Common Themes.
 The requirements to be implemented into national laws include the following:
a) Taking technical and organizational measures to manage risks posed to the security of
networks and information systems used in their operations;
b) Taking appropriate measures to prevent and minimize the impact of incidents affecting the
security of the networks and information systems used for the provision of such essential
services, to facilitate the continuation of those services;
c) Notifying, without undue delay, the competent authorities or agencies of incidents
having a significant impact on the continuity of the essential services they provide;
d) Providing information necessary to assess the security of their networks and
information systems
e) Providing evidence of the effective implementation of security policies, such as the
results of a security audit.

2. Overview
b) Common Themes.
 The NIS Directive also requires that member state’s national laws impose network and information
security requirements on digital service providers, such as online market places (e.g., e-commerce
platforms), cloud computing services; and online search engines. Digital service providers based outside
the EU that provide services within the EU fall under the scope of the NIS Directive.
 Member state’s national laws will also have to require digital service providers to identify and take
appropriate and proportionate technical and organizational measures to manage risks posed to the
security of network and information systems they use, such as incident handling, business continuity
management, monitoring, auditing and testing, and compliance with international standards.
 Member State’s national laws will have to require digital service providers to take measures to prevent
and minimize the impact of incidents. They will be required to notify the competent authorities or
agencies, without undue delay, of any incident having a substantial impact on the provision of a service,
including sufficient information to enable the competent authority or agency to determine the
significance of any cross-border impact. Where an operator of essential services relies on a third party
digital service provider for a service that is essential, the operator will be required to notify any
significant impact on the continuity of the essential services due to an incident affecting the digital
service provider.

2. Overview
b) Common Themes.
iii. THE AMERICAS
1. Central and South America
 Central and South American countries also are adopting data protection laws at a
rapid pace.
 Each of these laws includes a security requirement and places on the data
custodian the burden of ensuring the protection and security of personal data
wherever the data are located, and especially when transferring to a third party.
 For example, Argentina, Chile, Colombia, Mexico, Peru and Uruguay have passed
data protection laws inspired mainly by the European directive 95/46/EC, and may
include references to the APEC Privacy Framework.
 The federal data protection law of Mexico includes security breach disclosure
provisions.

2. Overview
b) Common Themes.
iii. THE AMERICAS
2. North America: United States
 Due to its sectoral approach, the United States has hundreds of federal, state and local
regulations, from the details of a written information security plan to the rules for disclosing
security breaches.
 As a result, organizations that do business in the United States or collect or process personal
or other information of individuals or companies located in the United States are often
subject to several federal, state or local privacy or information security laws.
 The variety and complexity of these rules might be daunting both for providers or users of
cloud services and for the service providers and subcontractors who participate in the
provision of these services.

2. Overview
b) Common Themes.
iii. THE AMERICAS
a. U.S. Federal Laws
 Numerous federal laws and their related regulations—such as the Gramm-Leach-Bliley Act (GLBA), the
Health Insurance Portability and Accountability Act of 1996 (HIPAA), and the Children’s Online Privacy
Protection Act of 1998 (COPPA)—contain provisions that pertain to the privacy and the security of
personal information.
 Security-related provisions require companies to adopt reasonable security measures when processing
personal data.
 Most of these laws require companies to take precautions when hiring subcontractors and service
providers. They may also hold organizations responsible for the acts of their subcontractors.
 For example, the security and privacy rules under GLBA and HIPAA require that covered organizations
compel their subcontractors, in written contracts, to use reasonable security measures and comply with
data privacy provisions.

2. Overview
b) Common Themes.
iii. THE AMERICAS
a. U.S. State Laws
 In addition to federal laws and regulations, most U.S. states have laws relating to data privacy and/ or data security.
 These laws apply to any entity that collects or processes personal information (as narrowly defined in the applicable
law) of individuals who reside in that state, regardless of where in the United States the data is stored.
 Some state laws are elaborate. See, for example, the extensive requirements under Massachusetts’ “Standards for the
Protection of Personal Information of Residents of the Commonwealth,” or 201 CMR 17.00. Other state laws are more
general (see Washington State law RCW 19.255.020(2)(b) that assigns liability on the basis of compliance) and a small
number of state laws reference other specific standards (such as the Payment Card Industry Data Security Standard,
PCI-DSS, mentioned above). Most state laws that address information security issues require that the company have a
written contract with the service provider with reasonable security measures. Numerous state laws also require
companies to provide adequate privacy protections and security for personal data, and require their service providers
to do the same.

2. Overview
b) Common Themes.
iii. THE AMERICAS
a. U.S. State Laws
i. Security Breach Disclosure Laws
 Numerous federal security laws or rules, such as those applying to healthcare providers, as well as
most state laws, require entities that have suffered a breach of security that compromised specified
categories of data, such as PHI (patient health information), to promptly notify affected individuals,
and in many cases, state or federal agencies, of the occurrence of the breach of security.
 Knowledge and understanding of these laws is critical for both cloud customers and cloud
vendors, because breaches of security often trigger significant cost, including for example, the
cost of responding to class action suits. Recent breaches of security have been reported to affect
hundreds of millions of individuals, and the resulting legal costs and damages to be paid out by
affected companies have also been significant.

2. Overview
b) Common Themes.
iii. THE AMERICAS
a. U.S. State Laws
ii. Federal and State Agencies
 In addition to specific laws and regulations, cloud providers and users should be aware of the “common law of
privacy and security,” the nickname given to the body of consent orders that have been published by federal and
state government agencies at the conclusion of their investigations into security incidents and events.
 For almost 20 years, U.S. government agencies, such as the Federal Trade Commission (FTC) and the State
Attorneys General have used their power under Federal or state “unfair and deceptive practices” acts to conduct
enforcement actions against companies whose privacy or security practices are inconsistent with claims made in
their public disclosures, making their practices unfair or deceptive.
 The numerous consent decrees issued by the FTC in enforcement cases under Section 5 of the FTC Act: Unfair or
Deceptive Acts or Practices— or by state attorneys general in similar cases under their states’ unfair and deceptive
practices act— at the conclusion of many of these security investigations provide important guidance on the views
and objectives of the Federal or State agencies regarding the collection, use and protection of personal information.

2. Overview
c) Contracts and Provider Selection
If the privacy notice allows individual data subjects to have access to their personal data, and to
have this information modified or deleted, the cloud service provider must also allow these access,
modification, and deletion rights to be exercised to the same extent as it would in a non-cloud
relationship.
When data or operations are transferred to a cloud, the responsibility for protecting and securing the
data typically remains with the collector or custodian of that data, even if in some circumstances this
responsibility may be shared with others.
Even when it relies on a third party to host or process its data, the custodian of the data remains
liable for any loss, damage, or misuse of the data.
It is therefore prudent, and may be required by law or regulation, that the data custodian and the
cloud provider enter into a formal written agreement that clearly defines the roles, the expectations
of the parties, and the allocation of the many responsibilities that are attached to the data at stake.
Such an agreement should also clearly identify the permitted and prohibited uses of the data, and
the measures to be taken if the data were stolen or compromised.
The laws, regulations, standards and the related best practices discussed above also require data
custodians to ensure that these obligations will be fulfilled by conducting due diligence (before
execution of the contract) or security audits (during performance of the contract).

2. Overview
i. Internal Due Diligence
Companies are the custodians of data entrusted to them.
As seen above, numerous laws, regulations and contracts prohibit, restrict and limit
disclosure and transfer of data to a third party.
For example, health information protected under HIPAA cannot be transferred to a third
party or “business associate” without imposing specific obligations on that associate.
In addition, if data originates abroad, it is likely that there are significant obstacles to its
transfer across borders into a country that does not provide “adequate protection” to privacy
rights and personal data.
Before entering into a cloud computing arrangement, both the cloud service vendor and the
cloud customer should evaluate respective practices, needs and restrictions to identify
relevant legal barriers and compliance requirements.
For example, a cloud customer should determine whether its business model allows for the
use of cloud computing services, and under which conditions.
The nature of its business might be such that it is restricted by law from relinquishing
control of company data.
A cloud vendor may find it prudent to evaluate in advance the cost of doing business in
certain markets that might be subject to legal requirements with which the vendor is
unfamiliar.

2. Overview
i. Internal Due Diligence
A cloud customer should investigate whether it has entered into any confidentiality
agreements or data use agreements that might restrict the transfer of data to third parties,
even if these third parties are service providers.
If the company, or potential cloud customer, has signed a confidentiality agreement to protect
personal information or trade secrets, this agreement probably prohibits hiring a
subcontractor without prior permission of the data owner.
A data use agreement to which the company is a party may require the consent of a customer
if the company plans to subcontract the processing of the customer’s data to a third party.
That restriction would in most cases apply to transfers to a cloud service provider.
Under these circumstances, moving data to a cloud without the prior permission of the
customer (data owner) would cause a breach in the data use agreement with that customer.
In other circumstances, the data processed by the company might be so sensitive or
confidential that it should not be transferred to a cloud service, or the transfer might require
significant precautions.
This might be the case, for example, for files that pertain to high stakes projects such as R&D
(Research & Development) road maps, or plans for an upcoming IPO (Initial Public Offering),
merger, or acquisition.

2. Overview
ii. Monitoring, Testing, and Updating
The cloud environment is not static.
It evolves and involved parties must adapt.
Periodic monitoring, testing, and evaluation of cloud services are recommended in
order to insure required privacy and security measures are followed.
Without periodic testing of cloud services, control efficacy may be compromised in an
undetected fashion.
In addition, the legal, regulatory, and technical landscape in which any company
operates changes at a rapid pace.
New security threats, new laws, and new compliance requirements must be
addressed promptly.
Both cloud clients and cloud providers must keep abreast of relevant legal,
regulatory, contractual, and other requirements, and ensure that both their
operations remain compliant with applicable laws and regulations, and that the
security measures in place continue to evolve as new technologies emerge.

2. Overview
iii. External Due Diligence
In most cases, the cloud customer will want to evaluate at least the applicable service level, end-
user and legal agreements; privacy policies; security disclosures; and proof of compliance with
applicable legal requirements (e.g., registration requirements) to ensure the conditions stated by
the cloud provider are suitable for the customer’s organization.
Depending on the expected depth and intensity of the due diligence, issues to be investigated may
include the following:
1. Will the service be reliable and easy to use?
2. How will the servers be used to process data?
3. How will the service operate and be provided?
4. Will data be collocated with other customers’ data?
5. How will data be protected from intrusion or disasters?
6. How will the price evolve over time?
7. Will the cloud vendor meet the company’s computing and access needs?
8. Will the cloud vendor remain in business for the next few years? What is its financial profile?
9. What service levels will be offered?

2. Overview
iii. External Due Diligence
Depending on the expected depth and intensity of the due diligence, issues
to be investigated may include the following:
10. What security measures are used?
11. What will happen in the event of a security breach?
Reviewing all terms and conditions of the cloud services agreement
(including all annexes, schedules and appendices) is good due diligence for
any new project. It is especially critical for cloud computing, as some
vendor terms and conditions will be non-negotiable.
In those instances, the customer needs to make an informed decision to
use or not use a provider.

2. Overview
iv. Contract Negotiations
Cloud contracts are intended to accurately describe the understanding of all
parties.
Numerous precautions and measures can be taken by the parties to reduce
exposure to legal, commercial and reputational risk in connection with the use of
cloud services.
The proposed contract should always be reviewed carefully, even if one is told
that it is not negotiable.
For one thing, it might actually be possible to negotiate changes.
Even if it is not possible to do so, each purchaser of cloud services should
understand the consequences and implications of the engagement it is making.
A contract that cannot be negotiated is likely to lack some of the protections that
the typical customer would need. In this case, the customer should weigh the
risks from foregoing these protections against potential benefits.

2. Overview
iv. Reliance on Third-Party Audits and Attestations
Audits and compliance are covered in more detail in Domain 4, but two
considerations may affect contractual and legal/regulatory requirements.
In cloud computing, third-party audits and attestations are frequently used to
assure compliance with aspects of the cloud provider’s infrastructure, allowing a
customer to build their own compliant services on top of the cloud platform.
It is critical for a provider to publish, and a customer to evaluate, the scope of the
assessment, and which features and services are included in the assessment.
For example, a cloud provider’s newest storage offering may not be HIPAA-
compliant (and thus the provider may not be willing to sign a HIPAA Business
Associate Agreement (BAA) covering it), even though many of its other service
offerings are able to be used in a HIPAA-compliant fashion.

2. Overview
d) Electronic Discovery
U.S. rules around “discovery” - the process by which an opposing party obtains private documents for
use in litigation - cover a wide range of potential documents.
In particular, discovery need not be limited to documents known at the outset to be admissible as
evidence in court; instead, discovery will apply to all documents reasonably calculated to lead to
admissible evidence (evidence that is both relevant and probative). See Rule 26, Federal Rules of Civil
Procedure (FRCP).
In recent years, many litigants have deleted, lost or modified evidence that was detrimental to their
case. In these cases, the Federal Rules of Civil Procedure allow, among other penalties, money to be
awarded to the side not responsible for the destruction; in some cases, the jury may be given
an instruction on an “adverse inference” (where a jury is instructed to assume that the destroyed
evidence contains the worst possible information for the party that destroyed it). See Rule 37, FRCP. As
a result of the ongoing litigation in this area, the FRCP have been changed to clarify the obligations of
the parties, especially in the case of electronically stored information (ESI).
Since the cloud will become the repository of most ESI needed in litigation or an investigation, cloud
service providers and their clients must carefully plan how they will be able to identify all documents
that pertain to a case, in order to be able to fulfil the stringent requirements imposed by FRCP 26 with
regard to ESI, and the state equivalents to these laws.
In this regard, the cloud service client and provider need to consider the following issues in matters
when a client is subject to a discovery request and potentially relevant data exists with the cloud
provider.

2. Overview
i. Possession, Custody and Control
In most jurisdictions in the United States, a party’s obligation to produce relevant
information is limited to documents and data within its possession, custody or control.
Hosting relevant data via a third party, such as a cloud provider, generally does not
obviate a party’s obligation to produce information.
However, not all data hosted by a cloud provider may be in the control of a client (e.g.,
disaster recovery systems, or certain metadata created and maintained by the cloud
provider to operate its environment).
Distinguishing the data that is and is not available to the client may be in the interest of
both the client and provider at the outset of a relationship.
The obligations of the cloud service provider as cloud data handler with regard to the
production of information in response to legal process is an issue left to each jurisdiction
to resolve.

2. Overview
ii. Relevant Cloud Applications and Environment
On occasion, an actual cloud application or environment could itself be relevant to resolving a dispute.
In these circumstances, the application and environment will likely be outside the control of the client
and require that a subpoena or other discovery process be served on the provider directly.
iii. Searchability and E-Discovery Tools
In a cloud environment, a client may not be able to apply or use e-discovery tools that it uses in its own
environment.
Moreover, a client may not have the ability or administrative rights to search or access all the data
hosted in the cloud.
For example, where a client could access multiple employees’ e-mail accounts on its own server at once,
it may not have this ability with e-mail accounts hosted in the cloud. As such, clients need to account for
the potential additional time and expense this limited access will cause.
To the extent the customer is able to negotiate or supplement the cloud service agreement, this issue
could be addressed ahead of time.
Otherwise, the cloud customer may have no option other than to address issues on a case-by-case basis;
and might therefore have to pay for additional services from the cloud provider.

2. Overview
iv. Preservation
Depending on the cloud service and deployment model that a client is using, preservation in the
cloud can be similar to preservation in other IT infrastructures, or it can be significantly more
complex.
In the United States, a party is generally obligated to undertake reasonable steps to prevent
the destruction or modification of data in its possession, custody or control that it knows, or
reasonably should know, is relevant either to pending or reasonably anticipated litigation or a
government investigation.
(This is often referred to as a “litigation hold” on document destruction.)
These concerns are addressed broadly by Federal Rule of Civil Procedure 37, though there are
myriad jurisdictional rulings that apply to potential litigants.
In the European Union, information preservation is governed under Directive 2006/24/EC of the
European Parliament and of the Council of 15 March 2006. Japan, South Korea and Singapore
have similar data protection initiatives.
In South America, Brazil and Argentina have the Azeredo Bill and the Argentina Data Retention
Law of 2004, Law No. 25.873, respectively.

2. Overview
v. Data Retention Laws and Record Keeping Obligations
In addition to data preservation obligations resulting from U.S. laws regarding e-discovery,
companies need to be aware that data retention laws require covered entities to retain data for a
certain period of time.
a. Costs and Storage:
Preservation can require that large volumes of data be retained for extended periods.
Customers should consider these questions and determine the risk tolerated before moving to
the cloud:
1. What are the ramifications of retaining data under the service level agreement (SLA)?
2. What happens if the preservation requirements outlast the terms of the SLA?
3. If the client preserves the data in place, who pays for the extended storage, and at what
cost?
4. Does the client have the storage capacity under its SLA?
5. Can the client effectively download the data in a forensically sound manner so it can be
preserved off-line or near-line?

2. Overview
b. Scope of Preservation:
A requesting party is entitled only to data hosted in the cloud that contains, or is reasonably
calculated to lead to, relevant, probative information for the legal issue at hand.
The party is not entitled to all the data in the cloud or in the application. (The issue of precise
limits is likely to be resolved in litigation.)
However, if the client does not have the ability to preserve only the relevant information or data
in a granular way, it may be required to over-preserve in order to secure reasonable
preservation, depending on the investigation.
The over-preserved information is then examined for a determination of what must and must
not be turned over as part of the discovery process.
This process, referred to as a document review or privilege review, may be undertaken by client
paid attorney staff or, in some cases, by emerging expert systems.
How to sort the ever-more-voluminous quantities of information that may be produced by
discovery is an ongoing area of both legal and technical research.

2. Overview
c. Dynamic and Shared Storage:
The burden of preserving data in the cloud may be relatively modest if the
client has space to hold it in place, if the data is relatively static, and if the
people with access are limited and know to preserve the data.
However, in a cloud environment that programmatically modifies or purges
data, or one where the data is shared with people unaware of the need to
preserve, preservation can be more difficult.
After a client determines that such data is relevant and needs to be preserved,
the client may need to work with the provider to determine a reasonable way
to preserve such data.

2. Overview
vi. Collection
Because of the potential lack of administrative control a client has over
its data in the cloud, collection from the cloud can be more difficult, more
time-consuming and more expensive than from behind a client’s firewall.
In particular, a client may not have the same level of visibility across its
cloud data, and it may have more difficulty comparing the data it has
collected with the data in the cloud to determine that export was
reasonably complete and accurate.

2. Overview
vi. Collection
i. Access and Bandwidth
In most cases, a client’s access to its data in the cloud will be determined
by its SLA.
This may limit its ability to collect large volumes of data quickly and in a forensically sound
manner (i.e., with all reasonably relevant metadata preserved).
Clients and cloud providers should consider this issue at the outset of their relationship, and
establish a protocol (and cost) for extraordinary access in the case of litigation.
Absent these agreements, clients are responsible for the extra time and cost implicated by
collection in the cloud when making representations to requesting parties and courts.
Note that FRCP 26(b)(2)(B) excuses a litigant who is able to show that the information
requested is not reasonably accessible.
However, a court may nonetheless order discovery from such sources if the requesting party is
able to show why this information is needed and may not be obtained otherwise.

2. Overview
vi. Collection
i. Access and Bandwidth
In a related issue, a client’s right of access may provide them access to a full
range of data, but not provide them the degree of functionality that would best
assist them in a given situation.
For example, a client may have access to three years of retail transactional
data, but may only be able to download data two weeks at a time because of
functionality constraints.
Moreover, a client may not only have view of limited metadata. It is prudent
for a client to learn what is possible with the tools available before it becomes
necessary to use them as a part of active litigation.

2. Overview
vi. Collection
ii. Forensics
Bit-by-bit imaging of a cloud data source is generally difficult or impossible.
For obvious security reasons, providers are reluctant to allow access to their hardware,
particularly in a multitenant environment where a client could gain access to other
clients’ data.
Even in a private cloud, forensics may be extremely difficult, and clients may need to
notify opposing counsel or the courts of these limitations.
Luckily, this type of forensic analysis is rarely warranted in cloud computing, because
the environment often consists of a structured data hierarchy or virtualization that
does not provide significant additional relevant information in a bit-by-bit analysis.

2. Overview
vi. Collection
iii. Reasonable Integrity:
A client subject to a discovery request should undertake reasonable
steps to validate that its collection from its cloud provider is complete
and accurate, especially where ordinary business procedures for the
request are unavailable and litigation-specific measures are being used
to obtain the information.
This process is separate from verifying that the data stored in the cloud
is accurate, authenticated or admissible.

2. Overview
vi. Collection
iv. Limits to Accessibility:
Due to differences in how data is stored, and the access rights and
privileges available to the owner of the data, there are cases where a
cloud customer may not be able to access all their data stored in a cloud.
The cloud customer and cloud provider may have to analyse the request
for information and the pertinent data structures for relevance,
materiality, proportionality, or accessibility, when responding to a
discovery request.

Cloud Security (Domain1- 5)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cloud Security (Domain1- 5)

Similar to Cloud Security (Domain1- 5) (20)

More from Maganathin Veeraragaloo

More from Maganathin Veeraragaloo (20)

Recently uploaded

Recently uploaded (20)

Cloud Security (Domain1- 5)