> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # HIPAA Compliance The Health Insurance Portability and Accountability Act (HIPAA) is a U.S. law that sets national standards for protecting the privacy and security of protected health information (PHI). It includes rules that govern how Covered Entities and their Business Associates use, disclose, protect, and provide access to PHI (Protected Health Information) across electronic, paper, and oral formats. **Note:** The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see [Shared Responsibility Model.](https://www.mongodb.com/resources/products/fundamentals/shared-responsibility) Under HIPAA: - MongoDB is a [Business Associate](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html), meaning an entity that performs certain functions or activities involving the use or disclosure of PHI (Protected Health Information) on behalf of, or provides services to, a Covered Entity. - MongoDB's customers are usually [Covered Entities](https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html), such as healthcare providers, health plans, or healthcare clearinghouses, that create, receive, maintain, or transmit PHI (Protected Health Information), but MongoDB's customers can also be Business Associates. - [Protected Health Information (PHI)](https://www.hhs.gov/answers/hipaa/what-is-phi/index.html) is any individually identifiable health information held by a Covered Entity or Business Associate, including, for example, names, addresses, Social Security numbers, medical records, test results, and insurance information. HIPAA establishes the following core rules for compliance: - [Privacy Rule](https://www.hhs.gov/hipaa/for-professionals/privacy/index.html): governs how protected health information (PHI) can be used and disclosed, and gives individuals rights over their health information - [Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/index.html): governs how Covered Entities and their Business Associates must protect individuals' electronic personal health information (ePHI) - [Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html): governs how Covered Entities and their Business Associates provide notification following a breach of unsecured PHI (Protected Health Information) **Important:** To learn more about MongoDB's privacy and data protection program, including information on our Data Processing Agreement, see: - [MongoDB Privacy Hub](https://www.mongodb.com/legal/privacy) - [MongoDB Trust Center](https://www.mongodb.com/products/platform/trust) MongoDB has completed an independent assessment of its HIPAA Security Rule compliance. To obtain a copy of the independent practitioner's report: - Existing customers can request a copy through the [Customer Trust Portal](https://trust.mongodb.com/) - Prospective customers can request access by contacting the [MongoDB Sales team](https://www.mongodb.com/company/contact?tck=docs) [Connect with our Sales team](https://www.mongodb.com/company/contact?tck=docs) to request a Business Associate Agreement (BAA). To learn more, see the [HIPAA and Atlas For Government](https://www.mongodb.com/products/platform/trust/hipaa-atlas-for-government?tck=docs) page in the MongoDB Trust Center. ## Privacy Rule MongoDB Atlas provides features that support compliance for the Privacy Rule: ### Individual Right of Access and Record Rectification The Privacy Rule gives individuals rights over their health information, including the right to examine and obtain a copy of their health records and to request corrections where appropriate. The following MongoDB Atlas features support compliance in this area: - The [Atlas UI](https://www.mongodb.com/docs/atlas/atlas-ui/documents/) and MongoDB [Drivers](https://www.mongodb.com/docs/drivers/) allow authorized users to securely connect to your MongoDB Atlas deployment and view, create, update, or delete documents containing an individual's PHI (Protected Health Information) in accordance with your policies. - Atlas's robust [query capabilities](https://www.mongodb.com/docs/atlas/atlas-search/return-scope/) enable authorized users to locate and retrieve an individual's PHI (Protected Health Information) using rich filters and aggregation capabilities. ### Data Retention and Secure Disposal The Privacy Rule sets standards for how Covered Entities should protect PHI (Protected Health Information) throughout its lifecycle, including when PHI (Protected Health Information) is no longer needed and must be securely disposed of. The following MongoDB Atlas Architecture Center articles describe Atlas features that support compliance in this area: - [Guidance for Atlas Disaster Recovery](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-dr): Create backups of your data for recovery purposes during its retention period, enable compliance policies to prevent backups from being modified or deleted, and securely delete backups when they are no longer needed. - [Guidance for Atlas Data Encryption](https://www.mongodb.com/docs/atlas/architecture/current/data-encryption.md#std-label-arch-center-data-encryption): Use encryption features to protect PHI (Protected Health Information) at rest, in transit, and in use throughout its lifecycle, including when it is being deleted. ### Minimum Necessary Standard (Data Minimization) The Privacy Rule's minimum necessary standard is the principle that Covered Entities must take reasonable steps to use, disclose, and request only the minimum amount of PHI (Protected Health Information) needed to accomplish the intended purpose of the use, disclosure, or request. The following MongoDB Atlas Architecture Center articles describe Atlas features that support compliance in this area: - [Guidance for Atlas Auditing and Logging](https://www.mongodb.com/docs/atlas/architecture/current/auditing-logging.md#std-label-arch-center-auditing-logging): Monitor, record, and review database events such as user authentication attempts and permission adjustments that impact access to PHI (Protected Health Information). - [Guidance for Atlas Data Encryption](https://www.mongodb.com/docs/atlas/architecture/current/data-encryption.md#std-label-arch-center-data-encryption): Apply encryption in use techniques like Client-Side Field Level Encryption (CSFLE) and Queryable Encryption to limit exposure of sensitive PHI (Protected Health Information) data to only authorized application components and users. ## Security Rule MongoDB Atlas provides features that support compliance for the Security Rule: ### Encryption and Transmission Security The Security Rule sets standards for how Covered Entities must ensure the confidentiality, integrity, and availability of ePHI (electronic Protected Health Information), including by implementing technical security measures guarding against unauthorized access to ePHI (electronic Protected Health Information) that is being transmitted over an electronic network. The following MongoDB Atlas Architecture Center article describes Atlas features that support compliance in this area: - [Guidance for Atlas Data Encryption](https://www.mongodb.com/docs/atlas/architecture/current/data-encryption.md#std-label-arch-center-data-encryption): Ensure data encryption in transit (TLS), at rest (AES-256, BYOK, CMK, KMS, or TDE), and in use (CSFLE, random encryption, or queryable encryption). - [Guidance for Atlas Network Security](https://www.mongodb.com/docs/atlas/architecture/current/network-security.md#std-label-arch-center-network-security): Safeguard network access to Atlas clusters and protect ePHI (electronic Protected Health Information) during transmission with encryption in transit, IP access lists, firewall configurations, private endpoints, and network isolation. ### Access Control The Security Rule requires that only authorized personnel have access to ePHI (electronic Protected Health Information). The following MongoDB Atlas Architecture Center articles describe Atlas features that support compliance in this area: - [Guidance for Atlas Authentication](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-authentication-recs): Control access to your Atlas databases by implementing secure identity management with authentication mechanisms such as Federated Authentication with IdPs (Identity Providers), AWS (Amazon Web Services) IAM (Identity and Access Management) role authentication, multi-factor authentication (MFA), and more. - [Guidance for Atlas Authorization](https://www.mongodb.com/docs/atlas/architecture/current/auth/authorization.md#std-label-arch-center-authorization-recs): Ensure that only authorized personnel can access ePHI (electronic Protected Health Information) based on their specific job functions and responsibilities by implementing secure access management with role-based access control (RBAC). ## Breach Notification Rule MongoDB Atlas provides features that support compliance for the Breach Notification Rule: ### Auditing and Information System Activity Review The Breach Notification Rule asks Covered Entities and Business Associates to implement mechanisms that record and examine activity in information systems containing or using ePHI (electronic Protected Health Information). The following MongoDB Atlas Architecture Center articles describe Atlas features that support compliance in this area: - [Guidance for Atlas Auditing and Logging](https://www.mongodb.com/docs/atlas/architecture/current/auditing-logging.md#std-label-arch-center-auditing-logging): Monitor, record, and review database events such as user authentication attempts and permission adjustments. - [Guidance for Atlas Monitoring and Alerts](https://www.mongodb.com/docs/atlas/architecture/current/monitoring-alerts.md#std-label-arch-center-monitoring-alerts): Track cluster health, performance, and operational metrics, and configure alerts that can surface anomalous activity relevant to ePHI (electronic Protected Health Information). You can also leverage [Atlas Stream Processing](https://www.mongodb.com/docs/atlas/atlas-stream-processing.md#std-label-atlas-sp-overview) to build custom data processing pipelines on top of real-time data streams including Kafka topics, Kinesis, and Atlas [Change Streams](https://www.mongodb.com/docs/manual/changeStreams/), a native MongoDB feature that exposes an ordered stream of change events (insert, update, delete, etc.) from your MongoDB collections, databases, or clusters. You can integrate Atlas Stream Processing with third-party monitoring and logging tools to create a comprehensive view of system activity for your applications that process ePHI (electronic Protected Health Information). ### Breach Notification and Incident Response The Breach Notification Rule sets standards for how Covered Entities and Business Associates should provide notification following a breach of unsecured PHI (Protected Health Information). - [Third-Party Integrations](https://www.mongodb.com/docs/atlas/tutorial/third-party-service-integrations/) with SIEM (Security Information and Event Management) tools like PagerDuty, Microsoft Teams, and Prometheus, support alert routing, on-call notification, and coordinated incident response workflows. ### Contingency Planning: High Availability and Disaster Recovery MongoDB Atlas provides features that support contingency planning to ensure the availability and recoverability of ePHI (electronic Protected Health Information) in the event of an emergency or other event that damages systems containing ePHI (electronic Protected Health Information). The following MongoDB Atlas Architecture Center articles describe Atlas features that support compliance in this area: - [Guidance for Atlas High Availability](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-high-availability): Create cluster configurations that meet your availability needs and expedite recovery from disasters through automated failover and data replication. - [Guidance for Atlas Disaster Recovery](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-dr): Create and manage backups of your Atlas clusters to meet your RPO (Recovery Point Objective) and RTO (Recovery Time Objective) goals. - [Guidance for Atlas Disaster Recovery](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-dr): Create a disaster recovery plan with steps to take if you experience an outage, accidental deletion of prod data, and more.