- Nebius AI Cloud, and
- Nebius Token Factory.
1. How to Use This Guideline
Customers should first determine which Nebius product will process, transmit, or store ePHI.
Section 3 describes requirements applicable to all HIPAA-regulated workloads on Nebius.
Section 4 describes requirements specific to Nebius AI Cloud.
Section 5 describes requirements specific to Nebius Token Factory.
Only products, services, capabilities, and API methods explicitly identified as eligible in this guideline or in an applicable agreement with Nebius may be used with PHI/ePHI.
2. Definitions and Scope
This guideline applies to Nebius services used for workloads involving the processing, transmission, or storage of electronic Protected Health Information (ePHI) as defined by 45 CFR §160.103.- Customer - a covered entity, Business Associate, or other organization that uses Nebius services and is responsible for determining whether HIPAA applies to its use case.
- PHI - Protected Health Information as defined under HIPAA.
- ePHI - PHI that is created, received, maintained, or transmitted in electronic form and is subject to the HIPAA Security Rule.
- Business Associate Agreement (BAA) - an agreement governing the handling of PHI between Nebius and a Customer where required by HIPAA. Customers must have an executed BAA with Nebius before using covered Nebius services with PHI/ePHI.
- Nebius AI Cloud - Nebius cloud infrastructure and platform services. HIPAA eligibility is determined separately for individual AI Cloud services and for the manner in which those services are used.
- Nebius Token Factory - a managed Nebius platform for model inference and related AI capabilities. HIPAA eligibility is determined separately for individual Token Factory capabilities and API methods and may depend on required privacy configurations.
- Zero Data Retention (ZDR) - a Token Factory privacy configuration under which customer request and response content is not retained after request processing, subject to the applicable Token Factory product terms and technical implementation.
- Covered Service or Capability - a Nebius service, feature, or API method explicitly approved for use with PHI/ePHI under the applicable BAA and Nebius documentation.
3. Requirements Applicable to All Nebius HIPAA Workloads
3.1 Business Associate Agreement
Before processing, transmitting, or storing PHI/ePHI using Nebius, Customers must execute a Business Associate Agreement (BAA) with Nebius where required. PHI/ePHI must not be submitted to Nebius services until:- the BAA has been fully executed;
- the intended Nebius products and capabilities are confirmed to be within scope; and
- all required product-specific configurations have been applied.
- the intended use case;
- the Nebius products and services to be used;
- the types of PHI/ePHI involved; and
- any applicable regional, residency, or contractual requirements.
3.2 Use Only Covered Services and Capabilities
Only Nebius services and capabilities explicitly identified as eligible for use with PHI/ePHI may be used for HIPAA-regulated workloads. A service, feature, or API method that is not explicitly identified as eligible must be treated as not covered by default, unless separately approved and documented by Nebius. Customers are responsible for restricting PHI/ePHI to covered services and configurations.3.3 Shared Responsibility Model
Nebius and its Customers share responsibility for protecting ePHI. Nebius is responsible for security controls applicable to the infrastructure, platform, and managed services under Nebius control. Customers remain responsible for the security and compliance of their applications, identities, configurations, data-handling processes, and workloads.
Product-specific responsibilities are described in Sections 4 and 5.
3.4 Data Classification and Metadata
Customers must not include ePHI, PII, or other confidential information in metadata fields, resource names, labels, tags, identifiers, or other fields that are not explicitly approved for regulated data. Such information may be processed by control-plane, monitoring, billing, routing, or operational systems. Customers should store ePHI only as Customer Data in storage services explicitly approved for PHI/ePHI use.3.5 Data Residency
Nebius services are offered in multiple regions. Customers are responsible for selecting regions and service configurations consistent with their own legal, regulatory, contractual, residency, and data-sovereignty requirements. Availability and compliance scope may differ by product, service, or region. Customers should confirm applicable requirements before placing PHI/ePHI into a Nebius service.4. Nebius AI Cloud Implementation Requirements
Customers using Nebius AI Cloud with ePHI must comply with this section in addition to the common requirements in Section 3.4.1 AI Cloud HIPAA Eligibility Scope
HIPAA eligibility is determined at the individual service level.
If a service is not explicitly identified as eligible, Customers must not use it with ePHI unless Nebius has separately approved and documented such use.
4.2 Object Storage Requirements
Object Storage is the Nebius AI Cloud service approved for persistent storage of ePHI. Customers using Object Storage with ePHI must:- store ePHI only as Customer Data within object contents;
- use appropriate IAM permissions and least-privilege access;
- enable required access logging for buckets containing ePHI;
- monitor access to those buckets;
- configure retention and lifecycle rules according to Customer requirements; and
- ensure that resource names, object keys, tags, and metadata do not contain ePHI.
4.2.1 Access Logging
Data-access logging for Object Storage is not enabled by default. Customers must request access-log activation through Nebius Support for Object Storage buckets that contain ePHI. Access logging is enabled on a per-bucket basis. Once enabled, applicable read, write, and delete events are recorded through Nebius logging and audit capabilities. Customers are responsible for:- monitoring and reviewing relevant logs;
- configuring appropriate alerting;
- retaining logs for periods required by their policies and applicable law; and
- ensuring that log-generating fields do not themselves contain ePHI.
4.3 Compute Instances and Managed Kubernetes
Compute Instances and Managed Kubernetes may be used to process or transmit ePHI only in transient form. Customers must ensure that ePHI is not persistently written to storage mechanisms that are outside the approved HIPAA scope. This includes, unless separately approved:- local VM disks;
- Nebius Block Storage;
- shared filesystems;
- persistent Kubernetes volumes backed by non-approved services;
- managed databases or other managed solutions; and
- container images or image layers.
4.4 Encryption and Key Management
Nebius provides platform-level encryption for supported AI Cloud services. At rest - objects stored in Nebius Object Storage are encrypted using platform encryption. In transit - Nebius service endpoints use encrypted network transport. Customers are responsible for:- application-level encryption where required by their risk assessment or organizational policy;
- management and protection of credentials and encryption keys under Customer control;
- application authorization;
- appropriate IAM configuration; and
- ensuring that ePHI is stored only in approved locations.
4.5 Data Integrity
Nebius is responsible for protecting the integrity of infrastructure and platform components under its control. Nebius does not validate the application-level, semantic, or clinical correctness of Customer data. Customers are responsible for implementing appropriate controls to detect and recover from unintended modification, corruption, or deletion of ePHI. Depending on the Customer’s use case, such controls may include:- checksums or digital signatures;
- application-level validation;
- periodic integrity verification;
- backups;
- recovery procedures; and
- restoration testing.
4.6 Data Retention
Nebius does not prescribe a single retention period for ePHI. Customers are responsible for determining applicable retention periods under:- federal and state law;
- contractual requirements;
- healthcare record-retention requirements;
- organizational policies; and
- other applicable obligations.
4.7 Data Deletion and Lifecycle Management
Nebius Object Storage provides Customers with lifecycle and deletion controls for Customer data. Customers may delete objects and buckets using available Nebius interfaces and APIs. Nebius applies platform mechanisms designed to make deleted data irrecoverable in accordance with Nebius storage architecture and applicable service commitments. Customers are responsible for:- defining appropriate lifecycle and deletion policies;
- verifying that deletion is permitted under applicable legal and contractual retention requirements; and
- understanding that deleted data may not be recoverable.
4.8 AI Cloud Implementation Checklist
Before processing ePHI using Nebius AI Cloud, Customers should verify that:- A BAA with Nebius has been executed.
- Only HIPAA-eligible AI Cloud services are used.
- Persistent ePHI is stored only as Customer Data in Object Storage.
- Compute and Kubernetes workloads process ePHI only transiently.
- Object Storage access logging is enabled for relevant buckets.
- Least-privilege IAM policies are configured.
- ePHI is not included in metadata, labels, tags, resource names, or object keys.
- Logging and monitoring processes are established.
- Retention and lifecycle policies are defined.
- Backup, recovery, and integrity controls are implemented as appropriate.
- Regional and data-residency requirements have been evaluated.
5. Nebius Token Factory Implementation Requirements
Customers using Nebius Token Factory with PHI/ePHI must comply with this section in addition to the common requirements in Section 3.5.1 Token Factory HIPAA Eligibility Scope
HIPAA eligibility is determined at the capability and API-method level.
Customers are responsible for ensuring that requests containing PHI/ePHI are sent only through covered Token Factory capabilities.
5.2 Zero Data Retention Requirement
Customers must enable the required Zero Data Retention (ZDR) configuration before submitting PHI/ePHI to an eligible Token Factory API method. ZDR must be enabled for the Token Factory scope through which the relevant PHI/ePHI requests are processed. The exact configuration scope and behavior of ZDR are defined by the applicable Token Factory Documentation. Where ZDR is not enabled, Token Factory must not be used with PHI/ePHI under this guideline.5.3 Covered API Methods
PHI/ePHI may be transmitted only through Token Factory API methods explicitly designated as covered. Customers are responsible for preventing PHI/ePHI from being sent through excluded or unsupported capabilities. This includes application routing, SDK use, middleware configuration, and any other integration logic that determines which Token Factory APIs receive Customer data.5.4 Data Handling
Customers must not use non-covered Token Factory features to persist, upload, train on, or otherwise process PHI/ePHI. In particular, unless separately approved under an applicable agreement, Customers must not include PHI/ePHI in:- fine-tuning datasets;
- training data;
- uploaded files;
- batch-processing jobs;
- embedding requests;
- dataset-management features; or
- other storage-oriented Token Factory capabilities.
5.5 Regional and Routing Requirements
Customers are responsible for ensuring that Token Factory processing locations and routing configurations satisfy their applicable regulatory, contractual, and data-residency obligations. Where specific Token Factory regions or processing locations are required, Customers must configure their integrations accordingly.5.6 Logging, Monitoring, and Customer Applications
Customers remain responsible for their own application logging and monitoring practices. Applications should be configured so that PHI/ePHI is not unintentionally copied into:- application logs;
- tracing systems;
- analytics systems;
- debugging output;
- monitoring metadata; or
- third-party services that are not approved for PHI/ePHI.
5.7 Token Factory Implementation Checklist
Before processing PHI/ePHI using Token Factory, Customers should verify that:- A BAA with Nebius has been executed.
- The intended Token Factory API method is explicitly covered.
- The required ZDR configuration is enabled.
- ZDR has been verified before submitting PHI/ePHI.
- PHI/ePHI traffic is restricted to covered API methods.
- Fine-tuning, batch inference, embeddings, file upload, dataset management, and other excluded capabilities do not receive PHI/ePHI.
- Application logs and monitoring systems do not capture PHI/ePHI unintentionally.
- Regional and routing requirements have been evaluated.
- Customer IAM and application access controls are appropriately configured.
6. HIPAA Safeguards Alignment
Nebius security controls support the administrative, physical, and technical safeguard categories of the HIPAA Security Rule. The applicability and allocation of individual safeguards depend on the Nebius product and Customer architecture.7. Compliance and Certification References
Nebius maintains security and privacy programs aligned with internationally recognized frameworks and third-party assurance programs. These may include:- ISO/IEC 27001 - Information Security Management System;
- SOC 2 Type II - applicable trust-services controls;
- ISO/IEC 27701 - Privacy Information Management; and
- other certifications and assurance programs applicable to specific Nebius products and services.
8. Recommended Best Practices
Customers using Nebius services for HIPAA-regulated workloads should:- apply least-privilege IAM policies;
- separate HIPAA-regulated workloads from general-purpose environments;
- restrict PHI/ePHI to explicitly approved services and storage locations;
- use application-level encryption where appropriate;
- regularly review IAM bindings, logs, and access patterns;
- periodically verify data integrity;
- test backup and restoration processes where applicable;
- document retention and deletion policies;
- review application logging and telemetry for accidental PHI exposure; and
- periodically validate that the deployed architecture remains within the scope of the applicable BAA and Nebius HIPAA guidance.
Web address: https://docs.nebius.com/legal/hipaa Publication date: September 15, 2026
Effective date: September 15, 2026 Previous version of the document: https://docs.nebius.com/legal/archive/hipaa-20251031