Episode Details

Here’s the shocking truth: moving to Microsoft 365 in KRITIS or government isn’t a technical problem — it’s an organizational survival challenge. One overlooked misstep with identity or governance doesn’t just slow you down; it can undermine your compliance with BSI before you even get started. This isn’t theory — it’s happened in real projects. So the bigger question is: how do you actually avoid those traps and deliver a secure, compliant rollout?Why Most M365 Projects Fail in the First 90 DaysWhat if I told you that most regulated Microsoft 365 deployments are already non-compliant before the first user even signs in? That sounds exaggerated, but in practice it plays out more often than you’d expect. The problem doesn’t come from some obscure technical corner case. It usually starts with how organizations underestimate the complexity of Baseline Security and BSI requirements when shifting to the cloud. The rollout looks smooth from the outside, licenses get assigned, and services light up quickly. But the foundation beneath those services rarely lines up with what auditors expect to see from day one.A lot of IT leaders come into this move with a sense of reassurance. The logic sounds straightforward: Microsoft runs a global cloud, it has countless compliance certifications, so surely most of the hard lifting around regulation has already been taken care of. And yes, Microsoft has done serious work to get its platform approved for different international markets. But the dangerous assumption is thinking certification of the platform equals compliance of the customer. It’s a classic gap in shared responsibility. Microsoft provides features and infrastructure compliant with different standards. Whether you enable them correctly, set them up according to local law, and build governance on top of them—that remains entirely on your shoulders.You can imagine where this leads. A public authority, pressed by political timelines, pushes through a Microsoft 365 rollout in just a couple of months. The rollout itself is celebrated as a success—mail migrations done, Teams adopted, SharePoint online for document workflows. From a user perspective, the transformation looks complete. Then the first real audit hits a few months later. Auditors request detailed identity documentation, want to see control records for privileged accounts, and check whether specific BSI mandates have been applied. What they get back are screenshots taken after the fact, gaps in audit trails, and makeshift explanations on where data residency is supposed to be guaranteed. The verdict is not pretty: non-compliant, even though the technical services were working fine.That brings us to the uncomfortable truth. The issue isn’t that Microsoft lacks features. The toolbox is there. The issue is that most organizations plan their rollout like a normal IT project—license, configure, deploy—while BSI standards require a completely different mindset. It’s less about lighting up services and more about proving at every step who has access, how logs are handled, and how responsibilities are documented. Without that proof, the rollout may appear successful on the surface, but from a compliance perspective, it’s already failed.Think of it like securing your house with brand-new smart locks on every door, cameras on every entrance, motion sensors in the hallway—and then forgetting to close the bathroom window. That single oversight is the first thing an auditor notices, not the twenty controls you implemented correctly. Compliance works the same way. An organization can map out fifty technical policies, but if just one critical gap in identity management or operational documentation exists, the audit outcome is already negative.So what are the traps that BSI auditors spot immediately? They don’t need weeks of forensic analysis to see non-compliance. In fact, the first gap shows up right at the start. Identity architecture is often inconsistent, relying on outdated on-premises di