Who Owns Compliance When You Leave Microsoft’s Umbrella?

May 20, 2026

Reading Time: 6 minutes

There is a question most businesses have never thought to ask their IT provider, and it does not appear on any vendor brochure. It is not about price, or features, or uptime. It is this: if something goes wrong with the platform your data sits on, who is actually accountable for proving it was secure in the first place?When the platform is Microsoft 365, cloud compliance has a relatively straightforward answer. Microsoft holds ISO 27001 certification covering OneDrive and its broader cloud infrastructure. An independent auditor has assessed their information security management system, published compliance reports exist, and clients can point any questionnaire to Microsoft’s own documentation. You still carry responsibility for how your organisation uses the platform. But the platform itself arrives with a compliance foundation already in place.When the platform is not Microsoft’s, that foundation may not come with it.

What the shift actually means for cloud compliance

We recently moved from hosting client file data on OneDrive to running Nextcloud on our own AWS infrastructure. It was a deliberate technology decision, driven by specific requirements around backup architecture and the ability to restore individual files rather than entire environments. AWS was the right choice for the storage layer. Nextcloud was the right application for the job.

But the compliance picture changed the moment we made that decision.

AWS provides excellent infrastructure. Their data centres, physical security, core networking, and computing layer are all AWS’s responsibility. What they do not provide is certification for what we build and run on top of that infrastructure. A useful analogy our Security and Compliance Specialist uses — AWS secures the building. We are responsible for the rooms, the doors, the keys, the cameras, and everything that happens inside them.

That means Si Futures is now responsible for the operating system running the Nextcloud instance, the application itself, the security group and firewall configuration, patching across Linux and all Docker containers, user access controls, encryption choices, backup integrity, and logging and monitoring. AWS does not assume any of that. They explicitly state that for EC2 instances, the customer owns the guest operating system, application software, and security configuration.

Building on the previous analogy: running on AWS is not the same as being AWS compliant. AWS gives you the certified building. You still have to prove the rooms are properly secured.

The assumption most businesses make about inherited compliance

Many SMEs, and frankly many MSPs, assume that because a solution is hosted in a reputable cloud environment, the cloud compliance question is largely answered. This is a dangerous misunderstanding. It assumes inherited compliance, and inherited compliance does not work that way.

The same logic applies if you hosted Nextcloud on Azure rather than AWS. Azure is a strong platform, but the application layer, the operating system, and the governance controls remain the operator’s responsibility. The compliance accountability follows the platform, not the underlying cloud provider’s brand.

What needs to be in place

Hardening a self-hosted cloud platform is not one task. It is a set of controls that must be configured, evidenced, and maintained continuously. The main areas include firewall configuration where only the required ports are open, secure baseline configuration with defaults removed and unnecessary services disabled, active patching across the operating system and all application containers, multi-factor authentication and least-privilege access controls, threat detection and response with the ability to detect suspicious activity, and tested backups where restore capability is confirmed, not just assumed.

That last point matters more than it might seem. A backup that has never been tested is not a backup. It is a hope.

Most of these controls are things a well-run MSP is already implementing on every server it builds. The gap is often not the technical execution. It is the documentation and evidence that proves it has been done, and that it continues to be done. When a client sends a vendor security questionnaire, or an auditor asks for evidence of controls, historical configuration notes are not sufficient. The evidence needs to be current, structured, and retrievable.

The questions you should be asking

If your data sits on a platform managed by your IT provider — whether that is a private cloud, an MSP-hosted alternative to Microsoft 365, or any self-hosted service — there are seven questions worth asking:

  1. Who owns compliance for this platform — the software vendor, the cloud host, or you as the MSP?
  2. Is the platform independently certified, or only the underlying cloud provider?
  3. How is admin access controlled and reviewed?
  4. How are patches applied, and what evidence exists?
  5. Are backups restore-tested, not just configured?
  6. What logging and monitoring is in place?
  7. And, in the event of a breach or data loss, what is the defined process and who carries the liability?

Most clients have never asked these questions. Most MSPs have never been asked. That is not a comfortable position for either party to be in.

What we are doing about it

We identified this potential compliance risk when we made the move to Nextcloud, and we are addressing it directly by pulling the Nextcloud deployment into our Cyber Essentials project. That means reviewing the AWS and Nextcloud configuration in detail, identifying gaps, conducting hardening sessions with our Senior Cloud Infrastructure Architect, and building the evidential framework needed to prove the platform is properly controlled.

The immediate path is Cyber Essentials certification for Si Futures as a combined UK and SA organisation. From there, the progression runs through Cyber Essentials Plus, IASME Cyber Assurance, and potentially ISO 27001 alignment, in steps as the programme matures.

The honest truth is that Si Futures already implements most of these controls in practice. Patching, access management, firewall configuration, monitored backups — this is standard operating procedure for every environment we build. The discipline we are adding is the evidence layer: structured, auditable, provable documentation of what is done and when.

Because here is the broader point. Even with Microsoft 365, most organisations take the compliance inheritance on trust. They assume Microsoft does what Microsoft says it does, and do not independently verify their own configuration against current standards. We have seen environments where Microsoft has implemented controls but left specific settings for the administrator to enable, with no prompt that action may be required. Inherited compliance is not always as comprehensive as it appears.

Moving to a platform we own and operate means we must prove the controls are in place. That is a higher bar. It is also a more honest one.

The takeaway for any business evaluating a private cloud or MSP-hosted service is straightforward: cloud compliance follows accountability, not technology. If you move outside Microsoft’s compliance umbrella, the question is not whether your provider uses AWS or Azure or their own infrastructure. The question is who now owns the evidence, the controls, and the risk, and whether they can prove it.

Ask the seven questions. If the answers are clear, documented, and current, you are in good hands.

If you want to understand how Si Futures approaches managed cyber security — and how we evidence the controls that matter — we would welcome a conversation. Get in touch with our team to discuss your compliance requirements.
Sean Rogers is Security and Compliance Specialist at Si Futures.
author avatar
Sean Rogers

Let’s connect