HITRUST Penetration Testing Requirements: r2 vs i1 vs e1, Scope, Frequency

Quick answer: HITRUST publishes no penetration testing frequency. The HITRUST CSF requirement statements are licensed content inside MyCSF, so no public HITRUST page states "penetration testing must be performed every 12 months," and any article that quotes one without a link to a HITRUST document is quoting itself. What HITRUST does publish is the machinery around the test. The Assessment Handbook version 1.2 sets a 90-day control incubation period before a control can be tested as implemented, a maximum 90-day fieldwork window, certification thresholds of 83 per domain for the e1 and i1 and 62 per domain for the r2, and independence rules that expressly permit assessor personnel to perform penetration testing for an assessed entity so long as they do not also remediate. The published vulnerability-management requirement statement 07.10m1Organizational.3 reads "Information systems are periodically scanned to proactively (annually at minimum) identify technical vulnerabilities."

Every HITRUST statement on this page was read from a document HITRUST publishes, on 5 September 2026, and links back to it. Where a widely repeated claim could not be traced to a HITRUST-published source, this page says so instead of repeating it.

Start here: what HITRUST publishes, and what it does not

This is the part most guides skip, and it changes how you should read every other guide on the subject.

HITRUST publishes: the assessment types and their characteristics, requirement counts for the fixed-scope assessments, certification validity, the control maturity model, the scoring thresholds, the assessor independence rules, the incubation and fieldwork timing rules, the interim and bridge assessment rules, a Never N/A Registry containing the verbatim text of roughly 130 core requirement statements, and a certification control reference list in its CSF Assurance Program Requirements.

HITRUST does not publish: the full HITRUST CSF requirement statement library, the illustrative procedures External Assessors use to test each requirement, or any document stating a penetration testing cadence. The CSF is licensed and delivered through MyCSF; the Assessment Handbook carries the HITRUST copyright notice on every page.

That asymmetry produces a specific market failure. Search "hitrust penetration testing requirements" and you will find a dozen pages confidently asserting an annual external and internal penetration test requirement, usually attached to control 10.m, none of them citing a HITRUST document that says it. The assertion may well match what assessors ask for in practice. It is still not a published requirement, and telling a CFO that a regulation says something it does not say is how security budgets lose credibility.

So this guide does two things instead. It sets out exactly what HITRUST publishes, quoted. And it explains what that published machinery implies for when and how to run a penetration test, labelled as inference rather than requirement.

Where penetration testing actually appears in HITRUST's published documents

Searching the full text of the Assessment Handbook version 1.2 returns the phrase "penetration test" in two places. Both are worth reading carefully, because both tell you something useful.

1. The independence rules say your assessor's firm may test you

Chapter 3.3 sets out independence requirements for External and Internal Assessors. Criterion 3.3.6 states that assessor personnel involved in a HITRUST validated assessment "may perform consulting or evaluation services for the Assessed Entity," and lists them. The list includes:

Penetration testing (excluding remediation activities that involve implementation or operation of a control)

Vulnerability scanning and HITRUST readiness or gap assessments appear on the same list with the same exclusion. The boundary HITRUST draws is not between testing and assessing; it is between finding and fixing. An assessor firm may find your vulnerabilities and still validate your assessment. It may not implement or operate the controls and then validate them.

The neighbouring criterion is the harder one. Criterion 3.3.5 states that External or Internal Assessor personnel involved in the prior 12 months in the implementation or operation of controls evaluated within a validated assessment "may not work on the validated assessment for that Assessed Entity," and that a separate team, including a separate engagement executive or partner, must be brought in.

Read together, those two criteria are the reason many organisations deliberately split the work: an independent penetration testing firm finds and reports, the internal team or an implementation partner remediates, and the External Assessor validates. That split is not mandated, but it is the configuration with the fewest independence questions attached to it.

2. The reliance rules say a penetration test is direct testing, not third-party reliance

Criterion 13.2.3 concerns the Audits and Assessments Utilized webform in MyCSF, which records where an assessment leaned on inheritance or on another party's audit. It states:

The Audits and Assessments Utilized webform may only include information related to the assessment's usage of inheritance and/or reliance. Reports used to support direct testing of a requirement statement (such as Penetration Tests, Vulnerability Assessments, Risk Assessments, etc.) should not be included in the Audits and Assessments Utilized webform.

