The Organization for Economic Cooperation and Development

The Organization for Economic Cooperation and Development (OECD) guidelines lay out privacy and security guidelines. (See www.oecd.org/sti/ieconomy/privacy-guidelines.htm.) The OECD guidelines are echoed in European privacy law in many instances. The basic principles of privacy in the OECD include the following:

• Collection limitation principle: There should be limits on the collection of personal data as well as consent from the data subject.
• Data quality principle: Personal data should be accurate, complete, and kept up-to-date.
• Purpose specification principle: The purpose of data collection should be specified, and data use should be limited to these stated purposes.
• Use limitation principle: Data should not be used or disclosed without the consent of the data subject or by the authority of law.
• Security safeguards principle: Personal data must be protected by reasonable security safeguards against unauthorized access, destruction, use, or disclosure.
• Openness principle: Policies and practices about personal data should be freely disclosed, including the identity of data controllers.
• Individual participation principle: Individuals have the right to know if data is collected on them, access any personal data that might be collected, and obtain or destroy personal data if desired.
• Accountability principle: A data controller should be accountable for compliance with all measures and principles.

In addition to the basic principles of privacy, there are two overarching themes reflected in the OECD: first, a focus on using risk management to approach privacy protection, and second, the concept that privacy has a global dimension that must be addressed by international cooperation and interoperability. The OECD council adopted guidelines in September 2015, which provide guidance in the following:

• National privacy strategies: Privacy requires a national strategy coordinated at the highest levels of government. CCSPs should be aware of the common elements of national privacy strategies based on the OECD suggestions and work to help their organizations design privacy programs that can be used across multiple jurisdictions. Additionally, a CCSP should be prepared to help their organization design a privacy strategy using business requirements that deliver a good cost-benefit outcome.
• Data security breach notification: Both the relevant authorities and the affected individual(s) must be notified of a data breach. CCSPs should be aware that multiple authorities may be involved in notifications and that the obligation to notify authorities and individuals rests with the data controller.
• Privacy management programs: These are operational mechanisms to implement privacy protection. A CCSP should be familiar with the programs defined in the OECD guidelines.

Asia Pacific Economic Cooperation Privacy Framework

The Asia Pacific Economic Cooperation Privacy Framework (APEC) is an intergovernmental forum consisting of 21 member economies in the Pacific Rim. (See www.aicpa.org/content/dam/aicpa/interestareas/informationtechnology/resources/privacy/downloadabledocuments/10252-346-records-management-pro.pdf.) The goal of this framework is to promote a consistency of approach to information privacy protection. This framework is based on nine principles.

• Preventing harm: An individual has a legitimate expectation of privacy, and information protection should be designed to prevent the misuse of personal information.
• Collection limitation: Collection of personal data should be limited to the intended purposes of collection and should be obtained by lawful and fair means with notice and consent of the individual. As an example, an organization running a marketing operation should not collect Social Security or national identity numbers, as they are not required for sending marketing materials.
• Notice: Information controllers should provide clear and obvious statements about the personal data that they are collecting and the policies around use of the data. This notice should be provided at the time of collection. You are undoubtedly familiar with the banners and pop-ups in use at many websites to notify users of what data is being collected.
• Use of personal information: Personal information collected should be used only to fulfill the purposes of collection and other compatible or related purposes except: a) with the consent of the individual whose personal information is collected; b) when necessary to provide a service or product requested by the individual; or, c) by the authority of law and other legal instruments, proclamations, and pronouncements of legal effect.
• Integrity of personal information: Personal information should be accurate, complete, and kept up-to-date to the extent necessary for the purposes of use.
• Choice and consent: Where appropriate, individuals should be provided with clear, prominent, easily understandable, accessible, and affordable mechanisms to exercise choice in relation to the collection, use, and disclosure of their personal information.
• Security safeguards: Personal information controllers should protect personal information that they hold with appropriate safeguards against risks, such as loss or unauthorized access to personal information or unauthorized destruction, use, modification, or disclosure of information or other misuses.
• Access and correction: Individuals should be able to obtain from the personal information controller confirmation of whether the personal information controller holds personal information about them, and have access to information held about them, challenge the accuracy of information relating to them, and have the information rectified, completed, amended, or deleted.
• Accountability: A personal information controller should be accountable for complying with measures. Companies must identify who is responsible for complying with these privacy principles.

General Data Protect Regulation

The General Data Protect Regulation (GDPR) is perhaps the most far-reaching and comprehensive set of laws ever written to protect data privacy. (See gdpr.eu/what-is-gdpr .) In the EU, the GDPR mandates privacy for individuals, defines companies' duties to protect personal data, and prescribes punishments for companies violating these laws. GDRP fines for violating personal privacy can be massive at 20 million Euros or 4 percent of global revenue (whichever is greater). For this reason alone, a CCSP should be familiar with these laws and the effects that they have on any company operating within, housing data in, or doing business with citizens of these countries in the 27-nation bloc. GDPR became the law of the land in May 2018, and incorporated many of the same principles of the former EU Data Protection Directive.

GDPR identifies formally the role of the data subject, controller, and processor. The data subject is defined as an “identified or identifiable natural person,” or, more simply, a person. The GDPR draws a distinction between a data controller and a data processor to formally recognize that not all organizations involved in the use and processing of personal data have the same degree of responsibility.

• A data controller under GDPR determines the purposes and means of processing personal data.
• A data processor is the body responsible for processing the data on behalf of the controller.

In cloud environments, this is often separate companies, where a company may be providing services (the data controller) on a cloud provider (the data processor).

The GDPR is a massive set of regulations that covers almost 90 pages of details and is a daunting challenge to many organizations. A CCSP should be familiar with the broad areas of the law, but ultimately organizations should consult an attorney to ensure that operations are compliant. GDRP encompasses the following main areas:

• Data protection principles: If a company processes data, it must do so according to seven protection and accountability principles.
  • Lawfulness, fairness, and transparency: Processing must be lawful, fair, and transparent to the data subject.
  • Purpose limitation: The organization must process data for the legitimate purposes specified explicitly to the data subject when it was collected.
  • Data minimization: The organization should collect and process only as much data as absolutely necessary for the purposes specified.
  • Accuracy: The organization must keep personal data accurate and up-to-date.
  • Storage limitation: The organization may store personally identifying data for only as long as necessary for the specified purpose.
  • Integrity and confidentiality: Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (for example, by using encryption).
  • Accountability: The data controller is responsible for being able to demonstrate GDPR compliance with all of these principles.
