Evaluate the service and configuration, not just the provider name
A regulated organisation can use cloud services for electronic protected health information (ePHI) when the applicable HIPAA requirements are met. The assessment should cover the service relationship, appropriate business associate arrangements, risk analysis and the safeguards each party operates. A supplier’s general claim of HIPAA readiness does not establish that every feature or customer configuration is suitable for the proposed use. Guidance on HIPAA and Cloud Computing
HHS explains that a cloud provider maintaining ePHI can be a business associate even when the data is encrypted and the provider does not hold the decryption key. No-view hosting is therefore not automatically outside the business associate framework. Encryption can reduce risk, but it does not erase the need to analyse the role and responsibilities. Guidance on HIPAA and Cloud Computing
For a senior buyer, the central question is whether the proposed service can support the organisation’s actual workflow and obligations. Confirm the exact products, account tier, locations, support model and integrations. Then assign customer and supplier responsibilities with evidence and tests. Cloud adoption can improve capabilities, but it also creates dependencies that need explicit ownership.
Identify the features that will handle ePHI
List the primary service and every enabled feature that may receive, maintain or transmit ePHI. Storage, search, monitoring, support, analytics, recording and artificial intelligence functions may follow different processing paths or terms. An agreement for one service should not be assumed to cover an optional feature merely because it appears in the same administration console.
Map normal use and troubleshooting. A production database may remain in an approved region while support attachments are uploaded elsewhere. An integration may send a copy to another supplier. A diagnostic event may include identifiers or free text. Ask engineers and operational users to demonstrate representative flows with synthetic records, then compare the result with the supplier’s documented scope.
Confirm the contracting entity and relevant agreement. Record the service names or identifiers needed to distinguish included and excluded products. Make any restrictions visible to administrators and product owners. Procurement approval is ineffective if staff can enable an excluded feature without recognising that it changes the information boundary.
Define change triggers. A new integration, region, support arrangement or data use should prompt review of the map, agreement and safeguards. A periodic supplier review can help, but it should not be the only opportunity to notice a material feature change. Put the question into the process where cloud configuration and product decisions are made.
Allocate responsibilities at a usable level of detail
A shared responsibility model should describe the actual service. Infrastructure protection may sit with the provider, while the customer controls identities, permissions, application design and data handling. Managed services can shift some tasks, but the allocation must be confirmed rather than assumed. Name the owner of each significant activity and the dependency on the other party.
For identity, determine who provisions users, approves privileges and removes access. For logging, determine which events are available, who enables them and who reviews them. For backup, determine what is included, what the customer must configure and how recovery is requested or performed. For incidents, determine who supplies evidence and how customer-specific facts are established.
Include operational handoffs. A provider may act on an account-removal request, but the customer must send a reliable workforce notification. A supplier may make logs available, but the customer must retain or review them. These gaps are easy to overlook when the responsibility chart uses only broad labels such as security or data protection.
Turn the matrix into tests. Demonstrate a new user, a removed user, a relevant alert, a record retrieval and a recovery task. The goal is not to test the provider’s entire internal environment without authority. It is to verify the responsibilities the organisation relies upon and identify where evidence or capability remains limited.
Control customer-owned settings and privileged access
Cloud defaults should be evaluated against the intended ePHI workflow. Review permissions, public sharing, administrator roles, authentication, network access, data export and relevant logging. A platform may offer appropriate controls without enabling them automatically. Record the approved baseline and who can change it, then monitor material deviations in a way suited to the environment.
Separate ordinary work from administration. Privileged accounts can change protection settings or access broad information, so assign them carefully and review their use. Include service accounts, integration credentials and automation. A forgotten deployment key can remain a powerful route into the environment after the person who created it has left.
Plan changes around service continuity. Tightening a permission or rotating a key can disrupt a clinical integration if dependencies are unknown. Use controlled testing and a defined rollback process where appropriate. The need to avoid disruption is a reason for good engineering, not a reason to leave unsafe settings indefinitely without a plan.
Keep evidence tied to the account and service in use. Generic provider documentation explains capability; configuration records and tests show the customer’s implementation. For an assessment, state what was observed and what is supported only by supplier assurance. HHS does not recognise private Security Rule certification as relief from legal obligations, so broad badges should not replace that analysis. Are we required to certify compliance with the Security Rule?
Read our HIPAA Security Rule guide to connect individual cloud settings with the wider safeguard responsibilities and evidence needed for the service.
Assess location, support and legal dependencies
HHS cloud guidance states that overseas storage or processing is not categorically prohibited by HIPAA, provided the relevant requirements are met, and highlights geographic risks for risk analysis and management. This does not mean every overseas arrangement is acceptable under every customer contract or other law. Review the specific locations, parties and obligations. Guidance on HIPAA and Cloud Computing
Include human access. Keeping servers in one country does not mean information is only processed there if support workers can view records elsewhere. Identify support locations, access approval, supervision and evidence. Consider language, time-zone coverage and the practical ability to obtain incident information or enforce agreed protections. Avoid unsupported assumptions about risk based solely on a country’s name.
Confirm region behaviour for backups, failover and optional services. An application setting may control primary storage while another feature uses a different arrangement. Ask what the provider commits to and what the customer can configure or verify. If the evidence is incomplete, record the uncertainty and decide whether additional restrictions or assurance are needed.
Document the approval conditions in operational terms. For example, a customer may permit a particular hosting region and named support model but require review before changes. Ensure administrators and service managers can recognise those conditions. A legal restriction that is invisible to the team selecting cloud settings is unlikely to be implemented reliably.
Plan retrieval, recovery and exit before dependence grows
Determine how the organisation will obtain its information during an outage, dispute, termination or migration. A cloud service can become operationally critical quickly, while export and recovery limitations remain untested. Identify the information, metadata and relationships needed for another system or for an individual-rights response. A downloadable file is not necessarily a usable record set.
Clarify backup responsibilities and restoration capability. Some services protect their infrastructure while the customer remains responsible for recovering particular deleted or corrupted content. Others provide specific recovery features with limits. Compare the actual service with the healthcare workflow’s needs and test the customer-controlled parts safely. Do not infer a recovery guarantee from a general availability statement.
Exit planning should address return, deletion, retained copies and subcontractors under the relevant agreement. Determine what happens to logs, support attachments and backups. If immediate destruction is infeasible in a particular context, obtain appropriate review of the continuing protection and permitted handling. Avoid promising a deletion outcome that the architecture cannot perform. Business Associate Contracts
Maintain an exit record that can be updated as the service grows. Include contacts, export format, validation method, access removal and remaining dependencies. The work need not imply an imminent departure; it gives the organisation a credible option if the supplier or service no longer meets its needs.
Hypothetical example: a clinic adopts a hosted collaboration platform
A fictional clinic selects a hosted platform for internal coordination. The provider offers an agreement for specified services, but the platform also includes optional third-party extensions and recording features. The clinic’s team identifies the workflows that may involve protected health information (PHI) and compares each feature with the approved scope. It does not treat the provider’s brand as approval for every function.
The privacy lead defines appropriate uses and channels, while the technical team configures access and sharing. Procurement verifies the relevant agreement and support responsibilities. Staff practise a representative handoff with synthetic patient information. The exercise reveals that an external sharing option remains enabled in a workspace intended only for internal use.
The clinic corrects the setting and establishes a controlled exception process for legitimate external collaboration. It checks whether activity is logged and who reviews unusual sharing. It also tests retrieval of a relevant record and the handling of a departing employee’s account. The result is a configuration and operating process tied to the clinic’s actual purpose.
When a department later requests automated meeting summaries, the feature triggers review because it may create a new information flow and processing purpose. The original approval remains useful because it states its boundary. Without that boundary, a seemingly minor feature activation could expand PHI handling without a deliberate decision.
Hypothetical example: a software vendor changes cloud recovery architecture
A fictional healthcare software vendor plans to improve resilience by replicating data into a second cloud region. Engineering expects the change to be invisible to customers. The shared responsibility review identifies customer-specific location commitments, new key dependencies and a change in the route used for recovery. These matters require review before the architecture is deployed.
The vendor maps the replicated data and confirms which services and agreements cover the new region. It identifies customers whose conditions require notice or approval. Security reviews access and key management, while operations defines activation and reconciliation. The team determines what evidence will show that recovery protects both availability and data integrity.
A controlled test restores a synthetic tenant in the second region. It checks authentication, application access, logging and the ability to reconcile transactions after return to normal operation. The test discovers that an integration uses a region-specific endpoint, so the service is not yet fully recoverable. The issue remains open until corrected and retested.
The vendor updates customer-facing scope information accurately and retains the test’s limitations. The example illustrates that cloud resilience is a shared operational design, not merely a storage setting. A technically attractive change can affect contracts, privacy, security and service delivery at the same time.
The team also tests a partial failure in which the primary region remains reachable but its records are no longer current. This prevents automatic failover from being evaluated only as an on-or-off infrastructure event. Operations establishes who confirms data consistency and authorises a return to the primary environment. Engineering documents how duplicate or conflicting transactions will be identified and resolved under the approved process.
Customer assurance material then explains the service actually demonstrated: which components were tested, what assumptions applied and which dependencies still require customer action. It avoids turning a successful synthetic exercise into a guarantee of uninterrupted service under every circumstance. Procurement retains the relevant supplier evidence and confirms how future changes to the recovery feature will be reviewed. This creates a maintainable responsibility record rather than a one-time architecture approval that becomes stale after the next cloud release.
Review a changed default before broad deployment
Cloud providers can introduce new settings or alter available features. Establish how the service owner learns about changes that may affect information sharing, support access, logging or retention. Evaluate the effect on the approved baseline and customer conditions before enabling the feature widely. Where an update is automatic, identify the available review and rollback options and document any limitation. This keeps responsibility with the organisation operating the service instead of assuming that a provider update necessarily preserves every decision made during the original procurement.
Turn a changed setting into a scoped verification task using the evidence and findings methods in our HIPAA gap-assessment guide.
Reference basis
HHS: Guidance on HIPAA and Cloud Computing; HHS: Security Rule certification FAQ; HHS: Business associate contracts.
Frequently asked questions
Can a no-view cloud provider still be a business associate?
Yes. HHS explains that maintaining encrypted ePHI can create business associate responsibilities even when the provider lacks the decryption key.
Does a signed cloud BAA cover every feature?
Do not assume so. Confirm the exact services, account scope, optional features and downstream processing covered by the arrangement.
Does HIPAA prohibit every overseas cloud arrangement?
No categorical prohibition is stated in the HHS guidance discussed here, but applicable HIPAA requirements, geographic risks, contracts and other laws must be assessed for the specific arrangement.
Discuss the next practical step
Before expanding a cloud service, establish the exact features, account scope and data routes proposed. A shared-responsibility review should connect the agreement to configuration, monitoring, recovery, support and exit duties.
Explore CyberVantage360 HIPAA assessment and implementation services, or contact CyberVantage360 to discuss your priorities.