This is a quiet but consequential distinction. A SOC 2 report from a cloud provider is reliance: someone else tested, and your assessor is leaning on their work. Your own penetration test is not reliance. It is evidence that the External Assessor examines directly, exactly like a configuration screenshot or an access review export.

The practical consequence is about report quality. Evidence that gets inspected directly has to stand on its own: scope statement, methodology, dates, affected assets, reproduction detail, severity with a stated rating basis, and a retest record. A four-page executive summary with a risk dial on the cover is not evidence an assessor can test a requirement statement against.

The assessment types: e1 vs i1 vs r2

HITRUST describes the three certifiable assessments as a traversable portfolio. In the Assessment Handbook's words: "All requirements within the e1 assessment are included within the i1, and all requirements within the i1 are included within the baseline requirements of the r2 assessment." Work done at one level carries upward.

Sources for every cell: the HITRUST Assessment Handbook version 1.2 comparison table in chapter 4 and the reporting criteria in chapter 15.1, plus the published control counts on the HITRUST e1, i1 and r2 product pages.

Three details behind the table matter for a testing programme.

The e1 count moves with the CSF version. HITRUST's product page states 43 foundational controls. The advisory that introduced the assessment, HAA 2023-004, stated that "all e1 Assessments performed against a particular version of the HITRUST CSF will include the same requirements, currently 44 requirements," and that changes to the e1 selection ship in major and minor CSF releases. Treat the count as version-dependent rather than fixed, and confirm the number for the CSF version your assessment is created against.

The i1 recertifies on a lighter set. HITRUST states that year-two i1 recertification focuses on "approximately 60 core controls rather than the full 182-control set." That reduces effort but not the underlying obligation to keep the controls operating.

The r2 is scoped by questionnaire, not by checklist. For an r2, the assessed entity completes a risk-based scoping questionnaire in MyCSF covering General, Organizational, Geographical, Systematic and optional Compliance factors, and "a customized set of HITRUST CSF control references and requirement statements are automatically generated." That is why no fixed r2 requirement count exists, and it is also why r2 scoping conversations should happen before a penetration test is scoped rather than after.

What HITRUST publishes on vulnerability management

Appendix A-20 of the Assessment Handbook is the Never N/A Registry: a list of core requirement statements "that are expected to never be scored as Not Applicable," printed verbatim with their HITRUST Baseline Unique IDs. It is the largest body of actual CSF requirement text HITRUST puts in public, and several entries sit in the vulnerability-management family under control 10.m Control of Technical Vulnerabilities.

Four observations, and the honest limits of each.

A cadence does appear, for scanning. 07.10m1Organizational.3 carries "annually at minimum" in the requirement text itself. That is a HITRUST-published frequency, and it applies to scanning rather than to penetration testing.

Annual is HITRUST's default rhythm in this family. Configuration checking under 06.h and compliance assessment under 06.g both carry "annual" in the published text. An annual penetration test sits naturally alongside those, which is the most defensible basis for the annual cadence everyone recommends. It is an inference from published neighbours, not a quotation.

The control references are published. HITRUST's CSF Assurance Program Requirements prints an appendix of certification control references, and it includes 06.g Compliance with Security Policies and Standards, 06.h Technical Compliance Checking and 10.m Control of Technical Vulnerabilities alongside access control, network and application controls. That document is dated October 2019 and is written against CSF v9.3, so treat it as evidence that these control families are certification-relevant rather than as a current requirement list.

Remediation is a scored requirement, not a courtesy. 0709 requires the risks and the actions to be identified and the corrections performed "in a timely manner," and 0778 requires consecutive scan results to be compared to verify remediation. Both are Never N/A, meaning they must be scored even where the population for testing is zero. In evidence terms: the retest is not optional.

Independence: can your penetration testing firm also be your assessor?

The rules are published and they are more permissive than most buyers assume, but they have edges.

The External Assessor firm must be a separate legal entity from the assessed entity (criterion 3.3.1), and the assessor function must be independent of the business functions being assessed, with "no overlap in responsibilities, staffing, ownership of the controls, or reporting" (3.3.2).