• Data security: Companies are required to handle data securely by implementing appropriate technical measures and to consider data protection as part of any new product or activity.
• Data processing: GDPR limits when it is legal to actually process user data. There are very specific instances when this is allowed under the law.
• Consent: Strict rules are in place for how a user is to be notified that data is being collected.
• Personal privacy: The GDPR implements a litany of privacy rights for data subjects, which gives individuals far greater rights over their data that companies collect. This includes rights to be informed, access, rectify, restrict, obtain, and the much touted “right to be forgotten,” which allows the end user to request deletion of all personal data.

Additional Legal Controls

The cloud service provider has also significantly complicated the legal landscape when it comes to legal controls. The provider of the infrastructure, platform, or software as a service must be evaluated as an additional party when considering compliance. If a cloud provider is responsible for a violation of a legal control, the company can still be responsible for the legal ramifications. This applies to legal and contractual controls such as the following:

• Heath Insurance Portability and Accountability Act (HIPAA): This 1996 U.S. law regulates the privacy and control of health information data.
• Payment Card Industry Data Security Standard (PCI DSS): The current standard version 3.2 affects companies that accept, process, or receive electronic payments.
• Privacy Shield: This provides a voluntary privacy compliance framework through which companies can comply with portions of the GPDR in order to facilitate the movement of EU citizens' data into the United States by companies based in the United States. Note that this agreement is facing legal challenges in the EU.
• Sarbanes–Oxley Act (SOX): This law was enacted in 2002 and sets requirements for U.S. public companies to protect financial data when stored and used. It is intended to protect shareholders of the company as well as the general public from accounting errors or fraud within enterprises. This act specifically applies to publicly traded companies and is enforced by the Securities and Exchange Commission (SEC). It is applicable to cloud practitioners in particular because it specifies what records must be stored and for how long, internal control reports, and formal data security policies.
• Gramm–Leach–Bliley Act (GBLA): U.S. federal law that requires financial institutions to explain how they share and protect their customers' private information.

Laws and Regulations

The cloud represents a dynamic and changing environment, and monitoring/reviewing legal requirements is essential to staying compliant. All contractual obligations and acceptance of requirements by contractors, partners, legal teams, and third parties should be subject to periodic review. When it comes to compliance, words have real meaning. You (and Microsoft Word's thesaurus) might think that the terms law and regulation are interchangeable, but when it comes to data privacy issues, they can have starkly different outcomes if they are not satisfied. Understanding the type of compliance that your company is subject to is vital to a CCSP. The outcome of noncompliance can vary greatly, including imprisonment, fines, litigation, loss of a contract, or a combination of these. To understand this landscape, a CCSP must first recognize the difference between data protected by legal regulations and data protected by contract.

• Statutory requirements are required by law.
  • U.S. federal laws, such as HIPAA, GLBA, and SOX outlined in the previous section
  • Additional federal laws such as the Family Education Rights and Privacy Act (FERPA), which deals with privacy rights for students, and the Federal Information Security Management Act (FISMA), which protects federal data privacy
  • State data privacy laws, which now exist in all 50 states as well as U.S. territories
  • International laws, which we will discuss in a later section covering country-specific laws
• Regulatory requirements may also be required by law, but refer to rules issued by a regulatory body that is appointed by a government entity.
  • In the United States, many regulatory examples exist, mostly dealing with contractor compliance to do business with the government. An example would be security requirements outlined by NIST that are necessary to handle government data (such as NIST 800-171).
  • At the state level, several states use regulatory bodies to implement their cybersecurity requirements. One example is the New York State Department of Financial Services (NY DFS) cybersecurity framework for the financial industry (23 NYCRR 500).
  • There are numerous international requirements dealing with cloud legal requirements (including APEC and GDPR).
• Contractual requirements are required by a legal contract between private parties. These are not laws, and breaching these requirements cannot result in imprisonment (but can result in financial penalties, litigation, and terminations of contracts). Common contractual compliance requirements include the following:
  • Payment Card Industry Data Security Standard (PCI DSS)
  • Financial Industry Regulatory Authority (FINRA)
  • Service Organization Controls (SOC)
  • Generally Accepted Privacy Principles (GAPP)
  • Center for Internet Security (CIS) Critical Security Controls (CSC)
  • Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM)

It is vital to consider the legal and contractual issues that apply to how a company collects, stores, processes, and ultimately deletes data. Few companies or entities have the luxury of not considering the important national and international laws that must be complied with to do business. Perhaps not surprisingly, company officers have a vested interest in complying with these laws. Laws and regulations are specific in who is responsible for the protection of information. Federal laws like HIPAA spell out that senior officers within a company are responsible for (and liable for) the protection of data. International regulations like GDPR and state regulations such as NYCRR 500 identify the role of a data protection officer or chief information security officer and outline their culpability for any data loss incident.

If you are using cloud infrastructure from a cloud provider, you the customer must impose all legal, regulatory, and contractual obligations that are imposed on you by relevant legislation onto your cloud provider. No matter who is hosting your data or services, you the customer are accountable for compliance of effective security controls and data security.

eDiscovery Challenges in the Cloud

For a security professional, the challenges of eDiscovery are greatly increased by the use of cloud technologies. If you received a call from an outside law enforcement agency (never a phone call that anyone likes to receive) about criminal activities on one of your servers in your on-premise data centers, you might immediately take that server offline in order to image it, always having the data firmly in your possession. Now imagine if the same service was hosted in a SaaS model in the cloud distributed across 100 countries using your content delivery network. Could you get the same data easily? Could you maintain possession, custody, or control of the electronically stored information? Who has jurisdiction in any investigation? Can a law enforcement agency compel you to provide data housed in another country? All of these questions make cloud eDiscovery a distinct challenge.

eDiscovery Considerations

When you’re considering a cloud vendor, eDiscovery should be considered during any contract negotiation phase. If you think about your cloud providers today, can you recall how many conversations you might have had with their support teams? Would you know who to contact if an investigation was needed?

To pose another question, do you actually know where the data is physically housed? Many companies make use of the incredible replication and fail-over technologies of the modern cloud, but that means data may be in different time zones, countries, or continents when an investigation is launched. As we have outlined, laws in one country or state may in fact clash or break with laws of another. It is the duty of the cloud security profession to exercise due care and due diligence in documenting and understanding to the best of their ability the relevant laws and statutes pertaining to an investigation prior to it commencing.

In some cases, proactive architectural decisions can simplify issues down the road. For example, if a company chooses to house customer data within their legally defined jurisdiction (for example, EU citizen data is always housed on cloud servers within the EU), it can simplify any potential investigations or jurisdictional arguments that might arise.

