HITRUST for Startups

As a B2B startup, proving to customers you can be trusted with their data is an essential step to success. As a young and growing company, how do you prove you can be trusted? In this guide tailored to startups, we cover everything you need to know about HITRUST and how a HITRUST certification can be used to earn trust, accelerate sales, and standardize the language of trust and security at your company.

If you’re a startup, you have too much to do and not enough time or resources to do it. Audits are just one more thing that you have to get done. But, you aren’t big enough, and don’t have a large, dedicated audit team to do audits for everything - HIPAA, PCI, GDPR, CCPA, SOC 2, ISO, on and on. Which compliance framework, or frameworks, do you choose and why?

With its initial start in healthcare, HITRUST has emerged as a flexible and powerful option as a compliance, or trust, DNA. In this guide, we cover the background on HITRUST, the types of HITRUST assessments, how HITRUST is scored, the cost of HITRUST, how HITRUST maps to industry and reporting standards, and how best to get an ROI from HITRUST.

Overview of HITRUST

The simplest way to think about HITRUST is that it is an attempt to simplify and streamline security assessments. The goal of HITRUST, a non-profit organization initially backed by large healthcare insurance companies, is to create efficiencies for both companies being assessed and for organizations assessing other companies.

The problem HITRUST is solving is the largely bespoke security review process to which organizations subject other organizations. HITRUST has also expanded from security assessments to allow companies to use HITRUST to complete assessments for SOC 2, PCI, and GDPR. While HITRUST initially launched with a focus on healthcare and HIPAA, it has expanded into other industries and data protection regimes; healthcare remains the industry with the strongest adoption of HITRUST.

> ⚡ Assess Once, Report Many - HITRUST Tagline

HITRUST accomplishes this mission and tagline with its CSF, or Common Security Framework. The CSF rationalizes controls across multiple regulations and frameworks such as NIST, PCI, and HIPAA. The CSF is a meta framework for security and privacy. It can be used both for compliance, as a point in time assessment, as well as a continuous risk management tool.

Having used HITRUST extensively for over 7 years, it works mostly as intended. While there is a steep learning curve for HITRUST first timers, it is a certification that can streamline security assessments with partners and customers. The caveat is that not all organizations accept HITRUST in leu of their own security assessments.

While the foundation of HITRUST is the CSF, HITRUST does offer multiple programs for managing risk and proving compliance.

• HITRUST Assurance Program. This is the core of HITRUST and the focus of this training course. The HITRUST Assurance Program leverages the CSF to streamline security assessments and 3rd party assessments.
• De-identification. The De-identification Framework is both a framework and a methodology that organizations can adopt and use for their de-identification programs. With big data initiatives and analytics becoming more and more common, de-identification is a large topic when it comes protected data and this is an attempt by HITRUST to provide a mechanism for organizations to de-identify data.
• Threat Catalogue. The Threat Catalogue is a database of threats mapped to CSF controls. It is updated along with the CSF and assists organizations in using the CSF as a risk management tool.
• Shared Responsibility. In order to meet the needs of companies leveraging the cloud, HITRUST created this program. The tagline is Assess Once, Inherit Many. Basically, companies can inherit certain controls from their cloud providers, such as physical security controls. Inheritance is done in the CSF.
• HITRUST Academy. The HITRUST Academy is the educational component of HITRUST, with courses focused on training security professionals to manage risk and be administrators for the CSF.

The HITRUST CSF

The HITRUST CSF (Common Security Framework) is the anchor for all HITRUST programs. It is a certifiable framework that can be used to both demonstrate compliance as well as manage risk; the difference between these functions is that risk management is an ongoing operational process and demonstrating compliance is typically a point in time validation of a data protection program.

The CSF rationalizes and maps various data protection regimes, such as PCI and HIPAA, and data protection frameworks such as NIST into one framework. By using the CSF, companies can easily show how their information security programs meets the requirements for various regimes and regulations. Assess once, report many.

