When you are leasing a car does not mean that you can drive around totally wreckless on the streets and skip all the rules that apply. You still need to drive the car according to certain terms, conditions, and rules. You are not allowed to be lawless and go cowboy-style. This behavior is not-so-good driver of a car.

The same goes when you and your organization choose to invest in a cloud service. You can choose to go totally bananas, skip the due diligence of the service and supplier, and be totally careless about how you manage the data and information. Neglect regulatory compliance and organizational security requirements. This behavior is not-so-good security practice.

Accountability for security can never be outsourced. Just because a CSC (Cloud Service Customer) outsources the management and operations of a certain service to a CSP (Cloud Service Provider) does not mean accountability for security is removed.

Unfortunately, this is how some organizations do. They are totally unaware of and do not contemplate what security means when it comes to cloud services. They lack the knowledge, skills, competence, and resources. Or those cloud services coming into the organization are bypassing the formal procurement process and are purchased directly by the organization.

In this article, I will further explain the fundamental components of the Cloud security governance process and why they are important.

When services, independent of whether they exist in the cloud or on-prem, a customer’s organization is still accountable for the security. Accountability for security can not be outsourced. The responsibility though can be, to some extent.

The CSP (Cloud service provider) is responsible for ensuring the services provided to the CSC (Cloud service customer) are secured according to the agreed terms and conditions. And there it is, one of the most important things related to cloud security governance. “Agreed terms and conditions”.

So how does a customer’s organization ensure the security requirements meet the agreed requirements the service provider is responsible for? <*Drum roll*> Contract management that includes commercial terms and agreements.


When insight and control are reduced for the CSC there is a need to mitigate this by gaining an understanding of how certain tasks conducted by the CSP are performed. Security does not come as a result of what is presented on a PowerPoint by a cloud service provider. Security does not come as a result of what the name is on the appliance box. It can not be enough for a CSC to blindly trust in the promises made during the sales pitch or initial discussions with the CSP. And security is not a result or a product of the CSC telling the CSP “I want this service to be secure! Fix it.”. Secure according to what? According to what terms of requirements? The CSC can not outsource accountability of security to the CSP.

These forms of discussions need to take place during the procurement process between the CSC and CSP. Each part must help the other out. The CSC is responsible for addressing the security requirements of the organization to the CSP. If there are certain security requirements from the CSC explicit for the organization those need to be addressed. It is a two-way street. The CSP cannot and shall not sit there on the other end of the table and guess what and which security requirements apply to the customer’s organization. Security shall not, according to my belief, work that way or be approached like that. Help each other out to gain insight. That is the way forward. Security is not a guessing game and should not be approached as one, independent of whether it is about cloud services or on-prem services. Security is a team sport. Do it together, as a customer and service provider.


For a CSC to understand a CSP’s security posture a stringent and intelligent method is highly recommended. The CSC is accountable for security, and for this reason, understanding and insight around the CSP’s security controls in place, weaknesses, vulnerabilities, threats, and risks need to be gained. And this needs to be done before the ink is put on the paper, I.e. the commercial agreement between the CSC and CSP is signed.

When a contract is signed with a CSP the chances of accomplishing a change in the service are significantly reduced. And if the CSP does not get all the necessary information in advance related to certain security requirements it is impossible, for the CSP, to help the customer’s organization in achieving the required security level. Change management always comes with a cost, in both ways. For the CSC and the CSP. Help each other and discuss this as a part of the contract establishment. “What if we identify certain requirements that result in a change during the first 6 months?”. This is a good question to be asked and discussed together.

And think about it. If both parties do not fully understand the security requirements is also a security risk as such. Risks need to be sorted out forehand so that the chances are reduced for unmitigated security glitches. Each part, the CSC and CSP, will benefit from understanding the risks involved. This is an exercise in which both the CSC and CSP need to cooperate. And the CSC needs to be able to articulate the security requirements to the CSP. And the CSP needs to help the CSC out to better understand how to ask the right questions or to coach them in the dialogue. Communication from both ends is key. The dialogue can go out something like this, or start from here:

“We as an organization have several security requirements all our third-party suppliers need to adhere to. Those are stipulated in appendix 1A Information Security Requirements for Third Party and Cloud Suppliers. Please review this appendix. Mark out those parts where you feel uncertain or need further guidance around our requirements. And as a part of this exercise, we would also like to review the security policies that you as a CSP operate according to. Please provide us with a copy of your Information security policies and relevant artifacts.

