Solution Atlas
SpecialisedUser storyConsultative playbook

Patient data is moving to the cloud and HIPAA mapping is not optional

A healthcare provider is moving clinical applications to Azure. The CIO needs every architecture pattern mapped to the relevant HIPAA controls before sign-off — encryption, access logging, classification of patient health information, and the kind of attestation that holds up under continuous audit.

Trigger
Cloud migration sign-off; HIPAA controls required.
Good outcome
Every clinical application in Azure has a clear line from its design to the HIPAA control it satisfies. The customer can pass a HIPAA audit without an emergency project each year.
Discovery — signals and questions

Signals validating this story

  • ·Clinical applications migrating to Azure
  • ·BAA signed but operational controls partial
  • ·HIPAA controls required for sign-off
  • ·Continuous audit cycle expected
  • ·Customer-managed keys requirement under review

Discovery questions

  1. 1.Which patient data categories are migrating — PHI, demographics, claims, research?

    WhyDifferent categories have different controls.

  2. 2.What's your HIPAA controls baseline today — fully implemented, partial, aspirational?

    WhyBaseline drives gap analysis.

  3. 3.How are encryption keys managed today — Microsoft-managed or customer-managed?

    WhyCustomer-managed keys often required for the regulated tier.

  4. 4.What's your access logging story for PHI?

    WhyAudit-defensible logging is a HIPAA requirement.

  5. 5.Is the audit cycle annual or continuous?

    WhyContinuous audit demands continuous attestation tooling.

  6. 6.Has Legal mapped HIPAA controls to specific Azure services and SKUs?

    WhyIf yes, anchor on it. If no, the engagement starts there.

Baseline architecture → Target architecture
Baseline architecture

BAA signed with Microsoft. HIPAA controls partially implemented. Encryption with Microsoft-managed keys. Access logging fragmented across services. Audit response reactive.

Typical concerns

  • ·PHI access logging incomplete
  • ·Customer-managed keys not in place for regulated tier
  • ·No continuous compliance attestation
  • ·Audit preparation manual
  • ·Sensitivity classification of PHI inconsistent

Capability gaps

  • ·PHI sensitivity labelling
  • ·HIPAA compliance framework baseline
  • ·PIM for clinical admin access
  • ·Customer-managed HSM keys for regulated PHI
  • ·Continuous attestation tooling
Target architecture

Purview Information Protection classifies PHI tenant-wide. Defender for Cloud HIPAA compliance framework baseline live with continuous attestation. Entra ID P2 + PIM for clinical admin access. Managed HSM holds customer-managed keys for the most regulated PHI workloads. Audit-defensible posture demonstrable on demand.

Key capabilities

  • PHI sensitivity classification
  • HIPAA compliance framework baseline
  • PIM for clinical admin access
  • Customer-managed HSM keys
  • Continuous compliance attestation
Architecture decisions

  1. 1.Key custodianship — Managed HSM vs standard Key Vault HSM

    Managed HSM (FIPS 140-3 Level 3)

    Fits whenAuditor demands Level 3; regulated PHI tier.

    Trade-offsSignificantly higher cost per HSM.

    Standard Key Vault HSM (Level 2)

    Fits whenAuditor accepts Level 2.

    Trade-offsMay not satisfy all regulators.

    Default recommendationManaged HSM for the regulated tier; standard Key Vault for non-PHI workloads.

  2. 2.PHI access logging — Sentinel-routed vs Azure Monitor-only

    Sentinel-routed

    Fits whenActive SOC; PHI access alerts need SOC triage.

    Trade-offsSentinel ingest cost.

    Azure Monitor only

    Fits whenNo SOC; logs for audit-only.

    Trade-offsNo real-time response to suspicious access.

    Default recommendationSentinel-routed for production PHI workloads.

  3. 3.Encryption scope — at-rest only vs include in-use (Confidential Computing)

    At-rest + in-transit

    Fits whenStandard HIPAA baseline.

    Trade-offsSome regulators expect in-use too.

    Add Confidential Computing for in-use

    Fits whenMost sensitive PHI workloads; research with patient identifiers.

    Trade-offsVM premium for Confidential Computing.

    Default recommendationAt-rest + in-transit baseline; Confidential Computing for the most sensitive workloads selectively.

Low-risk trial — proof of value

60-day HIPAA baseline rollout

~8 weeks

PHI sensitivity labels live tenant-wide. Defender for Cloud HIPAA framework enabled with continuous attestation. Entra ID P2 + PIM for clinical admin roles. Managed HSM provisioned for one regulated workload. First audit-readiness report produced.

Success criteria

  • PHI classification coverage above 80% on the trial scope
  • HIPAA control coverage measured and gaps identified
  • PIM live for all clinical admin roles
  • Managed HSM key custodianship demonstrated end-to-end for the trial workload

InvestmentPurview IP in M365 E5 or as add-on. Defender for Cloud paid CSPM. Entra P2 for clinical admins (~100 seats typical). Managed HSM ~€3.20/hour. Estimated ~€8–15k/month for trial scope.

Proof metrics

  • ·HIPAA control coverage above 90%
  • ·Audit-readiness report produced on demand
  • ·PHI access alert quality measurable
  • ·Customer-managed key custodianship audit-defensible

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

PHI classification — sensitivity labels are the auditable proof of "we know what is PHI and what is not."

Why for this story

HIPAA compliance framework baseline + continuous attestation. The controls dashboard the audit references.

Why for this story

PIM for clinical admin access; Identity Protection for the most-attacked identity tier.

Why for this story

FIPS 140-3 Level 3 customer-managed keys for the most regulated PHI workloads.

Back to Regulatory mapping