Vendor Risk Management for Femtech Period-Tracking Apps: HIPAA Compliance Essentials

When is a period-tracking app subject to HIPAA?

A period-tracking app is not subject to HIPAA simply because it collects menstrual-cycle, fertility, pregnancy, or other health information. HIPAA generally applies to covered entities—such as certain health plans, health care providers, and health care clearinghouses—and to business associates that handle protected health information on their behalf. A direct-to-consumer app that a person independently downloads and uses is usually outside HIPAA when it operates only for that person, rather than for a covered entity.

The key question is not whether the data is sensitive, but who handles it and for whose purposes. Health information held by an app for its own consumer service is not automatically HIPAA-protected electronic protected health information (ePHI). If a clinic offers an app to patients and the developer manages their data on the clinic’s behalf, however, the developer may be a business associate and HIPAA can apply to that relationship. The HHS resources for mobile health app developers explain how the app’s function and relationship with a provider affect the analysis.

Sharing data with a provider also does not, by itself, make an app developer the provider’s business associate. HHS distinguishes an app that handles information for a covered entity from one that a consumer chooses to use and directs to receive or send information. The provider’s HIPAA obligations and the app’s obligations must be assessed based on their actual roles and arrangements.

How does an app developer become a business associate?

An app developer may become a business associate when it creates, receives, maintains, or transmits protected health information on behalf of—or for the benefit of—a covered entity to perform a covered function or service. For example, a provider that contracts with a developer to supply a period-tracking app to patients, manage cycle data for care, or enable patient messaging may create a business associate relationship if the developer handles PHI for the provider.

By contrast, a consumer’s independent use of a period-tracking app, a clinician’s general recommendation of an app, or an individual’s choice to send app information to a provider does not alone establish that relationship. HHS notes that consumer-directed access or data exchange alone does not make an app developer a business associate; the relevant facts include whether the app is provided by or on behalf of the covered entity. See the HHS guidance on apps designated by individuals.

For vendor risk management, map the relationship before exchanging data. Identify who selects and pays for the app, who determines its role in care, what information it handles, and whether it performs a service on behalf of a covered entity or another business associate. A vendor’s contract label does not replace this factual assessment.

When is a business associate agreement required?

A covered entity generally must have a business associate agreement (BAA) in place before allowing a business associate to create, receive, maintain, or transmit PHI on its behalf. The same obligation applies through the business associate chain: a business associate that engages a subcontractor to handle PHI for it must obtain the required written assurances from that subcontractor. A BAA is not required merely because an app receives information at a user’s direction and does not handle ePHI on behalf of a covered entity.

The agreement must set out permitted and required uses of PHI, require appropriate safeguards, address reporting of improper uses or disclosures and security incidents, and require the business associate to ensure that relevant subcontractors agree to comparable restrictions and safeguards. It should also cover what happens to PHI when the relationship ends, subject to the circumstances described in the rules. See the BAA provisions in 45 C.F.R. § 164.504(e).

Do not treat a signed BAA as proof that a vendor is secure or that the covered entity has completed its own compliance work. The agreement establishes responsibilities; the parties still need to understand the data flows, assess risks, and implement appropriate safeguards.

How to assess vendor risks to electronic protected health information

A HIPAA Security Rule risk analysis should cover the ePHI an organization creates, receives, maintains, or transmits—including data handled by app developers, cloud hosts, analytics tools, and other vendors. HHS describes risk analysis as an assessment of threats and vulnerabilities that could affect ePHI’s confidentiality, integrity, or availability, together with the likelihood of those risks. The analysis must be tailored to the organization; HIPAA does not prescribe one universal assessment method. See the HHS Guidance on Risk Analysis and 45 C.F.R. § 164.308(a)(1).

For each vendor, document and evaluate:

• Data and system scope: What cycle, fertility, appointment, or account data the vendor handles; where it is stored; how it moves between the app, APIs, cloud services, and connected devices; and which systems or people can access it.
• Threats and vulnerabilities: Reasonably anticipated risks such as unauthorized access, compromised credentials, insecure interfaces, lost devices, ransomware, misconfigured cloud storage, or inappropriate onward disclosure.
• Likelihood and impact: How plausible each risk is and what its consequences could be for confidentiality, integrity, availability, and affected individuals.
• Existing safeguards and gaps: Whether security measures are in place and properly configured, who is responsible for them, and what remediation or additional protections are needed.
• Vendor and subcontractor practices: Data retention and deletion, access restrictions, incident escalation, use of analytics and advertising tools, further sharing, and the identities and roles of relevant subcontractors.

