HITRUST offers three validated assessments, e1, i1 and r2, all built on the HITRUST framework. For a DevOps lead the common thread is evidence: configuration, access, change and vulnerability records that show a control ran over time. Automate collection before the assessment window opens.
What is the HITRUST framework?
HITRUST describes its framework as a single control set that brings together requirements from standards and regulations such as ISO/IEC, NIST, HIPAA, PCI and GDPR. The e1, i1 and r2 assessments all draw on it. HITRUST states that they differ in depth and rigor, so pick the level your buyers ask for. Confirm the current requirement counts and scoring on HITRUST's own pages, because they change between versions.
Where does DevOps get asked?
Whatever the level, assessors tend to test the same practical areas:
- Identity and access: who has production access, how it is approved and removed.
- Change management: pull request review, approvals and deployment records.
- Configuration: hardening baselines for hosts, containers and cloud accounts.
- Vulnerability and patch management: scans, severity targets, and proof of closure.
- Logging and monitoring: what is logged, who reviews alerts.
- Backup and recovery: restore tests with dates and results.
- Encryption and key handling.
- Third party management for tools that touch in-scope data.
What does evidence look like?
A constructed example: for change management, an assessor may pick five production deployments and ask to see for each the pull request, the reviewer who was not the author, the passing checks and the deployment record. If these live in Git, CI and a deploy log with consistent identifiers, you answer in minutes. If a manual spreadsheet ties them together, you lose days.
Think about samples over time too. An assessment looks at a period, so a control that was fixed last week shows a gap earlier.
What should we automate first?
- Access reviews: scheduled exports of who holds which roles, with sign-off.
- Branch protection and required reviews: settings captured as configuration.
- Vulnerability scans for code, dependencies and images, with ticket links for fixes.
- Asset inventory: accounts, clusters, repositories and data stores in scope.
- Restore tests: scripted and logged.
A platform such as Safeguard can generate dependency inventories and vulnerability records and support compliance evidence collection, but you still define scope and own the controls.
How do you keep scope small?
Every system in scope adds evidence work. Separate the environment that handles regulated data, limit the people with access, and keep other systems out of the path. Write a scope statement and diagram early and update it when architecture changes.
What goes wrong most often?
Three patterns repeat. First, evidence exists but cannot be tied to a date or an owner, so it cannot be used. Second, scope drifts: a new service starts handling regulated data without being added to the boundary. Third, exceptions are handled in chat and never recorded. A simple fix for each is to timestamp every export, add a scope check to the architecture review template, and keep an exceptions register with an approver and an expiry date.
What to do
- Ask the buyer or program owner which HITRUST assessment is required.
- Draw the in-scope boundary and list systems, accounts and data stores.
- Map the practical areas above to owners.
- Automate evidence capture and store it in a dated, read-only location.
- Run an internal sample of five records per control area and fix gaps.
- Keep a change log of scope and architecture decisions.
Quick check
Is HITRUST a law?
No. It is a private assurance framework and assessment program. Laws such as HIPAA are separate, although the HITRUST framework maps to them.
Which assessment should we pick first?
Pick the one your buyer or partner requires, then check HITRUST's current guidance on levels. Starting at a lower level can be reasonable when it satisfies the request.
Sources
Last reviewed: 18 October 2026.