At the most basic level, the CSF is a database of 135 controls with mappings to various data protection schemes. This does not trivialize the CSF. The value in it is all of the mapping that has been done and that is kept up to date with data protection regulations as well with modern technology.

Additionally, HITRUST provides prescriptive guidance to assist companies in meeting the 135 mapped controls. This prescriptive guidance goes beyond other frameworks and the regulations themselves.

The CSF has 19 domains listed out below. Think of domains as categories or collections of controls or Requirements Statements.

1. Information Protection Program
2. Endpoint Protection
3. Portable Media Security
4. Mobile Device Security
5. Wireless Security
6. Configuration Management
7. Vulnerability Management
8. Network Protection
9. Transmission Protection
10. Password Management
11. Access Control
12. Audit Logging and Monitoring
13. Education, Training, and Awareness
14. Third-Party Assurance
15. Incident Management
16. Business Continuity and Disaster Recovery
17. Risk Management
18. Physical and Environmental Security
19. Data Protection and Privacy

You can download the current version of the CSF here.

Initially, the CSF was offered as a spreadsheet. It is now used via a web app called MyCSF. You buy a license to MyCSF or to a certain tier of assessments in the MyCSF. The CSF is then populated by users and then optionally validated by assessors and again by HITRUST the organization.

Each version of the CSF is different in terms of the specific control requirements that must be met to achieve HITRUST Certification. HITRUST updates these certification requirements based on changes to the regulatory and technical environments. Because of this, HITRUST Certification is specific to the version of the CSF that was used for the assessment. HITRUST CSF is current at CSF version 9.x.

Practically speaking, for each control, which contains a Requirement Statement and a control description, a users for the company will assess the maturity of the company against the control and add supporting statements and evidence. Having been through this multiple times, it can be a time consuming process to populate the entire CSF.

For each control in the HITRUST CSF, there are 3 different Implementation Levels. As you go up in Implementation level, the requirements for each control increase. The implementation level for each control is determined by the specific calculated risk for that organization, application, or environment. The higher the determined risk, the higher the implementation level. A large health system will have different requirements that a small digital health startup. Risk is determined by the following factors (and done automatically by the CSF):

1. Organizational - scope and scale of the company;
2. Regulator - regulations to which the company must comply (PCI, HITECH, etc); and
3. System - type of data processed and accessibility (mobile, public Internet, etc).

The HITRUST CSF serves as the basis for a HITRUST assessment. It can also be used as a risk management tool on an ongoing basis. Used for risk management, it is updated regularly and identified or emerging gaps in security are documented, and ideally mitigates, as they arise.

The HITRUST CSF is a meta-framework that maps to multiple regulations and data protection regimes, providing prescriptive guidance for each control. It is the basis for HITRUST Assurance, assessments, and shared responsibility.

Types of HITRUST Assessments

After you've determined that HITRUST is a framework to which you want to comply, the next step is to decide on the type of HITRUST assessment for your company. HITRUST offers 3 different types of assessments, which are analogous to levels of certification offered by other frameworks such as the PCI self assessment questionnaires (SAQ) and reports on compliance (ROC).

Each type of HITRUST assessment builds on the previous one, with additional assurance with each higher level.

The three types of HITRUST assessments are below.

1 - Self Assessment

A HITRUST self assessment is just what it sounds like, an assessment completed by the company. The self assessment is simply the company populating the CSF and attesting, without external validation, to meeting the HITRUST controls. Despite not being validated, this type of assessment does offer companies a standard security report they can share with customers and partners.

It's important to remember that most bespoke security assessments performed by companies against their vendors are simply self assessments, albeit self assessments using custom spreadsheets and questionnaires. A security assessment typically involves a questionnaire, often in the format of a spreadsheet, with questions that a vendor must answer. Oftentimes, the questions on these assessments cover the exact same content as the CSF but in different order and with different words. The onus is on the assessing company to investigate and attempt to validate what their vendors claim in security assessment spreadsheets. This is not an easy task.

