Ultimate Guide to HITRUST Certification

What is HITRUST certification, and who asks for it?

HITRUST certification is a status HITRUST grants after an authorized external assessor tests an organization's controls against the HITRUST CSF for a defined set of systems and HITRUST reviews that work. Health systems and payers ask vendors for it when the vendor will store, process or transmit their protected health information.

The certification describes a scope, not a whole company. A report covers the named systems, platforms, facilities and services that were assessed, so a vendor with two products can hold a certification for one and not the other.

Read the scope section of any HITRUST report before relying on it, whether it is your own or a supplier's. The scope tells a customer exactly which part of your business the assurance applies to.

How do e1, i1 and r2 differ?

The three validated assessments differ in how many controls they test, how the control set is chosen and how long the certification lasts. HITRUST describes them on its assessments pages as follows.

• e1, foundational: A fixed set of 43 foundational cybersecurity controls, valid for one year. HITRUST positions it for startups, low-risk programs and organizations building a security base.
• i1, leading practices: A fixed set of 182 control requirements, valid for one year, for organizations that want a higher level of assurance without a fully tailored assessment.
• r2, risk-based: A control set tailored to factors such as system complexity, regulatory obligations and data sensitivity. It is valid for two years, with an interim assessment required after the first year.

The difference matters to engineering because a fixed control set can be planned from day one, while an r2 control set is only known once the scope and risk factors are entered. A team that starts with e1 and later needs i1 or r2 keeps the controls it already runs and adds to them, so the first assessment works as a base layer rather than a throwaway.

Which assessment should a health software vendor start with?

Start with the assessment your customers' contracts or security reviews actually name, and no higher. The decision list below covers the situations vendors usually face.

• A contract names r2: Plan for r2, and put the interim assessment in year one and recertification in year two into the budget from the start.
• A customer asks for "HITRUST" without naming a type: Ask their security team in writing which assessment they accept. The answer decides the whole plan, so get it before scoping.
• An early-stage product with a few pilot customers: e1 gives a validated baseline and a first certification while the product, team and scope are still small.
• A product holding PHI for many provider or payer customers: i1 gives a larger fixed control set that answers more of a typical hospital security questionnaire.
• A product embedded in clinical workflows or holding large volumes of PHI: Ask early whether r2 is required. If it is, design logging, access and network segmentation for its tailored control set before launch.
• No customer has asked yet: Build the controls and evidence first. A certification nobody requested costs assessor fees and renewals without helping close a deal.

Drawing the scope boundary

Scope decides how much has to be tested, because every system inside the boundary has to show the applicable controls. A tight scope follows the PHI and stops where the PHI stops.

For a typical cloud product, that means the production application and its databases, the cloud accounts that host them, the identity provider, the pipeline that deploys to production, and any support or analytics tool that can see patient data.

• Data flows: Map every path PHI takes into and out of the product, including EHR interfaces, file drops, analytics exports and support tickets.
• Shared services: List what the product depends on, such as single sign-on, central logging, backups and secrets management, and decide whether each sits inside the boundary.
• Third parties: Record which cloud and SaaS providers host in-scope components and whether they offer HITRUST results you can inherit.
• Out of scope by design: Keep PHI out of the systems you want excluded. A staging database loaded with production data pulls staging into scope.
• People and devices: Decide which staff laptops and admin workstations can reach production, because those endpoints come into scope with the access.

HITRUST's Shared Responsibility and Inheritance Program lets an organization reuse controls already validated for a supplier, such as a cloud platform. Inheritance reduces testing for those controls, but the configuration you own on top of the platform is still yours to show.

How does the path from readiness to report run?

The path runs in six stages, from confirming the assessment type to planning the renewal. Skipping the readiness stage is how teams discover gaps in front of the assessor.

