How ValueMentor guided a multi-tenant cloud and data center provider through its HITRUST i1 assessment by building on existing SOC 2 and PCI DSS controls instead of starting over
182 controls. 19 domains. Two existing compliance programs to build on. One certification healthcare buyers recognize.
01 OVERVIEW
Healthcare buyers wanted proof, not promises
The client runs private and hybrid cloud, colocation and disaster recovery services from data centers across the United States. Its customers include healthcare, financial services and SaaS companies that choose it over hyperscale public cloud for one reason: audit-ready infrastructure with hands-on support.
For most buyers, the client’s SOC 2 and PCI DSS reports settled the cloud security compliance question. Healthcare buyers were different. Hospital systems, health plans and digital health companies were adding HITRUST to their vendor security reviews, and HITRUST healthcare compliance was fast becoming a line item in RFPs rather than a nice-to-have.
ValueMentor was engaged to take the client through a HITRUST i1 assessment: choosing the right tier, defining scope across a shared environment, reusing existing controls, closing gaps and supporting the assessment through HITRUST’s quality assurance review. The client achieved HITRUST i1 certification and now answers healthcare security reviews with an independently validated report.
Engagement at a glance
| Client | Private and hybrid cloud, colocation and disaster recovery provider |
| Customers served | Healthcare, financial services and SaaS organizations |
| Assessment | HITRUST i1 validated assessment (1-year certification) |
| Starting point | SOC 2 and PCI DSS programs already in place |
| ValueMentor role | Tier selection, scoping, MyCSF setup, gap assessment, remediation support, assessor coordination and QA support |
| Outcome | HITRUST i1 certification |
02 THE CHALLENGE
Why this wasn’t a simple checklist exercise
| Challenge | What it meant in practice |
|---|---|
| Buyer pressure | Healthcare prospects were sending HITRUST requirements in security questionnaires and RFPs. Without it, deals slowed down in long control-by-control reviews. |
| A shared environment | In multi-tenant infrastructure, some controls belong to the provider and some to the customer. Drawing that line wrongly either bloats the assessment or leaves buyers’ questions unanswered. |
| Overlapping frameworks | SOC 2 and PCI DSS already covered many of the same controls. Running HITRUST as a separate project would have meant asking the same teams for the same evidence twice. |
| A higher evidence bar | HITRUST expects proof that each requirement is implemented across the full scope, which is often stricter than how the same control is tested for SOC 2. |
| Teams running live infrastructure | Engineering and operations teams support production environments around the clock, leaving limited time for compliance work. |
03 THE DECISION
Why HITRUST i1, and not e1 or r2
The first question in any HITRUST assessment is which one to pursue. We looked at who the client sells to, what those buyers ask for, and how quickly the sales team needed a credential.
| e1 | i1 | r2 | |
|---|---|---|---|
| What it proves | Foundational cybersecurity hygiene (44 controls) | Leading security practices are implemented (182 controls) | A risk-based program that is implemented, measured and managed |
| Certification period | 1 year | 1 year | 2 years, with an interim review |
| Fit for this client | Too light for a provider hosting PHI for many customers | Matched buyer expectations on a realistic timeline | Deepest assurance, but heavier than needed as a first step |
The i1 had one more advantage: it is built on the same HITRUST CSF as the r2. If larger healthcare customers later ask for r2, the scope, control mapping and evidence carry forward rather than starting again.
04 THE APPROACH
Five steps from scope to certification
1. Draw the boundary before touching the controls
We defined the in-scope environment across data center facilities, the managed cloud platform and the supporting processes behind them: identity and access, change management, monitoring, backup and disaster recovery. We then documented which controls the provider owns and which remain with its customers. That shared responsibility view kept the HITRUST i1 assessment focused, and it also gives customers a clear picture of what they can rely on.
2. Map what already exists
We set up the client’s MyCSF environment and mapped controls already tested for SOC 2 and PCI DSS to HITRUST i1 requirements. Where existing evidence met HITRUST’s standard, it was reused. Where it fell short, we showed teams exactly what was missing, which is usually a matter of coverage or documentation rather than a missing control.
3. Find the real gaps and rank them
A control-by-control gap assessment separated real gaps from paperwork gaps and ranked each by risk and effort. In cloud environments at this stage, common gaps include formal tenant isolation reviews, consistent access recertification across platforms, log retention that matches policy, and documented oversight of subservice providers.
4. Remediate alongside the team
Our HITRUST policy, procedure and evidence templates gave the client’s teams a starting point instead of a blank page. Our consultants worked with engineering and operations to put fixes in place and confirm they were working before the assessment began, fitting the work around production commitments.
5. Prepare for QA before submission
We coordinated with the authorized External Assessor throughout fieldwork, reviewed evidence and scoring before submission, and managed responses to HITRUST’s quality assurance questions. Catching issues before QA is the single biggest factor in avoiding delays at the end of a HITRUST assessment.
05 THE RESULTS
What changed after certification
| Area | Before | After |
|---|---|---|
| Healthcare security reviews | Long questionnaires and control-by-control explanations | An independently validated HITRUST i1 report shared up front |
| Market positioning | “Audit-ready” as a claim | HITRUST-certified, and verifiable by any buyer |
| Compliance program | SOC 2 and PCI DSS managed separately | One mapped control set in MyCSF supporting multiple frameworks |
| Growth path | An r2 would mean starting from scratch | The i1 foundation carries forward into a future r2 |
HITRUST i1 compliance also opens a door that matters to healthcare tenants. Through HITRUST’s Shared Responsibility and Inheritance Program, customers of a certified provider can inherit applicable controls into their own HITRUST assessments, reducing their effort and making the provider an easier choice.
06 KEY TAKEAWAYS
What other cloud and infrastructure providers can learn
- Match the tier to the buyer, not the biggest option. For many providers, an i1 answers healthcare buyers’ questions faster than an r2, with no wasted effort if you move up later.
- Scope the shared environment first. A clear line between provider and customer controls prevents both over-scoping and a report that doesn’t answer buyers’ questions.
- Don’t start from zero. Existing SOC 2 and PCI DSS controls can carry much of the load when mapped properly.
- Plan for QA from day one. Reviewing evidence against HITRUST’s standard before submission avoids late-stage rework.
- Treat certification as a sales asset. In healthcare, a HITRUST report does more for cybersecurity compliance conversations than any completed questionnaire.
07 NEXT STEPS
Hosting healthcare workloads? Start with the right assessment.
Our HITRUST compliance services help cloud, colocation and managed service providers earn the certification healthcare buyers ask for, from choosing a tier to annual renewal.
- HITRUST for cloud providers: e1, i1 and r2 readiness and assessment support
- Tier selection and scoping for multi-tenant and shared environments
- Combined HITRUST and SOC 2 programs from a single evidence base
- Support for customer control inheritance, r2 upgrade planning and annual renewal
Talk to our HITRUST team or read more about HITRUST i1.