Conducting eDiscovery Investigations

Where there is a problem in technology, there is usually a solution, and the marketplace for eDiscovery tools has grown commensurately with the explosion in the use of cloud service providers. There are a healthy number of vendors that specialize in this area. For a CCSP, it is important to learn about eDiscovery actors when evaluating contracts and service level agreements (SLAs) to determine what forms of eDiscovery are permissible. These are the main types of investigatory methods:

• SaaS-based eDiscovery: Why not use the cloud to perform eDiscovery on the cloud? These tools from a variety of vendors are used by investigators and law firms to collect, preserve, and review data.
• Hosted eDiscovery: In this method, your hosting provider includes eDiscovery services in the contractual obligations that can be exercised when and if necessary. This may limit a customer to a preselected list of forensic solutions, as CSPs are often wary of customer-provided tools due to the potential for affecting other cloud customers during the process.
• Third-party eDiscovery: When there are no obligations in a contract, a third party may be contracted to perform eDiscovery operations. In this model, the CCSP must work especially closely with the third party to provide appropriate access to necessary resources in the cloud.

Cloud Forensics and Standards

As you can see, the forensic and eDiscovery requirements for many legal controls are greatly complicated by the cloud environment. Unlike on-premises systems, it can be difficult or impossible to perform physical search and seizure of cloud resources such as storage or hard drives. Standards from bodies such as the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) and the Cloud Security Alliance (CSA) provide guidance to cloud security practitioners on best practices for collecting digital evidence and conducting forensics investigations in cloud environments. CCSPs should be familiar with the following standards:

• Cloud Security Alliance: The CSA Security Guidance Domain 3: Legal Issues: Contracts and Electronic Discovery highlights some of the legal aspects raised by cloud computing. Of particular importance to CCSPs are the guidance provided on negotiating contracts with cloud service providers in regard to eDiscovery, searchability, and preservation of data.
• ISO/IEC 27037:2012: This provides guidelines for the handling of digital evidence, which include the identification, collection, acquisition, and preservation of data related to a specific case.
• ISO/IEC 27041:2014-01: This provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are “fit for purpose.” CCSPs should pay close attention to sections on how vendor and third-party testing can be used to assist with assurance processes.
• ISO-IEC 27042:2014-01: This standard is a guideline for the analysis and interpretation of digital evidence. A CCSP can use these methods to demonstrate proficiency and competence with an investigative team.
• ISO/IEC 27043: The security techniques document covers incident investigation principles and processes. This can help a CCSP as a “playbook” for many types of incidents, including unauthorized access, data corruption, system crashes, information security breaches, and other digital investigations.
• ISO/IEC 27050-1: This standard covers electronic discovery, the process of discovering pertinent electronically stored information involved in an investigation.

Contractual Private Data

When your organization collects, processes, transmits, or stores private data as part of normal business processes, the information must be protected according to relevant laws and regulations. If an organization outsources any of those functions to a third party such as a cloud service provider, the contracts must specify what the applicable rules and requirements are and what laws that the cloud service provider must adhere to.

For example, if a company is handling PHI that must be processed within the United States, any contracts with a CSP must clearly specify that fact. It is the obligation of the data owner to make all terms and conditions clear and transparent for the outsourcing contract.

Regulated Private Data

The biggest differentiator between contractual and regulated data is that regulated data must be protected under legal and statutory requirements, while contractual data is protected by legal agreements between private parties. Both PII and PHI data are subject to regulation, and the disclosure, loss, or altering of these data can subject a company (and individuals) to statutory penalties including fines and imprisonment. In the United States, protection of PHI data is required by HIPAA, which provides requirements and penalties for failing to meet obligations.

Regulations are put into place by governments and government-empowered agencies to protect entities and individuals from risks. In addition, they force providers and processors to take appropriate measures to ensure protections are in place while identifying penalties for lapses in procedures and processes.

One of the major differentiators between contracted and regulated privacy data is in breach reporting. A data breach of regulated data (or unintentional loss of confidentiality of data through theft or negligence) is covered by myriad state and federal laws in the United States. There are now data privacy laws covering PII in all 50 states, with legislative changes happening every year. Some states have financial penalties of as little as $500 for data privacy violations, while others have fines in the hundreds of thousands of dollars as well as prison time for company officers. The largest state fine for a data privacy breach was handed to Uber for a 2016 breach and totaled over $148 million dollars in fines to the state of California.

Components of a Contract

As we have detailed, the outsourcing of services to a cloud service provider in no way outsources the risk to the company as the data owner. A CCSP must be familiar with key concepts when contracting with cloud service providers to ensure that both parties understand the scope and provisions when private data is concerned. Key contract areas include the following:

• Scope of data processing: The provider must have a clear definition of the permitted forms of data processing. For example, data collected on user interactions for a cloud customer should not be used by the CSP to inform new interface designs.
• Subcontractors: It is important to know exactly where all processing, transmission, storage, and use of data will take place and whether any part of the process might be undertaken by a subcontractor to the cloud service provider. If a subcontractor will be used in any phase of data handling, it is vital that the customer is contractually informed of this development.
• Deletion of data: How data is to be removed or deleted from a cloud service provider is important and helps protect against unintentional data disclosure. In the old days, data was often physically destroyed (with a screwdriver through a hard drive). In the cloud environment, that is next to impossible, so contracts must spell out the methods that data is to be securely removed from any environment (and subcontractor environment). One example is cryptoshredding, or rendering data inaccessible by cryptographic methods.
• Data security controls: If data requires a level of security controls when it is processed, stored, or transmitted, that same level of security control must be ensured in a contract with a cloud service provider. Ideally, the level of data security controls would exceed what is required (as is often the case for cloud service providers). Typical security controls include encryption of data while in transit and while at rest, access control and auditing, layered security approaches, and defense-in-depth measures.
• Physical location of data: Knowledge of the physical location of where data is stored and processed (and, in some cases, transferred) is vital to ensure compliance with legal and regulatory requirements. Contractually indicating what geographic locations are acceptable for data storage and processing (and failover/backup) can protect a company from falling victim to unintended legal consequences. In addition to the location of the data, it is important to consider the location of the cloud service provider's offices and the offices of any subcontractors in use.
• Return or surrender of data: How does one break up with a cloud service provider? They know a lot about you, and they have your data. It is important to include in any contract the termination agreements, which should specify how and how quickly data is to be returned to the data owner. In addition, the contract should outline how returned data is ensured to be removed from the cloud service provider's infrastructure. Cloud data destruction standards should be identified when entering into a contract to ensure that methods are standardized and documented when data is returned or destroyed.
• Audits: Right to audit clauses should be included to allow a data owner or an independent consultant to audit compliance to any of the areas identified earlier. In practice, most CSPs will agree to be bound by standardized audit reports such as SOC 2 or ISO 27001, and most contracts specify the frequency that these reports must be produced.

