Medical data can be stored in the cloud, but a cloud environment cannot be assessed only by the provider’s name, the selected region, or enabled encryption. What matters is proving control over the entire chain: where the data is located, who has access, who manages the keys, which actions are logged, where backups are stored, and what the provider is obligated to do in the event of an incident.
The main risks often appear not in the primary database, but at the boundaries:
- A contractor retains unnecessary access after the work is completed;
- Encryption keys are managed by too broad a group of administrators;
- Logs do not capture exports, bulk downloads, or support actions;
- Backups, logs, or analytics exports are moved to another region;
- A test environment receives real medical data without proper protection;
- The contract does not define incident notification timelines, processing regions, or the procedure for data deletion.
HIPAA in the United States, GDPR in Europe, and similar regulatory frameworks in other countries and regions provide important reference points, but they do not replace an assessment of the specific architecture. For medical data, it is necessary to verify not only compliance requirements, but also the actual processing routes: the production environment, copies, integrations, logs, queues, analytics, support, and recovery.
The practical criterion is simple: the organization must be able to show where medical data is located, who can decrypt it, who has accessed it, where copies are stored, and which obligations are assigned to the provider. If this cannot be verified, the selected region and enabled encryption remain only part of the protection — not a complete architecture.
Control Must Cover the Entire Data Chain
For medical data, cloud infrastructure must be verifiable, not merely “secure by default.” The selected region, enabled encryption, and a well-known provider reduce some risks, but they do not cover the full picture.
Problems often arise at system boundaries. The primary database may be stored in the correct region, while the backup is stored in another jurisdiction. Data may be encrypted, but a contractor may still retain administrative access. Logs may record logins, but fail to show bulk exports of records. The provider may offer technical security tools, but the contract may not require it to report an incident quickly enough.
That is why storing medical data in the cloud should start not with choosing a service, but with a map of responsibilities and processing routes. The organization needs to understand which data enters the cloud, where it appears in derived copies, who has access to it, how keys are managed, where logs are kept, how backups are organized, and which obligations are documented in writing.
The next logical step is classification: which specific types of medical data require special control, and where they may appear beyond the primary medical record.
Which Medical Data Requires Special Control
It is risky to treat “medical data” as a single category. In a cloud system, it rarely exists only as an electronic medical record. One patient may appear in an appointment record, lab result, image, prescription, insurance bill, chat with a doctor, activity log, and backup copy.
In the United States, the term ePHI is used for this type of data: electronic protected health information under HIPAA, if it relates to an identifiable patient. In Europe, health data is considered a special category of personal data under GDPR, which means a stricter processing regime applies.
For architecture purposes, it is more practical to divide medical data into several groups:
| Data Group | Examples |
| Clinical data | Medical records, diagnoses, medical history, prescriptions, treatment plans, doctors’ reports |
| Diagnostic data | Lab results, genetic and biometric indicators, CT, MRI, X-ray, ultrasound, photographs |
| Administrative and financial data | Insurance details, invoices, reimbursements, payment documents, referrals |
| Patient communications | Forms, consents, complaints, correspondence, chats, telemedicine consultation recordings |
| Derived and service copies | Activity logs, cache, test environments, exchange queues, analytics exports, backups |
This classification is not needed for formality. It shows where separate rules may be required for access, encryption, storage, auditing, region selection, and provider contractual guarantees.
The main risk is protecting the primary database while forgetting about derived copies. Medical information may remain in a report, archive, log, test environment, exchange queue, or backup. That is why the data map should cover not only the production system, but also every place where data appears after processing.
It is also important to distinguish between identifiable, pseudonymized, and anonymized data. Pseudonymization reduces risk, but it does not always remove data from the stricter control regime: if a matching key or additional sources exist, the link to a person may be restored. Anonymization requires a separate assessment: it is not enough to remove a name; the reasonable possibility of re-identification must also be excluded.
After classifying the data, the next step is shared responsibility: which controls are provided by the cloud provider, and which remain on the customer’s side.
Shared Responsibility: What the Provider Covers and What Remains with the Customer
A large cloud provider with certifications reduces some risks, but it does not fix customer-side mistakes: open storage, excessive contractor permissions, disabled logs, or backups placed in an unsuitable region.
The shared responsibility model means that the provider protects the platform, while the customer is responsible for applying these capabilities to their own data. The provider usually covers physical data center security, resilience of core services, and provides tools for encryption, logging, and access management. The customer decides which roles are granted, where data is placed, who manages keys, which events are logged, and how recovery is tested.
Typical areas of responsibility can be broken down as follows:
| Element | Usually Covered by the Provider | Usually Covered by the Customer | Risk If Misconfigured |
| Physical security | Data centers, engineering protection | Review of guarantees and reports | Platform control is mistakenly treated as data control |
| Encryption | Providing encryption mechanisms | Enabling, configuring, and choosing the key model | Data remains without the required protection |
| Key management | Key storage service | Ownership, permissions, rotation, and access revocation | Too many users can decrypt data |
| Roles and permissions | IAM tools | Least privilege, MFA, access review, and revocation | Contractors retain permanent access |
| Access logs | Technical ability to record events | Enabling, storing, analyzing, and protecting logs | It is impossible to prove who accessed the data |
| Backups | Backup tools | Policy, regions, encryption, recovery testing | Data loss or copies stored in another jurisdiction |
| Region and replication | Available regions | Region selection and prevention of unnecessary movement | Violation of data residency requirements |
| Contracts and incidents | Some guarantees and reports | Review of terms, timelines, and notification channels | No clarity on who reports an incident and when |
The key takeaway is that the provider can offer a secure platform and control tools, but leakage risk often appears in customer configuration and processes. That is why the next step is to assess where the data is located, who accesses it, which copies are created, and what happens if something goes wrong.
Risk Assessment Before Migration
Risk assessment should be carried out before migration, audit, or architecture changes. Otherwise, protection will be built around the “primary database,” while sensitive information may already exist in file storage, integrations, logs, test environments, and backups.
The inventory should include more than the production database with electronic medical records. The data map should cover:
- File and object storage;
- APIs for exchange with external systems;
- Integrations with insurers, laboratories, and partners;
- Development and test environments;
- Analytics exports and reports;
- Access logs and technical logs;
- Service accounts and exchange queues;
- Backups, archives, and snapshots.
At this stage, it is important to understand where data is stored, where it is transferred, where it is automatically copied, and who can work with it. Contractors, service accounts, logs, reports, and test environments should be reviewed separately: this is where copies often remain outside the primary protection model.
The result of this assessment should become practical requirements: which data needs stronger encryption, where access must be restricted, which events must be logged, which regions must be excluded, and which recovery scenarios should be tested in advance.
After the data map is complete, the next step is encryption. But here it is important not to stop at the statement “the data is encrypted”: for medical data, it is critical to understand who can initiate decryption.
Encryption and Keys: Protecting Data Is Not Enough — Decryption Must Be Controlled
Encryption should be applied not only to the primary database, but also to disks, file and object storage, snapshots, archives, and backups. Data in transit should be protected separately: user connections, APIs, and integrations with laboratories, insurers, and partners.
However, encryption does not solve the problem of legitimate but excessive access. For example, a database may be encrypted, but a contractor may retain permanent administrative access in the production environment and export information through a standard interface. The storage medium is protected, the channel is protected, but the access model still allows a leak.
That is why not only the fact of encryption matters, but also key management: who creates the keys, where they are stored, who can use a key, and where key operations are logged.
| Key Model | What It Means | When It Fits |
| Provider-managed keys | The provider manages the keys and key storage infrastructure | Basic scenarios where standard platform protection is sufficient |
| Customer-managed keys in KMS | The customer manages access policies, rotation, and key usage through a key management service | Sensitive medical data and higher control requirements |
| HSM or dedicated key environment | Key material is protected by a hardware module or a stricter control model | Strict security, audit, or contractual requirements |
At a minimum, the organization should check who is considered the key owner, which services and administrators can use the key, how quickly access can be revoked, how rotation is performed, and where key operations are logged.
This is especially important when an administrator leaves, a contractor changes, or an account is compromised. Access to data must be terminated in a controlled way, and key-related actions must remain verifiable.
After keys, the next layer is access control and logs. Encryption protects data from some technical risks, but it does not replace control over who accessed medical information and what exactly they did.
Access Control and Logs: Who Accessed the Data and What Exactly They Did
For medical data, access should follow the principle of least privilege. A user, service account, or contractor should receive only the permissions required for a specific role and period of work. Permanent administrative privileges, shared accounts, and “just in case” access create risks that encryption alone cannot compensate for.
How to Separate Roles
In a practical access model, several types of roles should be separated:
Medical roles — doctor, receptionist, call center operator, insurance department employee;
Technical roles — administrator, support engineer, developer, analyst;
Service roles — accounts used by applications, integrations, and backup tools;
Temporary roles — access for contractors, auditors, external support, and project teams.
For sensitive medical data, unique user accounts, multi-factor authentication, separation of administrative and user roles, regular access reviews, and fast access revocation are critical.
Test environments are a separate risk. Real patient data should not automatically enter them without a separate assessment, protection measures, and access control.
What Should Be Logged
Logs are needed not only for incident investigations. They also allow the organization to prove that it controls data access, detects unusual activity, and can reconstruct the sequence of events.
For medical systems, logs usually capture:
- Successful and failed login attempts;
- Viewing, creating, modifying, and deleting medical records;
- Data export, bulk download, and printing;
- Changes to roles, permissions, and MFA settings;
- Actions by administrators and technical support;
- Encryption key operations;
- Creation, copying, and recovery of backups;
- Disabling or changing logging rules;
- Access through APIs and integrations.
The logs themselves are also sensitive assets. They may contain patient identifiers, fragments of diagnoses, technical tokens, and information about doctors’ actions. That is why logs should be protected from modification, stored with a defined retention period, access to them should be restricted, and they should be analyzed regularly.
After access control and logging, the next step is to review the regional policy: where not only production data is stored, but also copies, logs, analytics, replicas, and support environments.
Placement Region: Where Data, Copies, and Service Traces Are Stored
Choosing a cloud region for medical data should not be reduced to the nearest data center or the lowest latency. The region determines where the primary database, file storage, backups, replicas, logs, and service data are located. It also affects which laws and cross-border data transfer mechanisms may apply.
It is not enough to check only the primary region specified when the service is created. Data may move or become accessible through cross-region replication, backups, archives, analytics, monitoring, logs, disaster recovery, provider support, and subcontractors.
For organizations working with patients in different countries, the region question is tied to the roles of the parties and the legal grounds for processing. For example, European health data requires an assessment under GDPR rules, including data transfers outside the European Economic Area. In the United States, when processing ePHI, the cloud model must align with HIPAA requirements and the contractual terms with the service provider.
A practical region review should answer several questions:
- Where is the primary environment with medical data located?
- Where are backups, archives, and logs stored?
- Is automatic replication to other regions enabled?
- Which provider support staff can access the environment, and from which countries?
- Can processing outside the selected regions be technically prohibited?
- How are cross-border data transfers documented, if they exist?
For medical data, a particularly dangerous situation is when the primary database is hosted in an approved region, while backups, logs, or analytics exports are automatically moved to another jurisdiction. That is why the regional policy should cover the entire data lifecycle, not only the production application database.
After the region, the next logical area is backups: they often become the hidden second location where medical data is stored.
Backup and Recovery: A Copy Is Valuable Only If Recovery Has Been Tested
For medical systems, backup is not only about business continuity. Loss or prolonged unavailability of medical data can affect treatment, insurance settlements, legal obligations, and patient trust.
A minimum backup policy should define not only the fact that copies are created, but the entire protection model around them:
| What to Define | Why It Matters |
| Which data is copied | Databases, files, images, logs, configurations, and key settings may require different rules |
| How often copies are created | Frequency affects acceptable data loss during an incident |
| How long copies are retained | The retention period should account for medical, contractual, and legal requirements |
| Which region they are stored in | Copies should not automatically move to an unsuitable jurisdiction |
| Who has access | Creating, reading, deleting, and restoring copies should be restricted |
| How copies are encrypted | A backup should be protected no less strictly than production data |
| How recovery is tested | A copy is useless if it cannot be restored within the required time |
For medical data, two indicators are especially important: acceptable data loss and acceptable recovery time. The first shows how many changes the organization can afford to lose between the last backup and an incident. The second shows how long the system can remain unavailable without unacceptable consequences for a clinic, telemedicine service, laboratory, or insurance process.
Backups must be protected from the same risks as production data: unauthorized access, deletion, movement to an unsuitable region, and uncontrolled reading. For ransomware and internal error scenarios, immutable copies or storage with deletion protection for a defined period are useful, as long as they are compatible with data retention and deletion requirements.
Recovery testing should be regular. It is not enough to confirm that backups are being created: the organization should periodically restore a test environment, verify data integrity, access rights, logs, integration links, and the actual recovery time.
The technical backup policy should match the contract. If the provider or contractor is responsible for part of the infrastructure, this must be documented in writing.
Provider Contractual Obligations: What Must Be Documented in Writing
Technical cloud configuration does not replace contractual obligations. For medical data, it is important that the responsibilities of the parties are described not only in the general service terms, but also in documents that apply to the processing of sensitive data.
The contract should define the roles of the parties, data categories, processing purposes, permitted regions, rules for engaging subcontractors, and the incident notification procedure. Encryption, access management, logging, backup, recovery, return, export, and data deletion after contract termination should also be reviewed separately.
In the United States, when working with ePHI, a BAA — Business Associate Agreement under HIPAA — may be required. In the European context, a DPA — Data Processing Agreement under GDPR — is usually reviewed. Service availability and service parameters are often described in an SLA — Service Level Agreement.
The key point is to align the contract with the actual architecture. If the contract allows processing only in specific regions, backups and logs should not leave those regions. If the provider promises incident notification, the timeline, communication channel, and content of the notification must be clear. If the customer requires auditability, the contract should provide access at least to independent reports and evidence of controls.
The contract formalizes what the technical architecture cannot guarantee by itself: who is responsible for what, how quickly issues are reported, where data may be processed, and what happens to the data after the cooperation ends.
Checklist for Storing Sensitive Medical Data in the Cloud
This checklist is not a formality. It is a quick way to verify whether the entire medical data processing chain is covered — from the primary database to backups, logs, support, and the provider contract.
The technical layer can be checked as follows:
| Area | What Must Be Checked |
| Data and copies | Categories of medical data, storage locations, test environments, logs, archives, and backups |
| Encryption and keys | Protection of data at rest and in transit, key ownership, rotation, access revocation, and logging of key operations |
| Access control | Least privilege, MFA, unique accounts, and no permanent excessive access |
| Logs | Logins, views, changes, exports, administrator actions, key operations, and backup operations |
| Regions | Production environment, replicas, backups, logs, analytics, and support remain in approved regions |
The organizational and contractual layer is just as important:
| Area | What Must Be Documented |
| Responsibility | Provider and customer responsibilities are separated for infrastructure, configuration, access, keys, and logs |
| Regulatory requirements | It is clear whether HIPAA, GDPR, or other requirements apply, based on patients and jurisdictions |
| Recovery | The backup policy is documented and recovery is regularly tested: data, access rights, integrations, and recovery time |
| Contract | Roles of the parties, regions, subcontractors, incident notifications, data return, and deletion are defined |
| Incidents and review | Responsible persons, notification timelines, log retention, and regular review of access rights, keys, regions, and contracts are defined |
This checklist shows the minimum set of checks without which cloud storage of medical data remains incomplete. Some risks may be addressed technically but not confirmed by processes and contracts. And the opposite is also true: a strong contract will not help if real copies, logs, or access rights do not match the architecture.
Conclusion
The cloud can be an acceptable environment for medical data if the organization controls the entire processing chain: data, copies, keys, roles, logs, regions, recovery, and contractual obligations.
Enabled encryption, provider certifications, or a selected region do not remove the customer’s responsibility for configuration and processes. The practical readiness criterion is simple: the organization must be able to prove where medical data is located, who has accessed it, how decryption is protected, which actions are logged, how data is recovered, and which obligations are assigned to the provider. If even one of these elements cannot be verified, the risk remains controlled only on paper.
FAQ
Can medical data be stored in the cloud?
Yes, if the applicable jurisdictional requirements are met, technical protection measures are configured, and the relationship with the provider is properly documented. In the United States, HIPAA and ePHI must be considered. In the EU, GDPR applies, and health data is treated as a special category of personal data.
Is enabling encryption enough?
No. Encryption protects data at rest and in transit, but it does not prevent export through legitimate access. Key control, roles, multi-factor authentication, activity logs, and regular access reviews are also required.
What should be checked in access control?
Check unique accounts, least-privilege permissions, separation of administrative and user roles, temporary access for contractors, prohibition of shared accounts, and the process for revoking access when an employee leaves or a team changes.
What logs are needed for medical data?
Logs should capture not only system logins, but also record views, data exports, role changes, administrator actions, key operations, creation and recovery of backups, logging configuration changes, and technical support actions.
How should the placement region be chosen?
Do not look only at the primary data center region. Backup regions, replication, support access from other countries, provider subcontractors, and cross-border data transfer mechanisms also matter.
What should be included in the contract with the cloud provider?
The contract should define the roles of the parties, incident notifications, data return and deletion rules, the list of subcontractors, data transfer restrictions, SLA — Service Level Agreement, audit rights or access to reports, and, where applicable, a BAA — Business Associate Agreement under HIPAA — or a DPA — Data Processing Agreement under GDPR.
Sources
2. HHS — Guidance on HIPAA & Cloud Computing
3. NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule
4. Regulation (EU) 2016/679 — General Data Protection Regulation, EUR-Lex