Management may not restrict testing scope. Criterion 3.3.4: "Management of the Assessed Entity must not be able to restrict the nature, scope, and extent of testing determined to be required by the External or Internal Assessor."

Assessor personnel may run your penetration test (3.3.6), provided they do not perform remediation activities involving implementation or operation of a control.

But not if they built or ran the controls in the last 12 months (3.3.5), in which case a separate team with a separate engagement partner is required.

Internal Assessor functions need at least two CCSFP holders (3.2.15), must be approved by HITRUST before an External Assessor can rely on their work (3.2.13), and their testing cannot rest on evidence more than 90 days old (12.4.8).

The clean configuration, and the one that survives the most scrutiny in a customer security review, is a three-party split: an independent penetration testing firm finds and reports, your team or an implementation partner remediates, and the Authorized External Assessor validates. Where budget forces consolidation, the published rules allow the assessor firm to test, and the exposure sits entirely on the remediation line.

Timing: the 90-day clock nobody plans for

This is where penetration testing programmes and HITRUST calendars collide, and it is entirely published.

Controls must be in place for 90 days before they can be tested. Criterion 11.2.8: "All controls established by the Assessed Entity in support of each of the HITRUST requirement statements must be implemented for a minimum of 90 days prior to testing (i.e., 90-day incubation period). This includes either a newly implemented control or a control remediated due to deficiencies. The control must have been operating in its current state for a consecutive 90 days (or more) before it can be tested as an implemented control."

Read that second sentence again. A control remediated due to deficiencies restarts the 90-day clock. If your penetration test lands three weeks before fieldwork and produces a High finding that requires a configuration change, the fixed control cannot be tested as implemented inside that assessment.

Policies and procedures need 60 days. Criterion 11.2.10 sets a 60-day incubation for policies and procedures, and notes that because the maximum fieldwork window is 90 days, a policy deficiency identified in the first 30 days of fieldwork can still be remediated and used for scoring later in the same window. Technical controls get no equivalent grace.

Service provider controls can skip the wait. Criterion 11.2.9: where a service provider performs the requirement, the assessed entity does not need to wait out the incubation period if the provider's control has already been implemented for 90 days, and inheritance or reliance on a provider's HITRUST certification can be used immediately.

Fieldwork itself is capped at 90 days for all three assessment types.

The r2 interim is a hard deadline. Criterion 15.4.10: the interim assessment must be submitted by the External Assessor on or within 90 days prior to the one-year anniversary of the r2 certification date, and "non-submission of an interim assessment by the deadline will result in suspension and/or revocation of the Assessed Entity's certification." The interim samples one randomly selected requirement statement from each assessment domain plus every requirement that generated a required corrective action plan.

Bridge certificates buy 90 days, not an extension. A HITRUST bridge certificate is valid for 90 days from the expiration of the previous r2 certification and "does not extend the expiration date of a HITRUST report."

The practical calendar

Working backwards from a target fieldwork start date, the sequence that avoids the incubation trap is:

1. Fieldwork start minus 6 to 7 months: scope and run the penetration test. For an r2, complete the scoping questionnaire first so the test scope matches the assessment scope.

2. Minus 5 to 6 months: remediate. This is where the median Critical fix time matters, and where healthcare change windows tend to slip.

3. Minus 4 months: retest and confirm closure. Anything still open here needs a corrective action plan rather than a fix.

4. Minus 3 months: the 90-day incubation clock starts on the last remediated control. Nothing technical should change after this point without accepting that it cannot be tested as implemented.

5. Fieldwork: up to 90 days, with the penetration test report and retest report presented as direct evidence.

Teams that run the test two months before fieldwork are not buying assurance, they are buying corrective action plans.

Scoping a penetration test for a HITRUST assessment

Four rules that follow from what HITRUST publishes.

Match the test scope to the assessment scope, in that order. For an r2 the scoping questionnaire drives control selection, so it should be completed before the test is scoped. For an e1 or i1 the requirement set is fixed, so the variable is which systems and environments are in scope. A penetration test of a system that is out of the assessment scope produces findings the assessor cannot use and remediation deadlines nobody needed.

