Penetration testing for HITRUST

Penetration testing for HITRUST: what the report must prove to an assessor

A penetration test counts toward a HITRUST assessment only when its report maps to the requirement statements in scope. The HITRUST Assessment Handbook v1.2 treats penetration test reports as evidence for direct testing of requirement statements, so the question for a CISO preparing for an e1, i1 or r2 assessment is not whether a test was performed but whether the report can be traced to specific statements the assessor will test. Before commissioning work, pull the scope from the assessment object and list the requirement statements that touch external and internal exposure, remote access, and the systems that hold or transmit the data in scope. Then confirm with your assessor which of those statements they expect penetration testing to support. A generic test of the whole company will often leave gaps against a narrower scope. Assessors look for four things in the report: a clear statement of scope and the systems, network segments and applications tested; the method and the tester's approach; the findings with severity and evidence; and the retest results showing how each exploitable finding was corrected and verified. A report that lists vulnerabilities without the scope or retest is hard to map to a requirement statement and will generate follow-up questions. Ask the provider to show a sample report and check that each finding can be tied to an asset in scope. Also confirm the tester's independence from any party that implements or operates your controls, because the Handbook allows assessor organizations to perform testing for an assessed entity but excludes remediation work that implements or operates a control. DeployOpen plans and performs security testing and prepares the evidence package, including scope documentation, reports and retest records. DeployOpen does not issue HITRUST assessment outcomes, validated reports or certifications. Those decisions rest with HITRUST and its assessor organizations, so confirm the expected evidence format with your assessor before fieldwork begins.

How to scope penetration testing for HITRUST assessment scope

A HITRUST penetration test only counts as evidence for the requirement statements it actually exercises. Each decision below ties the test back to the systems that hold or transmit in-scope information, so the assessor can trace the report to specific controls.

Systems that hold or transmit in-scope data

Start from the systems named in the assessment scope: applications, hosts, databases, cloud accounts, APIs and network segments that store, process or transmit the covered information. Map each one to the requirement statements it supports, so a finding on a host can be traced to a control. Systems that merely connect to the scope boundary should be recorded with a reason for inclusion or exclusion, since the assessor will ask about both.

External and internal vantage points

Decide which tests run from the internet and which run from inside the network, and from which network zones. Internal testing from a segment that reaches in-scope systems usually matters more for clinical or data-store assets than external testing alone. Document each vantage point in the scope letter so the report states where every result was observed.

Test accounts and roles

Agree which user roles, tenants and privilege levels the tester will use, such as standard user, administrator and service account. Authenticated testing exposes access control weaknesses that unauthenticated testing misses. Confirm who provisions these accounts, how credentials are handled and when they are removed after the engagement.

Cloud and third-party boundaries

Confirm which cloud accounts, subscriptions and hosted services fall inside the assessed environment, and which belong to a provider whose testing rules or contract terms restrict what you can test. Record the shared responsibility split for each service so the report does not claim coverage of components the organization does not operate. Confirm any provider approval required before testing begins.

Rules of engagement and testing windows

Write down what the tester may and may not do: permitted techniques, denial of service exclusions, data handling limits, stop conditions, escalation contacts and out-of-hours windows. Clear rules protect production systems and make the report defensible to the assessor. Confirm these terms with your assessor and the testing provider before any work starts.

Assessor-agreed scope confirmation

Before testing begins, get the final scope in writing from your HITRUST assessor, covering systems, requirement statements, vantage points and rules of engagement. Changes to the environment after that point should trigger a scope review. Check with your assessor whether the scope must be reconfirmed if the assessment window moves.

Who may perform the testing under HITRUST independence rules

The HITRUST Assessment Handbook v1.2 allows an assessor organization to provide penetration testing and vulnerability scanning to an assessed entity, provided the work does not extend into remediation. The assessor may run the test and report the results, and HITRUST treats those penetration test reports as evidence for direct testing of requirement statements. The boundary is about role conflict: an assessor that also builds, configures or operates a control it later evaluates has compromised its own objectivity, so the Handbook excludes remediation work that implements or operates a control.