The European Union (GDPR)

The 27-member EU serves as the bellwether for personal privacy in the developed world. The right to personal and data privacy is relatively heavily regulated and actively enforced in Europe, and it is enshrined into European law in many ways. In Article 8 of the European Convention on Human Rights (ECHR), a person has a right to a “private and family life, his home and his correspondence,” with some exceptions. Some additional types of private data under the GDPR include information such as race or ethnic origin, political affiliations or opinions, religious or philosophical beliefs, and information regarding a person's sex life or sexual orientation.

In the European Union, PII covers both facts and opinions about an individual. Individuals are guaranteed certain privacy rights as data subjects. Significant areas of Chapter 3 of the GDPR (see gdpr.eu/tag/chapter-3) include the following on data subject privacy rights:

• The right to be informed
• The right of access
• The right to rectification
• The right to erasure (the so-called “right to be forgotten”)
• The right to restrict processing
• The right to data portability
• The right to object
• Rights in relation to automated decision-making and profiling

Australia

Australian privacy law was revamped in 2014, with an increased focus on the international transfer of PII. (See www.oaic.gov.au/privacy/australian-privacy-principles.)

Current law in Australia, under the Australian Privacy Act, allows for the offshoring of data but requires the transferring entity (the data processor) to ensure that the receiver of the data holds and processes it in accordance with the principles of Australian privacy law. As discussed in the previous section, this is commonly achieved through contracts that require recipients to maintain or exceed privacy standards. An important consequence under Australian privacy law is that the entity transferring the data out of Australia remains responsible for any data breaches by or on behalf of the recipient entities, meaning significant potential liability for any company doing business in Australia under current rules.

The United States

Data privacy laws in the United States generally date back to fair information practice guidelines that were developed by the precursor to the Department of Health & Human Services (HHS). (See Ware, Willis H. (1973, August). “Records, Computers and the Rights of Citizens,” Rand. Retrieved from www.rand.org/content/dam/rand/pubs/papers/2008/P5077.pdf.) These principles include the following concepts:

• For all data collected, there should be a stated purpose.
• Information collected from an individual cannot be disclosed to other organizations or individuals unless specifically authorized by law or by consent of the individual.
• Records kept on an individual should be accurate and up-to-date.
• There should be mechanisms for individuals to review data about them, to ensure accuracy. This may include periodic reporting.
• Data should be deleted when it is no longer needed for the stated purpose.
• Transmission of personal information to locations where “equivalent” personal data protection cannot be assured is prohibited.
• Some data is too sensitive to be collected unless there are extreme circumstances (such as sexual orientation or religion).

Perhaps the defining feature of U.S. data privacy law is its fragmentation. There is no overarching law regulating data protection in the United States. In fact, the word privacy is not included in the U.S. Constitution. However, there are now data privacy laws in each of the 50 states as well as U.S. territories.

There are few restrictions on the transfer of PII or PHI out of the United States, a fact that makes it relatively easy for companies to engage cloud providers and store data in other countries. The Federal Trade Commission (FTC) and other regulatory bodies do hold companies accountable to U.S. laws and regulations for data after it leaves the physical jurisdiction of the United States. U.S.-regulated companies are liable for the following:

• Personal data exported out of the United States
• Processing of personal data by subcontractors based overseas
• Projections of data by subcontractors when it leaves the United States

Several important international agreements and U.S. federal statutes deal with PII. The Privacy Shield agreement is a framework that regulates the transatlantic movement of PII for commercial purposes between the United States and the European Union. Federal laws worth review include HIPAA, GLBA, SOX, and the Stored Communications Act, all of which impact how the United States regulates privacy and data. At the state level, it is worth reviewing the California Consumer Protection Act (CCPA), the strongest state privacy law in the nation.

Privacy Shield

Unlike the GDPR, which is a set of regulations that affect companies doing business in the EU or with citizens of the EU, Privacy Shield is an international agreement between the United States and the European Union that allows the transfer of personal data from the European Economic Area (EEA) to the United States by US-based companies. (See www.impact-advisors.com/security/eu-us-privacy-shield-framework/ and iapp.org/media/pdf/resource:center/Comparison-of-Privacy-Shield-and-the-Controller-Processor-Model.pdf.) This agreement replaced the previous safe harbor agreements, which were invalidated by the European court of justice in October 2015. The Privacy Shield agreement is currently facing legal challenge in European Union courts as of July 2020. Adherence to Privacy Shield does not make U.S. companies GDPR-compliant. Rather, it allows the company to transfer personal data out of the EEA into infrastructure hosted in the United States.

To transfer data from the EEA, U.S. organizations can self-certify to the Department of Commerce and publicly commit to comply with the seven principles of the agreement. Those seven principles are as follows:

• Notice: Organizations must publish privacy notices containing specific information about their participation in the Privacy Shield Framework; their privacy practices; and EU residents' data use, collection, and sharing with third parties.
• Choice: Organizations must provide a mechanism for individuals to opt out of having personal information disclosed to a third party or used for a different purpose than that for which it was provided. Opt-in consent is required for sharing sensitive information with a third party or its use for a new purpose.
• Accountability for onward transfer: Organizations must enter into contracts with third parties or agents who will process personal data for and on behalf of the organization, which require them to process or transfer personal data in a manner consistent with the Privacy Shield principles.
• Security: Organizations must take reasonable and appropriate measures to protect personal data from loss, misuse, unauthorized access, disclosure, alteration, and destruction, while accounting for risks involved and nature of the personal data.
• Data integrity and purpose limitation: Organizations must take reasonable steps to limit processing to the purposes for which it was collected and ensure that personal data is accurate, complete, and current.
• Access: Organizations must provide a method by which the data subjects can request access to and correct, amend, or delete information the organization holds about them.
• Recourse, enforcement, and liability: This principle addresses the recourse for individuals affected by noncompliance, consequences to organizations for noncompliance, and compliance verification.

The Health Insurance Portability and Accountability Act of 1996

The HIPAA legislation of 1996 defined what comprises personal health information, mandated national standards for electronic health record keeping, and established national identifiers for providers, insurers, and employers. Under HIPAA, PHI may be stored by cloud service providers provided that the data is protected in adequate ways.

The Gramm–Leach–Bliley Act (GLBA) of 1999

