TL;DR
- Health Cloud holds the most sensitive data category an organisation collects: patient records, care plans, and clinical relationships.
- The features that make Health Cloud useful (patient portals, care-team sharing, clinical integrations) are the ones most likely to expose that data.
- A review built for Health Cloud weights guest and portal access, the clinical sharing model, integration egress, and privileged access.
- Findings map to the frameworks the organisation reports against, including HISO 10029, the NZ Privacy Act, and the universal ISO 27001, SOC 2 and OWASP.
What You'll Learn
- Why a Health Cloud org carries more security risk than a standard Salesforce org
- The four areas a Health Cloud security review weights most heavily
- Which compliance frameworks apply to health data in Salesforce
- What a review produces and what it deliberately does not claim
The Problem
Salesforce Health Cloud holds the most sensitive data category your organisation collects. Patient records, care plans, clinical notes, and the relationships between a person and the people treating them. The features that make Health Cloud worth running are the same ones that put that data one misconfiguration away from exposure: patient portals on Experience Cloud, care-team sharing across related records, and integrations into clinical and claims systems. A general Salesforce security review treats a Health Cloud org like any other org. It is not like any other org.
Common Questions This Article Answers:
- What does a Salesforce Health Cloud security review actually check?
- How is securing Health Cloud different from securing a standard Salesforce org?
- Which compliance frameworks apply to patient data held in Salesforce?
Quick Answer
A Health Cloud security review weights its attention on the four areas where health data is most exposed: guest and external access through Experience Cloud patient portals, the sharing model on clinical objects, integration egress paths to clinical and claims systems, and privileged access held by health-operations staff and integration users. Each finding is then mapped to the compliance frameworks the organisation reports against. For organisations in New Zealand that includes HISO 10029:2022, the Health Information Privacy Code, the Privacy Act 2020 and NZISM, alongside the universal ISO 27001, SOC 2 and OWASP.
Guest and external access
Patient and member portals run on Experience Cloud, often with guest users and self-registration. That is the point of them. It is also the highest-consequence attack surface in a Health Cloud org. A guest profile with one over-broad object permission, or an Apex class reachable from the portal that runs without sharing, is a path from an unauthenticated web request to clinical records. The classic Salesforce guest-access failures are bad anywhere. On Health Cloud they are a notifiable privacy breach.
A review checks guest object and field permissions, sharing rules that touch guest access, portal-exposed Apex and flows, and self-registration settings on every live site.
The sharing model on clinical data
Health Cloud's value is in modelling who is connected to whom: care teams, related accounts, household and clinical relationships. That richness is also where access control gets hard. Org-wide defaults set too open, criteria-based sharing rules that over-reach, or without sharing automation can quietly make a patient's record visible to staff with no clinical reason to see it. Internal over-exposure of health information is a breach the same as external exposure; it is just harder to notice.
A review examines org-wide defaults on the sensitive objects, sharing rules that grant broad internal access, field-level security on clinical and identifier fields, and the sharing context of the flows and Apex that operate on them.
Integration and data egress
Health Cloud rarely stands alone. It connects to EHRs, claims platforms, and clinical messaging over HL7 or FHIR, usually through a mix of named credentials, remote site settings, and connected apps. Each of those is a route health data can leave by. Unrestricted remote sites, connected apps with broad OAuth scopes and long-lived tokens, and credentials stored where they should not be are how an integration becomes an exfiltration channel.
A review inventories the egress paths, checks remote sites and named credentials, reviews connected app scopes and token policy, and looks for credentials hard-coded in Apex, custom settings, or custom labels.
Privileged access and service accounts
Health operations run on a lot of administrative access and a lot of integration users. Both are prime targets. A review accounts for who holds system-wide permissions, which standard profiles are still in use, whether MFA is actually enforced for internal and external users, and how non-human integration identities are scoped and monitored.
The compliance obligations that come with health data
Health information is the most regulated data category in almost every jurisdiction, and a Health Cloud org carries those obligations whether or not anyone has mapped them. A finding becomes useful to a CISO or a privacy officer when it is tied to the control it implicates.
So every finding is mapped to the frameworks that apply to the organisation:
- the universal baselines: OWASP Top 10, ISO/IEC 27001:2022, and the SOC 2 Trust Services Criteria
- the Salesforce-native standard: the Security Benchmark for Salesforce, which encodes the platform-specific controls a generic scanner does not know about
- for organisations in New Zealand: HISO 10029:2022, the Health Information Security Framework; the Health Information Privacy Code 2020; the NZ Privacy Act 2020; and NZISM for entities connected to government
How that mapping is built and verified is covered in Mapping Salesforce security to NZISM, the NZ Privacy Act and ISO 27001.
What a review produces
The review runs read-only against the org. The output is a single report a security or clinical-governance lead can act on: a posture grade, the handful of issues to fix first with the way each one gets abused, a remediation roadmap grouped by effort, and a compliance coverage matrix scoped to the frameworks the organisation reports against. No agent is installed, no data is modified, and nothing leaves the org's control.
Frequently Asked Questions
Q: How is securing Salesforce Health Cloud different from a standard org?
A: Health Cloud concentrates the highest-sensitivity data and exposes it through features a sales org does not use: Experience Cloud patient portals, care-team and clinical-relationship sharing, and integrations to clinical systems. A review built for Health Cloud weights those areas, where a generic review treats every object the same.
Q: Which compliance frameworks apply to patient data in Salesforce?
A: Health information is the most regulated data category. In New Zealand that means HISO 10029:2022, the Health Information Privacy Code 2020, and the Privacy Act 2020, with NZISM for government-connected entities. The universal frameworks (ISO 27001, SOC 2, OWASP) and the Security Benchmark for Salesforce apply as well.
Q: Can guest users on a patient portal reach clinical records?
A: They can if the configuration allows it. An over-broad guest object permission, a sharing rule that touches guest access, or portal-reachable Apex running without sharing can expose records to an unauthenticated request. These are the first things a Health Cloud review checks.
Q: Is a Health Cloud security review a certification or a penetration test?
A: Neither. It is a read-only, point-in-time configuration review. It tells you where your configuration stands against the frameworks and what to fix first. "No findings detected" against a control is not a statement of compliance, and the report says so.
Key Takeaways
- Health Cloud is not a standard org: the same features that make it valuable concentrate and expose the most sensitive data category you hold.
- Guest and portal access is the first priority: Experience Cloud patient portals turn a configuration error into a notifiable breach.
- Map to the frameworks you report to: HISO 10029, the Health Information Privacy Code and the Privacy Act for NZ, alongside ISO 27001, SOC 2 and OWASP.
- A review finds and prioritises; it does not certify: the value is a report your board can read, not an audit opinion.
What's Next?
Recommended Reading:
Action Items:
- Inventory every live Experience Cloud site and its guest access before anything else.
- Confirm which compliance frameworks your organisation reports against.
- Review the sharing model on your clinical objects, not just the standard CRM objects.