Cloud compliance: how to tell a compliant cloud from a claim

What cloud compliance actually covers

Most organisations looking for cloud compliance are looking for a single property that settles everything. There is no such property. Compliance comes out of three layers that can fail independently of one another: the contract between you and the provider, the technical architecture of the platform, and the operating model people work to every day.

On the contract layer the subject is processing on your behalf. You remain responsible for the data, the provider processes it on your instruction and within your frame. That includes instruction rights, a named list of the sub-processors in use, rules for deletion and return, and what happens during an incident. A provider that cannot name its sub-processors in full also cannot explain who works on your data.

On the architecture layer the subject is data storage, encryption, network segmentation and access control. These things belong inside the platform, not in an add-on fitted afterwards. An organisation that plans governance and security only after the build puts them into an environment that is already running, and that is considerably more expensive.

On the operating layer sits the question that most often goes unanswered in audits: who holds administrative access to the critical systems, service providers included, and is that documented? While that question is open, neither the location nor the finest certificate helps.

Three questions behind every GDPR cloud discussion

However a cloud looks technically, the same three questions land on the table in practice. Knowing them helps steer a provider conversation somewhere useful. The wording below follows the EU GDPR, because that is the regime most buyers in this market are working to. Organisations in the United Kingdom work to UK GDPR alongside the Data Protection Act 2018; the criteria in this text are technical and organisational, so they hold either way, but which regime applies to you is a question for your legal function.

Who processes on whose behalf?

The data processing agreement is the frame in which a cloud provider may act at all. What matters is less whether a contract exists and more whether it describes what actually happens. If a provider delivers support out of several time zones, that belongs in it. If backups sit in a second location, that belongs in it. Contracts that are vaguer than the operations they are meant to describe get noticed in the audit at the latest.

Does data leave the legal space, and who can reach it?

A third country transfer does not begin only when data is physically copied. Administrative remote access from another legal space is access too. This is exactly where the debate around the Cloud Act starts: it is not only about where the disk sits, but about which law the company operating the systems is subject to. In practice that means establishing which countries administration happens from, and how that access is logged.

What happens when something goes wrong?

Notification duties, restart and evidence are not subjects for the emergency, they are subjects for the build. If nobody can say how long a restart takes and where the configuration for it comes from, the recovery plan exists on paper only. A reproducible restart from documented configuration is therefore a compliance characteristic, not just a technical one.

Why data residency alone is not enough

The sentence heard most often in this market is: the servers are in Europe, so we are fine. That is half the truth. Data residency is a necessary condition for many requirements, but it is not a sufficient one. Control comes out of the operating model, not out of the postcode of the data centre.

Two expensive fallacies follow from that. The first: it is in our own data centre, so we are sovereign. A server in your own building is not control as long as it is undocumented who holds administrative access, as long as the platform cannot be reproduced from its documentation, and as long as nobody knows what happens to operations when the team is unavailable. Plenty of on premise estates meet the residency requirement perfectly and the evidence requirement not at all.

The second fallacy: it sits with a service provider, so we are not sovereign. That does not hold either. An operating partner that logs access, keeps configuration as code and tests the restart regularly delivers more traceability than an in-house setup in which three people hold rights that grew historically. The question is not whether somebody else is involved, but whether that involvement is governed and traceable.

In practice this can be checked against four characteristics that have nothing to do with location: traceable access, documented configuration, a reproducible restart, and the ability to change operating partner. An organisation that can evidence all four has solid ground. One that can only name a location has a marketing sentence.

Free whitepaper · 7 pages

Your Own Cloud in Your Own Datacenter

By Andreas Hankel, CTO onehundred. Download in exchange for your e-mail address, no sales call.

Get the whitepaper

Seven criteria for assessing a cloud provider

The points below can be asked in a first conversation. They are deliberately phrased so that an evasive answer stands out.

• Certificates and audit reports. ISO 27001 evidences a management system for information security. A C5 attestation, the criteria catalogue of the German Federal Office for Information Security (BSI) for cloud services, describes audited criteria and is regularly asked for in German tenders. Both point to process maturity. Ask what the certificate actually refers to: the data centre, the provider, or a single service. A provider that uses certified data centres is not thereby certified itself. Anyone who blurs that distinction will blur others.
• Administrative access. Who can log in to which systems, from which country, and how is that logged? Is there four-eyes approval for critical changes?
• Sub-processors. A complete, current list with purpose and location. Changes should be announced, not discovered afterwards.
• Encryption and key management. Encryption in transit goes without saying. The interesting part is encryption at rest, and the question of who holds the keys and how they are rotated.
• Restart and backup. How long does a full restart take, when was it last tested, and do backups sit in a way that survives an attack on the production environment?
• Exit capability. In what format do you get your data and your configuration back, and how long does that take? A provider whose platform only it can operate is a risk regardless of its location. With us, configuration lives in Git repositories that belong to the customer, and the stack is chosen so that any competent provider can take it over.
• Operating model. Is there on-call cover around the clock, monitoring and alerting, a governed patch and escalation process? Compliance without operating discipline lasts exactly until the first incident.