This U.S. federal law requires financial institutions to explain how they share and protect their customers' private information. GLBA is widely considered one of the most robust federal information privacy and security laws. This act consists of three main sections:

• The Financial Privacy Rule, which regulates the collection and disclosure of private financial information
• The Safeguards Rule, which stipulates that financial institutions must implement security programs to protect such information
• The Pretexting provisions, which prohibit the practice of pretexting (accessing private information using false pretenses)

The act also requires financial institutions to give customers written privacy notices that explain their information-sharing practices. GLBA explicitly identifies security measures such as access controls, encryption, segmentation of duties, monitoring, training, and testing of security controls.

The Stored Communication Act of 1986

The Stored Communication Act (SCA), as enacted as Title II of the Electronic Communication Privacy Act, created privacy protection for electronic communications (such as email or other digital communications) stored on the Internet. In many ways, this act extends the Fourth Amendment of the U.S. Constitution—the people's right, to be “secure in their persons, houses, papers, and effects, against unreasonable searches and seizures”—to the electronic landscape. It outlines that private data is protected from unauthorized access or interception (by private parties or the government).

The California Consumer Privacy Act of 2018

It may seem odd to talk about a state privacy law in the context of international privacy protection, but the California Consumer Privacy Act (CCPA) is at present the strongest data privacy law in the United States. The act is intended to protect within state law the rights of a California citizen to the following:

• Know what personal data is being collected about them
• Know whether their personal data is sold or disclosed and to whom
• Opt out of the sale of personal data
• Access their personal data
• Request a business to delete any personal information about a consumer collected (the right to be forgotten)
• Be protected from discrimination (by service or price) for exercising their privacy rights

The CCPA outlines what entities need to comply with the law, the responsibility and accountability of the law's provisions, and the sanctions and fines that may be levied for violations of the law. Those fines can vary between $100 to $750 per consumer per data incident (or actual damages, whichever is greater), which makes the CCPA the most stringent privacy law in the United States.

Generally Accepted Privacy Principles

Generally Accepted Privacy Principles (GAPP) consists of 10 principles for privacy from the American Institute of Certified Public Accountants (AICPA). (See www.aicpa.org/content/dam/aicpa/interestareas/informationtechnology/resources/privacy/downloadabledocuments/10252-346-records-management-pro.pdf.) The GAPP is a strong set of standards for the appropriate protection and management of personal data. The 10 main privacy principle groups consist of the following:

• Management: The organization defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
• Notice: The organization provides notice of its privacy policies and procedures. The organization identifies the purposes for which personal information is collected, used, and retained.
• Choice and consent: The organization describes the choices available to the individual. The organization secures implicit or explicit consent regarding the collection, use, and disclosure of the personal data.
• Collection: Personal information is collected only for the purposes identified in the notice (see “Notice,” earlier in the list).
• Use, retention, and disposal: The personal information is limited to the purposes identified in the notice the individual consented to. The organization retains the personal information only for as long as needed to fulfill the purposes or as required by law. After this period, the information is disposed of appropriately and permanently.
• Access: The organization provides individuals with access to their personal information for review or update.
• Disclosure to third parties: Personal information is disclosed to third parties only for the identified purposes and with implicit or explicit consent of the individual.
• Security for privacy: Personal information is protected against both physical and logical unauthorized access.
• Quality: The organization maintains accurate, complete, and relevant personal information that is necessary for the purposes identified.
• Monitoring and enforcement: The organization monitors compliance with its privacy policies and procedures. It also has procedures in place to address privacy-related complaints and disputes.

Standard Privacy Rights Under GDPR

In the EU, the GDPR codifies specific rights of the data subject that must be adhered to by any collector or processor of data. These rights are outlined in Chapter 3 of the GDPR (Rights of the Data Subject) and consist of 12 articles detailing those rights:

• Transparent information, communication, and modalities for the exercise of the rights of the data subject
• Information to be provided where personal data are collected from the data subject
• Information to be provided where personal data have not been obtained from the data subject
• Right of access by the data subject
• Right to rectification
• Right to erasure (“right to be forgotten”)
• Right to restriction of processing
• Notification obligation regarding rectification or erasure of personal data or restriction of processing
• Right to data portability
• Right to object
• Automated individual decision-making, including profiling
• Restrictions

The complete language for the GDPR data subject rights can be found at gdpr.eu/tag/chapter-3 .

Service Organization Controls

The American Institute of CPAs (AICPA) provides a suite of offerings that may be used to report on services provided by a service organization that customers can use to address risks associated with an outsourced service. See Table 6.2.

The differences between the SOC reports are as follows:

• Service Organizations Controls 1 (SOC 1): These reports deal mainly with financial controls and are intended to be used primarily by CPAs that audit an entity's financial statements.
• SOC for Service Organizations: Trust Services Criteria (SOC 2): Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy. These reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users' data and the confidentiality and privacy of the information processed by these systems. These reports can play an important role in the following:
  • Organizational oversight
  • Vendor management programs
  • Internal corporate governance and risk management processes
  • Regulatory oversight

  There are two types of reports for these engagements:

  • Type 1: Report on the fairness of the presentation of management's description of the service organization's system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.
  • Type 2: Report on the fairness of the presentation of management's description of the service organization's system and the suitability of the design and operating effectiveness of the controls to achieve the related control objectives included in the description throughout a specified period.
• Service Organization Controls 3 (SOC 3): Similar to SOC 2, the SOC 3 report is designed to meet the needs of users who need the same types of knowledge offered by the SOC 2, but lack the detailed background required to make effective use of the SOC 2 report. In addition, SOC 3 reports are considered general use and can be freely distributed, as sensitive details have been removed and only general opinions and nonsensitive data are contained.

AICPA definitions of SOC controls can be found at the following locations:

• SOC 1: www.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc1report.html
• SOC 2: www.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report.html
• SOC 3: www.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc3report.html

The Statement on Standards for Attestation Engagements (SSAE) is a set of standards defined by the AICPA to be used when creating SOC reports. The most current version (SSAE 18) was made effective in May 2017, and added additional sections and controls to further enhance the content and quality of SOC reports.

The international counterpart of the AICPA, the International Auditing and Assurance Standards Board, issues the International Standard on Assurance Engagements (ISAE). There are a number of differences between the two standards, and a security professional should always consult the relevant business departments to determine which audit report(s) will be used when assessing cloud systems.

Cloud Security Alliance