Understand what a carve-out does and does not do. e1 and i1 assessments allow requirements performed by a service provider on the entity's behalf to be carved out of consideration; r2 assessments do not. Where a control is inherited from a certified cloud provider, the provider's certification carries it. Where it is carved out, the requirement is simply not evaluated, and a customer reading the report may notice.

Do not carve out what cannot be carved out. Requirement statements in the Never N/A Registry, including the vulnerability-management set above, are expected to be scored even where the testing population is zero, and marking one Not Applicable opens a HITRUST quality assurance task. The application and network testing that produces evidence against those requirements is therefore not optional in practice.

Test the classes that certification thresholds punish. The r2 needs every domain to score at least 62 and the e1 and i1 need every domain to score at least 83, so a single weak domain sinks a certification regardless of how strong the rest is. Access control, network protection and vulnerability management are the domains most exposed to what an external tester actually finds.

For a multi-tenant healthcare platform, the scope that usually maps best is: external network perimeter, the web application and its APIs with a full authorisation matrix per role, the cloud configuration, and the internal network where staff access production. Stingrai's web application penetration testing service covers the middle of that list, which is also where the certification-relevant findings concentrate.

What a HITRUST-driven test actually finds

Cadence arguments get easier with data about outcomes. Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings across 55 penetration tests, and four of its numbers map directly onto the HITRUST timing rules above.

92.7% of tests surfaced at least one High or Critical finding. Plan the assessment calendar on the assumption that the test will produce something requiring remediation, because it almost always does. A schedule with no remediation window built in is a schedule that will produce corrective action plans.

70% of web application tests that produced findings surfaced a High or Critical authentication or authorization finding. These land squarely in the access-control domain, and the r2's 62-per-domain and the e1 and i1's 83-per-domain thresholds mean a weak domain is a failed certification rather than a lower score.

Median Critical fix time was 10.5 days, against 38 days for Highs. Add the 90-day incubation period to the High figure and you get roughly four months between the test and a defensible fieldwork start. That is the number to put in the project plan.

The false positive rate was 0.74%. Because a penetration test is direct evidence rather than third-party reliance under criterion 13.2.3, an External Assessor reads the findings themselves. A report inflated with unvalidated scanner output costs assessor time and credibility on the findings that matter.

What it costs

HITRUST publishes no penetration testing prices, and neither does anyone else in a form that can be verified. What can be published is arithmetic on two figures that are themselves published: a day rate and a day count.

At the median published penetration testing day rate of £1,000 across 30 UK public-sector rate cards in Stingrai's Penetration Testing Price Index 2026, and the published tester-day counts collected in the penetration testing cost per hour and day rates guide, the scopes that most often accompany a HITRUST assessment derive as follows. Conversions use US$1.3555 per GBP, the Federal Reserve H.10 observation dated 28 August 2026 cited in that guide.

Every figure in that table is derived, not quoted. None of it includes the assessor fee, the MyCSF subscription or the readiness work, which are the larger lines in most HITRUST budgets and which HITRUST prices through its assessor ecosystem rather than publicly.

Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest from US$3,000 one-time driven by Snipe, and a Hybrid Pentest at US$6,800 one-time where certified penetration testers work alongside Snipe throughout the engagement, both covering one web application and its APIs, with the same two tiers available continuously at US$450 and US$1,275 per month on a 12-month engagement. Retesting is part of the package, which matters more here than in most frameworks because the retest is what proves remediation under requirement 0778 and what starts the incubation clock cleanly.

HITRUST and HIPAA together

Most organisations pursuing HITRUST are also HIPAA regulated entities, and the two obligations pull in the same direction without being the same thing.

HIPAA is a regulation with an enforcement agency. Its Security Rule requires a risk analysis, a periodic evaluation and maintenance of security measures, and it names no test type. HITRUST is a private certification with a licensed control framework, an assessor ecosystem and a scoring model. HITRUST offers an Insights Report that translates assessment results into the language of specific compliance standards including HIPAA, and a Targeted assessment, which the Assessment Handbook describes as "a non-certifiable self-assessment which consists only of HITRUST requirement statements that map to one or more authoritative sources (e.g., NIST 171, FedRAMP, HIPAA)."

