What exactly is the cloud?

The most plain and simple definition: someone else’s server.

Forget the marketing images of clouds. The cloud, whether you use SaaS (Software as a Service, such as Microsoft 365) or IaaS (Infrastructure as a Service, such as AWS or Azure), comes down to one thing: your data and applications are stored on hardware owned and managed by an external party.

This is the essence that determines the risk:

1. Physical Access: The cloud provider (Azure, Amazon, Google, etc.) always has physical access to the servers and data centers where your data is stored. In many cases, you do not even have visibility into what happens to the physical device, and the physical device is shared with other customers.

2. Logical Access (Management): The provider’s staff has logical access (administrator rights) to the infrastructure, the network, and the hypervisor (the software that runs your virtual machine).

3. The Critical Implication: Without appropriate and enforceable measures, the provider, or a malicious employee of the provider, can do anything with your system and data. In principle, they can see and change everything.

In short: You trade the risk of an unsecured server in your own broom closet for the risk of a server over which you have no direct control. You must manage this.

Let us compare the cloud to renting a home. You rent a beautiful house from the landlord. The landlord is responsible for the foundation, the walls, and the roof. The landlord has the master key to the property (physical and logical access). Inside, you arrange your own life: you hang your art, store your valuables, and invite your guests (your data, applications, and users). The biggest fear is that the landlord – who has the master key – can simply walk in without knocking, look through your belongings, or fail to secure the front door properly. You want to trust the landlord, but you also want to enforce contractually that you may place your own locks and that the landlord does not simply walk in. That is exactly the relationship you have with your cloud provider.

The relevance of the cloud for ISO 27001

ISO 27001 is a risk management system. As soon as you outsource data or processes to a cloud provider, you must include that provider and their risks in your overall security chain.

This is why the cloud is so relevant to your information security:

1. Your Liability Remains: The General Data Protection Regulation (AVG/GDPR) states that you remain responsible at all times for protecting the data of your customers and employees. In addition, you will likely enter into various other agreements in which your liability is also emphasized. You can outsource the responsibility for execution, but the liability remains with you as an SME owner.

2. Continuity Risk: What happens to your business if the cloud provider goes bankrupt (Exit Planning, see other blogs) or is down for a week? You must demonstrate that you have A Plan B.

3. The proof is external: You must prove to the auditor that the cloud provider takes security measures. You cannot simply walk into their data center. You therefore have to enforce security through contracts and verify it through certificates (such as SOC 2 or ISO 27001), your own audits, or alternative methods.

Our sober view: The cloud is a fantastic solution for scalability and continuity. But it must not be a black box. The ISMS forces you to take the management and security of those remote servers just as seriously as the server under your own desk.

Conclusion: Manage cloud risk instead of blindly trusting

The cloud is a necessity, but it is not an automatic guarantee of security. It is an extension of your own IT. Your ISMS must show that you recognize the control power of the cloud provider and have taken effective countermeasures through contract, monitoring, and control.

The cloud security policy: your rules for the ‘rented server’

Earlier we broke through the cloud illusion: the cloud is a rented server, and the landlord (the provider) has the master key. The rental-home metaphor makes it clear that you remain the owner of the valuable assets, and therefore you must set the rules.

The Cloud Security Policy is that rulebook. This document is the essential link between the abstract ISO 27001 requirements and the day-to-day reality of working with external services. Although the standard does not literally require a document with this name, it is extremely useful for making matters clear and demonstrable.

And yes, we understand that Microsoft is not going to read your cloud security policy document, let alone sign it. If the policy cannot be discussed with, or enforced on, the supplier, it is important to look internally at the extent to which the supplier complies with the policy and whether that is acceptable.

What should be in your cloud security policy?

Your policy must set out the essential agreements needed to manage the risk of the 'landlord'. These are the four critical topics that form the basis of your ISMS and that every auditor wants to see:

The scope: who is responsible for what (shared responsibility)

This is an important part. You must define where your responsibility ends and the provider’s begins (the Shared Responsibility Model).

• Responsibility Matrix: A clear table or paragraph stating:

  • Provider: Responsible for the physical security of the data center, power, cooling, and the base software (for IaaS).

  • You (the SME): Responsible for the data, access rights (passwords, MFA), encryption, and patching of the applications.

• The Rule: State that for every new cloud service, this scope must be clear in advance and recorded.

There are also good models, such as the image below, which you can use as guidance:

Note that this can differ per supplier (and cloud service). See also the difference between, for example, IaaS and SaaS in the figure above.

The data: where does our (sensitive) information go?

Not every cloud service offers the same level of security. Your policy must therefore provide a clear, risk-based framework for the use of the cloud based on the sensitivity of the data.

• Data Classification Rule: Determine that highly confidential data (such as intellectual property, strategic customer data, or personal data) may only be stored with providers that are at least certified. This certification is the hard, demonstrable assurance you need.

• Enforce Encryption: State that unprocessed, highly critical data may only be stored in the cloud after strong encryption (encryption on your side) has been applied. This neutralizes the landlord’s control over the content of the data.

• Acceptable Use (Shadow IT): Define which cloud use is allowed. Explicitly state that employees may not use unofficial, unsecured cloud services (also known as 'Shadow IT') to process any work data, in order to prevent uncontrolled IT (and therefore the risk of data leaks).

Access & identity in cloud services: the locks on the door

This concerns logical access to the cloud environment. This is a major risk factor.

• MFA is Mandatory: Define that for all cloud services containing sensitive data, Multi-Factor Authentication (MFA) is required, including for administrators. This is an absolute must for the ISO auditor (an unwritten rule).

• Least Privilege: State that employees only receive access to the cloud environments and data that they strictly need for their work. As soon as the role changes, access must be reviewed immediately.

• Offboarding Procedure: Link the policy to the HR procedure: when an employee leaves, access to all cloud services must be demonstrably and immediately revoked. Helpful technical implementations such as SSO (Single Sign-On) can support this.

• Visibility into administrative access: also define how you maintain visibility into the use, and potential misuse, of your data and systems by administrators of the cloud services. After all, these are people working at an external organization, sometimes thousands of kilometers away from you. That organization may also not have its internal controls in order.

Control over the landlord: logging and audit rights

This point focuses on controlling the administrators of the cloud provider, who may sometimes work thousands of kilometers away from you and can access everything.

• Visibility into Use (Logging): State the requirement that the cloud provider supplies demonstrable logging of every time their administrators gain logical or physical access to your environment. This log must be accessible to you for checking misuse.

• Audit Right Requirement: Define that contracts with critical providers must always include the right to audit. You or an independent party must be able to verify that the provider complies with the agreements.

• Data Breach Procedure: Define how you require the provider to notify you immediately if they detect potential misuse by their staff.

Exit strategy and termination

A sober policy anticipates the day the service stops or goes bankrupt.

• Mandatory Exit Plan: State the requirement that for critical cloud services (on which your primary process depends) there must be an up-to-date Exit Plan. This also helps ensure you are not left with excessive damage or transition costs.

• Data Ownership: Define that the organization (you) always remains the owner of the data, even after termination of the contract, and that the provider must destroy the data in an agreed manner and within an agreed period.

A living document, not a paper tiger

The Cloud Security Policy is not a document meant to impress; it is your internal navigation map for secure cloud operations. Something that today is becoming increasingly important. It ensures that everyone knows where the boundaries are, what the minimum security requirements are, and who checks the 'locks'. By keeping the policy short and workable, you avoid the 'paper tiger' we discussed earlier.

This policy forms the basis. The next step is to make sure the provider also follows the rules: enforcing them through the contract.