Permitted work: Penetration testing and vulnerability scanning delivered as a service to the assessed entity.
Excluded work: Fixing findings, implementing a control, or operating a control that the same firm will assess.
Evidence role: The report can be used as direct testing evidence for the relevant requirement statements, subject to the assessor's own workpaper standards.
Sequencing: Confirm whether the test is performed before or during fieldwork, and whether the same engagement team is involved.
Documentation: Keep the statement of work, tester identities and the separation between testing and remediation on file.

Confirm with your assessor whether they offer testing under the current Handbook version and how they document the independence assessment.

How a penetration test for HITRUST runs, phase by phase

The sequence moves from written rules of engagement to a validated, retested set of findings, so each phase produces evidence that maps to the requirement statements the assessor will test. The order also keeps testing and remediation separated so the assessed entity owns its controls.

Agree scope and written rules of engagement
The assessed entity and the tester agree in writing which systems, applications, networks, cloud accounts and facilities are in scope, which HITRUST requirement statements the test is meant to inform, and which test types are allowed. The rules of engagement cover testing windows, contact points, handling of production data, stop conditions and who may approve out-of-scope activity. The closing check is a signed scope document that names every in-scope asset and the owner who approved it. Ask the provider to confirm that its team is organizationally independent of any remediation work on the same environment, because the HITRUST Assessment Handbook v1.2 limits what an assessor organization may do for the entity it assesses.
Map the environment and model threats
The tester collects the architecture view, asset inventory, data flows and access model from the client, then builds a threat model that ties likely attack paths to the systems that store, process or transmit regulated data. This is where the team decides which applications, APIs, identity services and network segments need the deepest coverage. The output is a short test plan listing targets, threat scenarios and the test types chosen for each, reviewed and accepted by the client. Reviewing the threat picture against recent threats is a useful step to document, since it shows the test responds to current conditions and not only to a fixed checklist.
Test applications and APIs
Testers assess in-scope web applications, mobile back ends and APIs against recognized testing guidance, with particular attention to authentication, session handling, authorization, input handling and sensitive data exposure. Testing runs in the agreed environment, which may be a production-like staging system, and every action is logged with timestamps for later review. Weaknesses are recorded by category and tied to the affected requirement areas. The step closes when each target in the plan has either been tested to the agreed depth or documented as limited, with the reason stated.
Test networks, cloud and identity
Testers assess external and internal network exposure, remote access, wireless where in scope, cloud configuration and identity services within each provider's published testing rules and the shared responsibility model. Segmentation between systems holding regulated data and the rest of the environment is checked, because the boundary determines which controls the report can speak to. Results are recorded per target with evidence sufficient for a reader to reproduce the observation without the tester present. The step closes when coverage matches the plan and every gap in access or tooling is written down.
Validate findings and assign severity
Before reporting, the tester confirms each finding is real, removes duplicates and rates severity using a method the client agreed in the rules of engagement. Findings that cannot be confirmed are marked as unverified rather than dropped, so the client sees the full picture. This follows the vulnerability handling approach in ISO/IEC 27002:2022, which asks organizations to obtain information about technical vulnerabilities, evaluate their exposure and decide on treatment. The closing check is a findings register where every item has a status, severity, affected asset and evidence reference.
Deliver the report and brief the owners
The tester issues a report with scope, methodology, dates, tester qualifications, a summary for leadership and a detailed findings section. The report is written so the assessed entity can give it to its HITRUST assessor as evidence for the relevant requirement statements. A walkthrough with the system owners clarifies each finding and the expected fix, but the tester does not design or implement the fix. The step closes when the client confirms receipt, the report version is recorded and the findings register is handed over to the entity's own remediation tracking.
Track remediation on the entity's side
The assessed entity owns remediation: it prioritizes findings, assigns owners, changes configurations or code, and records the actions taken and the dates. The tester may answer clarification questions about a finding but does not implement or operate the fix, which keeps the test independent of the control it is checking. The closing check is an updated findings register showing the change applied to each item, with supporting records such as change tickets or pull requests. Ask the provider to confirm which remediation support it offers and how it keeps that support separate from testing.
Retest to verify the fixes
Once the entity reports that fixes are in place, the tester repeats the relevant checks against the changed systems and records whether each finding is closed, partly closed or still open. Retest results are added to the report or issued as a retest letter with its own date and scope, so an assessor can see that the corrected state was verified. Findings that remain open carry a documented reason and an accepted risk decision from the entity. The step closes when every critical or high finding has a retest outcome and the register reflects the verified status.

