Healthcare: continuous visibility of a Data & AI platform's security posture with Microsoft Defender for Cloud

Over two years a hospital group built a Data & AI platform: a lakehouse in Microsoft Fabric, a Databricks workspace per research domain and a handful of agents in Microsoft Foundry. The design was sound on paper and had passed a security review. What nobody could answer was whether it still looked that way today. The annual healthcare compliance audit asked exactly that question, and the answer was a folder of screenshots from four portals, taken the week before.

The problem was not that nothing was switched on. The problem was that switched on and demonstrably switched on are two different things, and the distance between them grew with every sprint.

Microsoft Defender for Cloud sits across every subscription in the platform and delivers two things that need to be kept apart. Posture, or CSPM: the configuration of storage, keys, network and identity, measured against the Microsoft cloud security benchmark and against a rule set aligned to the healthcare standards. And workload protection, the plans that actively watch storage accounts, databases, containers and the AI services underneath.

The result does not land in a dashboard but in the work. Through a tagging agreement on the resource group, every recommendation gets an owner: the platform team for the foundation, the domain team for its own workspace. The secure score is visible per subscription, so a domain team sees its own number and not somebody else's. Alerts from Defender for Cloud flow on to Defender XDR and from there into the existing incident queue, so no second place appears where alerts sit waiting for someone.

Purview keeps doing what it did: classifying and labelling. The two meet at one point, and that point is why this works. A storage account holding patient data and one holding anonymised research data get the same recommendation from Defender for Cloud, but not the same urgency.

The auditor's question is not "which controls did you implement" but "how do you know they are still there". That is a measurement question, and you can only answer it with something that measures continuously and returns a number you can follow over time. A periodic manual review answers it on one day a year.

Defender for Cloud is also the only place where the posture of Fabric, Databricks and the Azure services underneath is expressed in the same language. Three separate product tools would produce three scores that cannot be added up, and then nobody can answer the board's question either.

Building a script set on top of Azure Policy was seriously considered: it is cheaper and the team could do it. It fell away because the rules then have to be maintained in-house, and the healthcare standards move. Azure Policy on its own also covers configuration but not workload protection: it sees that a storage account is publicly reachable, not that a suspicious file has landed in it.

An external multi-cloud CSPM vendor gave a broader view, but this group runs everything on Azure and the link to Defender XDR would have to be rebuilt. The extra breadth did not pay for itself.

Turning everything on and ignoring the number is the third variant, and in practice it happens more often than anyone admits. A score nobody reads is a monthly invoice without a control.

• The plans are priced per resource, so switching everything on everywhere is a decision and not a default. That split belongs in the design, together with the answer to where which data lives.
• A recommendation without an owner gets ignored. The tagging agreement is therefore not administration but the core of the design; without it this is a dashboard.
• The first score is low and that is uncomfortable. It is manageable if you record the baseline and steer on the movement rather than the absolute number.
• Defender for Cloud does not know the context of the data. Without the labels from Purview every storage account looks equally important.

Microsoft Defender for Cloud (CSPM, plans for storage, databases, containers and AI workloads), Microsoft Defender XDR, Microsoft Purview, Microsoft Entra ID, Microsoft Fabric, Azure Databricks.

• Record the baseline before you fix anything. Without a starting point there is no movement to demonstrate, and the movement is exactly what convinces an auditor.
• Tie every recommendation to a team through a tag, not to a person. People change roles, resource groups do not.
• Enable the plans per data type rather than per subscription. A research sandbox with synthetic data needs a different regime from the layer holding patient data.
• Let the alerts land in the existing incident queue. A second queue is a second place nobody looks.

The biggest gain did not come from the recommendations themselves but from the conversation they forced. Three resource groups turned out to have no owner at all; they had been created by a colleague who had since left and had been outside every overview ever since. The first quarter was therefore mostly about ownership and only after that about configuration.

What disappointed was the lead time of the plans. The expectation was that switching on and measuring would be the same moment; in practice it took days before the picture was complete, and during those days the score looked artificially good. Since then a new subscription only counts as measured once it has been switched on for a full week.