Get in Touch
Close

Your Cloud Story,
Engineered for Success

Contacts

US Office: Obsium, 6200,
Stoneridge Mall Rd, Pleasanton CA 94588 USA

Kochi Office: GB4, Ground Floor, Athulya, Infopark Phase 1, Infopark Campus Kakkanad, Kochi 682042

+91 9895941969

hello@obsium.io

Healthcare cloud managed services: what to look for and what to avoid

Healthcare cloud managed services: what to look for and what to avoid

Healthcare cloud managed services: what to look for and what to avoid

In early 2025, Oracle Health disclosed that hackers accessed patient data from a legacy Cerner server that had not been migrated to Oracle Cloud. Up to 80 hospitals were affected.

Oracle’s response was slow, communication was limited, and healthcare CIOs were left figuring out their own breach notification timelines (Becker’s Hospital Review: Oracle Health Data Breach).

That breach is a good summary of the managed services problem in healthcare. The vendor had the data. The vendor had the legacy infrastructure. The vendor did not catch the unauthorized access for weeks. And the hospitals were still on the hook for notifying patients.

The healthcare cloud computing market hit $63 billion in 2025 (Precedence Research: Healthcare Cloud Computing Market).

Gartner projects that 99% of cloud security failures through 2026 will be the customer’s fault, not the provider’s (Fidelis Security: Cloud Misconfigurations Causing Data Breaches).

That means choosing the right managed services provider is not about finding someone to hand your infrastructure to. It is about finding someone who will actually configure, monitor, and maintain it the way HIPAA requires.

What healthcare cloud managed services actually cover

“Managed cloud” means different things depending on who is selling it. At the generic end, it is someone else managing your AWS account. At the healthcare-specific end, it includes compliance automation, PHI data handling, audit trail management, and incident response.

A healthcare cloud managed services engagement should cover:

  • Infrastructure management. Provisioning, patching, scaling, and monitoring your cloud environment. This is the baseline.
  • HIPAA compliance management. Continuous compliance checks, policy enforcement, audit evidence generation, and remediation when configurations drift.
  • Security operations. Threat detection, vulnerability scanning, intrusion monitoring, incident response. Not a quarterly report. Active, ongoing monitoring.
  • Backup and disaster recovery. Automated backups for PHI data stores, tested restore procedures, defined RTO/RPO targets.
  • Observability and monitoring. Metrics, logs, traces, dashboards, and alerting. Knowing what is happening in your environment before your users tell you.
  • Cost management. Right-sizing, reserved instance optimization, tagging governance, budget alerts.

If a provider covers infrastructure but not compliance, they are a generic managed services provider with a healthcare logo on the website. That is a problem, because the compliance piece is where healthcare organizations fail.

What HIPAA requires from your cloud provider

When you store or process ePHI in the cloud, your cloud provider is a business associate under HIPAA. That means two things: they must sign a Business Associate Agreement (BAA), and they are directly liable for compliance with applicable HIPAA rules (HHS: Guidance on HIPAA & Cloud Computing).

A BAA is the legal minimum. It is not the operational minimum. Here is what you should actually evaluate:

What to checkWhy it mattersRed flag if missing
Signed BAALegal requirement for any cloud provider handling ePHIWalk away. No BAA means no HIPAA compliance, period.
HITRUST certification (i1 or r2)Covers HIPAA, HITECH, and NIST requirements in one assessment. The gold standard for healthcare cloud.Not disqualifying, but means you need to do more due diligence on their security controls.
SOC 2 Type 2 reportIndependent audit of security controls over a 6-12 month period. Shows controls work consistently over time, not on a single audit day.Major red flag. SOC 2 Type 2 is table stakes for any serious managed services provider.
Encryption at rest and in transitHIPAA requires it as of the 2025 proposed rule update. Was previously “addressable.”Walk away.
Incident response SLAHow fast will they respond to a security incident? 24 hours? 4 hours? 15 minutes?Vague SLAs like “as soon as reasonably possible” mean nothing in a breach.
Breach notification timelineHIPAA requires notification within 60 days. Good providers commit to faster.If they cannot define a specific timeline, their incident response process is immature.
Subprocessor disclosureWho else touches your data? Your provider’s subcontractors need BAAs too.If they cannot list their subprocessors, they may not know who has access to your PHI.