Weakness categories a HITRUST penetration test looks for

This table maps six weakness categories to how they typically appear in an in-scope environment and why each one matters to the assessment. Read it as a guide to where testing effort concentrates, then check each row against your own system description and risk assessment.

Weakness category	How it appears in this target	Why it matters to the assessment
Broken authentication and session handling	Weak login flows, session tokens that persist after logout or privilege change, gaps in multi-factor enforcement on administrative paths	Access control requirement statements depend on identity being reliable, so testers document whether authentication holds under realistic conditions
Broken access control between tenants or roles	Users reaching records, functions or other tenants' data by altering identifiers or using roles they should not hold	Authorization is among the most direct tests of whether the system protects the data it claims to protect, and findings here often map to multiple requirement statements
Misconfigured cloud identity and storage	Overly broad role grants, publicly readable object storage, unmanaged service accounts and logging disabled on sensitive resources	Configuration evidence supports requirement statements on least privilege, logging and encryption, and testers confirm the configuration rather than relying on policy documents
Exposed or outdated remote access	Remote access gateways, VPN endpoints or admin consoles reachable from the internet with unpatched software or default settings	Remote access is a common entry point, so assessors look for evidence that exposed services are inventoried, patched and tested on a defined cycle
Insecure APIs carrying sensitive data	Endpoints returning more fields than the client needs, missing rate limits on authentication, or inconsistent authorization between web and API paths	Where protected health information or other regulated data moves through APIs, testing shows whether transmission and access controls hold at the interface level
Weak segmentation between in-scope and out-of-scope systems	Flat networks, shared credentials across environments, or management paths that let out-of-scope hosts reach in-scope systems	A narrow scope is only defensible if boundaries are proven, so testers attempt to cross them and report what they can reach from each segment

What the client prepares before a penetration test

The assessed entity's preparation decides whether a penetration test can serve as direct evidence for HITRUST requirement statements. Start with a confirmed in-scope asset list that names every host, application, API, cloud account and network segment that supports the systems in the scope of the assessment, along with the environments each one runs in. An assessor testing requirement statements needs to know that the tested systems are the ones the organization actually operates. Agree the list in writing before testing begins, and record any asset that is excluded along with the reason, so the report and the system description point to the same boundary. Also confirm test accounts with agreed roles (for example, a standard user, a privileged user and a service identity where relevant), because access-control and authentication statements are only tested meaningfully when the tester can see each role's real permissions.

Next, name the people who make the test safe to run and quick to stop. Assign a technical contact who can answer questions about architecture and environment, and an escalation contact with authority to halt testing if a system degrades. Name them in the rules of engagement, with out-of-hours numbers. Set a change freeze window so that configuration changes, patches and deployments do not alter the target during testing, because a report describes the system as it was tested and a mid-test change makes its findings hard to tie to the system description. Give the security operations team advance written notice of the test windows, source addresses and any planned backup jobs, so that detection and response staff can separate authorized testing from a live incident. Log those notices. If the monitoring team does not know a test is running, the organization's own detection evidence may be incomplete, and an assessor may question it.

Finally, supply the documents that anchor the test to the assessed environment. Provide the current system description and the architecture diagrams it relies on, along with the results and remediation records from earlier penetration tests and vulnerability scans. Earlier reports show the assessor how findings were tracked and closed, and they make it easier to judge whether a retest actually verified a fix. Confirm with your assessor organization how these materials will be shared and stored, since they contain sensitive detail about your environment. Also confirm with your assessor whether the test provider is independent of the organization's own control implementation. The HITRUST Assessment Handbook v1.2 permits an assessor organization to provide penetration testing to the assessed entity, but excludes remediation work that implements or operates a control, so the preparation work above should be done by your team or a separate provider, not the assessor's remediation staff.

What the report must show for HITRUST evidence and what customers receive

A penetration test report only helps a HITRUST assessment when it shows what was tested, how it was tested and what happened to each finding. The cards below cover the report sections an assessor will look for, the separate summary a customer may receive, and the decisions that determine how the assessor uses the report in fieldwork.

Scope and methodology

