HITRUST Penetration Testing Requirements: Scope, Frequency, Process & Compliance Guide

HITRUST assessments review an organisation’s controls to determine its ability to protect sensitive information and mitigate cyber risks. Penetration testing may become an integral part of such validation, especially if an organisation’s environment has internet accessible systems, applications, APIs, internal networks, cloud, or any other technology that may create exploitable vulnerabilities.

Yet, penetration testing cannot stand alone as a process. Its scope, methodology, frequency, and evidence must be defined based on an organisation’s environment, assessment scope, HITRUST requirements and risks.

This guide will help you understand the place of penetration testing in HITRUST assessments, the components of the testing scope, how often to perform such testing, and how to prepare evidence required for an assessment.

What Is HITRUST Penetration Testing?

HITRUST penetration testing is the active testing of an organisation’s systems and applications aimed at uncovering security vulnerabilities that an attacker can exploit.

Unlike automatic scanning for vulnerabilities, penetration testing is based on the validation and exploitation of vulnerabilities to test whether these vulnerabilities can be used to break into systems, steal sensitive data, disable controls, or traverse the environment.

Penetration testing allows organizations to prepare for HITRUST assessment and prove the presence of functioning security controls.

The approach to penetration testing should be consistent with the environment defined by the organisation and the requirements for the HITRUST assessment.

How Penetration Testing Fits HITRUST e1, i1 and r2 Assessments?

One of the important factors when planning penetration testing for HITRUST is understanding the assessment level being pursued.

HITRUST offers various types of assessments such as e1, i1, and r2. However, these are not just names of different assessments. There is a difference between these in terms of scope and level of assurance.

Under the current HITRUST CSF v11.9.0 structure, the e1 baseline contains 44 requirement statements, while the i1 baseline contains 182 requirement statements. HITRUST also uses a nested structure in which the e1 requirements are included within i1, and the i1 requirements are included within r2.

A practical way to understand how penetration testing may fit into each assessment is to compare the broad focus of the assessment with the testing approach that may be appropriate. The table below is an illustrative guide, not a fixed set of testing requirements for every organisation.

Assessment level	Security Objective	Validation Activities
e1Assessment	Security Hygiene & Exposure Visibility	Automated Scanning & Cyber Hygiene Review
I1Assessment	Security Control Effectiveness	Targeted Penetration Testing & Control Validation
R2 Assessment	Risk-Based Adversarial Resilience	Comprehensive Offensive Testing & Retesting

The assessment level should inform the planning process, but it does not automatically prescribe a particular penetration testing package. The final scope and methodology should be based on the applicable HITRUST requirements, the assessment boundary, the technologies in use, and the organisation’s risk profile.

HITRUST e1

The HITRUST e1 assessment concentrates on core cybersecurity controls and gives basic level of assurance.

In assessing e1 level, penetration testing shall be considered in view of the particular system(s), applications, and technology being assessed.

It shall not be assumed that the level of the assessment implies that a one size fits all penetration testing package is required for each entity.

The right penetration testing package shall depend on the applicable requirements, technology, and risks.

HITRUST i1

The HITRUST i1 Assessment covers more areas than e1 level and the requirement statements of e1 assessment are part of baseline at the i1 level.

Since the control scope is wider, organisations will have to take into account more aspects including the technologies and the attack surfaces while planning the penetration test.

This may cover external infrastructure, internal networks, web applications, APIs, cloud environments, and other systems under the scope of the assessment.

HITRUST r2

HITRUST r2 is more thorough and uses a risk-oriented assessment process. This is because there is more flexibility in terms of adjusting the requirements to the specific risk profile of the organisation.

When planning penetration testing for an r2 assessment, it must be done according to the needs of the organisation, rather than a pre-defined list of testing criteria.

This may require testing several attack surfaces and providing enough proof that the necessary security controls have been tested.

What Does the Assessment Level Mean for Penetration Testing?

The main idea here is that the levels e1, i1, and r2 cannot be regarded as three different penetration test packages.

The assessment level establishes the broader assurance context, while the actual penetration testing strategy should consider:

• The applicable HITRUST requirements
• The defined assessment boundary
• External and internal attack surfaces
• Applications and APIs
• Cloud and other technology environments
• Network segmentation
• Business and security risks
• Significant changes to the environment
• Previous penetration testing findings
• Remediation and retesting requirements

Knowing the assessment level is important for organisations in order to know how penetration testing should fit into their overall assessment and evidence plan.

What Should Be Included in a HITRUST Penetration Testing Scope?

The penetration testing scope should be defined prior to testing. The scope should include the systems and technologies that are relevant to the assessment.

External Network Testing

External network testing evaluates internet-facing systems and infrastructure from an attacker’s perspective.

Testing may include:

• Public IP addresses
• Internet-facing servers
• Network devices
• Remote access services
• Externally accessible security controls
• Exposed services and ports

The aim is to identify any weakness that can enable a third party to gain entry into the environment.

Internal Network Testing

Internal network testing checks on the security of the system after the attacker has found a way into the environment.

Depending on the defined scope, testing can examine:

• Internal servers
• Workstations
• Active Directory environments
• Network devices
• Privilege escalation opportunities
• Lateral movement paths
• Internal applications
• Segmentation controls

When network segmentation is a key security measure, segmentation penetration testing can assist in determining if the boundaries of the networks limit the unauthorised movement across different environments.

Web Application and API Testing

Web applications and APIs could pose risks to sensitive data and business functionality and hence must be considered for testing.

Testing can include:

• Authentication and authorisation
• Session management
• Input validation
• Access control
• Business logic
• API endpoints
• Sensitive data exposure
• Common application vulnerabilities