“Certifications such as HITRUST, SOC 2 Type 2, ISO 27001, FedRAMP, and CSA STAR simplify vendor evaluations, reduce compliance risks, and streamline procurement processes.” — Censinet (Key Certifications for Healthcare Cloud Vendors in 2025)

In early 2025, HHS proposed the most significant HIPAA Security Rule update in over a decade. The proposed rule would make encryption and MFA mandatory (removing the “addressable” loophole), require annual verification of BAA compliance, and create new obligations around data backup, network segmentation, and real-time monitoring (HealthTech Magazine: Providers Evaluate Security as Updated HIPAA Compliance Looms).

AWS vs Azure vs GCP for healthcare

All three major cloud providers sign BAAs and offer HIPAA-eligible services. The differences are in breadth, integration, and pricing.

AWSAzureGCP
HIPAA-eligible services166+ (largest catalog)90+130+ covered products
BAA processSign through AWS ArtifactIncluded in Online Services Terms automaticallySign through Google Cloud console
Healthcare-specific servicesHealthLake (FHIR), Comprehend Medical (NLP), HealthImaging (DICOM)Azure Health Data Services (FHIR, DICOM), Microsoft Fabric for healthcareCloud Healthcare API (FHIR R5, DICOMweb), Vertex AI for healthcare
Strongest use caseBroadest service catalog, deepest partner ecosystemOrganizations already in Microsoft/Epic ecosystemHealthcare analytics and AI/ML workloads
Pricing positionPremiumMid-rangeMost competitive for compute and storage
FedRAMPYes (GovCloud)Yes (Azure Government)Yes (Assured Workloads)

The provider choice matters less than the configuration. All three clouds can be HIPAA-compliant. All three can also be misconfigured in ways that expose PHI. The difference is how your team (or your managed services provider) configures, monitors, and maintains the environment.

82% of cloud security incidents in healthcare are caused by human error and misconfigurations, not provider flaws (Fidelis Security: Cloud Misconfigurations Causing Data Breaches). The shared responsibility model means the provider secures the infrastructure. You secure everything else:

  • IAM policies and access controls
  • Encryption key management
  • Network configuration and segmentation
  • Application security
  • Data classification and handling
  • Audit logging and retention

What to look for in a healthcare cloud managed services provider

Beyond certifications and BAAs, here is what separates a healthcare-capable provider from a generic one:

They understand the shared responsibility model and own their side of it. A good provider goes beyond handing you a BAA. They configure your environment to meet HIPAA requirements, monitor for drift, and fix misconfigurations before they become findings on an audit.

They have healthcare clients, not a healthcare page on their website. Ask for references. Ask how many healthcare organizations they manage. Ask what compliance frameworks their clients pass. A provider that has helped clients through a HITRUST assessment understands the requirements differently than one that read the documentation.

Their incident response is specific, not vague. You want concrete answers to these questions:

  • What is the response time SLA for a critical security incident?
  • Who gets notified, and through what channel?
  • What is the escalation path?
  • How do they handle forensics and evidence preservation?
  • What is the breach notification process?

They provide observability, not uptime monitoring. Checking whether a server is up is not observability. You need:

  • Metrics on resource utilization, request latency, error rates
  • Centralized logging with search and alerting capabilities
  • Distributed tracing for microservices architectures
  • Dashboards your team can access directly, without going through the provider
  • Alerts on PHI access anomalies and configuration drift

They have an exit plan. Ask what happens when the engagement ends. How do you get your data out? What format? What is the timeline? If the answer is vague or hostile, that tells you something about the relationship.

What to avoid

These patterns show up often enough to be worth calling out directly:

The BAA-only provider. They sign the BAA, point you at the cloud console, and disappear. A BAA is a legal document, not a security control. It does not configure your IAM policies, encrypt your databases, or monitor your audit logs.

The compliance-theater provider. They give you a dashboard with green checkmarks, but cannot explain what the checks actually verify. Compliance is not a dashboard. It is a set of controls that are continuously tested and enforced.

The provider has no healthcare clients. Generic managed services providers sometimes add “healthcare” to their website when they see the market size. Ask for references. Ask about their HITRUST status. Ask what HIPAA means for how they handle your data. If the answers are vague, you are their first healthcare client, and they are learning on your dime.

