HIPAA in the UK: the UK equivalent and what it means for health software

The UK has no HIPAA. Its closest equivalent is the UK GDPR together with the Data Protection Act 2018 (DPA 2018), which protect health data held by organizations based in the UK or serving people there, not only by healthcare providers and their vendors. Software used by the NHS in England has to pass extra NHS checks, and some health apps are medical devices. We build healthcare apps to UK or US data protection requirements, with prices from $30,000, and estimate a second market separately.

This guide is for teams that build a health product for UK patients, US patients or both. It explains what each set of rules asks of the software, when a UK company still needs HIPAA, and what that changes in the product and the budget. It does not replace legal advice: your lawyer confirms which rules apply to you.

Does the UK have HIPAA?

No. HIPAA is a US law, and its rules apply to covered entities and business associates; an organization that is neither a covered entity nor a business associate “does not have to comply with the HIPAA Rules”. HIPAA names three kinds of covered entities: health plans, health care clearinghouses, and health care providers that send health information electronically in transactions HIPAA covers, such as insurance claims. A UK clinic or health app does not become one by holding health data.

HIPAA typically reaches a UK company through US work, when the company handles protected health information (PHI) for a US covered entity, either directly or as a subcontractor of one of its business associates. The rules can also reach a UK health care provider that is itself a covered entity, for example because it sends claims to a US health plan electronically.

What is the UK equivalent of HIPAA?

The UK GDPR and the DPA 2018 are the closest UK match to HIPAA: they set the main duties for health data. Other rules can also apply: the duty of confidentiality under common law covers what patients tell their clinicians, software for the NHS in England has its own checks, and a medical app can fall under medical device rules.

• UK GDPR and the DPA 2018. The UK GDPR defines data concerning health as personal data about a person's physical or mental health, including the health care they receive, that reveals their health status. It is a special category: Article 9 prohibits processing it unless one of the listed conditions applies. For health care, that condition is set out in the DPA 2018, Schedule 1, “health or social care purposes”.
• The common law duty of confidentiality. The ICO notes that in health care “patient data is held under a duty of confidence”, and providers generally share it for direct care on the basis of implied consent. This duty applies alongside the UK GDPR and does not replace it.
• NHS requirements. Security, clinical safety and technical checks for products that NHS organizations in England use.
• Medical device rules. Software with a medical purpose can be a medical device regulated by the MHRA.

Under Article 3 of the UK GDPR, the law applies to organizations established in the UK and to organizations abroad that offer goods or services to people in the UK or monitor their behavior there. The sector does not matter, so a fitness app, an employer well-being tool and a private clinic that serve people in the UK all fall under it.

The ICO, the UK data protection regulator, enforces the UK GDPR. Organizations that use personal information pay the ICO a data protection fee unless they are exempt. From September 30, 2026, the Information Commissioner's Office is the Information Commission. It keeps its regulatory functions and is still known as the ICO.

HIPAA vs UK healthcare laws: key differences

The biggest difference is scope. HIPAA protects PHI held by covered entities and their business associates, while UK law protects health data in any sector, held by UK organizations or by organizations abroad that serve or monitor people in the UK. UK law also gives people extra rights, such as erasure where the lawful basis allows it, and sets higher maximum fines. The table compares the points that change how a product is built.

What UK data protection law requires from a health app

Before launch, a health app in the UK needs a legal ground for each use of health data, a data protection impact assessment (DPIA) where the processing is likely to be high risk, security measures matched to the risk, contracts with its vendors and a way to answer patient requests. After launch, it needs a process for reporting breaches:

• A lawful basis and a condition. Health data needs both: a basis under Article 6 and a condition under Article 9. The ICO says that “in the healthcare context consent is often not the appropriate lawful basis”; it tells providers to identify another basis, used together with the health or social care condition. A consumer wellness app is a different case, and the choice of basis also decides which patient rights apply.
• A DPIA. Article 35 requires one where processing is likely to result in a high risk to people's rights and freedoms, and in particular for processing special category data, such as health data, on a large scale. The ICO's example of large scale is a hospital processing patient data, not an individual doctor, and it recommends a DPIA whenever you are in doubt.
• Security. Article 32 asks for measures appropriate to the risk and names encryption, the ability to restore data after an incident, and regular testing of those measures.
• Processor contracts. Every vendor that processes personal data for you, such as the cloud host or the email service, works under a contract with the terms that Article 28 requires.
• Patient rights. Access requests are answered within one month. The rights to erasure and to portability depend on the lawful basis: where the processing relies on the condition for health or social care, the ICO says the person has no right to erasure.
• Breach reporting. A breach goes to the ICO without undue delay and, where feasible, within 72 hours, unless it is unlikely to put people at risk. Affected people are told when the risk to them is high.

The Data (Use and Access) Act 2025, which received Royal Assent on June 19, 2025, amended parts of the UK GDPR, and its changes come into force in stages. The ICO marks several guidance pages as under review because of it, so check the current text of each page you rely on.