Neither replaces the other. A HITRUST certification is not a HIPAA compliance determination, and OCR does not certify anyone. What they share is evidence: one well-built penetration test, with a scope statement, a technical report, a remediation record and a retest, satisfies the HITRUST assessor's direct-testing requirement and the HIPAA risk analysis input at the same time. Our companion guide to HIPAA penetration testing requirements sets out the clause-by-clause mapping on the HIPAA side, and the pentest evidence auditors accept guide covers the same package across SOC 2, ISO 27001, PCI DSS and CMMC.

What this means for buyers

• Do not quote a HITRUST penetration testing frequency to your board. Quote the published scanning cadence, "annually at minimum" from requirement 07.10m1Organizational.3, and the annual configuration-checking and compliance-assessment requirements, then justify an annual penetration test as the consistent practice rather than as a citation.

• Work backwards from the 90-day incubation period. Test roughly six months before fieldwork, remediate, retest, then freeze technical change. This single rule prevents more corrective action plans than any other planning decision.

• Ask the External Assessor what evidence they want before you scope the test. The report is direct evidence under criterion 13.2.3, so its structure matters. Findings mapped to control references, per-role authorisation coverage and a retest record are worth more than a longer findings list.

• Decide the independence configuration deliberately. The published rules permit an assessor firm to run your penetration test; they do not permit the same personnel to have implemented or operated the controls in the prior 12 months. Write the split into the statements of work rather than discovering it during fieldwork.

• Watch the weakest domain, not the average. Certification is gated per domain, at 83 for the e1 and i1 and 62 for the r2, so an access-control or vulnerability-management domain dragged down by test findings fails the whole assessment.

• Confirm the requirement count for your CSF version. The e1 has been published at both 44 and 43 requirements across CSF releases, and e1 and i1 assessments must be created against the most current CSF version available at the time.

Frequently Asked Questions

Does HITRUST require penetration testing?

HITRUST publishes no document stating a penetration testing requirement or frequency. The CSF requirement statements are licensed content inside MyCSF and are not public. Penetration testing appears in HITRUST's published Assessment Handbook version 1.2 in the independence rules, which permit assessor personnel to perform it, and in the reliance rules, which classify a penetration test report as direct testing evidence rather than third-party reliance. Both references treat penetration testing as a normal part of an assessment, without setting a cadence.

How often should we run a penetration test for HITRUST?

At least annually, and finished far enough ahead of fieldwork that remediated controls clear the 90-day incubation period. The published basis for annual is the neighbouring requirement text: 07.10m1Organizational.3 requires vulnerability scanning "annually at minimum," 0613.06h1Organizational.12 requires annual technical security configuration checks, and 0601.06g1Organizational.124 requires annual compliance assessments. An annual penetration test is the consistent practice rather than a quoted HITRUST rule.

What is the difference between HITRUST e1, i1 and r2?

The e1 is a one-year certification against 43 foundational controls, scored on the Implemented maturity level only, aimed at lower-risk organisations. The i1 is a one-year certification against 182 control requirements, also scored on Implemented only, with a lighter year-two recertification focused on approximately 60 core controls. The r2 is a two-year certification with requirements tailored by a risk-based scoping questionnaire, scored across Policy, Procedure and Implemented with optional Measured and Managed levels, and it requires an interim assessment before the one-year anniversary. All three require an Authorized External Assessor to inspect evidence.

What score do we need to certify?

Each domain must clear a threshold, and the threshold differs by assessment type. Per criterion 15.1.2 of the Assessment Handbook, "The i1 and e1 require the core e1 and i1 requirement statements in each domain to score at least an 83, while the r2 requires each domain to score at least a 62 to achieve certification." Assessments that do not clear the threshold receive a validated-only report that states the certification thresholds were not met.

What is the HITRUST 90-day incubation period?

Criterion 11.2.8 requires every control supporting a HITRUST requirement statement to have been implemented for a minimum of 90 consecutive days before it can be tested as implemented, and that applies to a newly implemented control and to one remediated due to deficiencies. Policies and procedures carry a shorter 60-day incubation under criterion 11.2.10. Controls performed by a service provider can skip the wait where the provider can demonstrate 90 days of operation, per criterion 11.2.9.

Can our penetration testing firm also be our HITRUST External Assessor?