Two more that are less obvious: vendor-locked providers who build everything on proprietary tooling (if you leave, you start from scratch), and providers who cannot explain their own monitoring setup. If they cannot tell you what metrics they collect and what the alert escalation looks like, their monitoring is either immature or nonexistent.

“AWS’ security stops at the perimeter of its infrastructure. The rest of security is carried out by customers.” — Stephen Schmidt, VP and CISO at AWS (Cybersecurity Dive)

Healthcare cloud modernization: what it looks like in practice

Healthcare cloud modernization is broader than migration. It includes moving workloads to the cloud and then rearchitecting how you build, deploy, and operate applications in that environment.

A modernization engagement typically covers:

  • Assessment. Inventory existing workloads, map dependencies, classify data, baseline costs.
  • Architecture. Design the target cloud environment: networking, IAM, encryption, observability, cost governance.
  • Migration. Move workloads in waves, starting with lowest risk. Validate after each wave.
  • Containerization. Where it makes sense, move from VMs to containers on Kubernetes. This is where the operational model changes significantly.
  • Observability. Deploy monitoring on day one. Prometheus for metrics, Grafana for dashboards, Loki for logs, Tempo for traces. The observability stack itself falls under HIPAA’s scope if it contains information about PHI systems.
  • Enablement. Train the internal team to operate the new environment. The goal is independence, not dependency on the consulting firm.

The healthcare cloud modernization service providers keyword has a KD of 0. That means almost nobody is writing about this topic, despite it being a real purchasing category. Organizations searching for it are actively evaluating providers.

The observability gap

Here is the reality most healthcare organizations face after migration: the workloads are running in the cloud, but nobody can see what is happening inside them.

The average detection time for a cloud misconfiguration is over 180 days (DataStackHub: Cloud Misconfiguration Statistics). Six months of exposure before anyone notices. Organizations with mature log management programs have compressed that to under 4 hours.

That gap is the difference between a managed services provider that monitors your infrastructure and one that actually observes your environment. Monitoring tells you a server is up.

Observability tells you:

  • Which services are handling PHI, and how they are performing
  • Whether access patterns to sensitive data stores match expected baselines
  • Whether your compliance controls (encryption, audit logging, access policies) are still in place or have drifted
  • Whether backup jobs for ePHI data stores are completing successfully

Your observability stack is the detection layer that catches the misconfigurations, the unauthorized access, and the compliance drift that scanners miss.

Where Obsium fits

If your team needs help with the observability layer for healthcare cloud workloads on Kubernetes, book a free 30-minute consultation. No sales deck, just an engineer-to-engineer chat about your stack.

FAQs

What are healthcare cloud managed services?

Cloud infrastructure management, security operations, HIPAA compliance monitoring, and operational support for healthcare organizations handling PHI.

Do cloud providers need a BAA for HIPAA compliance?

Yes. Any cloud service provider that stores, processes, or transmits ePHI on behalf of a covered entity must sign a Business Associate Agreement. The CSP is directly liable for compliance with applicable HIPAA rules, beyond the contractual liability in the BAA.

Which cloud provider is best for healthcare?

AWS has the broadest catalog of HIPAA-eligible services (166+). Azure integrates well with Microsoft and Epic environments. GCP leads on healthcare analytics and AI/ML. All three support HIPAA compliance through signed BAAs. The right choice depends on your existing ecosystem and workload requirements.

What certifications should a healthcare cloud provider have?

HITRUST i1 or r2 is the gold standard for healthcare. SOC 2 Type 2 is the minimum. ISO 27001, FedRAMP (for government healthcare), and CSA STAR are also relevant depending on your compliance requirements.

How do you evaluate a healthcare managed services provider?

Start with the basics: signed BAA, HITRUST or SOC 2 certification, healthcare client references. Then dig deeper: what are their incident response SLAs? Can they list their subprocessors? What does their observability setup look like? Do they have an exit plan for when the engagement ends? A provider that answers vaguely on any of these is not ready for healthcare workloads. The specificity of their answers tells you more than their marketing site.

Leave a Comment

Your email address will not be published. Required fields are marked *