Extra rules for software used by the NHS in England

If NHS organizations in England will use your product, expect three more checks on top of the UK GDPR: the Data Security and Protection Toolkit (DSPT), the Digital Technology Assessment Criteria (DTAC) and the clinical safety standards DCB0129 and DCB0160. They cover security, the product as a whole and the risk of harm to patients.

• DSPT. An online self-assessment against the National Data Guardian's 10 data security standards. Every organization that has access to NHS patient data and systems must use it, and the assessment is repeated every year. The 2026-27 version has its own set of evidence items for IT suppliers.
• DTAC. An assessment framework that NHS and social care buyers use to check a digital health product in five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. NHS England introduced a shorter form in 2026, and the previous form should not be used from April 6, 2026.
• DCB0129 and DCB0160. Clinical risk management standards required under the Health and Social Care Act 2012. DCB0129 applies to the manufacturer of a health IT system and DCB0160 to the organization that deploys it. DCB0129 requires a Clinical Safety Officer, who must be a registered clinician with suitable experience. NHS England ran a public consultation on both standards until September 11, 2026, to inform their revision.

Under the Data (Use and Access) Act 2025, since February 5, 2026, information standards for health and adult social care in England can apply directly to IT providers and cover the design, security and interoperability of their products. Ask your NHS customer which standards apply to your product type.

When a health app is a medical device in the UK

A health app counts as a medical device when its manufacturer intends it for a medical purpose, such as the diagnosis, prevention, monitoring or treatment of a disease. The MHRA then regulates it, and it needs a UKCA marking, or a CE marking that Great Britain still accepts, before it goes on the Great Britain market. An app that books appointments or stores records without a medical purpose is not a device.

• Intended purpose. The definition in the Medical Devices Regulations 2002 includes software, and what counts is the purpose the manufacturer states on the labeling, in the instructions for use and in promotional materials, so the purpose stated on the landing page and in the app store text counts too. MHRA guidance helps manufacturers write an intended use statement for software.
• Marking and registration. Per MHRA guidance, every device must be registered with the MHRA before it is placed on the Great Britain market. CE-marked devices are accepted until June 30, 2030 at the latest, depending on the type of device and the EU rules it meets.
• After launch. Stricter post-market surveillance requirements came into force on June 16, 2025, so the product needs a way to collect and act on reports about its safety and performance.

For NHS buyers, the DTAC also asks for proof that a device has a UKCA marking or a recognized equivalent. How device software is built, and how FDA and EU rules treat it, is covered in our guide to medical device software development.

When a UK company still needs HIPAA

A UK company needs HIPAA when it creates, receives, stores or transmits PHI on behalf of a US covered entity or of a business associate working for one, for example by running a US clinic's patient portal or storing a US health plan's records. That makes it a business associate. A consumer app that people use for themselves, with no US provider or health plan behind it, usually stays outside HIPAA.

• A business associate agreement. The covered entity, or the business associate that hires you, must have a written contract with you, and business associates are also directly liable for parts of the HIPAA Rules. The contract commits you to the Security Rule for electronic PHI and to reporting breaches to that customer promptly and within 60 days of discovery at the latest.
• Your own vendors. A cloud host, email service or backup tool that handles the PHI for you is your subcontractor and signs a BAA with you. HHS's cloud computing guidance allows PHI on servers outside the United States under a BAA, and asks you to weigh the risks of that location in your risk analysis.
• Consumer apps. In its health app scenarios, HHS says a developer that only offers services directly to consumers, and not on behalf of a provider, health plan or clearinghouse, is “not likely to be subject to HIPAA”. The same developer becomes a business associate for an app it offers on behalf of a covered entity. A consumer app that keeps health data of US users can instead fall under the FTC Health Breach Notification Rule, which applies to foreign and domestic vendors of personal health records and requires breach notices to users and the FTC.

There is no official HIPAA certification in the UK or the US. HHS answers the question in a Security Rule FAQ: covered entities are not required to certify their compliance, and HHS does not endorse private “certifications”. A US customer checks your risk analysis, your policies and the controls in the product instead. For other US laws that can apply to a health product, see our guide to healthcare laws and regulations in the US.

What the rules change in the product

HIPAA and UK law use different words, but one set of features in the code can serve both: know where health data lives, let only the right people see it, record who opened what, and be ready to answer patients and regulators. The list below shows how that can look in a patient app, a clinic dashboard or a backend that stores health records.

