EFK audit: a Microsoft 365 backup independent of Microsoft

On 21 October 2026, the Swiss Federal Audit Office (EFK, or SFAO in English) published its audit of Microsoft 365 in the federal administration and found that the required backup on the administration’s own systems was still being built. Because the backup tool meant for federal data centres had its console hosted in the US, the Federal Office of Information Technology, Systems and Telecommunication (BIT, or FOITT) used Microsoft 365 Backup, Microsoft’s own service, in the interim; the EFK writes that if the connection to Microsoft 365 were lost, no backup would be available. One of its four priority-1 recommendations is a local backup with regular restore tests, which the BIT says in the report is now in production.

This post covers the finding, the rule behind it, the backup console, test frequency, the open-source case and a dated checklist. The full report and the directive are in German only (the EFK publishes an English summary), so translations are ours.

What did the Swiss Federal Audit Office find about the Microsoft 365 backup?

Audit EFK-25121 covered the Federal Chancellery’s Digital Transformation and ICT Steering Sector (BK-DTI) and ran from 23 February to 3 April 2026. The version published with the audited bodies’ statements is dated 28 July 2026, but the report does not cover developments after the audit. Through BK-DTI’s CEBA project, 54,000 BIT-operated workstations moved to Microsoft 365 between October 2024 and December 2025, used for now only for unclassified information.

The verdict is positive: the BIT implemented the platform “in accordance with good practice”, the English summary says, though “several key enhancements remain outstanding”, the backup among them.

Two stages. First, Microsoft 365’s own tools: item versioning and recycle bins that keep deleted items for 30 days, then a further 60. Second, a backup solution that holds a full copy in federal data centres.

The console. That solution’s administration console turned out to be hosted in the US, contrary to the federal directive AR009, so it is to be replaced by “eine neue, in Europa gehostete Lösung” (a new solution hosted in Europe), with Microsoft 365 Backup used in the interim.

The finding. The EFK notes that AR009 requires, among other things, a restore independent of a cloud service provider: “Dies ist aktuell noch nicht der Fall” (this is not yet the case). It calls the decision to wait for a compliant environment “nachvollziehbar” (understandable), but adds: “since no backup would be available any more in the current set-up if the connection to M365 were lost, a local backup must be created as quickly as possible.”

The recommendation. Recommendation 4, priority 1 (high), asks the BIT, with BK-DTI, to “rapidly set up a local backup environment for M365 and carry out regular restore tests”, with no deadline or test frequency. Four of the five recommendations are priority 1, a rating relative to the audited subject, and all five were accepted.

The response. The BIT says the local backup has since been completed and put into production, and that the CEBA project’s backup concept sets restore tests every six months. The report does not assess that statement, made after the audit, which names neither the product nor where its console is hosted.

Nothing in the report says any data was lost or accessed. The issue was dependency, and the BIT acted on it.

Why is a backup inside Microsoft 365 not independent?

Because it keeps the copy where the data already is. Microsoft documents Microsoft 365 Backup as creating backups “within the protected services’ data boundaries”, where the data “never leaves the Microsoft 365 data trust boundary”. The reason given is speed: restoring large volumes “from a remote, air-gapped location” can take “weeks or even months”. Against mass deletion or ransomware, a fast in-platform restore is the right tool, and it kept the BIT’s backups running without a gap.

Microsoft also documents protections inside that boundary, such as append-only storage and a 90-day grace period after offboarding. The limit comes from the same design: the copy still depends on the same tenant, contract, connection and administrator sign-in as the data it protects. The EFK calls the interim set-up “eine Abhängigkeit zu Microsoft als CSP” (a dependency on Microsoft as cloud service provider).

The EFK does not say how a connection might be lost; our own examples are a long outage, a suspended tenant, a contract dispute or a legal measure such as the US sanctions on the ICC.

An in-platform restore and an independent copy do different jobs, which is why the BIT’s design has both stages. Where the primary data sits is a separate question.

What does AR009 require of a Microsoft 365 backup?

AR009 requires a daily backup on the multi-generation principle, held among other places in federal data centres, and a restore that does not depend on the vendor. It is the Federal Chancellery’s architecture directive for Microsoft 365 in federal office automation, binding (a Weisung) within the federal administration; version 1.1 has been in force since 1 March 2026.

Section 2.1, point 3(b) reads: “Eine Wiederherstellung der Daten MUSS unabhängig von cloudbasierten Diensten und Hersteller Unterstützung möglich sein.” In our translation: a restore of the data must be possible independently of cloud-based services and vendor support.

AR009 binds no private organisation, but it states the test for any backup policy in one sentence. The National Cyber Security Centre (NCSC, since 1 January 2024 the Federal Office for Cyber Security, BACS) gave related, non-binding advice in a ransomware warning on 22 May 2023: at least two backup generations, on a medium physically separated from the computer or network after each backup, or WORM storage.

Two tests follow:

• Where are the copies? At least one at a second site you control, in your jurisdiction.
• Can you restore with the provider gone? Without its cloud, its support or its sign-in.