The Cloud Security Alliance (CSA) offers a Security Trust Assurance and Risk (STAR) certification that can be used by cloud service providers, cloud customers, or auditors and consultants to ensure compliance to a desired level of assurance. (See downloads.cloudsecurityalliance.org/assets/research/security-guidance/security-guidance-v4-FINAL.pdf.) STAR consists of three levels of certification:

• Level 1: Self-Assessment is a complimentary offering that documents the security controls provided by various cloud computing offerings, helping users assess the security of cloud providers they currently use or are considering using.
• Level 2: Attestation is a collaboration between CSA and the AICPA to provide guidelines for CPAs to conduct SOC 2 engagements using criteria from the AICPA (Trust Service Principles, AT 101) and the CSA Cloud Controls Matrix. STAR Attestation provides for rigorous third-party independent assessments of cloud providers.
• Level 3: Continuous monitoring through automated processes that ensure security controls are monitored and validated at all times.

Benefits of an ISMS

Though the function of an ISMS can vary from industry to industry, there are a number of benefits to implementation that hold true across all industries.

• Security of data in multiple forms: An ISMS will help protect data in all forms, whether paper, digital, or cloud based.
• Cyber attacks: Having an ISMS will make an organization more resilient to cyber attacks by having best practices in security in place throughout the operation.
• Central information management: An ISMS will put in place centralized frameworks for managing information, reducing shadow systems, and easing the burden of data protection.
• Risk management: Having a codified set of processes and procedures in place will reduce operational risks in a number of areas, including information security, business continuity, and adapting to evolving security threats.

As with any major organizational element, an ISMS requires buy-in from company leadership to be effective. In the cloud computing environment, an ISMS is extremely valuable in requiring detailed documentation on cloud provider environments and change logging.

Organizational Policies

Companies use policies and procedures to outline rules as well as outline courses of action to deal with problems. Organizations use policies to make employees understand the organization's views and values on specific issues, and what actions will occur if they are not followed. At the organizational level, policies are used to reduce the chances of the following:

• Financial losses
• Loss of data
• Reputational damage
• Statutory and regulatory compliance issues
• Abuse or misuse of computing systems and resources

Functional Policies

A functional policy is a set of standardized definitions for employees that describe how they are to make use of systems or data. Functional policies typically guide specific activities crucial to the organization, such as appropriate handling of data, vulnerability management, and so on. These are generally codified in an operation ISMS and can consist of the following (not an exhaustive list):

• Data classification policies: Identifies types of data and how each should be handled
• Network services policies: How issues such as remote access and network security are handled
• Vulnerability scanning policies: Routines and limitations on internal scanning and penetration testing
• Patch management policies: How equipment is patched on what schedule
• Acceptable use policies: What is and is not acceptable to do on company hardware and networks
• Email use policies: What is and is not acceptable to do on company email accounts
• Password policies: Password complexity, expiration, reuse
• Incident response policies: How incidents are handled

Cloud Computing Policies

Employee provisioned cloud services may present significant data management risks and may be subject to changes in risk with or without notice. Almost all cloud services require individual users to accept click-through agreements (which are rarely if ever read carefully). Agreements do not allow users to negotiate or clarify terms, often provide vague descriptions of services and safeguards, and often are subject to change without notice.

Cloud services should not be exempt from organizational policy application. These policies will define the requirements that users must adhere to in order to make use of the services. Because of the ease of provisioning cloud services, many organizations have specific policies in place that discourage or prohibit the use of cloud services by individuals outside of central IT oversight.

When pursuing cloud services, a security professional should pay close attention to the following:

• Password policies: If an organization has password policies around length, complexity, expiration, or multifactor authentication (MFA), it is important to ensure that these same requirements are met by a cloud service provider.
• Remote access: The same bar must be met for remote access to cloud providers as on-premises services. This may include items such as up-to-date patching, hard disk encryption, or MFA.
• Encryption: Policies about encryption strength and when encryption is required. Key escrow can be an important aspect of policy to focus on (for example who has the decryption keys?).
• Data backup and failover: Policies on data retention and backup must be enforced on cloud providers. If policies exist on data location for backups and redundancy, they must also be enforced on CSPs.
• Third-party access: What third parties might have access to data stored with the CSP? Can this access be logged and audited?
• Separation of duties: Can controls for the separation of key roles be enforced and maintained by the cloud provider?
• Incident response: What are the required steps in a response, including who is contacted for a variety of incidents?

In some instances, a cloud service provider cannot meet a company's requirements when it comes to adhering to a specific policy. If this happens, it is important to consider the risks of using the provider, and any deviations from policy should be carefully documented.

Stakeholder Identification Challenges

To identify stakeholders, some key challenges that a cloud security professional may face include the following:

• Defining the enterprise architecture currently used to delivery services.
• Evaluating potential cloud options and solutions objectively and without existing bias.
• Selecting the appropriate service(s) and cloud provider.
• Identifying what users may be affected by the service offerings and planning change management. This may particularly difficult if roles are being eliminated by a shift to cloud computing.
• Identifying both the direct costs (costs paid to CSP or third parties) and the indirect costs (training, loss of productivity due to learning a new system, etc.).
• Identifying appropriate parties to engage on risk management.

Governance Challenges

In addition to identifying stakeholders, cloud security professionals should be prepared to deal with governance challenges when moving to a cloud environment, including the following:

• Audit requirements and how to accomplish them in the cloud
• Regulatory and legal obligations
• Reporting and communication lines within the organization and with the cloud service provider
• Documentation of all operational procedure and process changes and where this documentation will be safely stored
• Review of all disaster recovery and business continuity planning documents to ensure updates for new cloud architecture

The benefits of the cloud can quickly and easily move beyond just the financial for many companies. The prevalence of distributed workforces, reliability and scalability, worldwide delivery of services, and backup and recovery possibilities are just a few benefits that have driven cloud adoption across countless industries. For those reasons, the emphasis and appetite to move to cloud computing may come from many different areas within a company. It is important to coordinate communication across the many departments that may be affected by cloud projects.

Communications

In a traditional IT model, teams are generally familiar with what roles and functions are filled by different personnel. Depending on the company, they may be on a first-name basis (and might play on the company softball team together). Distributed IT means that these roles and functions may be separated geographically and all correspondence takes place via technology.

In some cases, less formal processes (for example, “I call Jim in networks when I need to have a Client Access License [CAL] added to the system”) move to more structured interactions using standardized processes (for example, “I submitted a ticket in service now for a new CAL to be provisioned”).

From a security perspective, this is considered an improvement, despite the potential business impacts caused by increased effort to get IT functions accomplished quickly. Using formalized ticketing systems and processes means that changes are far more likely to be recorded, adding to the overall adherence to change management controls.

