You have decided which HITRUST assessment you need. Now someone has to turn that decision into a validated report, and the first question is usually "what do we do before the assessor arrives?"
The answer is most of the work. A HITRUST validated assessment rewards preparation more than almost any other audit, because the requirement statements are known in advance and the assessor's job is to test them, not to discover them. Teams that struggle usually started fieldwork with an unclear scope or evidence that only existed in someone's head.
This article walks through preparation in order, from fixing scope to what happens after your assessor submits. If you have not yet chosen between the e1, i1 and r2, start with our comparison of the three.
Step 1: fix the scope before anything else
HITRUST assessments are performed against a defined scope: the organization, the systems, the facilities and the services you are putting forward. Every requirement statement is tested across that scope, so a vague scope makes every test vague.
Write the scope down in terms your assessor can test:
Services and products that are in scope, by name.
Systems and platforms that support them: cloud accounts, production databases, identity provider, endpoints used by people with production access.
Facilities, which for a cloud-only company may be an office with no production systems in it, plus the data centers of your cloud provider.
Third parties whose services you rely on, and which of their responsibilities you intend to rely on in the assessment.
For an r2, scope also includes the scoping factors you declare in MyCSF. Those answers decide which requirement statements apply. Treat them as design decisions, made with your buyer's requirement in front of you, not as a form to fill in quickly.
Step 2: choose an assessor and agree the plan
Validated assessments are performed by external assessor organizations that HITRUST has authorized. Your assessor tests the requirement statements and records the results in MyCSF. HITRUST then reviews that work before issuing anything.
When you talk to prospective assessors, ask practical questions:
Who will do the fieldwork, and have they tested this assessment type before?
How do they want evidence delivered, and in what format?
What sampling approach will they use for recurring controls, such as access reviews or vulnerability scans?
What timeline do they expect from fieldwork start to submission, and how do HITRUST's windows for testing and submission affect it?
HITRUST has independence rules for assessors. A firm that designed or built your controls is generally not able to assess them. If you hire consultants to help you prepare, confirm with HITRUST's current rules and your intended assessor that the arrangement does not create a conflict.
Step 3: run a readiness assessment
A readiness assessment uses the same requirement statements as the validated one, but you score yourself. It produces no certification. Its value is that it shows you where you are weak while there is still time to fix it.
Do it honestly. A readiness assessment that rounds every score up gives you a comfortable plan and an uncomfortable fieldwork. For each requirement statement, ask the question the assessor will ask: what would I show to prove this, across the whole scope?
The output is a gap list. Sort it into three groups:
Not implemented. The control does not exist. These need building and enough operating history to be tested.
Implemented but undocumented. The control runs, but the policy or procedure is missing. This matters most in an r2, where documentation is scored separately.
Implemented but unprovable. The control runs and is documented, but the evidence is scattered or not retained. These are often the fastest to fix.
Step 4: build evidence the assessor can test
HITRUST assessors test requirement statements by examining documents, inspecting configurations, interviewing people and reviewing records. The evidence that survives that testing has the same properties it has in any audit. Our article on types of audit evidence covers why system-generated records outrank screenshots and attestations.
A practical evidence checklist for each requirement statement:
- Not done:
The policy statement that covers it, with its approval and version date.
- Not done:
The procedure that describes how it is carried out, by whom and how often.
- Not done:
Records showing it was performed across the scope, not on one system.
- Not done:
For recurring controls, records for each occurrence in the period the assessor will sample.
- Not done:
For controls your cloud provider or another service provider performs, the basis on which you are relying on them.
Map evidence to requirement statements, not to systems. Assessors work through requirements one at a time, and an evidence library organized by system forces them, and you, to translate on every request.
Policies and procedures deserve their own pass
Policies are where many first HITRUST efforts slow down. HITRUST requirement statements are specific, and a policy written for another framework often covers the topic without covering the requirement. Read each policy against the requirement statements it is meant to support. Where the requirement names an element, such as a frequency, a role or a type of system, the policy or procedure should address that element.
Step 5: prepare people, not only documents
Assessors interview control owners. A control that is well documented and well run can still test poorly if its owner cannot explain it.
Before fieldwork, have each control owner walk through their controls with someone playing the assessor. They should be able to say what the control is, how often it runs, what record it produces and what happens when it fails. They should also know where that record is kept, so a request does not become a search.
Step 6: fieldwork, submission and quality assurance
During fieldwork, your assessor tests the requirement statements and records results in MyCSF. Expect requests, follow-up questions and occasional re-testing where evidence was incomplete. Keep a single request tracker so nothing is answered twice or not at all.
When testing is complete, the assessor submits the assessment to HITRUST. HITRUST's quality assurance team reviews the assessor's work and may come back with questions, which usually route through the assessor to you. Only after QA does HITRUST issue the report and, if the results meet its criteria, the certification.
Two points that surprise first-time teams:
QA is part of the timeline. The report does not arrive at the end of fieldwork. Build HITRUST's review time into any date you give a customer.
Questions at QA need fast answers. Keep your evidence and your control owners available after fieldwork ends.
What to plan for after the report
A certification is the start of a cycle, not the end of a project. The e1 and i1 run for one year. The r2 runs for two years and requires an interim assessment in between. Requirement statements that fell short may come with corrective action plans that you will be expected to work through.
If this is your first assessment of any kind, our guide to planning your first audit timeline helps you sequence readiness, remediation and fieldwork around the dates your buyers care about. The HITRUST framework page summarizes how the CSF relates to the other frameworks you may already run.
How TrustLynce helps
TrustLynce collects evidence on a schedule from your cloud, identity, HR and code systems, timestamped and attributed, so the records exist before the assessor asks (evidence collection). Policy management keeps policies versioned with approval and acceptance history, and the auditor portal keeps requests and findings in one place during fieldwork.