The report must name the assessed systems, the hosts, applications and APIs in scope, the testing dates, the testers and the methodology followed. Map the scope to the systems supporting the HITRUST assessment scope so the assessor can see that the tested environment matches the environment described in the assessment. Confirm with your assessor which standards the report should cite, and check that exclusions are written down with a reason.

Findings mapped to requirement statements

Each finding should carry a severity rating, a description of the weakness category, the affected system, and the HITRUST requirement statements it bears on. Without that mapping, an assessor must reconstruct the link manually, which slows fieldwork. Ask the provider to explain its severity scale so that the ratings can be compared with your own risk register.

Exploitability validation

For each significant finding, the report should state whether the weakness was confirmed as exploitable in your environment, what conditions were needed, and what limited the impact. This shows the assessor that a finding was verified rather than inferred from a scanner result. The report should describe the validation outcome in plain terms and never include exploit code or step-by-step reproduction.

Remediation recommendations

Each finding needs a recommended fix at the level an engineering team can act on, such as the configuration change, code correction or compensating control to apply. Recommendations are advice only. DeployOpen's HITRUST testing terms allow an assessor organization to test but exclude remediation work that implements or operates a control, so ask who will carry out fixes and record that ownership in the report.

Retest report and closed findings

A retest report shows which findings were corrected, which remain open, and the evidence used to confirm each fix. Ask for the retest to reference the original finding identifiers so the assessor can trace each one from first report to closure. Open findings should carry a dated plan and an owner, because an assessor will ask about them during fieldwork.

Customer summary letter

A summary letter gives customers a short statement of when testing occurred, its scope level and the overall outcome. It does not replace the full report, and customers who need detail should be told that the full report is available under a separate agreement. Confirm with your legal and security teams what may be shared, since the full report describes weaknesses in your environment.

What to check and ask for when choosing a penetration testing provider

Before signing, a buyer should establish whether the provider can be used as HITRUST evidence at all. The HITRUST Assessment Handbook v1.2 allows an assessor organization to perform penetration testing and vulnerability scanning for an assessed entity, but it excludes remediation work that implements or operates a control. A provider that is not an assessor does not issue HITRUST outcomes, and DeployOpen is not an assessor and does not issue HITRUST outcomes. Ask your assessor, in writing, which role the provider will play: an independent tester whose report the assessor will test directly, or a party whose work the assessor will review as input. Also ask whether the tester has any role in operating the controls being tested, such as running the firewall rules, managing the identity platform or building the systems under test. If the same team configures or runs a control and then tests it, the independence question will come back during fieldwork.

Ask for the written scope and rules of engagement before any testing starts. The scope should name each system in the HITRUST scope, the environments (production, staging, or both), the test windows, the source addresses the testers will use, accounts and test data provided, and what is off limits, such as denial-of-service testing or social engineering. The rules of engagement should name the client contacts who can stop testing, the escalation path for critical findings found mid-test, and how credentials and sensitive data encountered during testing are handled. Ask for a sample report so you can check its structure: an executive summary, the methodology and tools used, the tested scope with any exclusions, each finding with severity, affected asset, evidence and remediation guidance, and a clear statement of what was not tested. Confirm the retest terms in writing, including whether retesting of corrected findings is included in the fixed price or billed separately, and how the provider documents closure. Finally, ask how findings and evidence are stored, who can access them, how long they are retained, and whether they are deleted on request. Request named testers with relevant experience and confirm they are the people who will do the work.

Penetration testing for HITRUST questions buyers ask

Does a penetration test alone satisfy a HITRUST requirement statement?

No. A penetration test is evidence that can support a requirement statement, but it rarely satisfies one on its own. The HITRUST Assessment Handbook v1.2 treats penetration test reports as evidence for direct testing of requirement statements, so the assessor decides whether a given report covers the statement's systems, scope, date and depth. Your report should name the systems tested, the methodology, the findings, and how critical findings were remediated and verified. Policies, configuration records and the vulnerability management process may also be needed. Confirm the mapping with your assessor before the test is scoped.

Who is allowed to perform the penetration test for HITRUST?

The tester must be qualified and the assessment team's independence rules apply. The Handbook allows assessor organizations to provide penetration testing and vulnerability scanning to an assessed entity, but excludes remediation work that implements or operates a control. Using the assessor firm for testing is therefore possible, though it limits what that firm may later do for the same environment. Internal teams and outside firms can both be considered. In each case, document the tester's qualifications, their independence from the team that operates the system, and the boundaries of the work. Confirm the arrangement with your assessor early, because the final decision on acceptable testers sits with them.