Coordination of Activities

Technology project management is a key component to the success of any IT department. Successful PMs oversee the implementation of hardware and software projects using project management methods and expertise that is a key skillset within any company, especially in an IT organization.

The specialized nature of distributed IT models (and cloud services offerings) makes it less likely that an organization will have personnel in house with the specialized knowledge required to successfully implement projects. For this reason, it is important to consider bringing in outside experts for implementation projects. This common practice gives the distinct advantage of having subject-matter experts involved in the rollout or deployment of a new service or offering. In addition, this relieves some of the burden on an organization's IT team in learning, coordinating, and provisioning new systems that they may be completely unfamiliar with. Consultant agreements generally allow a provider to deliver service to a customer's requirements with sufficient accountability and oversight from company representatives.

Governance of Activities

Effective governance can require additional steps in a distributed IT environment. When IT functions are dispersed across providers, countries, or continents, additional efforts may be needed to pull together information for program management, risk management, audit, compliance, and legal functions. Additionally, the distribution of these IT functions across jurisdictions where different statutory and regulatory issues may apply may increase the overall efforts needed to ensure effective governance.

Selecting IT service providers that are effective and responsive in communication is key to establishing repeatable governance models. Many vendors specialize in the automation of information collection for governance purposes, which can help streamline the collection of information from distributed providers.

Distributed IT models mean that effective governance will require the collection of information from multiple sources. Coordinating those efforts should include the up-front identification of how these processes will be managed to achieve the common goals of the organization.

Risk Profile

A company's risk profile generally comprises two factors. The first is a quantitative measure of the types of threats that an organization faces. This can vary widely by company and business sector, as a financial company can face very different risks than a landscaping provider. The second factor is the company's willingness to accept risk (risk tolerance). In mature companies, this can be represented as a numerical value to help quantify the calculations. Combining these with potential costs associated with the occurrence of each risk can provide a nonsubjective profile of risk.

A risk profile can help a company identify the level of risks that it is willing to accept. This profile is developed collaboratively with numerous stakeholders throughout the organization, such as business leaders, data owners, enterprise risk management, internal and external audit, legal, and compliance officers.

Risk Appetite

Risk appetite is just what it sounds like: the appetite a company has to accept risk. Every company is different in this arena, and it is directly affected by regulations and statutory requirements in a particular industry. The risk appetite of a company may be significantly larger if their success depends largely on time-to-market. They may be willing to accept larger risks in the cloud computing arena to achieve scalability or utilize cloud technologies to reach consumers in more geographic areas.

Breach Notifications

As detailed earlier in this section, notification of data breaches is required by all 50 states, several federal statutes, and numerous international laws. In practice, nearly every human on the planet is familiar with these laws because they have been notified by numerous companies about the loss of their private data. In all cases (including cloud computing environments), the data controller is responsible under the law for notifying the appropriate authorities as well as the data subject of the loss of their personal data. Many states and international laws have timely notification requirements that companies must fulfill when personal data is lost.

Sarbanes–Oxley Act

If a company is publicly traded in the United States, they are subject to transparency requirements under the Sarbanes-Oxley Act (SOX) of 2002. Specifically, as data owners, these companies should consider the following:

• Section 802: It is a crime to destroy, change, or hide documents to prevent their use in official legal processes.
• Section 804: Companies must keep audit-related records for a minimum of five years.

SOX compliance is often an issue with both data breaches and ransomware incidents at publicly traded companies. The loss of data related to compliance due to external actors does not protect a company from legal obligations.

GDPR and Transparency

For companies doing business in the European Union or with citizens of the EU, transparency requirements under the GDPR are laid out in Article 12 (see gdpr-info.eu/art-12-gdpr ). The exact language states that a data controller (data owner) “must be able to demonstrate that personal data are processed in a manner transparent to the data subject.” The obligations for transparency begin at the data collection stage and apply “throughout the life cycle of processing.”

The GDPR stipulates that communication to data subjects must be “concise, transparent, intelligible and easily accessible, and use clear and plain language.” The methods of communication are also clearly defined. Information must be provided to the data subjects “in writing, or by electronic means” or orally upon request. All of this information must be provided free of charge and not be conditional upon the purchase of a service or the surrender of information.

In practical terms, this means that plain language must be used to explain why data is being collected and what it is being used for. Similar language is included in some current (CCPA) and forthcoming state regulations.

ISO 31000:2018