A HITRUST Self Assessment Report offers a standardized security assessment. If assessing companies are familiar with the HITRUST CSF, this means the entire security review process can theoretically be accelerated.

This is the cheapest option as the only cost is that of the CSF license. And of course the time it takes to populate the CSF.

2 - Validated Assessment

Moving up a level in terms of assurance, a HITRUST validated assessment requires a HITRUST-approved external assessor. An assessor would clarify and validate the CSF entries from the company. This type of assessment historically has required an on site visit by an assessor though this may change with the requirements to work from home.

In addition to validating the entries in the CSF, the assessor would then rate the maturity of each control using the HITRUST maturity model (more on that in the next lesson). A report is then is generated and, if the report meets or exceeds a HITRUST defined threshold, a HITRUST Validated report is issued.

While this type of assessment offers a level of validation and assurance beyond a self assessment, in my view it is hard to justify the effort and money for a validated assessment without doing a full HITRUST Certification (see below).

The cost of this assessment includes the cost of the CSF license and the cost of the external assessor. There are also additional resources needed to work with and respond to assessor questions and comments.

3 - HITRUST Certification.

Using the scoring from the validated assessment from above, a HITRUST Certification can be granted if certain required controls and scoring thresholds are met (more on scoring in the next lesson) and after HITRUST has validated the work of the assessor. HITRUST, the organization, will do additional validation on the work of the assessor.

A HITRUST Certification offers a lot of value over a self assessment and validated assessment. And the cost and level of effort is low relative to going from a self assessment to a validated assessment. In my experience, the external assessor does most of the work of interfacing with HITRUST.

The cost of this assessment includes the cost of the CSF license, the cost of the external assessor, and the cost of the HITRUST Certification itself.

The type of HITRUST assessment determines the level of assurance and the level of acceptance and value in the market. More cost → more assurance → more value.

The HITRUST RightStart Program for Startups

HITRUST does offer a special package and pricing for startups. You need to have a product or service in the market and meet the following requirements:

1. Incorporated or founded within the last three years;
2. Under 50 full-time employees; and
3. Revenue under $10M.

If you meet these requirements, the HITRUST RightStart program is a great way to get your company up to speed on HITRUST and achieve a level of trust through a HITRUST self assessment or validated assessment.

You can learn more about HITRUST’s RightStart program here..

HITRUST Scoring

HITRUST scoring can be complicated. The details of scoring are less important than understanding the high level approach and maturity model. The reason most people fret about the details of scoring is to assess the likelihood they will score high enough to obtain a HITRUST Certification.

The short version of the HITRUST scoring process is below.

1. Each CSF control is rated based on maturity.
2. The maturity ratings are weighted (HITRUST defines the weighting).
3. The aggregate score for each domain (domains are collections of controls), based on the weighted ratings, is calculated.
4. If all the domains are above the defined required threshold, the company qualifies for HITRUST Certification.

We'll get into the details of scoring below, but first it's important to understand the maturity model that HITRUST uses in evaluating Requirement Statements and controls.

Maturity Model

The maturity model used by HITRUST is adapted from NIST and Carnegie Melon models. The purpose in this approach is to be able to rate each HITRUST control in the CSF not simply as met or unmet, but to be able to rate each HITRUST control against different degrees of maturity. With this granular approach to rating each control, HITRUST is able to offer detailed and explicit guidance to companies and HITRUST assessors, increasing the level of consistency of HITRUST assurance.

The levels of maturity are outlined below.

1. Policy. Has you documented what you need to do? Considers the existence of current, documented information security policies or standards in the organization’s information security program and whether they fully address the control’s implementation specifications.
2. Procedure. Do you know how you will do what you need to do? Considers the existence of documented procedures or processes developed from the policies or standards and whether they reasonably apply to the organizational units and systems within scope of the assessment.
3. Implementation. Have you done what you need to do? Considers the actual implementation of the policies and whether the control’s implementation specifications are applied to all the organizational units and systems within scope of the assessment.
4. Measured. Do you test to ensure what you are doing is working properly? Considers the testing or measurement (metrics) of the specification’s implementation and whether they continue to remain effective.
5. Managed. Do you integrate the first 4 levels so they work together? Reviews the organization’s management of its control implementations based on these metrics.

