Which to pursue first when you take cards and sell to healthcare buyers
If you take card payments and a healthcare customer now asks for HITRUST, start with PCI DSS. PCI DSS is the obligation your payment brands enforce where they apply it, and it is proven by a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance, on official PCI SSC templates. A HITRUST certificate does not replace either document, and the PCI SSC states that certificates are not recognized as validation. Confirm with your acquirer or payment brand which validation level and document they require for your merchant or service provider role, since the PCI SSC does not set those requirements itself.
Once the PCI obligation is settled, extend the same evidence to HITRUST rather than building a second evidence set. The PCI SSC's FAQ 1567 allows a QSA to reuse evidence from SOC 2 or SOC 3 audits after independently reviewing it, and a comparable reuse logic applies to a HITRUST assessment, but you should confirm with your QSA and your HITRUST External Assessor which artifacts each will accept. Map your PCI evidence (network diagrams, access reviews, logging, change records) against the HITRUST requirement statements your customer actually needs, then decide whether a HITRUST e1, i1 or r2 is the right depth for that buyer. Those assessments are scoped and fee-quoted separately, so ask for a written scope before committing.
Plan for a recurring cycle on both tracks. PCI DSS v4.0.1 is the only active version, and the PCI SSC has announced no release date for its next iteration, so budget for the current version and watch for changes. HITRUST certifications run on their own validity periods, so a customer contract may fall due on a date unrelated to your PCI attestation. Keep a single control register that cross-references both, so each annual cycle reuses the same evidence rather than restarting it.
How PCI DSS and HITRUST differ on scope, owner and proof
This table sets PCI DSS and HITRUST side by side on who owns them, who must comply, how the control structure is organized, what proof each produces and how enforcement works. Read it to see which obligation a card-accepting healthcare organization must meet directly and where a HITRUST certificate sits relative to it.
| Dimension | PCI DSS v4.0.1 | HITRUST CSF |
|---|---|---|
| Owner and maintainer | PCI Security Standards Council, which maintains the standard and its assessment templates | HITRUST, which maintains the CSF and its assessment and certification programs |
| Who must comply | Entities that store, process or transmit cardholder data or sensitive authentication data, or could affect that environment, as set by the payment brands | Organizations that choose to certify, typically to meet customer or contract requirements; no regulator requires it |
| Control structure | 12 principal requirements grouped under six goals | 14 control categories, 49 control objectives and 156 control specifications |
| Proof produced | Report on Compliance by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance | Validated assessment by an Authorized HITRUST External Assessor, with a HITRUST certificate (e1, i1 or r2) |
| Certificates as proof | Not recognized as validation of PCI DSS compliance | Certificate is the outcome; it does not replace a ROC or SAQ for card brand purposes |
| Enforcement | PCI SSC does not enforce or impose penalties; payment brands decide who validates and run any enforcement | Customers and contracts set the consequence; HITRUST does not enforce compliance on an organization |
| Current version | PCI DSS v4.0.1 is the only active version; a new iteration has no release date announced as of October 2026 | HITRUST CSF v11.9.0 is the current version, available in MyCSF from September 24, 2026 |
| Validity period | Tied to the annual validation cycle set by the payment brand or acquirer | e1 and i1 certifications last one year; r2 certifications last two years with an interim assessment |
Where PCI work carries into a HITRUST assessment
PCI work and HITRUST work overlap in evidence and control design, but they answer different questions for different audiences. The cards below separate what a shared control set can reuse from what still needs its own assessment, report and decision.
PCI as a harmonized source
HITRUST describes the CSF as harmonizing 60 or more authoritative sources, and PCI is one of them, alongside ISO/IEC 27001 and 27002, NIST SP 800-53 Rev. 5 and HIPAA. A HITRUST assessment can therefore cover many PCI-relevant controls. Check the CSF mapping for the specific PCI DSS v4.0.1 requirements your cardholder data environment depends on, rather than assuming full coverage.
Shared ISO-based control structure
The CSF's core structure is based on ISO/IEC 27001 and 27002, so many security management controls map across both PCI DSS and HITRUST. This shared base helps when a team already runs an ISMS. Confirm the mapping at the requirement level with your QSA and assessor, because a shared control family does not mean the PCI test procedure is met.
CIS Controls as a bridge
The CIS Controls Navigator for v8.1 maps to PCI DSS v4.0, so teams can trace a single control to both frameworks. This is useful for planning and gap analysis. It is not a PCI validation or a HITRUST crosswalk, and each mapping should be checked against the current PCI SSC and HITRUST documents before it is used as evidence.
A mapping is not an attestation
A HITRUST mapping shows where a control appears in another framework. It does not produce a PCI Report on Compliance or Attestation of Compliance, and a HITRUST certificate does not replace a ROC or SAQ. Ask your acquirer or payment brand which PCI document they accept, and keep the PCI assessment on its own schedule and template.
SOC 2 reuse for QSAs
A QSA cannot rely on a SOC 2 or SOC 3 report for PCI DSS assessment, but may reuse evidence from those audits after independently reviewing it. Under PCI SSC FAQ 1567, this reuse can reduce duplicated evidence work. Do not treat a HITRUST report as the same thing: the QSA still has to review the evidence and document its own conclusions.
Customized approach is a separate decision
PCI DSS v4.x lets qualifying entities meet a requirement through a customized approach that achieves the stated objective in a different way. Choosing a HITRUST control set does not make that choice for you. Decide the PCI approach for each requirement with your QSA, document it in the PCI assessment, and then check whether the HITRUST control wording supports the same design.
Who assesses each one and what each issues
This table compares who performs each assessment, what document or certificate it produces, and how long the result stays valid. Read it to see that a PCI DSS attestation and a HITRUST certification answer different questions, and that neither substitutes for the other.
| Item | PCI DSS | HITRUST e1, i1 and r2 |
|---|---|---|
| Who performs the assessment | A Qualified Security Assessor (QSA) completes a Report on Compliance (ROC), or the entity completes a Self-Assessment Questionnaire (SAQ) on PCI SSC templates | Only Authorized HITRUST External Assessor organizations perform the validated assessment submitted for certification |
| Quality review before issue | Confirm with your QSA and acquirer how the ROC and AOC are reviewed before submission | HITRUST performs central quality assurance before issuing the report |
| Primary output | Report on Compliance or SAQ, each with an Attestation of Compliance (AOC) | HITRUST certification with a validated assessment report |
| Certificate status | PCI certificates are not recognized as validation | A HITRUST certification is the formal output of the validated assessment |
| Validity period | Set by the payment brand or acquirer, not by a fixed certificate term in this comparison | e1 and i1 are valid for one year; r2 is valid for two years |
| Interim requirement | Annual validation cycle set by the payment brand, confirm with your acquirer | r2 needs an interim assessment due in the 90 days before the first anniversary |
| Assessor fieldwork window | Confirm the engagement timeline with your QSA in the written scope | The validated assessment fieldwork window is at most 90 days for e1, i1 and r2 |
| Who decides who must validate | The individual payment brands decide which entities must comply and validate | HITRUST certification is voluntary, requested by the organization or its customers |
Why a HITRUST certificate does not replace a ROC or SAQ
A HITRUST certificate does not satisfy PCI DSS, and it cannot stand in for the Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) that a payment brand or acquirer requires. PCI DSS validation is documented on official PCI SSC templates: a ROC completed by a Qualified Security Assessor, or an SAQ, each with an Attestation of Compliance (AOC). The PCI SSC states that certificates are not recognized as validation (PCI SSC FAQ 1220). The payment brands decide which entities must validate and run their own enforcement programs, so the document that counts is set by the card ecosystem, not by HITRUST. The PCI SSC FAQ on compliance certificates is the natural next read before you brief your acquirer.
The two documents come from different owners and answer different questions. HITRUST issues a certificate from its own assessment process, carried out by Authorized HITRUST External Assessor organizations, and it is scored against the HITRUST CSF. A ROC or SAQ records whether the cardholder data environment meets PCI DSS requirements, on the templates the PCI SSC publishes. HITRUST harmonizes PCI among its authoritative sources, which means some PCI content appears in the CSF, but that mapping does not make the HITRUST report a PCI validation. Before you rely on any overlap, confirm with your acquirer and QSA which PCI assessment document and AOC they will accept for your cardholder data scope.
In practice, the acquirer or brand will still ask for the current AOC, and a healthcare customer may ask for the HITRUST certificate as evidence of its assurance program. Those are two separate requests, and each needs its own owner and its own evidence pack. Plan for both: keep the PCI scope and AOC current on the PCI SSC template, and treat the HITRUST certificate as the answer to the customer's security assurance question. Where the same controls and evidence serve both, a QSA may reuse evidence from a SOC 2 report after independently reviewing it (PCI SSC FAQ 1567), but the reuse decision belongs to the QSA and should be agreed in writing before fieldwork starts.
Doing both: order, scope and shared evidence
This sequence settles the PCI scope and the HITRUST scope before any evidence is gathered, so one set of artifacts can serve both assessments without either assessor working from a different system boundary. The output is a written scope agreement, an evidence map and a named reviewer for each item.
Confirm PCI scope and report type with the acquirer
Start by asking your acquiring bank or payment brand contact which PCI DSS validation applies to your organization, and whether it is a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. The payment brands decide which entities must validate, so this answer comes from them, not from HITRUST or from DeployOpen. Record the SAQ type or ROC route, the list of in-scope systems and any service providers whose responsibilities you must document. This step is done when the acquirer confirms the validation type in writing.
Confirm the PCI DSS version and future-dated requirements
Confirm that the assessment will be run on PCI DSS v4.0.1, the only active version after v4.0 was retired on 31 December 2024, and that v3.2.1 is no longer in use. Check which future-dated requirements from v4.0 are already effective, since 51 of the 64 new requirements became effective on 31 March 2025. Note that the PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 and has announced no release date for a new version. This step is done when the team has a written list of the requirements that apply to its SAQ or ROC.
Define the HITRUST scope against the same systems
Decide whether the HITRUST assessment will be an e1, i1 or r2 and define its scope using the same system boundary as the cardholder data environment. Where the HITRUST scope is wider than the PCI scope, document the systems that fall outside the cardholder data environment so the two boundaries are traceable to each other. Note that e1 and i1 certifications last one year and r2 certifications last two years with an interim assessment, so the chosen level sets the recurring workload. Confirm the scope with your HITRUST External Assessor, since only Authorized HITRUST External Assessor organizations perform validated assessments. The step is done when both scope statements reference the same asset inventory.
Map shared evidence to both frameworks
Build one evidence register that lists each artifact once and maps it to the PCI DSS requirements and to the HITRUST control specifications it supports. Typical shared items include network diagrams, data flow diagrams, access reviews, vulnerability scan reports, change records and security policies. For each item, record the owner, the date it was generated, the systems it covers and any gaps against the PCI scope. This register is the basis for reuse, so the step is done when every shared artifact has one owner and a traceable mapping to both frameworks.
Agree the QSA and assessor review responsibilities
Hold a joint scoping session with the QSA and the HITRUST External Assessor so each knows which artifacts they will review and which they will rely on. A QSA cannot rely on SOC 2 or SOC 3 reports for a PCI DSS assessment, but may reuse evidence from those audits after independent review, and the same logic applies to evidence prepared for HITRUST. Agree in writing who samples which controls, who receives which evidence and how questions are routed, so one artifact is not reviewed in conflicting ways. The step is done when each assessor has a written list of the evidence it will review.
Run one evidence collection cycle
Collect the shared evidence once against the agreed scope, using the register from the earlier step and recording the collection date on each item. Keep the cardholder data environment and the HITRUST boundary synchronized so a change in one is reflected in the other. Assign a single custodian for each artifact to avoid duplicate versions. The step is done when the register shows every item collected, dated and linked to the systems it covers.
Reconcile findings and close the cycle
After the QSA and HITRUST assessor complete their fieldwork, reconcile any findings that touch shared controls so the remediation and the evidence are consistent in both reports. Confirm that the PCI Attestation of Compliance or the HITRUST report reflects the scope agreed in the earlier steps. Record the next assessment dates for each framework, since the two cycles are separate and do not expire together. The step is done when the scope statements, evidence register and final reports agree and each cycle has a recorded renewal owner.
What do buyers ask about PCI DSS and HITRUST cost, effort and timing?
Does a HITRUST certification cover PCI DSS?
Not as a substitute. HITRUST harmonizes PCI DSS among its authoritative sources, so many PCI requirements map into the CSF, but a HITRUST certificate does not validate PCI DSS compliance for a card brand. PCI DSS validation still requires an official PCI SSC template, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Ask your acquirer which template and validation level applies to your merchant or service provider status, and ask your HITRUST assessor to show the mapping rows they rely on before you plan any shared evidence.
Can a HITRUST certificate replace a PCI DSS SAQ?
No. PCI SSC states that certificates are not recognized as validation for PCI DSS, and assessments are documented only on its templates with an Attestation of Compliance. A HITRUST certificate can still reduce duplicated work, because evidence gathered for a HITRUST assessment may be reusable in PCI assessment, but the QSA or merchant must review that evidence against PCI requirements. Confirm with your acquirer or payment brand whether they accept any reuse before scoping the work.
What drives the cost of a PCI DSS assessment?
The main drivers are the size of the cardholder data environment, the number of systems and connected third parties in scope, the validation route (ROC by a QSA or SAQ), and how ready your evidence is. The PCI SSC does not publish a cost estimate for PCI DSS compliance, so the figures you receive come from your QSA or internal budget. Ask each QSA for a written scope listing included systems, sampling assumptions, number of interview sessions, and whether re-testing after remediation is included.
What drives the cost of a HITRUST assessment?
HITRUST costs depend on the assessment type (e1, i1 or r2), the number of in-scope systems and facilities, the authorized External Assessor you hire, and the readiness of your control evidence. HITRUST does not list prices on its public assessment pages, so request a written quote that separates HITRUST fees from assessor fees. Ask whether interim and re-validation work is priced now, because r2 certificates run two years with an interim assessment.
How long is the assessment fieldwork window for HITRUST?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2, according to the HITRUST Assessment Handbook v1.1. This is the fieldwork window only. Preparation, evidence collection, remediation and HITRUST quality assurance before a report is issued take additional time, so plan the full calendar with your assessor. Also note that e1 and i1 certifications last one year and r2 certifications last two years, which sets the recurring cycle.
What does the reader need to supply for either assessment?
For PCI DSS, you need a current inventory of systems and network flows, a clear cardholder data environment boundary, evidence for each applicable requirement, and the service provider or third-party attestations you rely on. For HITRUST, you need documented control implementations, evidence for each in-scope requirement statement, system and facility lists, and a named owner for each control area. Both routes also need an executive sponsor who can approve scope and resolve gaps. Ask each assessor to publish an evidence request list before you sign.
Can an internal team prepare for PCI DSS and HITRUST without an outside firm?
An internal team can prepare evidence, maintain scope documentation and close gaps, but PCI DSS ROCs must be completed by a QSA and HITRUST validated assessments must be performed by an Authorized HITRUST External Assessor. Internal preparation reduces assessor hours only if your evidence is organized and current. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Any engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and pricing follows from that written scope.
What DeployOpen prepares before either assessor arrives
DeployOpen's role in a HITRUST and PCI DSS programme is preparation: planning the assessment scope, readying systems, controls and evidence, and documenting them so that a qualified assessor can test them. DeployOpen does not issue a Report on Compliance, a Self-Assessment Questionnaire, an Attestation of Compliance, a HITRUST report or a HITRUST certification. A Qualified Security Assessor completes the ROC, the SAQ is completed and attested by the entity against PCI SSC templates, and only Authorized HITRUST External Assessor organizations perform the validated assessments submitted for certification. Any readiness work we do is input to those assessments, never a substitute for them.
In practice, the first deliverable is a written scope that names the cardholder data environment, the systems that could affect it, and the HITRUST assessment scope that will share controls with it. The reader should confirm with the PCI assessor which system components and third parties they will test, and with the HITRUST assessor which assessment type (e1, i1 or r2) and scoping boundary they expect, before any evidence is collected. Fixed-scope engagements are agreed in writing, so scope, deliverables and timelines are documented up front, and changes to the boundary are handled as formal amendments rather than informal drift.
Preparation then covers the controls and evidence themselves: configuration baselines, access reviews, logging and change records, and policy documents mapped to the requirements each assessor will sample. Where a SOC 2 report already exists, the reader should ask the QSA how much of that evidence they will accept after independent review, since PCI SSC FAQ 1567 allows reuse with review but not reliance. Ask any readiness provider for the list of artifacts it will produce, who owns each one after handover, and how the entity will keep them current through the next assessment cycle.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments. DeployOpen does not issue reports, attestations or certifications; your Qualified Security Assessor, HITRUST Authorized External Assessor or other independent assessor does that work.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which systems hold, process or transmit cardholder data and which fall under the HITRUST assessment scope.
- Scoping decides which shared controls serve both assessments and which need separate evidence.
How we build
- Controls and configurations are implemented in the client's own cloud accounts, data centers or air-gapped networks.
- Security testing for applications, APIs and infrastructure is scoped separately and documented against the agreed control set.
- Evidence is collected once in a shared register, mapped to PCI DSS requirements and HITRUST control specifications.
How we hand over
- Deliverables include configuration records, policies, procedures and evidence packs prepared for the independent assessor.
- Documentation explains which evidence supports the ROC or SAQ and which supports the HITRUST validated assessment.
- Handover includes runbooks so your team can operate and maintain the controls after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial readiness work.
- Retainers can track changes when PCI DSS v4.0.1 or a later version is adopted and when HITRUST releases a new CSF version.
- Confirm with your assessor which evidence they accept before support work begins, since DeployOpen does not set assessment outcomes.
