Three rule sets shape healthcare software testing, and they ask for different evidence. HIPAA asks whether electronic protected health information (ePHI) is safeguarded, so testing targets access control, audit logs, encryption and the handling of patient data in test environments. FDA rules ask whether a regulated system or device does what it is intended to do, which means documented validation and, for electronic records, 21 CFR Part 11 controls. IEC 62304 asks whether medical device software was built and verified under a defined lifecycle, with rigor set by its safety class.
| Framework | Applies to | What testing must show | Typical evidence |
|---|---|---|---|
| HIPAA Security Rule | Covered entities and business associates handling ePHI | Technical safeguards work; risks are analysed and re-evaluated | Risk analysis, safeguard test results, gap report, BAA |
| FDA software validation and 21 CFR Part 11 | Device makers, pharma, clinical research systems that keep regulated records | The system fits its intended use; records and signatures are trustworthy | Validation plan, requirements trace, IQ/OQ/PQ or risk-based assurance records, validation summary |
| IEC 62304 | Software that is a medical device or part of one | Lifecycle activities done to the rigor of safety class A, B or C | Software development plan, verification records, integration and system test reports, traceability |
What Is HIPAA Compliance Testing?
HIPAA compliance testing checks that software which creates, stores or transmits ePHI meets the safeguards of the HIPAA Security Rule. Most test cases trace to the technical safeguards in 45 CFR 164.312:
- Access control: unique user IDs, emergency access, automatic logoff, encryption of stored ePHI.
- Audit controls: every read, change and export of ePHI leaves a record that can be reviewed.
- Integrity: ePHI cannot be altered or destroyed without authorisation, and tampering is detectable.
- Person or entity authentication: the system confirms who is asking before it releases data.
- Transmission security: ePHI is protected in transit, typically with current TLS.
The administrative safeguards in 45 CFR 164.308 add a risk analysis and a periodic technical and nontechnical evaluation. Test results feed both. A useful output is a gap report that maps each safeguard to a passed test, a failed test or an open risk, so the compliance officer and the engineering lead read the same document.
HIPAA Compliance Testing vs Security Testing
The two overlap but answer different questions. Security testing asks how an attacker could get in; it covers the OWASP Top 10, authentication bypass, injection, misconfigured cloud storage and exposed APIs, whether or not health data is involved. HIPAA compliance testing asks whether each required safeguard exists and works, and it includes items no attacker cares about: audit log completeness, automatic logoff, minimum-necessary access by role, and the absence of real patient data in non-production systems. A clean penetration test does not prove compliance, and a passed compliance checklist does not prove the system resists attack. Most healthcare teams run both and cross-reference the findings in one risk register.
Does HIPAA Require Penetration Testing?
The current Security Rule does not name penetration testing. It requires a risk analysis and periodic evaluation of safeguards, and penetration testing is a common way to produce evidence for both. That may change. In a notice of proposed rulemaking published on 6 January 2025, HHS proposed vulnerability scanning at least every six months and penetration testing at least once every 12 months. As of 2 October 2026 that rule is still a proposal; check the HHS NPRM page before you plan around it. Many buyers already budget for an annual test plus a retest after each major release; the cost guide covers typical price points.
Does a QA Vendor Need a BAA? PHI in Test Environments
A QA vendor needs a business associate agreement when it creates, receives, maintains or transmits PHI on behalf of a covered entity or another business associate. HHS sample BAA provisions show what the contract covers: permitted uses, safeguards, breach reporting and flow-down to subcontractors. If testers only ever see synthetic data, or data de-identified under 45 CFR 164.514 by Safe Harbor or Expert Determination, a BAA is usually not triggered. In practice, production log access, support tickets and database copies pull testers into PHI more often than test plans suggest.
What to check in a vendor's public material:
| Question | Example from the ranked vendors |
|---|---|
| Does the vendor sign a BAA before work starts? | DeviQA states it signs BAAs before engagement, together with NDAs and DPAs (source). |
| What test data is the default? | DeviQA states synthetic or de-identified data by default, with PHI access role-restricted and logged (source). |
| What happens when production-like data is needed? | Citrusbug Technolabs states that de-identification procedures and BAA documentation come first (source). |
| Is a BAA statement published at all? | No public BAA statement was found for a1qa or BetterQA; ask for one during selection. |
The trust and compliance block of the ranking covers BAA statements and certifications in more detail.
FDA Software Validation and 21 CFR Part 11
FDA's General Principles of Software Validation defines validation as confirming, with objective evidence, that software specifications conform to user needs and intended uses. For device makers, this sits inside the design controls of the Quality Management System Regulation, which took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. Software used to run production or the quality system itself falls under FDA's Computer Software Assurance guidance, which lets teams scale testing effort to risk rather than script every step.
21 CFR Part 11 applies when a system keeps electronic records or signatures that FDA rules require. Section 11.10 lists the controls that testing has to exercise:
- system validation for accuracy, reliability and the ability to detect invalid or altered records;
- secure, computer-generated, time-stamped audit trails that do not overwrite earlier entries;
- limits on system access to authorised people, and authority checks on actions;
- operational checks that enforce the permitted sequence of steps.
Signature tests add the manifestation rules of section 11.50 (name, date and time, meaning) and the record linking of section 11.70.
What Is Computer System Validation?
Computer system validation (CSV) is the documented process of showing that a computerised system used in a GxP context does what it is meant to do, every time. Classic CSV runs as a V-model: user requirements, functional specification, a risk assessment, then three qualification stages.
| Stage | Question it answers | Typical tests |
|---|---|---|
| IQ (installation qualification) | Is the system installed and configured as specified? | Versions, configuration settings, interfaces, environment checks |
| OQ (operational qualification) | Does each function work across its specified range? | Function tests, boundary values, security roles, audit trail, alarms |
| PQ (performance qualification) | Does it work in real use with real workflows? | End-to-end process runs by trained users with representative data |
A traceability matrix links each requirement to its tests, and a validation summary report closes the package. For clinical research platforms, FDA's question-and-answer guidance on electronic systems in clinical investigations explains how Part 11 applies to sponsors, sites and CROs, including systems run by service providers.
What Is IEC 62304? Safety Classes and V&V Records
IEC 62304 defines lifecycle processes for medical device software: development, maintenance, risk management (with ISO 14971), configuration management and problem resolution. The edition in use is the 2006 text with Amendment 1 of 2015. FDA lists it as a recognised consensus standard, so device submissions often declare conformity to it. Each software system gets a safety class, and the class sets how much verification you must document.
| Class | Hazard if the software fails | Testing and documentation impact |
|---|---|---|
| A | No injury or damage to health is possible | Requirements, system testing, release and problem records |
| B | Non-serious injury is possible | Adds architecture, unit verification, integration testing |
| C | Death or serious injury is possible | Adds detailed design per unit and extra unit acceptance criteria |
IEC 62304 testing is therefore less about test volume and more about records: each requirement traced to a test, each anomaly logged and assessed for risk, each release tied to a verified build.
SaMD Verification and Validation and Device Cybersecurity
Software as a Medical Device (SaMD) is software intended for a medical purpose that performs that purpose without being part of a hardware device; FDA uses the IMDRF definition. Verification shows the software meets its specification. Validation shows the finished product meets user needs in its intended use, which for SaMD includes clinical evidence and usability work. FDA's premarket guidance for device software functions sets a Basic or Enhanced documentation level for the submission.
Connected devices add a security layer. Section 524B of the FD&C Act requires makers of cyber devices to submit a software bill of materials and a plan to monitor and address vulnerabilities. FDA's cybersecurity guidance expects security testing evidence such as penetration testing, vulnerability scanning and fuzz testing in the submission.
Testing a Healthcare Application vs a Medical Device
Many health apps are not medical devices. Scheduling, billing, patient portals and general wellness apps usually fall outside device rules, as FDA's policy for device software functions explains. The difference shows up in what testing produces.
| Aspect | Healthcare application (non-device) | Medical device software or SaMD |
|---|---|---|
| Main rules | HIPAA, state privacy laws, ONC rules for certified EHRs | FDA QMSR and premarket rules, IEC 62304, ISO 14971, EU MDR |
| Test focus | Functions, security, PHI handling, interoperability, accessibility | Requirement-level verification, risk controls, clinical validation |
| Change control | Agile releases, regression suites | Every change assessed for risk and regulatory impact |
| Evidence | Test reports and a HIPAA gap analysis | Traceable V&V records that go into the design history file |
An app can move from one column to the other when a new feature makes a diagnostic or treatment claim, so classify features before each release. Interoperability testing applies to both; the HL7, FHIR and EHR testing guide covers it.
Choosing a HIPAA or IEC 62304 Testing Company
Ask for named deliverables, not a list of standards on a services page. The examples below come from the vendors' public material; the comparison table and best pick by scenario cover all 12 ranked vendors, and the methodology explains how this evidence was scored.
| Need | Ask for | Public example |
|---|---|---|
| IEC 62304 V&V | V&V plan, verification reports, traceability review | ScienceSoft describes V&V plans with acceptance criteria and verification reports for all three safety classes (source) |
| Class C device testing | A case that names the safety class | a1qa publishes a case verifying blood-processing device software against Class C requirements (source) |
| Vendor QMS for device work | ISO 13485 certificate number you can check | BetterQA publishes ISO 13485 certificate 13/RSC01786/0001/EN (source) |
| Part 11 or CSV package | Sample IQ/OQ/PQ protocol and validation summary | ScienceSoft lists IQ/OQ/PQ documentation on a practice page; no public case with these deliverables was found (source) |
| HIPAA testing with a BAA | BAA template and test-data policy | DeviQA, as shown above |
If a vendor cannot show a redacted sample of the document you need, treat the claim as unverified. The guide to choosing a testing company has a question list for that conversation.
HIPAA, FDA and IEC 62304 Testing: FAQ
How often should HIPAA compliance testing be done?
The HIPAA Security Rule does not set a fixed interval. It requires a periodic technical and nontechnical evaluation, and a new evaluation when the environment or operations change. Most teams test after each major release, after infrastructure or vendor changes, and at least once a year. An HHS proposal from January 2025 would require vulnerability scans every six months and a penetration test every 12 months; as of October 2026 it is not final, so treat those figures as a planning reference.
What is the difference between a BAA and an NDA?
An NDA protects confidential business information and is a private contract with terms the parties choose. A business associate agreement is required by HIPAA whenever a vendor handles PHI for a covered entity or another business associate. It must state permitted uses of PHI, require safeguards, set breach reporting duties and bind subcontractors to the same terms. An NDA cannot replace a BAA, so QA vendors that touch PHI usually sign both.
What is SaMD?
SaMD stands for Software as a Medical Device: software intended for one or more medical purposes that performs them without being part of a hardware device. Examples include software that analyses images to flag findings or calculates a dose. FDA uses the definition from the International Medical Device Regulators Forum. SaMD is regulated as a device, so its testing follows design controls, IEC 62304 lifecycle rules and ISO 14971 risk management.
What does IEC 62304 testing include?
IEC 62304 testing covers the verification tasks the standard requires for the software's safety class. Class A software needs requirement-based system testing and release records. Class B adds architecture checks, unit verification and integration testing. Class C adds detailed design per unit and extra unit acceptance criteria. At every class, each anomaly is logged and assessed for risk, and each requirement is traced to a test and a result. The output is a set of records for the design history file.
What does 21 CFR Part 11 validation cover?
Part 11 validation shows that a system holding FDA-required electronic records or signatures is accurate and reliable and can detect invalid or altered records. Tests exercise access limits, authority checks, time-stamped audit trails that keep earlier entries, operational sequence checks and record copying for inspection. Signature tests confirm that each signed record shows the signer's name, the date and time and the meaning of the signature, and that signatures cannot be moved to other records.
What do computer system validation services deliver?
A computer system validation service usually delivers a validation plan, user and functional requirements, a risk assessment, IQ, OQ and PQ protocols with executed results, a traceability matrix and a validation summary report. For production and quality system software at device makers, FDA's Computer Software Assurance guidance allows lighter, risk-based records for low-risk functions. Ask a vendor for a redacted sample of each document before signing, because services pages often list CSV without showing deliverables.
How is a clinical trial system validated?
Clinical trial systems such as EDC, eCOA, eTMF and randomisation tools are validated against their intended use in the study. The sponsor stays responsible even when a service provider hosts the system. FDA's 2024 question-and-answer guidance on electronic systems in clinical investigations explains how Part 11 applies, including audit trails, access controls and the sponsor's oversight of vendor validation. Expect requirement-based testing, a traceability matrix and documented change control for each study build.
What does a HIPAA penetration test cover?
A HIPAA-focused penetration test attacks the paths to ePHI: web and mobile apps, APIs, cloud storage, authentication and session handling, and integration endpoints such as HL7 or FHIR interfaces. Findings are rated by severity and mapped to Security Rule safeguards so they feed the risk analysis. A retest confirms fixes. The tester needs a BAA if any PHI may be exposed during the test, and the scope should say whether production systems are in or out.