The above maturity levels are assessed for every HITRUST control in the CSF. This can seem daunting at first, and it is when you first get started with HITRUST, but there is a lot of value in using this structured approach to assess your security program.

Maturity Ratings

Now that we have the overall structure of the maturity model, the next step is to rate each maturity model level. Each of the following ratings is given to each of the maturity levels listed above.

1. Non-compliant (NC) - score of 0%.
2. Somewhat compliant (SC) - score of 25%.
3. Partially compliance (PC) - score of 50%.
4. Mostly compliant (MC) - score of 75%.
5. Fully compliant (FC) - score of 100%.

Each of the above ratings has specific criteria for each maturity level. This provides specific criteria for rating each maturity level. The amount, or rough proportion, of criteria met determines the rating.

Scoring

Scoring is the method of tying all of the above together. Each control is given a maturity rating for each maturity level. These maturity ratings are then multiplied by a weighting factor to get an overall weighted score for each control. The average of all of the weighted scores within each domain is then calculated. In order to be HITRUST Certified, every domain needs an average weighted score of 62.5.

Even with this average across all domains, any specific control within a domain with a weighted score of less than 62.5% needs a corrective action plan (CAP). You can still be HITRUST Certified with CAPs.

HITRUST does an additional conversion on the weighted averages to get a PRISMA score between -1 to 5+. To me, it is simpler just to focus on the weighted average.

Weighting

HITRUST score weighting is a way to assign different weighting, or priority, to different maturity levels.

At the end of 2019, HITRUST adjusted it's weighting factors to put more priority on Implementation vs Policy and Procedure. This makes sense as HITRUST wants to encourage higher scores for doing the things you say (Implementation), not just saying you do them (Policy) and saying how you do them (Procedure).

Below are the current weighting factors and weighting factors before 2020.

Before this change in weighting, it was possible to be HITRUST Certified if you scored Fully Compliant (FC - 100%) on Policy and Procedure, Partially Compliant (PC - 50%) on Implementation, and Non-Compliant (NC - 0%) on Measured and Managed. Only implementing 50% of what you say you do is not a high bar. The new weighting requires you score at least Mostly Compliant (MC - 75%) on Implementation.

Measured and Managed are very hard to achieve and many smaller companies are HITRUST Certified while being non-compliant for these maturity levels.

Example

At this point, it's easiest to use an illustrative example to tie it all together. We are going to use a real HITRUST control as an example to show all of the elements of the scoring process.

> Mobile computing devices are protected at all times by access controls, usage restrictions, connection requirements, encryption, virus protections, host-based firewalls or equivalent functionality, secure configurations, and physical protections.

There's a lot in the above control statement. And a lot that needs to be done to meet it. For now, we're just going to score it and use those scores to calculate an overall weighted score for the control. Below are the ratings for each maturity level.

The overall weighting for the above control example is 65, which is above the 62.5 threshold for HITRUST Certification. But, this is just one control, and the average of all controls for this domain needs to be above 62.5 to be HITRUST Certified. And this threshold needs to be met by all 19 HITRUST domains.

HITRUST scoring can be complicated and the details are best left to assessors and the CSF. The main takeaway is to appreciate that Procedure, and especially Implementation, are most heavily weighted and will have the most impact on your overall HITRUST performance.

Shared Responsibility and HITRUST

Starting with version 9 of the CSF, HITRUST introduced the related concepts of shared responsibility and control inheritance. Both concepts were incorporated into the CSF to address the growing demand from cloud providers and cloud customers for a better way to manage compliance controls on the cloud. The concept of cloud shared responsibility has gained adoption rapidly over the last 5-7 years. A basic understanding of cloud infrastructure is important to understand shared responsibility and how it is used in the HITRUST CSF.

 ☁️ For the purposes of this lesson, "cloud" is synonymous with public cloud services offered by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