The published independence rules permit it. Criterion 3.3.6 lists penetration testing among the services assessor personnel involved in a validated assessment may perform for an assessed entity, excluding remediation activities that involve implementation or operation of a control. The limit is criterion 3.3.5: personnel involved in the prior 12 months in implementing or operating the controls being evaluated may not work on the validated assessment, and a separate team with a separate engagement partner is required. Many organisations still split the roles, because the split leaves the fewest questions in a customer security review.

Which HITRUST controls does penetration testing produce evidence for?

HITRUST's published certification control reference list in the CSF Assurance Program Requirements includes 10.m Control of Technical Vulnerabilities, 06.h Technical Compliance Checking and 06.g Compliance with Security Policies and Standards, alongside the access control, network control and application control families that an external test exercises directly. That document is written against CSF v9.3 and dated October 2019, so treat it as evidence of which control families are certification-relevant rather than as the current requirement list.

Does a HITRUST certification make us HIPAA compliant?

No. HITRUST is a private certification programme and HIPAA is a federal regulation enforced by the HHS Office for Civil Rights, which does not certify anyone. HITRUST does offer an Insights Report that translates assessment results into HIPAA language, and a non-certifiable Targeted assessment consisting only of requirement statements mapped to a chosen authoritative source such as HIPAA. The overlap is real and useful, but the HIPAA obligations sit on the regulated entity regardless of certification status. See our guide to HIPAA penetration testing requirements.

What happens if we miss the r2 interim assessment?

Criterion 15.4.10 states that the interim assessment must be submitted by the External Assessor on or within 90 days prior to the one-year anniversary of the r2 certification date, and that "non-submission of an interim assessment by the deadline will result in suspension and/or revocation of the Assessed Entity's certification." The interim samples one randomly selected requirement statement from each domain plus all requirements that produced required corrective action plans, and HITRUST performs a quality assurance review of the submission.

Can we mark vulnerability management requirements as Not Applicable?

Generally no. The Never N/A Registry in Appendix A-20 of the Assessment Handbook lists core requirement statements "expected to never be scored as Not Applicable," and the vulnerability-management set under control 10.m sits on it, including the scanning requirement 07.10m1Organizational.3 and the remediation-verification requirement 0778.10m1Organizational.5. HITRUST states these must be scored "even if there is a zero population for testing." Marking one Not Applicable opens a quality assurance task requesting that it be scored, and an exception process exists for genuinely unique circumstances.

How much does a penetration test for HITRUST cost?

HITRUST publishes no testing prices, and the assessor fee, MyCSF subscription and readiness work are separate lines it does not publish either. Deriving from published inputs only, at the median published day rate of £1,000 in Stingrai's Penetration Testing Price Index 2026 and the published tester-day counts in the cost per hour guide, a single web application at 3 to 5 days derives to £3,000 to £5,000 and an API scope at 4 to 9 days to £4,000 to £9,000. Stingrai's published packages start at US$3,000 one-time for one web application and its APIs.

Where can I read HITRUST's own rules?

The Assessment Handbook version 1.2 is the operative document and carries the independence, incubation, scoring, interim and reliance rules quoted throughout this page. The assessments and certifications overview and the individual e1, i1 and r2 pages carry the control counts and validity periods. The CSF Assurance Program Requirements carries the certification control reference appendix. The CSF itself is licensed and delivered through MyCSF.

Related Reading

• HIPAA Penetration Testing Requirements (2026): Security Rule, Cadence, Scope and Cost

• Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)

• SOC 2 Penetration Testing: What Auditors Expect and How to Scope It (2026)

• Healthcare Data Breach Statistics 2026

• Penetration Testing vs Vulnerability Assessment: What Compliance Frameworks Really Require

• Penetration Testing Price Index 2026

• The State of Penetration Testing 2026

References

1. HITRUST. The HITRUST Assessment Handbook, Version 1.2. Retrieved 5 September 2026. https://hitrustalliance.net/hubfs/Website/PDF%20Downloads/Final%20-%20HITRUST%20Assessment%20Handbook%20v1.2.pdf. The operative HITRUST programme document: assessment types and their comparison table (chapter 4), independence requirements (chapter 3.3), control maturity levels (chapter 9), testing and evidence rules including the 90-day and 60-day incubation periods (chapter 11.2), reliance rules (chapters 12 and 13.2.3), certification thresholds and reporting (chapter 15.1), interim assessment rules (chapter 15.4), bridge assessments (chapter 15.8) and the Never N/A Registry with verbatim requirement statements (Appendix A-20).