How should penetration testing be timed against the assessment fieldwork window?

Schedule the test so that its results are current when the assessor reviews evidence. Testing should finish early enough that critical and high findings can be remediated and retested before fieldwork begins. Testing late in the window leaves little room to correct problems, and assessors may question evidence that predates significant changes to the in-scope environment. Plan a change freeze or a re-test trigger for major releases, infrastructure moves or new integrations made after the test. Ask your assessor which evidence dates and look-back periods apply to your assessment type, since the Handbook sets the rules for each.

What must our team provide before a HITRUST penetration test starts?

Most of the effort in a penetration test before testing begins sits in preparation. The client typically needs to provide:

A written list of in-scope systems, applications, IP ranges and cloud accounts that matches the HITRUST scope boundary
Rules of engagement, including permitted test windows, prohibited activities and emergency contacts
Test accounts at each privilege level, plus documentation of the intended roles and authentication flows
Architecture diagrams, data flow information and any known segmentation controls
Prior test reports, open risk items and the remediation history for them

The tester will also need named contacts who can respond during testing. Gaps in these inputs usually lead to narrower testing or additional scoping time, so agree them in writing before work starts.

What drives the cost and effort of a HITRUST penetration test?

The cost reflects how much testing time the scope requires and how much reporting and retesting the assessment needs. The main drivers are the number of in-scope systems and applications, the number of environments, whether testing is authenticated or unauthenticated, the mix of external, internal and application testing, and the complexity of the architecture. Reporting depth, the number of retest rounds and any on-site requirements also add effort. Ask for a quote that separates planning, testing, reporting, retesting and any travel, and that states which items are one-time and which recur if you use a retainer for continuous testing. Compare quotes against the same written scope, not against the headline number.

Can our internal security team run the penetration test for HITRUST?

Internal teams can perform testing, but the decision depends on the team's skills, its independence from the systems it tests, and what your assessor will accept as evidence. Internal testers often know the environment well, which helps depth and speed, but they may struggle to demonstrate independence in the assessor's view. Keep the test plan, tool records, methodology and tester qualifications documented regardless of who performs the work. If an outside firm is used, note that DeployOpen plans, implements and supports self-hosted open-source platforms, so ask the assessor whether testing a platform your provider also implemented is acceptable for your assessment.

How does retesting work after a HITRUST penetration test finds issues?

Retesting verifies that corrected findings are actually fixed, and the assessor will expect evidence of that verification. After remediation, the tester re-examines each finding that was marked as corrected, records the outcome and updates the report or issues a retest letter. Critical findings should have documented mitigating actions and a clear closure record, even if the fix takes longer than planned. Agree the retest scope, the timeline for retests and the report format in the original scope, since retest effort is often priced separately. Keep the original report, remediation tickets, retest results and dates together so they can be presented as one evidence trail.

How DeployOpen scopes, tests, reports and retests

DeployOpen runs penetration testing as a fixed-scope engagement agreed in writing before work starts, so the report maps to the HITRUST requirement statements in your assessment. We document methods, findings and retest results in a form your assessor can trace, and we support the work with an optional retainer.

How we scope

Written scope lists the systems, environments and requirement statements the test is meant to inform.
We confirm which assessment scope, business units and hosting environments fall inside the test boundary.
Scope records whether testing is external, internal, application-layer or a combination, and who performs each part.

How we build

We agree test accounts, credentials and rules of engagement with your team before any testing begins.
Testing follows a documented methodology so each finding can be traced to the system and the test approach used.
Findings are rated by exploitability and business impact, and critical items are raised with your team during testing.

How we hand over

The report describes scope, methodology, tested assets, findings, evidence and recommended remediation for each issue.
Each finding is written so your assessor can match the test evidence to the requirement statement it supports.
A retest after remediation confirms whether each finding is closed, and the retest result is delivered in writing.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial test.
Retesting can be timed to your HITRUST assessment fieldwork window, which we confirm with your assessor and your team.
Ask your assessor which HITRUST assessor rules apply before engagement, since testing performed by an assessor organization has specific limits.