The Cloud is Software

The cloud as a computer in somebody else's data center is not accurate today. AWS, Azure, and GCP deliver cloud infrastructure to cloud customers as software, not hardware. This software allows cloud customers to interact with and leverage physical infrastructure (processors, storage, transmission, etc.) on demand.

The software layer that cloud providers offer on top of physical infrastructure is a layer of abstraction. This layer of abstraction prevents cloud customers from accessing the physical infrastructure directly. And, as cloud providers have launched more and more specialized cloud services, cloud customers are being abstracted further and further from the underlying infrastructure. Most cloud services today abstract customers completely from the physical and operating system levels and partially from the networking and software package levels. Abstraction opens up interesting issues when it comes to compliance.

In order to become HITRUST Certified, or complete a PCI, GDPR, SOC 2, and most other types of security audits, a company needs to attest to, and be accountable for, a set of controls. Cloud customers are abstracted away from the hardware, and increasingly the software, controls that are requirements for HITRUST (and other regulations).

Shared Responsibility on the Cloud

🌩️ How do cloud customers take responsibility for controls when they have no access to the hardware or software where the controls reside? Enter shared responsibility.

Shared responsibility is the concept in which responsibility, in this case specifically for hardware and software layers in cloud services, are shared. It is now a widely accepted concept for cloud services. The problems with shared responsibility stem from 1) different cloud services having various levels of abstraction and 2) most cloud customers are running multiple cloud services. Compounding those problems in compliance is that most auditors are not very tech or cloud savvy.

The result is opacity and ambiguity at the level of control detail that would normally be required by auditors.

HITRUST Inheritance

The HITRUST Shared Responsibility program attempts to solve the problems with shared responsibility on the cloud. HITRUST created the concept of control inheritance, or the ability to inherit controls from other vendors. The inheritance of controls is explicit, meaning that both companies, the one inheriting the control and the one allowing inheritance of its control, have to acknowledge the inheritance.

Let's use physical security as an example. Since cloud providers manage all of the physical security for their cloud offerings, an AWS customer doing a HITRUST assessment could choose to inherit each physical security control from AWS. This would happen in the CSF. An approved AWS HITRUST CSF user would then have to explicitly choose to allow that AWS customer to inherit those controls.

This goes a long way to resolving most of the opacity and ambiguity of shared responsibility. While it is not a perfect solution that addresses all cases of shared responsibility, it does help. Challenges remain based on the complexity of cloud environments and the constantly changing nature of cloud services.

HITRUST Shared Responsibility and CSF control inheritance specifically solve the challenge of accountability, transparency, and control of cloud infrastructure.

HITRUST and Data Regulations

One of the most daunting challenges for technology companies today is the myriad of data protection regulations. Some regulations are geographic like GDPR and CCPA. Some are industry specific like PCI and HIPAA. Some are just industry accepted frameworks like SOC 2, ISO, and NIST. Technology companies, by their nature, can easily cross both geographic and industry boundaries. The result is that many technology companies now need to comply with multiple data protection regulations. Go to any large, global technology company website and there is a good chance you'll find a page full of badges for different regulations to which the company has been audited.

HITRUST, as a meta framework that normalizes and maps to various regulations, has tried to solve this. The general idea is that you can use the CSF to be audited for other regulations and not necessarily have to complete questionnaires or spreadsheets specific to those other regulations. The prescriptive guidance that HITRUST provides goes further than the regulations in guiding companies to be successful meeting various informations security controls.

I've had personal experience leveraging HITRUST for HIPAA, SOC 2, and GDPR. While my use of HITRUST to attest to these other regulations and reporting frameworks did create efficiencies in the process, it is not a simple matter of completing the HITRUST CSF and then checking off the the regulations you want. And, there are additional auditor and assessor costs for each additional regulation and framework.