We see all our third-party suppliers as a part of our total ecosystem. And to help you out to do a good job as possible we would like to ask you if there is something that we as a customer need to take into consideration now when we are entering this partnership with you. How can we as a customer help out in establishing a strong and long-lasting relationship built upon security and trust?”


Security responsibility related to cloud services shifts between the different service models. And of this reason, it can not be assumed that a certain responsibility model is equal for every cloud service. Who is responsible for the cryptographic key management, identities, data/information, access controls, application security etcetera?

The solution to getting these answers is to do that due diligence in advance and together with the cloud service provider. To establish roles and responsibilities, as a part of the contract and agreement.

Cloud Security Alliance describes the different cloud service models and security responsibilities accordingly for the different cloud service models:

  • SaaS – 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.

  • PaaS– 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.

  • IaaS – 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 service models and differences, explained above, can be translated into two simple models presented below.

The above matrix may shift somewhat between cloud service providers. The goal of the matrix is to provide a holistic representation illustrating how roles and responsibilities shift, between cloud services and between the CSP and CSC.

And to simplify the matrix into something condensed in a visual form I think the below illustration does the job well.

How security responsibility shift in cloud services

Make sure to, as a part of the contract and agreement, with your cloud service provider to have a common understanding of who is responsible for what. Establish that RACI (Responsible, Accountable, Consulted, Informed) model before the contracts and agreements are signed…if this is not a part that is already included in the contract and agreements. The takeaway message is, to do it right from the beginning. Assess, evaluate, communicate and formalize the stuff in advance. And make sure the contracts and agreements, including responsibility models, are understood by each part (CSC and CSP).


Too often, and in all too many cases and organizations, I still see that cloud services are purchased without any form of contemplation around the risks involved. There is no assessment done, of either the service provider or service. This is something that the customer is accountable for. Do not be this form of organization. Do your due diligence on the service and supplier. You can thank me later.

The process as such when it comes to how procurements and contracts are managed usually lacks control points where security teams and experts are engaged to investigate the security posture of the CSP’s organization and the cloud service. When this exercise is to be conducted the CSP and CSC need to cooperate. Security teams from both parties need to participate.

The CSC needs to ask the right questions and conduct the exercise in such a way so that adequate information can be gained from the CSP. And if there are several CSPs that are evaluated at this point the CSC needs to ensure the information gathered is done in a way and format that makes it possible to be compared in an objective form and according to a benchmark (like for example a security framework).

The CSC needs to be the gatekeeper of its own realm. They are accountable for what is going in and out. Help is required from the CSP to support the CSC to understand and get access to the information requested so that an intelligent and adequate decision can be made around which service and CSP to make the investments in.

It is not rocket science. It is not something that needs to be complex. The key here is to make it with the help of a methodical model and process. Compare each service and service provider towards and with the help of the same tool (read: framework). This will make the communication, comparison, benchmarking, and decision process more effective. It will also reduce biased decisions and increase objective perspectives.

Provide the CSP with the questions in advance. Invest in time to explain why security is important for the organization. Explain why certain security requirements are stipulated. Explain what your organization is producing. Explain who your customers are. Explain your value streams. Discuss how and why relationships with your partners are important. Contracts and agreements are great and likewise regarding clear responsibilities and roles but at the end of the day, the relationship needs to work between the parties. Relationship management and people skills are essential to make sure strong and long-lasting partnerships are created. It does not have something to do explicitly with cloud services but in these situations, I think relationship management becomes even more important. Insight and control are reduced when it comes to cloud services. Create those relationships built on trust.


Do your due diligence. Make sure to evaluate those cloud service providers you invest in before the contracts and agreements are signed. You and your organization are accountable for the security. Accountability for security cannot be outsourced.

Make sure to involve security experts and all relevant stakeholders in your organization early on in the procurement process when new cloud services are investigated. Security is not something that is “fixed” or done when the stuff is purchased. It is too late to do the “security stuff” in this phase.

Make sure to have your organization’s security requirements well documented and crafted. Invest in time, during the procurement process, to explain those requirements to the cloud service provider.

For your information

If found this article interesting and want to read more about the subject, Cloud security governance, check this one out: Cloud Security Governance – The Process.

Henrik Parkkinen