ISO 31000, “Risk management - Guidelines,” was first published in 2009 and majorly revised in 2018. (See www.iso.org/obp/ui/#iso:std:iso:31000:ed-2:v1:en.) This ISO standard provides generic recommendations for the design, implementation, and review of risk management processes within an organization. The 2018 update provides more strategic guidance as well as redefines risk from the concept of a “probability of loss” to a more holistic view of risk as the “effect of uncertainty of objectives,” recasting risk as either a negative or positive effect. ISO 31000 recommends the following steps in planning for risk:

• Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk
• Accepting or increasing the risk to pursue an opportunity
• Removing the risk source
• Changing the likelihood
• Changing the consequences
• Sharing the risk with another party or parties (including contracts and risk financing)
• Retaining the risk by informed decision

ISO 31000 is a detailed framework, but is not designed to be used in certification (there is no such thing as “ISO 31000 certified”). Adopting this framework will require extensive management conformity to accountability standards as well as strategic policy implementation, communication, and review practices.

European Network and Information Security Agency

European Network and Information Security Agency (ENISA) produces a number of useful resources, and the “Cloud Computing Risk Assessment (2009)” is one of them (www.enisa.europa.eu/publications/cloud-computing-risk-assessment). This guide identifies 35 types of risk for companies to consider in the areas of policy and organizational, technical, legal, and risks not specific to the cloud. In addition, ENISA spells out 53 types of vulnerabilities that companies should be aware of and a top-eight security risk list based on the impact and likeliness of occurrence. This free resource is certainly worth review by any cloud security professional. The top eight security risks include the following:

• Loss of governance: Gaps in the security defenses caused by differences in the understanding of responsibility between the client and the CSP.
• Lock-in: The difficulty in leaving a CSP.
• Isolation failure: The potential failures caused by lack of separation in storage, memory, and other hardware between cloud clients.
• Compliance risk: The CSP provides a new challenge to achieving certification.
• Management interface compromise: Management interfaces for cloud environments provide an additional attack vector.
• Data protection: How CSPs handle data in a lawful way.
• Insecure data deletion: Secure deletion of the cloud is complicated by its distributed nature.
• Malicious insiders: Addition of a CSP adds high-risk access individuals who can comprise cloud architectures and data.

National Institute of Standards and Technology (NIST)

National Institute of Standards and Technology (NIST) makes the list of excellent standards once again with 800-146, “Cloud Computing Synopsis and Recommendations” (see csrc.nist.gov/publications/detail/sp/800-146/final). This risk framework was published in 2012, and is a comprehensive guide to the benefits and risks associated with SaaS, PaaS, and IaaS cloud environments. The guide also makes recommendations on management, data governance, security and reliability, and virtual machines, as well as software and applications. Another handy reference (albeit written specifically for U.S. federal government) is NIST 800-37, a generalized risk management framework for information systems that has well documented methods for controlling risk in IT environments.

ISO 15408-1:2009: The Common Criteria

The Common Criteria for Information Technology Security Evaluation is an international standard for information security certification. The evaluation process is designed to establish a level of confidence in a product or platform's security features through a quality assurance process. This is done through testing laboratories where the product of platform is evaluated.

Most cloud service providers do not have common criteria evaluations, but many cloud-based products do. One common example relevant to CCSPs are security tools designed to be deployed in virtual environments.

Does Common Criteria evaluation mean that a product is secure? Not necessarily. Though Windows operating systems have received certification under the program, they have later been found to have major security flaws. In addition, CC does not include any study of the administrative or business processes of a company that produced a product or platform; it is merely an evaluation of the technical merits of the platform itself. An up-to-date list of certified products can be found at www.commoncriteriaportal.org/products.

Cloud Security Alliance (CSA) STAR

It is worth revisiting the Security, Trust, and Assurance Registry (STAR) provided by the CSA (cloudsecurityalliance.org/star/levels) as a valuable tool in displaying transparency and assurance for cloud service providers. CSA STAR makes use of the cloud control matrix version 4.0. STAR consists of three levels of certification.

• Level 1, Self-Assessment, is a complimentary offering that documents the security controls provided by various cloud computing offerings, helping users assess the security of cloud providers they currently use or are considering using.
• Level 2, Attestation, is a collaboration between CSA and the AICPA to provide guidelines for CPAs to conduct SOC 2 engagements using criteria from the AICPA (Trust Service Principles, AT 101) and the CSA Cloud Controls Matrix. STAR Attestation provides for rigorous third-party independent assessments of cloud providers.
• Level 3, Continuous Auditing, consists of monitoring through automated processes that ensure security controls are monitored and validated at all times.

Since the registry of certified providers is publicly available, the STAR program makes it easy for a company to assess the relative risk of a provider and should certainly be consulted when assessing any new CSP.

ENISA Cloud Certification Schemes List and Metaframework

ENISA has provided another resource that can be used by cloud security professionals to assess the relative risk of a cloud service provider. (See resilience.enisa.europa.eu/cloud-computing-certification.) The Cloud Certification Schemes List (CCSL) provides an up-to-date summary of existing certification schemes that could be relevant for cloud computing. The list as of 2020 is as follows:

• Certified Cloud Service, TÜV Rheinland
• CSA Attestation, OCF Level 2
• CSA Certification, OCF Level 2
• CSA Self-Assessment, OCF Level 1
• EuroCloud Self-Assessment
• EuroCloud Star Audit Certification
• ISO/IEC 27001 Certification
• Payment Card Industry Data Security Standard v3
• Leet Security Rating Guide
• Service Organization Control (SOC) 1
• Service Organization Control (SOC) 2
• Service Organization Control (SOC) 3
• Cloud Industry Forum Code of Practice

ENISA describe the Cloud Certification Schemes Metaframework (CCSM) as an extension of CCSL. (See Figure 6.4.) It is a metaframework of cloud certification schemes. The goal of the metaframework is to provide a neutral high-level mapping from the customer's network and information security requirements to security objectives in existing cloud certification schemes, which facilitates the use of existing certification schemes during procurement. The agency also provides an online tool where it is possible to select from 27 different security objectives to see how the relative certifications compare.

Key SLA Requirements

Service level agreements can be a key factor in avoiding potential issues once a contract is in place. Service metrics, such as uptime or quality of service, can be included in this section of a contract. An uptime of 99 percent may seem adequate, but that level of allowed downtime would be equal to 87.6 hours a year! Service level agreements often include sections on the following:

• Uptime guarantees
• SLA violation penalties
• SLA violation penalty exclusions and limitations
• Suspension of service clauses
• Provider liability
• Data protection and management
• Disaster recovery and recovery point objectives
• Security and privacy notifications and timeframes

Cyber Risk Insurance

Cyber risk insurance is designed to help an organization modify risk by sharing the risk of a cyber incident with others via a policy that might offset costs involved with recovery after a cyber-related security incident such as a breach. This is a growing field, and many more companies are choosing to indemnify against the threats of harm from incidents. Cyber risk insurance usually covers costs associated with the following:

• Investigation: Costs associated with the forensic investigation to determine the extent of an incident. This often includes costs for third-party investigators.
• Direct business losses: Direct monetary losses associated with downtime or data recovery, overtime for employees, and oftentimes, reputational damages to the company.
• Legal notifications: Costs associated with required privacy and breech notifications required by relevant laws.
• Lawsuits: Policies can be written to cover losses and payouts due to class action or other lawsuits against a company after a cyber incident.
• Extortion: The insurance to pay out ransomware demands is growing in popularity. This may include direct payments to ensure data privacy or accessibility by the company.

ISO 27036: Information Security for Supplier Relationships

As we have seen with previous standards, the ISO provides a framework to allow for the evaluation and treatment of information risks involved in the acquisition of goods and services from suppliers. (See www.iso.org/obp/ui/#iso:std:iso-iec:27036:-4:ed-1:v1:en.) This is a four-part standard, part four (2016) of which “Guidelines for security of cloud services” provided excellent guidance for understanding and mitigating the risk of the cloud supply chain. According to ISO, the application of this standard should result in the following:

• Increased understanding and definition of information security in cloud services
• Increased understanding by the customers of the risks associated with cloud services to enhance the specification of information security requirements
• Increased ability of cloud service providers to provide assurance to customers that they have identified risks in their service(s) and associated supply chains and have taken measures to manage those risks

ISO 27036 is not yet available for free but provides a strong reference for understanding supply chain risk in the cloud context. Additional resources worth review include the draft NISTIR 8276 (Key Practices in Cyber Supply Chain Risk Management: Observations from Industry), NIST SP800-161 (Supply Chain Risk Management Practices for Federal Information Systems and Organizations), and the 2015 ENISA publication on supply chain integrity.