Testing should go beyond automated scanning where appropriate and include manual validation of security weaknesses.

Cloud and Other Technology Environments

Companies work within cloud technology, container, mobile environments, and various other technological structures.

If such technology is included within the relevant environment, consideration should be made of the related attack surfaces and security measures during penetration testing.

The scope should be documented prior to conducting penetration testing to allow for an understanding of what was tested, what was excluded, and for what reason.

Key HITRUST Penetration Testing Considerations

A good penetration test will do more than just use security tools on an IP address range.

1. Define the Scope

Find out what systems, applications, network, APIs, clouds and other assets are subject to testing.

2. Establish the Testing Methodology

The approach will describe in which way testing will be executed – reconnaissance, vulnerabilities validation, exploits, privilege escalation, etc.

3. Combine Automated and Manual Testing

While automated approaches are helpful to detect vulnerabilities quickly, manual testing is critical to see whether these vulnerabilities can actually be leveraged by attackers.

4. Consider Business and Security Risk

Testing needs to account for sensitivity of data and system, possible ways how attacks will occur, and the consequences of being compromised.

5. Document Findings

Every finding needs to describe the vulnerability, the affected asset, its possible impact, the level of its severity, and the evidence that proves the result.

6. Remediate Identified Weaknesses

Penetration testing is highly effective if vulnerabilities found are allocated to the right owners and are fixed using a proper remediation process.

7. Retest Where Appropriate

Once important vulnerabilities are remediated, re-testing will help find out if the issues have been properly fixed.

How Often Should HITRUST Penetration Testing Be Performed?

The frequency of penetration testing depends on the organisation’s requirements, risks, technology, and environment changes.

Organisations should not rely on a single test performed only before an assessment. Testing should be incorporated into the broader security testing programme.

Additional testing may be appropriate following significant changes such as:

• Major infrastructure changes
• Deployment of new internet-facing applications
• Significant application changes
• Network architecture changes
• Cloud environment changes
• Major security control changes
• Significant changes to the threat environment

The entity needs to keep proper documentation showing the time of testing, scope of testing, findings, and resolution of these findings.

HITRUST Penetration Testing Process

A proper penetration testing process will ensure that the produced evidence is usable for purposes of improving the security and preparing for an assessment.

Step 1: Define Objectives and Scope

Define assessment criteria including the systems, applications, network, and technology that needs to be assessed.

Step 2: Plan the Engagement

Determine testing schedule, rules of engagement, authorized targets, limitations of testing, and other contacts and escalations.

Step 3: Perform Reconnaissance

Testing personnel gather information from the environment to assess for attack surfaces and entry points.

Step 4: Conduct Vulnerability Assessment and Penetration Testing

Vulnerabilities are discovered and manually exploited on the system within the approved scope.

Step 5: Analyse and Document Findings

Results from the tests are properly documented with adequate technical detail as well as the impacts.

Step 6: Remediate Findings

The organization considers the findings, determines remediation priorities, and acts on them.

Step 7: Retest and Maintain Evidence

If necessary, the vulnerabilities found will be re-tested post-remediation. The final report and all relevant documentation should be maintained by the organization.

What Evidence Should Be Maintained?

The penetration test evidence must be able to show that the penetration testing has been carried out with proper planning, execution, documentation, and follow-up.

Depending on the engagement, relevant evidence may include:

• Approved penetration testing scope
• Rules of engagement
• Testing methodology
• Testing dates
• Assets and systems tested
• Penetration testing report
• Vulnerability and finding details
• Risk ratings
• Remediation records
• Retest results
• Evidence of management review

It will be dependent on the assessment requirement and the approach adopted by the organisation for conducting the test.

Common Gaps in HITRUST Penetration Testing

Problems are likely to arise if the process of penetration testing is seen as a mere vulnerability test by organisations.

Common gaps include:

• An incomplete testing scope
• Testing only external infrastructure while excluding relevant applications
• Relying entirely on automated scanning
• Failing to document testing methodology
• Not retaining sufficient evidence
• Not addressing significant findings
• Failing to perform appropriate retesting
• Not updating the testing approach after major environmental changes
• Using a testing scope that does not correspond with the defined assessment boundary

Addressing these gaps before the assessment can make the evidence review process more straightforward.

Preparing for HITRUST Penetration Testing

For organizations preparing for a HITRUST assessment, one must start with knowing one’s assessment level, assessment boundary, and the systems and technologies that need to be tested.

Penetration testing plan must then be mapped to the environment and security requirements.

It is also critical to allocate enough time for remediation and retesting prior to the start of the assessment process. Otherwise, there will be very little time available once the process starts to do any follow-up or gathering of evidence.

Penetration Testing Support for HITRUST Assessments

Organisations preparing for a HITRUST assessment may need penetration testing that covers networks, applications, APIs, segmentation, cloud environments, or other technologies within their defined scope.

ValueMentor provides penetration testing services covering external and internal testing, segmentation testing, application security, and other testing approaches. The engagement can be aligned with the organisation’s environment and defined testing objectives.

Conclusion

Penetration Testing of the HITRUST standard must be seen in the context of a wider process of security validation and assessment.

The right way of doing it will depend on the organisation’s level of assessment of the HITRUST standard, defined scope, technological environment, security risks and applicable requirements.

Organisations must know what must be tested, apply the right amount of both automated and manual tests, document the results, solve the problems found during testing and collect enough information for the assessment.

What is most important, an understanding of the differences between e1, i1, and r2 will help to prevent a one-size-fits-all approach in penetration testing.

FAQs