• A data map. A list of every field that holds health data, where it is stored and who can open it. The HIPAA risk analysis, any DPIA and every later decision start from this list.
• Roles and access control. A nurse sees only their own patients, a support agent sees an account without the medical history, and an admin cannot read records by default. This is one way to meet HIPAA's minimum necessary standard, which asks for reasonable efforts to limit health data to what the purpose needs.
• An audit log. Who opened, changed or exported a record, and when. HIPAA lists audit controls among its technical safeguards, and the same log is your evidence when the ICO asks what happened after a breach.
• Encryption at rest and in transit. HIPAA marks encryption as “addressable”, which means you either use it or write down why not and what you use instead. An HHS proposal of January 2025 would make encryption required, but it has not become a final rule. The UK GDPR names encryption among its example security measures, so a product for both markets builds it in.
• Strong sign-in. The HIPAA Security Rule requires procedures to verify that a person or entity seeking access is the one claimed and marks automatic logoff after a set time of inactivity as addressable. The UK GDPR names no sign-in control and asks for security that fits the risk. Two-factor authentication for staff and admins, session timeouts and short-lived tokens are controls the team chooses under its risk analysis.
• Patient request flows. Access and export of a patient's data and, where UK law gives the right, deletion, handled from the admin panel with a record of each request, so the team meets the deadlines in the table above.
• Third-party tools. Analytics, crash reporting and support chat can capture health data from screens and logs. Each such tool is either kept away from health data or covered by a contract: a processor contract in the UK, a BAA in the US.
• A breach playbook. One process that covers both deadlines: the ICO within 72 hours where feasible, and HIPAA notices as soon as reasonably possible, but no later than 60 days.

One of our projects has some of these controls in a real product: a web platform where patients kept their lab test results and shared them with a doctor or coach. We built its security controls to HIPAA requirements so that users and potential investors would trust the platform with medical data. We built the backend on Laravel, the frontend on Angular and the database on Google Cloud SQL. We made the second sign-in step use a code from an authenticator app instead of SMS or email, and set inactive sessions to log out automatically. We also set up monitoring alerts and extended the retention period for database backups. We also gave admins a place in the admin panel to handle requests to delete user data. The first version was followed by four more years of work with the same client. In a UK product, the same controls would serve the UK GDPR security duty, and the deletion flow would handle erasure requests where that right applies.

Building one product for UK and US users

One codebase can serve both markets if three things are decided for both from the start: where each patient's data is stored, which contracts cover each vendor, and which rules the shared features follow. When a UK rule and a HIPAA rule ask for the same feature, build it once to the stricter of the two.

• Storage regions. Sending UK patient data to a US cloud region is a transfer abroad under the UK GDPR. The UK-US data bridge, in effect since October 12, 2023, covers transfers only to US organizations that joined the Data Privacy Framework and its UK Extension. Decide in which region UK and US records are stored, and check where each vendor that sees UK data processes it.
• Vendor contracts. For US data, each vendor that stores or processes PHI for you is a subcontractor business associate and needs a BAA with you. For UK data, the same vendor needs a processor contract. Check both before you pick the email, SMS, storage and analytics providers.
• Shared features. The access rules, the audit log, sign-in and encryption work the same for every patient. Market-specific parts, such as consent texts, request deadlines and breach contacts, are configuration.

“With one codebase for two markets, the typical bug is a change made for one market that breaks the other. Run your automated tests against the UK settings and the US settings on every release, not only against the market you just changed.”

Alexander Storozhevsky, Lead developer at Ronas IT

How much a health app built to UK and US rules costs

The controls listed above go into the whole product, from the patient-facing app to the backend that stores the records. For one market, the UK or the US, such a product starts at $30,000 for one client platform, and the build runs at least 10 weeks. Design, project management, the admin panel and the integrations the product needs are inside that figure, not added to it.

A second market adds work, such as a second storage region, more vendor contracts and a longer list of patient request flows. So does the work for the NHS checks (DSPT, DTAC and DCB0129) if NHS organizations in England will use the product. If the product is a medical device, the regulated device work is part of the product estimate rather than a separate charge. We estimate this extra work from your data map and markets. An analysis phase, which we recommend but which is optional, uses them to work out what the product needs, what it costs and how long it takes.

Production runs in your own cloud account, and the provider sends the hosting bill to you. Legal advice, any DPIA sign-off and, for NHS products, the clinical safety sign-off stay with you and your advisers.

“Before you compare quotes, give every vendor the same data map and the same list of markets, and ask each one what its price leaves out. Two estimates for ‘an app that meets HIPAA and GDPR’ can describe two different products, and the difference shows only when you put those answers side by side.”

Roman Surikov, CEO at Ronas IT

What to do next

1. Ask your lawyer three questions. Will you handle PHI for US covered entities or their business associates? Will NHS organizations in England use the product? Could it be a medical device?
2. Write the data map. Every field with health data, where it is stored and who sees it.
3. Check early whether you need a DPIA. It is required for high-risk processing, such as large-scale processing of health data, and the risks it finds become features.
4. Choose regions and vendors. Decide where UK and US records live and which tools will touch health data, and check that each vendor signs the contract you need.
5. Ask for an estimate. We send a rough estimate first. An optional paid analysis phase, which we recommend before the build, gives you a document that describes the work for your target markets and estimates its cost and duration.

Send us your data map and target markets, and we will come back with what the build needs and how to scope it.

Get an estimate