Where does your backup console run?

The less obvious lesson: the copy was meant for federal data centres, but its console in the US was enough to conflict with the directive.

Independence has two layers: where the copies sit, and where the things that control them run (console and scheduler, encryption keys, sign-in identity, the vendor’s support access). A copy in your own data centre is only as independent as the weakest of them. Ask any backup tool or provider:

• Where is the console hosted, and who operates it? Country, legal entity, and whether backups keep running if it is unreachable.
• Where are the keys, and who can use them? Keys held by the data’s provider make the copy dependent on it.
• Which identity signs you in? Check that backups stay reachable when that identity provider or the SaaS tenant behind it is down, and that break-glass accounts work.
• Does a restore need the vendor’s cloud or support? A licence check, cloud API call or support ticket puts the vendor on your recovery path.
• Where does a restore land? Back into the same service, or into something you run.

How often should you test a restore?

As often as the system changes; in our view, monthly is a sensible default for critical systems, since an estate patched monthly changes monthly. The EFK set no frequency, and the CEBA backup concept, the BIT says, sets six months.

A test becomes an independence test when it lands on a target the provider does not run, is timed until users are working, and checks the data against the source. Set an RPO and an RTO per system and measure each test against them. Keep the record (date, scope, duration, result, failures included); what a restore test proves covers the method.

Why open source makes an independent backup simpler

Third-party tools that copy Microsoft 365 data to storage you choose, many in Switzerland, give you a copy outside Microsoft, and that is often the right next step. Check which kind you buy: Microsoft lists partner applications built on its Microsoft 365 Backup Storage platform, which keeps the copy inside the Microsoft 365 data trust boundary. But a copy is only half a recovery: users need a running service to restore into, and with a SaaS suite that service is the vendor’s.

When you run the software yourself, the whole recovery path is yours. The database dump and files are in open formats, any machine you control can be the restore target, and the console and keys can stay inside your perimeter, so AR009 section 2.1, point 3(b) follows from the design. It also makes recovery your job: the dumps, the keys, the second site and the test calendar. That work is what an operator should carry, under contract and on the record. And if the operator goes, the software stays: your own team or another provider can run the same apps from the same data.

The federal administration is itself preparing an open-source workplace for about 3,000 staff, to run beside Microsoft 365 from the end of 2027. You can start smaller: with a sovereign workplace, one app such as files or chat moves first while Microsoft 365 keeps the rest (Microsoft 365 alternative).

What to do, and by when

The dates are our suggested timetable, as of 22 October 2026.

1. By 30 November 2026: map every backup. For each critical system or SaaS, record where the copies sit, where the console runs and who operates it, which identity signs in, where the keys are and where a restore would land; for Microsoft 365, map Exchange Online, OneDrive and SharePoint separately.
2. By 31 December 2026: write the rule into your backup policy. Daily backups on the generation principle, one copy at a second site you control, a restore that works without the provider’s cloud and support (adapted from AR009 section 2.1, point 3(b)), and an RPO and RTO per system.
3. By 31 January 2027: restore your most critical data set outside the provider. Once, end to end, timed and recorded.
4. By 31 March 2027: put restore tests on a calendar. Name an owner for each system and file the records where your auditors can read them.
5. At every renewal: write the exit into the contract. Exports in open formats, the console’s location and notice periods; for EU cloud contracts, check the switching terms before 12 January 2027.
6. By 30 June 2027: move the first workload that must run without the provider to open source you run. Start with files or chat, with an exit plan for what stays.

How Pilae fits

For the open-source and source-available apps Pilae operates, on your premises or on dedicated machines in Pilae Cloud in Switzerland and the EU, the principle behind the EFK’s finding is how we work.

• Copies away from the machine, in the country you choose. Every app is backed up daily (database, files and configuration), encrypted on your machine before it leaves, under keys that stay with you, and stored offsite in the country named in your contract. On premises, the copies can go to storage you own at a second location you pick.
• A console in your region, or inside your perimeter. The control plane runs in the region named in your contract and receives health signals and deployment status, never application data. Staff sign in through your own identity provider; with Keycloak, identity stays in your deployment. In an air-gapped deployment the console runs inside your perimeter and nothing depends on Pilae Cloud.
• Restore tests every month, on the record. On the Enterprise plan, under managed operations, an engineer restores your apps into an isolated environment every month and checks they answer with their data intact; date, scope and result are recorded in the console, and RPO and RTO are stated per app in your contract.
• Open formats and a way out. The apps are open source or source-available, and every contract includes a written exit plan: your data, configuration and runbooks back in open formats, so your own team or another operator can take over the same apps without rebuilding them. For a SaaS suite you keep, an exit plan adds tested, scheduled open-format exports, stored in your chosen country.

If you want to know whether your backups would survive losing a provider, talk to an engineer: we go through the systems you run, where each copy and console sits, and how long you can do without each one.

This post is general information, not legal advice. For the official texts, read the EFK’s report EFK-25121 and the Federal Chancellery’s directive AR009.