Cloud Service Provider SLA Checklist For Executives

Cloud SLA Checklist For Executives by Tim Layton

Well-designed Service-Level Agreements (SLAs) can significantly contribute to avoiding conflict and can facilitate the resolution of an issue before it escalates into a dispute.

Who should review this document?

All enterprise stakeholders in the organization and executive responsible for the cloud security contract and service level agreement. Executives looking for a no-nonsense checklist to ensure all of the basics are covered will benefit from my checklist as well.

I strongly recommend that cloud subject matter experts are allowed to provide feedback and input before the SLA is signed because it serves as both the blueprint and warranty for cloud computing services.

Oftentimes the SLA is described as the rule book and legal contract for an organization’s relationship with the cloud services provider (CSP).

The SLA spells out the minimum level of service, availability, security, controls, processes, communications, support, and many other crucial business elements are stated and agreed to by both parties.

Not all SLAs that you review cover the focus points you may have issues or concerns with. Every effort should be made to obtain clarity prior to engaging with the cloud service provider. If you think it is time-consuming moving to cloud environments, wait until you try to get out.

The SLA also describes levels of service using various attributes such as availability, serviceability, or performance. The SLA specifies thresholds and financial penalties associated with violations of these thresholds.

Get My Free Cloud Security Journal

Important SLA points to consider include the following:

  • Affirm data ownership
  • Specify data return and destruction details
  • Document specific parameters, minimum service levels, and remedies for any failure to meet the specified requirements
  • Cloud system infrastructure details and security standards
  • Customer right to audit legal and regulatory compliance by the CSP
  • Rights and cost associated with continuing and discontinuing service use
  • Service availability
  • Service performance
  • Data security and privacy
  • Disaster recovery processes
  • Data location
  • Data access
  • Data portability
  • Problem identification and resolution expectations
  • Change management processes
  • Dispute mediation processes
  • Exit strategy

Organizations should have contingency plans in place to support worst-case scenarios.

Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.

Stay Connected With Tim Layton

LinkedIn: www.Linkedin.com/in/TimLaytonCyber

Website: http://CloudSecurityLaunchPad.com

Get My Free Cloud Security Journal


COMMON CYBERSECURITY RISK TERMS DEFINED

Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)

Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)

Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)

Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)

Likelihood: chance of something happening. (ISO 27001)

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)

Risk: effect of uncertainty on objectives. (ISO 27001)

Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)

Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)

Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)

Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)

Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)

Get My Free Cloud Security Journal

Tim Layton

Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.

Recommended Articles

1 Comment

  1. […] and reviewed by all stakeholders (legal, compliance, IT, security, compliance, etc.). I wrote an SLA Checklist article that you may also find […]

Leave a Reply

Your email address will not be published. Required fields are marked *