A clean cloud go-live is not assurance: lessons from Bern's M365 audit

A cloud platform can be built to good practice and still be only partly assured. That is the pattern in the Swiss Federal Audit Office's (SFAO) audit of Microsoft 365 (M365) in the Federal Administration ¹². The platform passed on construction. The priority-1 recommendations all concern what happens after go-live: reviewing provider evidence, automating configuration, setting a review rhythm and holding an independent backup. We think this is the typical gap for any organization that moves to a large software-as-a-service (SaaS) platform.

What the SFAO found on 21 October

The SFAO published its audit of M365 on 21 October 2026. The Federal Chancellery's Digital Transformation and ICT Steering Sector (FCh DTI) had rolled the platform out across the Federal Administration by the end of 2025. The Federal Office of Information Technology, Systems and Telecommunication (FOITT) migrated 54,000 workstations over 14 months, and 57 M365 services are approved in the standard service ¹².

The SFAO judged the platform to be implemented in accordance with good practice, with security controls appropriate to its currently restricted use. It also noted that several key enhancements remain outstanding ¹³. The report makes five recommendations. Four carry priority 1 (high) and one carries priority 2 (medium) ².

Three loops that a good build does not close

The report's findings sort into three assurance loops. This grouping is our model, not the SFAO's. Each loop turns a one-time decision into a repeated check.

Configuration: the target state moves

M365 receives new features and security updates continuously, so compliance has to be re-verified, not assumed ¹. The SFAO found that tenant configuration is automated only in part, which does not yet meet a mandatory criterion in the administration's own architecture guideline. It also found that benchmark settings were considered at build time but not all consistently implemented ². The FOITT disagreed with one reading of its guideline, noting that the degree of automation is not defined in it, and accepted the recommendation ².

A second point matters more for other organizations. According to the audit, some updates can be rolled out by Microsoft without a prior entry in the Message Center, which the administration uses as one input to its change process. The SFAO called such residual risks inherent to the system ². Change control is therefore necessary but cannot be the only assurance mechanism. It governs what the customer decides, not everything the provider changes.

Provider evidence: reports nobody owns

Microsoft publishes independent audit reports and other artifacts in its Service Trust Portal. The FOITT analyzes the relevant ones, while the FCh DTI reviews them sporadically but not yet systematically ². The SFAO asks for a defined scope, rhythm and responsible body, and made this the basis of recommendation 1 ². In the shared-responsibility model the customer remains responsible for its data, parts of the application configuration and identity management; the rest, including hardware, lies with the provider ². Evidence that no one reads is not assurance.

Recoverability: the backup that shares a dependency

The administration's architecture guideline requires multi-generation backup in a federal data center and restoration that does not depend on the cloud provider. The audit found this not yet met. During implementation, the administration also found that the management console of its first backup product was hosted in the US, contrary to the guideline's data-location rule, and decided to replace it with a solution hosted in Europe ². The SFAO concluded that, were the connection to M365 lost, no backup would be available in the interim setup, and recommended regular restoration tests ². The FOITT reports that the local backup is now in production ².

What it means for Switzerland

For federal bodies, the audit sets a reference: auditors will ask for evidence of the loops, not only of the build. The SFAO also notes about 30 further M365 tenants in the Federal Administration outside the FOITT and that it did not check their configuration ². The FOITT itself recommends auditing other tenant operators for consistent governance ².

For financial institutions, FINMA reports a significant increase in the outsourcing of IT infrastructure and critical data to the public cloud, with one in five banks or insurers outsourcing significant data there by 2024. It also warns that concentration at individual providers could seriously affect the Swiss financial market ⁴. The audit shows what that dependency looks like in operations: a tenant, a provider that changes it, and a backup that must not share the same dependency.

Outside regulated sectors the same logic applies without a supervisor to prompt it. Our assessment is that the three loops are a simple way to test whether a SaaS platform has been assured or only built.

Questions for leadership

1. For each critical SaaS platform, who owns the configuration loop, and how often do we learn about deviations?
2. Which provider reports do we receive, and who reads them against our own risks?
3. Which provider changes can reach our tenant without passing our change process, and how would we notice?
4. Could we restore critical data if the provider relationship failed, and when did we last prove it?
5. Is our assurance plan written for the platform as it was at go-live or as it is now?