The following regulations and frameworks are the most commonly asked about in terms of HITRUST mappings.

SOC 2

SOC 2 is the most formal existing partnership for HITRUST reporting. SOC 2 has been mapped to HITRUST CSF beginning with CSF version 8. The mapping of the CSF to SOC 2 controls is here.

SOC 2 is an increasingly common information security reporting framework. More and more companies are requiring SOC 2 Type 1 and Type 2 reports from their vendors. SOC 2 is governed by the AICPA and getting a SOC 2 report requires that you work with a CPA member of AICPA.

SOC 2 is made up of controls across five Trust Services Categories. One of the categories, Security, is a part of all SOC 2 reports while the other four categories are optional. The HITRUST CSF version 9.4 is mapped to the following SOC 2 Trust Services Categories - Security, Confidentiality, Availability, and Privacy. Privacy was the last Trust Service Category mapped to the CSF and laid the groundwork for mappings the CSF to GDPR and eventually CCPA (more on both below).

Even though SOC 2 and the CSF are mapped to each other and the AICPA and HITRUST have a formal partnership, the process of doing both a SOC 2 report and HITRUST Certification are different. Most companies will work with an auditing firm that has a CPA division. The first step is to do the HITRUST Certification process then the SOC 2 engagement. The main benefits are that the CPAs doing the SOC 2 report will require much less data and evidence as they will use the CSF for creating the SOC 2 report. If you use the same firm as you HITRUST assessor and SOC 2 auditor, you will gain additional efficiencies.

HITRUST has a SOC 2 FAQ here (it is from 2018 so slightly dated).

PCI-DSS

HITRUST, from it's beginning ~20 years go, has incorporated mappings to PCI into the CSF. PCI is similar to HIPAA in that it is an industry specific framework catering to the financial industry, specifically applying to companies that process credit / debit cards and cardholder data. Doing PCI with HITRUST is not a fully automated process. Using the mappings provided by HITRUST, companies can quickly populate the PCI self assessment questionnaire (SAQ) and work with a PCI approved auditor to create a Report on Compliance (ROC).

GDPR

GDPR was mapped to the CSF starting with CSF version 9.1 in 2018. All 99 Articles of GDPR are now mapped to the CSF. GDPR is relevant to all global technology companies as GDPR applies to all personal data on EU citizens. Companies can leverage the HITRUST CSF to show compliance with GDPR requirement, though this typically entails work, hours, and costs from auditors to do this work and ultimately generate a GDPR-specific report.

The Data Protection Authorities in the EU have not established specific certification bodies for GDPR, though the process of establishing such bodies is defined in GDPR. HITRUST is working to become a certifying body, which theoretically would enable companies to use their HITRUST Certification directly for GDPR.

CCPA

CCPA was mapped in 2019 to CSF version 9.3. CCPA is similar to GDPR but covers California resident data. CCPA went into effect in 2020 so the rules are new to all companies. The CSF mapping to CCPA is also similar to the GDPR in that is can be used by companies or auditors to manually verify how CCPA rules are addressed. Also similar to GDPR, CCPA prioritizes privacy over security so many of the rules are privacy-related, such as data subject rights and requests.

NIST

The NIST Cybersecurity Framework is a well adopted security framework. NIST is frequently used as an internal security and risk management tool. NIST was used as a basis for the original HITRUST CSF so mappings from the CSF to NIST have been a part of the CSF for many years. Organizations can use the CSF to populate or map evidence to NIST.

Department of Defense (DoD) Cybersecurity Maturity Model (CMMC)

The DoD recently, in 2020, mandated that all contractors must certify against the DoD maturity model (CMMC). Starting in HITRUST CSF version 9.4 in 2020, the CMMC is mapped into HITRUST. Organizations that use HITRUST can leverage the CSF to score and show their CCMC maturity levels in support of work with the DoD.