• 1. Confirm the assessment: Get the required type in writing from the customers that asked for it.
• 2. Scope: Document the systems, data flows, locations and third parties inside the boundary, and the reasons for each exclusion.
• 3. Readiness assessment: Enter the scope in HITRUST's MyCSF platform, generate the control requirements and rate the current state against each one.
• 4. Remediate: Close gaps in policy, procedure and technology. Give new controls time to operate so there is a history the assessor can sample.
• 5. Validated assessment: An authorized external assessor tests each requirement against evidence such as configurations, logs, tickets and interviews, then submits the work to HITRUST.
• 6. Report and renewal: HITRUST reviews the submission and issues the report. The renewal date, and for r2 the interim date, go into the roadmap on the day the report arrives.

Choose the external assessor early. An assessor can confirm scope and inheritance decisions before testing starts, which costs far less than a disagreement found halfway through the validated assessment.

Which controls land on the engineering team?

Engineering owns the controls that live in code, infrastructure and the delivery pipeline. Each one needs a working control and a record that proves it operated over time.

• Identity and access: Single sign-on for staff, multi-factor authentication for administrative and production access, role-based permissions in the product, and access reviews exported from the system rather than assembled by hand.
• Audit logging: Records of who viewed, changed or exported patient data, kept in a store that application engineers cannot edit, with alerts on unusual access.
• Encryption: Encryption for data at rest and in transit, plus key management records showing who can use and rotate each key.
• Vulnerability management: Dependency and container scanning in the pipeline, scheduled infrastructure scans, and a tracked fix window for each severity level.
• Change management: Every production change goes through a reviewed pull request and an automated deploy, so a ticket, an approval and a deploy record exist for any change an assessor samples.
• Backup and recovery: Backups with dated restore tests, so the contingency control has results and not only a written procedure.
• Secure development: Coding standards, peer review and security testing written into the release process, with the outputs kept.

Evidence matters as much as the control. Assessors sample, so a team that can export last quarter's access reviews or deploy approvals in minutes spends less assessment time than a team rebuilding the record from chat history and screenshots.

Build those exports into the product's admin tools: a filtered audit log download, an access review report and a deploy history with approvers. The same exports answer customer security questionnaires between assessments.

Where HITRUST efforts stall

HITRUST projects tend to stall on planning decisions rather than on any single hard control. These failure points each have a direct fix.

• Over-reaching first: Starting with r2 when a customer would accept e1 or i1 stretches the first certification well past the deal it was meant to close.
• Vague scope: An unclear boundary lets systems drift in during testing, and each one brings its own control requirements and evidence.
• Policies the product does not enforce: A written logging or session policy that the code does not implement fails when the assessor tests the live system.
• Last-minute evidence: Screenshots taken the week before testing cannot show that a control operated across the period under review.
• No owner per control: Engineering-run controls fall between the security lead and the development team unless one named person owns each one.
• Missed dates: An e1 or i1 lapses after a year, and an r2 needs its interim assessment after the first year. A lapsed report reopens every customer security review.

How does HITRUST relate to HIPAA and SOC 2?

HITRUST does not replace HIPAA. The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the risks to the ePHI they hold (45 CFR 164.308(a)(1)(ii)(A)), and a HITRUST report does not discharge that duty on its own.

A HITRUST report is still useful evidence inside a HIPAA program, because the HITRUST CSF maps its requirements to HIPAA safeguards. The risk analysis, business associate agreements, workforce training and breach procedures remain separate obligations with their own records.

SOC 2 is a different kind of report: an attestation by a CPA firm against the AICPA Trust Services Criteria. Some customers accept either report and some ask for both. Because the technical controls overlap, one set of access, logging and change records can feed both assessments.

How Agnotic can help

A HITRUST assessment tests what the software actually does, and that is the part Agnotic Technologies builds. Agnotic engineers add the identity controls, audit logging, encryption, vulnerability scanning and change records that assessors sample, and wire evidence exports into the product so the security lead is not rebuilding history before each assessment.

Agnotic works beside your security lead and your chosen HITRUST authorized external assessor. HITRUST and its assessors certify the organization; Agnotic's part is the engineering that makes each control real and provable inside the scope you define.

Sources

• HITRUST: Assessments and certifications (e1, i1 and r2 control sets and validity)
• HITRUST: r2 validated assessment (interim assessment and control inheritance)
• HHS: Guidance on risk analysis under the HIPAA Security Rule