2. HITRUST. Cybersecurity Assessments and Certifications. Retrieved 5 September 2026. https://hitrustalliance.net/assessments-and-certifications. Published portfolio overview: e1 at 43 core controls valid one year, i1 at 182 control requirements valid one year, r2 valid two years, and the traversable-portfolio model.

3. HITRUST. HITRUST e1 Assessment: 1-Year Validated Assurance. Retrieved 5 September 2026. https://hitrustalliance.net/assessments-and-certifications/e1. Published e1 control count, annual renewal requirement and target organisation profile.

4. HITRUST. HITRUST i1 Assessment: 1-Year Validated Assurance. Retrieved 5 September 2026. https://hitrustalliance.net/assessments-and-certifications/i1. Published i1 control count of 182 and the approximately 60 core controls used in year-two rapid recertification.

5. HITRUST. HITRUST r2 Assessment: 2-Year Validated Assurance. Retrieved 5 September 2026. https://hitrustalliance.net/assessments-and-certifications/r2. Published two-year validity, the interim assessment after one year, the risk-based tailoring model and the authoritative-source mapping claim.

6. HITRUST. HAA 2023-004: e1 Assessment Introduction. 17 January 2023, retrieved 5 September 2026. https://hitrustalliance.net/advisories/haa-2023-004-e1-assessment-introduction. States that all e1 assessments against a given CSF version carry the same requirements, at that time 44, and that changes ship in major and minor CSF releases.

7. HITRUST. HAA 2021-012: i1 Introduction and r2 Enhancements. 28 December 2021, retrieved 5 September 2026. https://hitrustalliance.net/advisories/haa-2021-012-i1-introduction-and-r2-enhancements. Introduces the i1 certification, renames the prior validated assessment to r2, and sets out the shared characteristics of the two.

8. HITRUST. HITRUST CSF Assurance Program Requirements. October 2019, written against HITRUST CSF v9.3, retrieved 5 September 2026. https://hitrustalliance.net/hubfs/CSF-Assurance-Program-Requirements.pdf. Appendix A lists the certification control references, including 06.g Compliance with Security Policies and Standards, 06.h Technical Compliance Checking and 10.m Control of Technical Vulnerabilities.

9. HITRUST. HITRUST CSF, Our Cybersecurity Framework. Retrieved 5 September 2026. https://hitrustalliance.net/hitrust-framework. States that the framework harmonises over 70 regulations, standards and other authoritative sources, and publishes the breach-free rate HITRUST reports for certified environments.

10. Stingrai. HIPAA Penetration Testing Requirements (2026). https://www.stingrai.io/blog/hipaa-penetration-testing-requirements-2026. The regulatory counterpart to this guide, with the HIPAA clause to test type to evidence mapping.

11. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, authentication and authorization finding rates, remediation timing and false positive rate.

12. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate and central band across 30 public-sector rate cards.

13. Stingrai. Penetration Testing Cost Per Hour and Day Rates (2026). https://www.stingrai.io/blog/penetration-testing-cost-per-hour-2026. Published tester-day counts per engagement type and the currency conversion basis used in the cost table above.

14. Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.

Ready to time a penetration test around your HITRUST assessment?

The 90-day incubation period is the constraint that decides whether your findings become fixed controls or corrective action plans, and it means the test belongs roughly six months ahead of fieldwork rather than six weeks. Stingrai is a CREST-accredited penetration testing service provider whose penetration testing supports HITRUST and HIPAA programmes by producing exactly what an External Assessor inspects directly: a scope statement, a technical report with findings mapped to control references, a remediation record and a retest. Certified penetration testers work alongside Snipe, our autonomous AI agent for web application penetration testing, throughout the engagement, hunting the broken authorization and business logic flaws that drag an access-control domain below its certification threshold. Book a free scoping call, get a quote for a multi-application or multi-environment scope, or read the published package prices on the pricing page.