> The HITRUST CSF is mapped to many regulatory frameworks and can be used to streamline assessments and audits for multiple industries, geographies, and reporting frameworks.

Leveraging HITRUST at Your Company

HITRUST is not a small investment. The size of your company does impact the overall cost and effort to adopt HITRUST but, regardless of size, HITRUST takes considerable time and money. HITRUST should be viewed as an investment. An investment that will create an ROI only if leveraged over time and in a proactive way. We've seen, and experienced personally, situations in which the value of HITRUST is not maximized.

Coordinating efforts across all teams, including teams like Marketing and Sales that are not usually involved in HITRUST assessments, is important to take advantage of your HITRUST Certification. To get the word out, and address questions for multiple groups, developing an internal presentation on HITRUST is a good first step. There is no HITRUST training for employees (other than this course I guess) so a simple presentation to set an internal baseline of company knowledge is a good first step. Beyond that, activities should be specific to functional groups.

Below are some example activities and ways to help you take advantage of HITRUST and leverage your HITRUST investment. It's important to note that all of these can be applied to any type of security certification or report.

Reason #1: Security as an Asset

In today's world, there is a huge and growing focus on security and privacy. Checking the box is simply not enough. HITRUST, with its rigor, specificity, mapping to so many frameworks and regulations, can help turn security into an asset for your company. But sales and marketing teams need to understand how to leverage it.

• Creating a landing page for security, whether your company is HITRUST Certified or not, is valuable.
• Specific education to inform sales and marketing about how to talk to customers about HITRUST. This should include an FAQ.
• Creating reusable slides that can be easily incorporated into sales presentations.
• Training sales and / or marketing subject matter experts (SMEs) on HITRUST.
• Creation of a simple workflow for sales to share the HITRUST report (either in entirety or only sections of the report).

Reason #2: Internal Rigor and Formality

While leveraging HITRUST normally includes ways to use HITRUST for marketing and sales, one of the most valuable aspects of HITRUST is realized internally. HITRUST is more prescriptive than most (maybe all) compliance frameworks. It is also clearly structured and intuitive once you have a little bit of experience with it. HITRUST helps to remove out ambiguity for people making day to day decisions that impact sensitive data.

Reason #3: Common Internal Language

A common language, namely the CSF, can be used across the entire company. This is more powerful than you’d think. Compliance has it’s own parlance and when there’s ambiguity between terms and definitions, it can cause serious problems. The language of HITRUST is a powerful asset if adopted internally. It is also easier to pass this language to new employees when there’s turnover and new hires.

Reason #4: Internal Inheritance

One of the lessons in this HITRUST course covers shared responsibility and HITRUST CSF inheritance. The focus of that lesson is on inheritance of controls from cloud providers, which is inheritance of external controls from 3rd parties.

Another form of inheritance is internal inheritance. This is especially valuable for larger companies or companies with multiple products. In these instances, certain controls in the HITRUST CSF can be inherited across teams and products.

Reason #5: Reporting Compliance to the Board

Increasingly, compliance is being reported as a form of status update to the board. Once the board has been educated on HITRUST, reporting on compliance by using the HITRUST CSF provides a structured approach for discussing compliance issues and tracking progress using HITRUST maturity ratings and corrective action plans (CAPs).

> HITRUST needs to be proactively communicated internally to ensure companies get an ROI for their HITRUST investment.

Getting Started with HITRUST

Compliance is an expensive and dynamic challenge for companies of any size. For startups, there are unique challenges because of the lack of resources and the lack of an established and mature compliance program.

For technology startups in healthcare, HITRUST is a great way to build trust quickly. It is a well established framework that is widely accepted in the healthcare industry.

For startups outside of healthcare, HITRUST is also a viable option. HITRUST maps to many regulations so provides flexibility for startups as they grow into new verticals and geographies.

This guide can quickly get you up to speed on how HITRUST works and what to expect as a startup doing HITRUST for the first time.