As a practical procurement step, request evidence that helps you validate the vendor’s claims—such as security policies, assessment results, incident-response procedures, and details about subprocessors. These are useful due-diligence measures, not a fixed set of documents that HIPAA universally requires a vendor to provide. HHS explains that a covered entity or business associate remains responsible for its own risk analysis when using a cloud service.

What safeguards should cloud and mobile vendors provide?

Vendors handling ePHI should be able to explain how their administrative, physical, and technical safeguards address the risks identified in the organization’s analysis. For a femtech app, assess protections across the entire data lifecycle: collection, device storage, transmission, cloud processing, backups, support access, analytics, retention, and deletion.

Depending on the system and assessed risks, useful controls to evaluate include unique user authentication, role-based access, audit logging, secure app and API design, encryption in transit and at rest, protected backups, vulnerability management, workforce security training, and a tested incident-response process. Review mobile-specific issues too, including sensitive data in notifications, device loss, third-party software development kits, and whether diagnostic or advertising tools receive health-related or identifying data.

These examples are risk-management considerations, not a claim that HIPAA mandates one particular product, encryption configuration, or security certification in every case. HHS states that covered entities and business associates may use cloud and mobile services when they use appropriate safeguards and meet applicable requirements, including entering into a BAA with a cloud service provider that handles ePHI on their behalf. HHS also explains that HIPAA does not expressly require a cloud provider to give customers security documentation or audit access; customers may seek such assurances based on their own risk analysis and contractual needs. See HHS Guidance on HIPAA and Cloud Computing.

How does the FTC Health Breach Notification Rule apply to non-HIPAA apps?

A period-tracking app that is not covered by HIPAA may still fall under the FTC Health Breach Notification Rule. The Rule applies to specified entities, including vendors of personal health records, related entities, and certain third-party service providers. A personal health record under the Rule is an electronic record of identifiable health information that has the technical capacity to draw information from multiple sources and is managed, shared, and controlled by or primarily for the individual. The FTC’s compliance guidance describes the covered categories and gives examples involving health apps.

For example, a period-tracking app may have the technical capacity to combine information entered by a user with information from a phone, wearable, or other connected source. Whether the Rule applies depends on the product’s capabilities, data, and role—not merely on whether every user connects an additional source. Its amended requirements, which took effect July 29, 2024, also clarify that a breach can involve unauthorized disclosure, not just an outside cyberattack. Sharing covered health information without the individual’s authorization may therefore trigger notification duties.

When the Rule applies, covered entities generally must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured identifiable health information. FTC notice is due at the same time as individual notice for breaches involving 500 or more people; for smaller breaches, reporting to the FTC may be made annually within 60 days after the end of the calendar year. Media notice may also be required when at least 500 residents of a particular jurisdiction are affected. The FTC’s Health Breach Notification Rule page summarizes the rule, and the current text of 16 C.F.R. Part 318 provides its requirements.

In short, assess HIPAA based on whether the app handles PHI for a covered entity, and assess the FTC Rule separately for consumer-facing products that may hold identifiable health information. A vendor relationship, data-flow map, documented risk analysis, and appropriate safeguards help clarify which obligations apply and how to manage them.

FAQs

Are direct-to-consumer period-tracking apps covered by HIPAA?

Usually not when a person independently downloads and uses the app for personal purposes and the developer does not handle PHI on behalf of a covered entity or business associate. HIPAA coverage depends on the relationship and function, not simply on the fact that the app collects sensitive health information. The FTC Health Breach Notification Rule or other laws may still apply.

When does a period-tracking app developer need a business associate agreement?

A BAA is generally required when the developer creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate. For example, a provider engaging an app developer to manage patient cycle data as part of its services may need a BAA before the developer handles that information. A user’s independent use of an app or user-directed data exchange alone does not establish the relationship.

What should a HIPAA vendor risk analysis include?

It should identify where ePHI is created, received, maintained, and transmitted; document reasonably anticipated threats and vulnerabilities; assess likelihood and impact; evaluate existing safeguards; and record gaps and risk-management decisions. Include app, cloud, mobile, API, analytics, and subcontractor data flows where relevant. HHS’s risk analysis guidance explains the required scope and core assessment elements.

Can the FTC Health Breach Notification Rule apply to a non-HIPAA health app?

Yes. The Rule can apply to a non-HIPAA app if it is a vendor of a personal health record, a related entity, or a covered third-party service provider, and an incident involves unsecured identifiable health information. Depending on the circumstances, unauthorized sharing can count as a breach even without a hacking incident. The FTC’s business guidance explains the Rule’s scope and notification responsibilities.