Microsoft is not a cloud service

The supplier directory holds one line: Microsoft. Next to it a contract, a contact, maybe a criticality rating. The cloud question is answered, or so it seems.

It is not, for a reason that has nothing to do with diligence: Microsoft is not a cloud service, it is a provider. Exchange Online, Teams and Entra ID are three services. They have different data locations, different owners inside the organisation, different exit routes and, when it matters, different subcontractors.

Why the building block forces this

BSI building block OPS.2.2 Cloud Usage requires a service definition, clarified areas of responsibility, evidence of information security and an orderly termination for every cloud service. Without a registry of services this cannot be maintained, because the reference object is simply missing. You cannot attach a service definition to a provider line, because it would have to hold for three services at once.

A cloud service therefore carries a service model and a deployment model, availability and service hours, plus two separate owners: business and IT. That separation is not a formality. Whoever decides on usage is rarely the same person who runs the connection.

The data location is not the company address

Recorded are the data centre country and, separately, all further processing countries. The two regularly diverge, for instance when operations run in Frankfurt but second-level support does not sit in the EU. Added to that are the subcontractors per service, because Article 28 GDPR ties information and objection rights to them.

The part nobody cares about at purchase

The exit section describes how you leave the service again: exit arrangement, notice period, portability and data formats. Beside it sits a field that appears in hardly any registry: exit rehearsed on.

Between a described and a rehearsed migration lies the question of whether the export is complete and whether the data is usable at all outside the service. You do not learn that from reading the contract, but from running it once. An empty field is an honest answer here; a filled-in exit arrangement without a date, by contrast, is a statement of intent that carries nothing when it counts.

What the registry is not

It replaces no existing directory. Whatever is already maintained in the supplier directory, in contract management or with the processor is a reference here. The service points to the provider, to the contract, to the processor and to the affected record of processing.

Nor is it a technical assessment. Misconfigurations in cloud accounts are found by cloud security posture management, which looks inside the accounts for that purpose. The registry answers the organisational half: which service, with which data, in which country, with which subcontractors and by which route back out.

And the requirements themselves?

They do not live in the registry. Every cloud service is a target object and therefore appears in the target object selection of the implementation plan, alongside processes, IT systems and software. From the detail view the building block requirements can be transferred there in one click, to where implementation status, dates and owners are maintained anyway. A second place for the same thing would drift apart, reliably so.

More on the cloud services registry module page.