None of these criteria is exotic. What stands out is how often they are missing from tenders while the server location gets asked three times.

On premise, private cloud or public cloud compared

The decision between the three models is rarely right for a whole organisation. It is best taken per workload. The overview below compares qualitatively, without prices and without a blanket verdict.

What the table mainly shows is this: the familiar on premise versus cloud framing is too narrow, because it leaves out the middle column. Private cloud services take the operating model of the public cloud and the control characteristics of your own data centre. That is why so many estates end up hybrid: predictable, data-heavy workloads in an owned or rented environment, strongly fluctuating workloads or ones bound tightly to managed services left where they are.

Colocation and your own data centre: what changes

Between your own server room and a rented environment sits colocation: you place your own hardware in a professionally operated data centre that belongs to somebody else. Power, cooling, physical security and connectivity come from the operator, the systems stay yours.

For the compliance question colocation changes little at first, because responsibility for data and access stays with you. In practice it changes a great deal. Physical security and the availability of the floor space are contractually assured and audited, which is far easier to evidence than an air conditioning unit in your own basement. Hardware also stays an asset of the organisation rather than becoming an operating cost line inside somebody else’s ecosystem.

When each location makes sense

• Your own data centre, where it already exists and should be modernised rather than abolished, or where latency to production machinery matters.
• Colocation, where you want to keep control of the hardware but do not want to be responsible for floor space and building services.
• An operator’s data centre, where you do not want to procure hardware at all. A data centre of your own is not a prerequisite for a private cloud. In that case we select a German, ISO 27001 certified data centre and run the platform there. Data does not leave those data centres.

In all three cases the decisive layer is the same: the platform above. Without automation, self-service and documented configuration, even the best data centre is just a room with servers in it.

Cloud repatriation: when bringing workloads back pays

Cloud repatriation is not a reversal of the trend, it is a correction of individual decisions. Going to the cloud was the right call in most cases, and for many workloads it stays the right call. The correction concerns the cases where the numbers no longer add up, or where regulatory requirements arrived later.

When a move back pays

• Load is predictable and grows steadily rather than in jumps. Elasticity that is never used does not pay for itself.
• The workload is data heavy, and a noticeable share of the bill goes on traffic leaving the platform and moving between zones.
• The data has to stay inside a given legal space anyway, and every exception costs approval effort.
• There is an evidence duty towards customers or a regulator that is awkward to satisfy under shared responsibility.

When it does not

• The workload sits deep inside managed services whose rebuild costs more than the migration saves.
• Load fluctuates strongly and unpredictably.
• There is nobody to run the platform afterwards. A move back without an operating model only shifts the problem.

The most common mistake is not the direction, it is the missing platform layer. An organisation that repatriates and lands back in ticket-driven provisioning loses self-service and elasticity, and with them exactly what the cloud was chosen for in the first place. The business side is used to minutes and gets days. That loss of acceptance appears in no cost model and tips projects anyway. A realistic calculation therefore includes the operating effort of your own platform, not only hardware and floor space.

Hybrid cloud security is operating discipline, not a product

Compliance and security overlap, but they are not the same thing. A setup can be contractually clean and technically exposed. In a hybrid estate that gap widens, because two environments have to be kept at the same level and the connection between them becomes a target of its own. The measures that actually work in operations are unspectacular, which is precisely why they get postponed.

• Minimise rights and review them regularly. Administrator rights that grew historically are the most common finding in existing environments.
• Patch management on a fixed rhythm. Security updates need maintenance windows, at night and on public holidays too. Anyone who has to schedule them by exception eventually stops scheduling them.
• Network segmentation. A compromised service should not open the path to every other one, and that includes the link between your own environment and the public cloud.
• Test backups, do not just take them. A backup whose restore has never been tested is an assumption.
• Monitoring and alerting with a real response behind it. You should learn about an incident from your operations report, not from your users.

The long version of these points is in our article Cloud security best practices: how companies protect their data. From the compliance perspective one thing matters above all: every measure named here produces evidence, provided it happens regularly and is documented. Evidence arises in operations and cannot be manufactured shortly before an audit.

Cloud to on premise migration: from inventory to target architecture

A project that starts with choosing a provider starts too late. The order that works in practice looks different.

1. Inventory and classify workloads. Which data, which requirements, which load, which dependencies? Five large workloads are enough to begin with, the rest follow the pattern.
2. Document access. Who can reach which systems administratively today, service providers included? This list is uncomfortable and it is the single most important step.
3. Decide the target per workload. Public cloud, owned or rented environment, hybrid. With costs and risks, not as a matter of principle.
4. Platform before migration. First the layer with automation, self-service and configuration as code, then the workloads on top. The other way round produces another estate nobody can reproduce.
5. Migrate with a fallback path. Service by service instead of a cut-over date, with a go decision at every transition that is allowed to be a no.
6. Operations and evidence. Monitoring, patch and escalation management, a tested restart. From here on the evidence an audit needs starts to accumulate.

We work in five phases with a go or no-go decision at every transition: analysis, target picture, test environment, migration, operations. The point of that structure is not the structure, it is the way out: after each phase you can stop without anything productive having been changed.