HIPAA vs PCI DSS: which applies to your practice, pharmacy or health tech product
If your practice, pharmacy or health tech product stores or transmits electronic protected health information and also takes card payments, HIPAA and PCI DSS are both likely required. They answer different questions, and neither replaces the other. HIPAA asks whether you protect ePHI under the Security Rule in 45 CFR Part 164 Subpart C, enforced by HHS Office for Civil Rights. PCI DSS asks whether you protect cardholder data and the systems that touch it, enforced through payment brand programs. Our recommendation is to pursue HIPAA for ePHI regardless of payments, pursue PCI DSS for any cardholder data environment, and shrink the PCI footprint first by using a PCI-listed P2PE solution and tight scoping before you choose a validation route.
Validation works differently on each side. HIPAA has no certification: HHS states that no Security Rule standard requires certifying compliance and that it does not endorse or recognize private certifications, so any vendor offering a HIPAA certificate is not providing proof HHS recognizes. PCI DSS assessments are documented on official PCI SSC templates, a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the payment brands decide which entities must validate and how. Ask your acquirer which validation type applies to you before you commission any assessment.
Start the scoping exercise by mapping where card data enters, is stored or passes through your environment, including payment terminals, billing modules, call center tools and any system that could affect that environment. Confirm with your acquirer and P2PE provider exactly which PCI DSS requirements remain after encryption is deployed, and record that decision in writing. Keep the ePHI inventory separate, because a P2PE terminal reduces card-data obligations but does not reduce your Security Rule obligations for patient records.
How HIPAA and PCI DSS differ on scope, enforcement and proof
This table compares the two programs on what they protect, who enforces them, how they are structured and what evidence they produce. Read it as a scoping aid: a provider or pharmacy that takes cards usually answers to both, but each program asks for different proof.
| Dimension | HIPAA Security Rule | PCI DSS v4.0.1 |
|---|---|---|
| Data protected | Electronic protected health information (ePHI) held or transmitted by covered entities and business associates | Cardholder data and sensitive authentication data, plus any system that could affect the cardholder data environment |
| Legal basis or program owner | Federal regulation at 45 CFR Part 164 Subpart C, issued by HHS | Industry standard owned by the PCI Security Standards Council, adopted through payment brand programs |
| Who enforces | HHS Office for Civil Rights through complaint investigations, compliance reviews and audits | Payment brands run enforcement; the PCI SSC does not enforce compliance or impose penalties |
| Who must comply | Covered entities (health plans, clearinghouses, covered providers) and their business associates | Merchants, processors, acquirers, issuers and service providers, with validation levels set by each payment brand |
| Structure | Flexible standards with 14 required and 22 addressable implementation specifications | 12 principal requirements grouped under six goals, with testing procedures for each |
| Customization | Technology neutral: entities choose any measures that reasonably and appropriately meet each standard | Defined approach, or customized approach for entities with robust security and risk management |
| Proof produced | No certification exists; documentation of risk analysis and decisions is the evidence an investigator reviews | Report on Compliance by a Qualified Security Assessor or Self-Assessment Questionnaire, each with an Attestation of Compliance |
| Current version | No version cycle; the Security Rule has not changed since 2013 amendments, with a proposed revision pending | PCI DSS v4.0.1 is the only active version; v4.0 retired 31 December 2024 |
| Penalty basis | Inflation-adjusted civil money penalties per violation, from $145 to $2,190,294 for penalties assessed on or after 28 January 2026 | No PCI SSC fines; financial consequences come from individual payment brand programs |
How to scope HIPAA and PCI DSS without double counting
Map the data flows before you draw any boundary. HIPAA scope follows electronic protected health information wherever it is created, received, maintained or transmitted, so a patient record that moves from a scheduling system to a billing platform is in scope for the Security Rule at every hop. PCI DSS scope follows the cardholder data environment: the systems that store, process or transmit account data, plus any system that could affect the security of that environment. Start with a diagram of every payment path (point of sale, payment page, portal, call center terminal, refund workflow) and every system the payment data touches, then mark which of those systems also hold ePHI. The overlap is where double counting happens, and it is usually the billing, patient portal and reporting servers.
Use P2PE to shrink the PCI boundary, then re-check it. A PCI-listed point-to-point encryption solution can significantly reduce the number of PCI DSS requirements that apply to a merchant, but it does not remove PCI DSS entirely (PCI SSC FAQ 1158). Confirm with your acquirer which validation type and questionnaire apply to your setup, because the payment brands set merchant levels and decide how each merchant validates. Once the P2PE scope is confirmed, the remaining in-scope systems are the ones to test against both programs, and any system that touches ePHI and cardholder data should be documented once with the evidence reused across both assessments.
Draw the two boundaries separately, then compare them. Keep one inventory with two columns: HIPAA Security Rule scope for ePHI and PCI DSS scope for account data. Assign each shared system a single owner, a single risk analysis entry and a single set of logs, and record which PCI requirements and which Security Rule standards it satisfies. Before you finalize, confirm the scope with your acquirer and your QSA, and confirm the HIPAA boundary with your privacy and security officers, since neither party can make that call for you.
Where the HIPAA and PCI DSS work overlaps
HIPAA and PCI DSS both reach the same systems when a provider or health tech company takes card payments next to ePHI. The overlap is in controls such as access, logging, encryption and vendor oversight, but each program tests and proves them differently, so the shared work still produces two sets of evidence.
Access control scope
HIPAA's access control standard requires unique user identification and access limited to what each role needs, and PCI DSS sets its own access control requirements for systems in the cardholder data environment. A shared identity system can serve both, but the assessor for each program will ask which accounts reach card data and which reach ePHI. Map each account population to both programs before you rely on one access review.
Audit logging and review
Both programs expect logs that record who accessed what and when, and that someone reviews them. HIPAA leaves the review frequency and tooling to the entity's risk analysis, while PCI DSS fixes specific logging and review expectations in its testing procedures. Confirm with your QSA and your HIPAA risk analysis whether one log pipeline and one retention setting satisfy both, since a single setting can be too short for one program.
Encryption in transit and at rest
Card data and ePHI both need protection in transit over open networks and at rest in storage and backups. HIPAA treats encryption as an addressable specification, so the entity documents its decision, while PCI DSS treats strong cryptography for cardholder data as a fixed requirement with its own testing. Where a PCI-listed P2PE solution removes card data from your systems, confirm whether the ePHI encryption design still needs its own documented review.
Vendor and service provider oversight
Payment processors, hosting providers and billing vendors often fall under both a HIPAA business associate agreement and PCI DSS service provider responsibilities. HIPAA requires written assurances from business associates, and PCI DSS requires you to track which providers affect cardholder data and to obtain their responsibility matrices. Build one vendor register that records which obligations each provider covers, and ask each one for evidence that matches the program it touches.
Risk analysis and PCI reviews
HIPAA requires an accurate and thorough risk analysis of potential risks to ePHI, and PCI DSS requires a formal targeted risk analysis for certain flexible requirements plus a defined testing schedule for others. The two analyses answer different questions, so a PCI review does not replace the HIPAA risk analysis. Use the PCI results as an input to the ePHI analysis, and record where the two disagree.
Evidence reuse with assessors
PCI SSC FAQ 1567 allows a QSA to reuse evidence from a SOC 2 or SOC 3 audit after independently reviewing it, which can cut duplicated work. That FAQ covers QSAs and SOC reports only, not HIPAA, so it does not let a HIPAA assessment rely on PCI evidence by default. The NIST CSF and CIS Controls publish mappings to PCI DSS v4.0 and the NIST CSF reference tool lists informative references, but neither replaces reading each text. No official HIPAA-to-PCI mapping is supplied here, so confirm any crosswalk with your assessor before relying on it.
Who assesses each program and what the assessment produces
This table compares who checks each program, what evidence the check produces and how often the rules change. Read it to see which program gives you a document you can hand to a payment brand or regulator, and which one gives you nothing to show except your own records. The main takeaway is that HIPAA produces no certificate or attestation, while PCI DSS produces a signed attestation on official templates.
| Item | HIPAA Security Rule | PCI DSS v4.0.1 |
|---|---|---|
| Who sets the rules | HHS, through the Security Rule at 45 CFR Part 164 Subpart C | PCI Security Standards Council, with payment brands deciding who must validate |
| Certification or proof | No HIPAA certification. HHS states no Security Rule standard requires certifying compliance and does not recognize private certifications | Report on Compliance by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance |
| Who checks compliance | HHS Office for Civil Rights through complaint investigations, compliance reviews and audits | A QSA or the merchant or provider itself using an official SAQ, with the payment brands running any enforcement |
| Recent audit activity | The 2024 to 2025 OCR HIPAA audits review 50 covered entities and business associates, focused on hacking and ransomware provisions | No audit program comparable to OCR is described in the supplied sources; confirm enforcement terms with your acquirer or payment brand |
| Current version | Security Rule text last amended by a 2013 Federal Register notice; a major revision was proposed on 6 January 2025 and is not final | PCI DSS v4.0.1, published 11 June 2024, is the only active version since v4.0 retired on 31 December 2024 |
| Future-dated items | Proposed 12-month penetration testing is a proposal in 90 FR 898, not current law | 51 future-dated requirements took effect 31 March 2025; a 2026 request for comments ran, with no new version date announced as of October 2026 |
| Penalty or fine source | HHS civil money penalties under the inflation-adjusted table in 45 CFR 102.3 | The PCI SSC does not impose fines; financial consequences come from individual payment brand programs |
| What to ask for before you start | Written HHS-aligned risk analysis, documented decisions on addressable specifications, and evidence you can produce on request | Your acquirer's validation level, the SAQ type or ROC scope, and whether the brand requires an AOC signed by a QSA |
Which program to do first and how to share evidence
This sequence maps where cardholder data and ePHI actually flow, shrinks the cardholder environment, and then runs PCI validation and HIPAA documentation in parallel on one shared set of controls. The result is one evidence set that both programs can draw on without duplicated work.
Map data flows and payment scope
Start by drawing every path that cardholder data and ePHI take through the organization, including point-of-sale terminals, payment pages, billing systems, the EHR or pharmacy system, call recordings, backups and third-party processors. Mark which systems store, process or transmit cardholder data or could affect the security of that environment, since PCI DSS applies to all of them. Confirm the output with the payment acquirer and the business owners of each system, and treat the diagram as incomplete until a system owner has signed off on it. The step is done when every system carrying either data type appears once on the map with a named owner.
Shrink cardholder data with P2PE or tokenization
Decide whether to remove or reduce cardholder data from your environment before writing any controls. A PCI-listed point-to-point encryption solution can significantly reduce the number of PCI DSS requirements that apply to a merchant, though it does not remove PCI DSS entirely. Tokenization, where your systems hold a token rather than the primary account number, is an alternative that you should evaluate with your processor and QSA, since its scope effect depends on the design. Ask the vendor for its PCI listing and confirm in writing which requirements remain with you. The step closes with a documented decision and an updated scope map showing the smaller cardholder data environment.
Complete the HIPAA risk analysis for ePHI systems
Run the Security Rule risk analysis across every system that creates, receives, maintains or transmits ePHI, using the reduced scope from the previous step. The Security Rule is technology neutral and scalable, so the analysis should record threats, vulnerabilities, likelihood and impact in your own words and justify the measures chosen. NIST SP 800-66 Rev. 2 offers sample questions for each standard, though it is informational and not legally binding. The step is complete when a dated risk analysis lists each ePHI system, its risks and the planned risk management actions, and a named executive has reviewed it.
Document addressable specification decisions in writing
For each addressable implementation specification, assess whether it is reasonable and appropriate for your organization. If it is not, document why and implement an equivalent alternative measure where reasonable and appropriate. Section 164.316 requires written policies and procedures and retention of documentation, so keep these decisions in the same repository as the risk analysis. Your team should record the reasoning, the owner and the review date for each decision. The step closes when every addressable specification has either an implemented measure or a written justification, and a compliance lead has checked the file for gaps.
Build shared controls once for both programs
Implement the controls that both programs require, such as access management, logging and monitoring, vulnerability management and vendor oversight, as single controls with one owner and one evidence trail. Map each control to the PCI DSS requirement it satisfies and to the HIPAA standard it supports, so one configuration change produces evidence for both. Where a requirement is specific to one program, such as the PCI DSS cardholder data controls, keep it separate. The step is done when a control register lists each shared control with its owner, its test procedure and both mappings.
Run PCI validation and HIPAA documentation in parallel
Once shared controls are in place, run the PCI DSS validation path, which is either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, with the Attestation of Compliance that the payment brands require. At the same time, keep the HIPAA documentation current, since there is no HIPAA certification to issue. Confirm with your QSA whether they can reuse evidence from any SOC 2 report you hold, provided they review it independently. The step is done when the AOC is on file with the acquirer and the HIPAA evidence binder is complete, with no claim in either document that the other program issued.
Decide which program leads and set the review cycle
Choose which program leads the roadmap by comparing the volume of cardholder transactions with the volume of ePHI and the revenue each depends on. A pharmacy with heavy card volume may need PCI validation to be finished first, while a clinic with a small card footprint may lead with the HIPAA risk analysis. Record the decision, the reasons and the review trigger, such as a new payment channel, a new EHR module or a new processor. The step closes with a documented leadership decision and a calendar of reviews agreed by the compliance lead and the finance owner.
Which path fits a provider, a pharmacy or a health tech company
A clinic or hospital that keeps an EHR for ePHI and takes card payments at a terminal usually sits under HIPAA as a covered entity for the EHR and under PCI DSS for the payment flow. The practical question is how much of the network the card data touches. Point-to-point encryption (P2PE) with a PCI-listed solution can significantly reduce the number of PCI DSS requirements that apply, but PCI DSS still applies, so the terminal and its connections remain in view.
- P2PE scope reduction: Confirm the terminal and decryption path are on the PCI-listed P2PE solution, since the reduction depends on that exact listing.
- Terminal segmentation: Keep payment terminals on a network segment that does not carry EHR traffic, and document the boundary.
- Remote support access: Vendors who reach terminals or the EHR for support must be controlled under both programs.
- Shared staff accounts: Front-desk logins that touch both systems need individual accountability under each framework.
- Evidence split: HIPAA risk analysis covers ePHI, while the PCI DSS SAQ or ROC covers the cardholder data environment.
Illustrative example: a clinic that moves all card entry to a P2PE terminal on a segmented network may find a much smaller PCI DSS footprint, but should still confirm the SAQ type its payment brand accepts. Ask the acquirer which validation applies and whether the EHR vendor's connection changes it.
A pharmacy usually faces both programs at once: prescription records and patient identifiers are ePHI, while the point-of-sale system and card terminals fall under PCI DSS. Because the two systems often share a store network, back office servers, and a pharmacy management vendor, the scope question is harder than in a single-terminal clinic. Both programs reach third parties, so vendor duties need to be mapped explicitly.
- Shared network scope: Confirm whether the POS, the pharmacy system and any store servers can reach each other, since that connection can bring the POS into PCI DSS scope.
- Vendor duties under HIPAA: A pharmacy management or cloud host that handles ePHI typically needs a business associate agreement with the pharmacy.
- Vendor duties under PCI DSS: A service provider that can affect cardholder data security may need its own validation, and the payment brands determine that status.
- Access reviews: Pharmacy staff who use both the dispensing system and the POS need access rules that cover both programs.
- Logging: Audit logs for the pharmacy system and the cardholder data environment should be retained and reviewed under each program's rules.
Illustrative example: a pharmacy whose POS vendor also hosts the pharmacy database would need to confirm that vendor's HIPAA and PCI DSS roles separately. Ask both vendors for their current validation documents and BAA terms.
A health tech company that processes payments on behalf of clinics often holds ePHI for those clinics, which makes it a business associate under HIPAA, and it moves or affects cardholder data, which may make it a service provider under PCI DSS. Roles are not decided by the company's own view. The payment brands decide which entities must validate and how, so this company should confirm both roles with its payment brand and its clinic and acquirer counterparties before scoping.
- Business associate role: Clinics will usually require a BAA that covers how ePHI is stored, accessed and returned or destroyed.
- Service provider role: Confirm with the payment brand whether the company must validate, and at what level.
- Segregated environments: Keep payment processing and clinical data flows separated so each program's scope can be drawn cleanly.
- Proof to produce: Expect PCI DSS validation through an AOC, and for HIPAA, evidence of the Security Rule program rather than a certificate, since HHS does not recognize private certifications.
- Penetration testing: PCI DSS sets testing requirements, and the January 2025 HIPAA proposal would add a 12-month penetration testing expectation if finalized.
Illustrative example: a company that handles clinic card payments through its own API may be both a business associate and a service provider, so it should map each data flow to the program that covers it before choosing an assessor. Ask the payment brand and each clinic to confirm roles in writing.
What do buyers ask before they hire help for HIPAA and PCI DSS?
What drives the cost of HIPAA Security Rule work compared with PCI DSS work?
Cost depends on how much of your environment handles ePHI or cardholder data and how much of it you must document and test. For HIPAA, the Security Rule is technology neutral and scalable, so the work centers on a risk analysis, the required and addressable implementation specifications, policies and evidence, and any system changes your risk analysis calls for. For PCI DSS, cost tracks the size of the cardholder data environment, the number of payment channels, and whether a Qualified Security Assessor must write a Report on Compliance. Both programs have one-time setup work and recurring costs such as annual assessments, monitoring, training and remediation. Ask every provider to split a quote into one-time and recurring lines and to name who performs each task.
Does PCI DSS have a published price for compliance?
No. The PCI Security Standards Council publishes no cost estimate for PCI DSS compliance, so there is no official figure to benchmark against. Your costs come from your assessor, your acquirer or payment processor, and the internal effort your team spends on controls and evidence. Ask your acquirer which validation type applies to you and whether they require a QSA-led assessment. Then request written quotes from each QSA or assessor that list the scope, the deliverables (ROC or SAQ with Attestation of Compliance), the testing hours they assume and any re-assessment terms. Compare quotes on the same scope, not on the headline number.
How long does a HIPAA or PCI DSS engagement take?
No fixed duration applies to either program, so treat any published timeline with caution. Duration depends on the size of the systems in scope, how current your documentation is, how many third parties handle data, and how quickly your team can produce evidence. Ask for a written scope and a timeline with named milestones before work starts, including what you must provide and when. For PCI DSS, also confirm the validation date your acquirer expects, since that sets the deadline your schedule must meet.
Can our team complete PCI DSS validation without an outside assessor?
Sometimes, but it depends on your validation type and your acquirer. Some merchants may complete a Self-Assessment Questionnaire themselves, and the SAQ and Attestation of Compliance are official PCI SSC templates. A Report on Compliance must be completed by a Qualified Security Assessor. Confirm with your acquirer which SAQ, if any, they accept for your payment channels, and whether they require an assessor even for an SAQ. Reducing scope with a PCI-listed point-to-point encryption solution can lower the number of requirements that apply, though it does not remove PCI DSS entirely.
What penalties apply under HIPAA compared with PCI DSS?
HIPAA penalties come from the HHS Office for Civil Rights, which enforces the Security Rule through complaint investigations, compliance reviews and audits. For penalties assessed on or after January 28, 2026, the adjusted per-violation range is $145 to $73,011 for no knowledge, $1,461 to $73,011 for reasonable cause, and $14,602 to $73,011 for corrected willful neglect. The uncorrected willful neglect range runs to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3, 91 FR 3666). PCI DSS is different: the PCI SSC does not impose fines. Any financial consequences come from individual payment brand programs, which decide who must validate and run enforcement.
Is there a HIPAA certificate we can display to customers?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation (HHS FAQ 2003). Customers may still ask for evidence, so offer a current risk analysis, policies, training records and third-party assessment results where you have them. For PCI DSS, the proof is the Attestation of Compliance on an official PCI SSC template, not a certificate, since PCI SSC does not recognize certificates as validation.
Who owns the HIPAA risk analysis and the PCI DSS scope decision?
Your organization owns both, and an outside provider can support but not replace that ownership. For HIPAA, the risk analysis must reflect your own systems, data flows and threats, and your leadership must act on the results. For PCI DSS, your acquirer and your assessor determine validation requirements, and the scope of the cardholder data environment should be documented and confirmed before testing. Ask any provider which decisions they will make, which they will prepare for you, and which remain with your staff, and put that split in the written scope. DeployOpen plans, implements, documents and supports self-hosted platforms in your infrastructure and prepares evidence for compliance assessments, but does not issue audit reports or attestations, which independent auditors and assessors provide.
How DeployOpen scopes and prepares evidence for both programs
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments. For HIPAA vs PCI DSS, the work starts by separating the ePHI boundary from the cardholder data environment, so each program is scoped and evidenced on its own terms. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and QSAs do.
How we scope
- Map where ePHI and cardholder data are stored, processed or transmitted across your systems and vendors.
- Identify which systems could affect the security of the cardholder data environment, even if they never touch card data.
- Record the agreed scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Implement HIPAA Security Rule safeguards and PCI DSS v4.0.1 controls on the same platforms where the two programs overlap.
- Document the reasoning for each addressable HIPAA specification and each PCI DSS defined or customized approach decision.
- Run security testing against in-scope systems and record findings, fixes and retests for both programs in one evidence set.
How we hand over
- Deliver configuration baselines, runbooks and policy documentation mapped separately to HIPAA and PCI DSS requirements.
- Provide evidence packages that a QSA or your HIPAA assessor can review, without implying DeployOpen issued any attestation.
- Confirm with your QSA or assessor which artifacts they need before handover, since their templates and sampling decide the format.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement closes.
- Keep scope boundaries current when systems, payment flows or vendors change, so neither program drifts unnoticed.
- Ask your payment brand or acquirer which validation level applies to you, because the brands set those levels, not DeployOpen.
Sources and further reading
- 45 CFR Part 164 Subpart C, Security Standards for the Protection of Electronic Protected Health Information ↗
- PCI Data Security Standard ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
- PCI SSC FAQ 1220: compliance certificates ↗
- PCI SSC FAQ 1158: P2PE and merchant validation ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide ↗
