HITRUST i1 Framework Breakdown (CSF v11 Edition)

This is the latest iteration of my HITRUST framework breakdown based on the i1 assessment under version 11 of the HITRUST CSF. The prior version of the i1 was initially released in January, 2022 and you can find the framework breakdown for that version here , which remains valid for assessments being performed on v9.6 of the CSF, though those assessments will no longer be accepted by HITRUST after 7/31/2023.

HITRUST i1 By The Numbers

Let's start by reviewing some of the numbers associated with the new i1 assessment for a few minutes:

?? The i1 assessment was reduced in size from 219 to 182 requirements.

??? There are a total of 633 evaluative elements which tie to those 182 requirements.

? On average, each requirement has roughly 3.5 evaluative elements attached to it.

??? The largest requirement in terms of evaluative elements relates to the development and maintenance of an asset listing as part of the vulnerability management program, and contains 17 evaluative elements.

?? There are 51 items which feature only one evaluative element, which makes each of those items significantly more valuable in terms of scoring impact per evaluative element (we'll talk about this throughout the article).

Now in terms of how the assessment changed between v9.6 and v11...

?? 64 requirements from v9.6 also exist in v11 - which means if you were previously doing i1 under v9.6, one-third of what you were doing did not change very much at all.

?? 10 requirements from v9.6 were modified (expanded in most cases) as part of the transition to v11.

? 108 requirements are "new" to the i1 under version 11. However, as I'll address below - much of what is "new" is actually a more generalized version of a requirement that previously existed.

In Summary:

Overall, I think the changes made in the i1 under v11 of the CSF are a positive move in the right direction - it removed a lot of "bloat" that many organizations really struggled with. I love the fact that the requirements for the e1 are all included within the i1, which means the #hitruste1 and #hitrusti1 are aligned in a trajectory to allow organizations to match their assessment to their maturity in terms of their information security program. Lastly, I'm glad to see HITRUST holding fast to their commitment to continually refine the HITRUST CSF to address new and evolving threats.

Domain 1 - Information Protection Program

There are 15 requirements in the information protection program domain, down from 18 in the v9.6 i1. This represents 8% of the requirements in the v11 i1 and also 8% (54) of the evaluative elements within the entire assessment. This is a larger-than-average number, and the second highest number of evaluative elements within any domain (behind only Vulnerability Management). Six of the requirements are new, eight were present in the prior i1 and one was modified.

What Stands Out:

For those who have been paying attention over the past year, HITRUST has increased its clarification that while the i1 is an "implementation-focused" assessment, policies and procedures are an important part of the assessment. This is in contrast to the early days of the i1, when the concept of implementation-testing-only was expressed, only to lead to conversations between assessors and assessed entities which required clarification that yes, policies and procedures are an important part of the assessment, and this domain is the most significant example of that.

What Really Needs To Be In Place:

Organizations should have a comprehensive set of policies that are reviewed, revised, approved and communicated on a regular cadence to suit the needs of the organization and address common topics, but specifically including:

?? ?? Infosec Roles and Responsibilities

?? ?? Employee Screening and Disciplinary/Feedback Mechanisms

?? Acceptable Use Policies

?? Coordination Between Management and User Populations

If the above things are in place, then the vast majority of the elements within this domain will be satisfied.

Final Thought:

Most typical off-the-shelf policy templates will not cleanly address all of the evaluative elements required within this domain. If you got your policies-in-a-box from an automated assessment platform solution, they're probably marginal at best, and will require significant re-work. That said, the requirements and evaluative elements in the new version of the i1 are more accessible and more appropriate for most typical organizations.

Domain 2 - Endpoint Protection

There are 7 requirements in the information protection program domain, down from 8 in the v9.6 i1. This represents 4% of the requirements in the v11 i1 and 6% (35) of the evaluative elements within the entire assessment. Three of the requirements are new, three were present in the prior i1 and one was modified.

What Stands Out: ??

Significant additions include requirements around the protection of unattended equipment (screensaver, session lockout, etc.) as well as the implementation of compensating to controls to address malware threats associated with "unknown vulnerabilities" - which could take a lot of different meanings including heuristic-based protection, file integrity management or other solutions based on the assessed environment.

Impacts Of Modifications On Controls: ↗?

This domain contains an example of a requirement which was not only modified, but also moved to another domain entirely. v9.6 of the i1 included a requirement around the usage of SPF on email servers. but in v11 of the i1 this requirement not only moved to domain 9 (transmission protection) but was also modified to expand the requirement scope to include DMARC and DKIM in addition to SPF - so button up your email configurations! The other significant modification to the domain is the introduction of a modified requirement related to the usage of default-deny configurations on endpoints, but this requirement is not new to the assessment, it just changed slightly and moved from domain 8 to this domain.

Thinking Strategically: ??

In reviewing the requirements that were dropped, several of them overlapped quite heavily with a single requirement with 13 evaluative elements which addressed malware protections, and another item with 11 evaluative elements that focuses on spam protection - so in this case we have 2 requirements that cover 70% of the evaluative elements for the entire domain. I don't mention this because it means you need to focus on those two items... in fact I want to point out the opposite. This arrangement means that the remaining five items have a disproportionately high impact on scoring, and if you look at these items from a strategic perspective - they become more "valuable" to address from a per-evaluative-element perspective than the evaluative elements contained within the two items that represent 70% of the evaluative elements, but only 28% of the scoring impact for the domain.

Domain 3 - Portable Media Security

There are 6 requirements in the portable media security domain, the same numbers as in the v9.6 i1. This represents 3% of the requirements in the v11 i1 and 3% (20) of the evaluative elements within the entire assessment. Three of the requirements are new, and three were modified between versions 9.6 and 11.

What Stands Out: ??

While the overall requirements have not changed significantly, HITRUST made a positive change by shifting the focus of the domain closer to the actual usage of portable media, and moved away from more generic requirements around data classification.

The Basics Of This Domain: ???

There are a few "basics" any organization should follow in relation to removable/portable media:

1 - Don't allow portable media to be allowed unless there is a legitimate business need.

2 - For instances where sensitive data must be placed on portable media, make sure it's encrypted.

3 - If portable media isn't allowed, a written policy isn't enough - block its usage with technical controls as part of your endpoint hardening mechanisms.

4 - Where portable media is used, implement mechanisms to sanitize devices, track their usage, and configure anti-malware solutions to scan them prior to usage upon insertion.

A Final Thought: ??

This version of the assessment introduces a number of requirements associated with the handling and protection of sensitive data during physical transit (i.e. off-site backups or shipped equipment) - if this is applicable to your organization, be sure to check this out.?

Domain 4 - Mobile Device Security

Just like domain three, the total count of requirements remained unchanged between v9.6 and v11. While these six items represent 3% of the requirements in the v11 i1 it only includes 1% (9) of the evaluative elements within the entire assessment, so each evaluative element deserves special attention. Five of the requirements are new, and one is a carry-over between versions 9.6 and 11.

What Was Removed: ??

One of the major changes in this domain is the removal of requirements pertaining to the usage of a "centrally managed" endpoint management solution (i.e. MDM). While this requirement has been removed, addressing most of the requirements would be made much simpler through the use of an MDM. A requirement associated with the formal authorization of connection of mobile devices was removed - this is good because it was an unusual requirement and was difficult for organizations to grasp the intent of the requirement given the usage of the i1 as an assessment in moderate-risk scenarios.

What Was Added: ??

In effect, not much was really added to the overall requirements - some very prescriptive requirements were replaced with more general requirements that address expected configurations for device management including:

1 - The prevention of the usage of rooted/jailbroken devices as well as a formal inventory (which are made far easier through usage of a MDM solution).

2 - The encryption of mobile devices.

3 - Teleworking protections (i.e. session limits, locks, privacy screens, etc.)

A Final Thought: ???

In case your organization involves travel to high-risk areas, there are some requirements around the usage of specific device configurations and integrity checks upon return, so check that out if applicable.

Domain 5 - Wireless Security

Wireless security is one of the few domains which increased in size, going from six requirements under v9.6 to 7 requirements in v11 of the i1. At 4% of the requirements in the v11 i1 it only includes 2% (13) of the evaluative elements within the entire assessment, so like in domain four, each evaluative element is important. The domain is largely unchanged, with the additional requirement coming from a split of a v9.6 requirement into two requirements in v11.

What's Important: ??

First of all, scoping around wireless networks is always a bit tricky, so entities should work closely with their external assessor organization to determine how the various requirements within this domain may (or may not) apply to them. Even if wireless networks are not in scope, there are requirements present which will require evaluation (specifically a requirement related to scanning for unauthorized wireless networks). Because of these complexities, it may end up that a portion of the domain is not applicable, which renders each of the remaining applicable controls very significant from a scoring standpoint.

What Should Be In Place: ??

1 - Basic hardening of wireless networking equipment and rotation of keys.

2 - Usage of strong cryptography to protect wireless traffic.

3 - Network segmentation between wireless and non-wireless networks.

4 - Disabling wireless capabilities on devices which have no business justification for wireless to be enabled (i.e. printers).

A Final Thought: ??

As stated above, don't write off this entire domain just because wireless might not be "in-scope" for your environment, because there are a few requirements which become even more important if you do not use wireless.

Domain 6 - Configuration Management

Configuration management was one of the largest domains under the v9.6 i1, but under the v11 i1, it has shrank 40% from 15 requirements down to only 9 requirements. The domain includes not only 5% over the overall requirements, but also 5% (30) of the evaluative elements contained in the v11 i1. Two of the v9.6 requirements remain, and seven requirements are new in the v11 i1.

What's Important: ??

It's best to look at this domain as a complete re-write, and while the basic concepts of change management from the prior version remain, there are some new additions worth mentioning:

1 - Software inventory

2 - Supply chain protections

3 - Tiered deployment structure

Analysis: ??

Due to the significant change not only in size but also coverage, it's worth pointing out that HITRUST has seemingly tried to focus more on the traditional nature of configuration (change) management functions within an organization. In my opinion, the v9.6 iteration of the i1 included a lot of endpoint-oriented requirements that felt more like endpoint protection than they did configuration management. I'm glad to see a return to more traditional configuration management requirements - and I'd like to see a move towards including package and dependency management as a stated evaluative element given the increased exposure of a software bill of materials for organizations.

Final Thoughts: ??

The simplification of this domain is certainly an improvement from the "kitchen sink" of requirements it was previously. That said, organizations seeking certification should evaluate the newly simplified requirements to confirm continued coverage of them within the organization's configuration and change management practices.

Domain 7 - Vulnerability Management

This is one of the few domains that increased in size, from 9 requirements to 12 requirements in the v11, or 7% of the overall assessment. It includes 77 evaluative elements, which is 12%, the largest single domain! One requirement remains intact from the prior version, while four requirements were modified and seven requirements are new to v11 of the i1.

What's Important: ??

This domain can be boiled down to a number of essential practices:

1 - Have an extremely robust inventory that is audited on a regular basis (or otherwise validated) - five requirements all tie back to various aspects of the inventory.

2 - For both infrastructure systems (including endpoints) and applications, maintain a process to identify and resolve vulnerabilities in a timely manner, leveraging automated tools when possible.

3 - Perform system hardening to limit the usage of software, ports, protocols and services to only required functions based on business justification.

4 - Leverage automated solutions to aid in the patching and updating of enterprise software packages.

Scoring Strategy: ??

The evaluative elements are distributed in a highly disproportionate manner and seemingly important items are actually rendered less important from a scoring strategy standpoint. Only four requirements in this domain represent 75% (57) of the elements within the domain, averaging over 14 elements each. On the other hand, the remaining eight items include an average of only 2.5 elements each. Those with a high number of elements are clearly the more important, but by including so many elements, HITRUST dilutes those?elements due to highly-prescriptive elements which in many cases do not bring true value to the organization's ability to address threats using a risk-based approach. Instead, the organization is led to take a risk-based approach to the scoring of each item, selecting which elements truly bring value, and ignoring the others due to minimal impact on score. This is only my opinion, but I feel strongly that HITRUST should place a cap on the number of evaluative elements within each requirement to reduce these disparities.

Other Differences: ??

The previous requirement for the execution of an internal and external penetration test was dropped, and replaced with a general expectation for vulnerability scanning to be in place.

Overall Feedback: ??

It's my opinion that this domain focuses entirely too much energy on inventory management. I'm not suggesting inventories are not important, but 55 evaluative elements, or 71% of this domain is focused on inventories to a level that is well beyond what most highly-mature organization already have implemented. I would also like to see further refinement of the evaluative elements to be more reflective of modern, cloud-based environments.

Domain 8 - Network Protection

Network protection underwent a drastic reduction in size, from 13 requirements in v9.6 to only 9 requirements in v11 of the i1. It represents only 5% of the assessment and 6% (44) of the evaluative elements within the assessment. Five of the requirements were brought over from v9.6 and four are new to v11 of the i1.?

What's Important:

While web content filtering is not new to this domain, some more technical implementation requirements were dropped in favor of a broader requirement to prevent assets from accessing known malicious addresses/domains. There is also an added requirement which speaks to the "right to audit" being included for each in-scope network service provider's contract/agreement - requirements like this can be tricky because they cannot be quickly/easily addressed in many cases, so planning is important.

Driving Elements:

There are two requirements which consist of nearly half of the evaluative elements for this domain, and they focus on network design, segmentation and traffic routing as well as access management, logging and the usage of secured and authorized interconnections.

Overall Feedback:

The domain saw a number of more esoteric requirements removed, some of which were likely originally included due to the desire to align closely with NIST 800-171. Similar to domain six, I see the changes in domain eight as a return to more traditional requirements associated with the overall design, implementation and management of network systems.

Domain 9 - Transmission Protection ??

Transmission protection was reduced in size, from 10 requirements in v9.6 to only 9 requirements in v11 of the i1. It represents only 5% of the assessment and 4% (24) of the evaluative elements within the assessment. Four of the requirements were brought over from v9.6 and four are new to v11 of the i1, while one item was modified during the transition.

What's Important: ??

There are two primary drivers to this domain: 1) Encryption and 2) Email Protections. Encryption needs to address typical topics such as using strong algorithms, key management, selecting secure protocols, and implementing integrity in communications. Email is pretty simple and includes the requirement to have mechanisms in place to block suspicious emails as well as unnecessary file types at the perimeter (not at the endpoint) as well as the implementation of DKIM, SPF and DMARC, which is easily checked with online tools.

Driving Elements: ???

One of the most significant items within the assessment is a requirement that focuses on the agreements that exist between organizations when system interconnections exist, or network-based services are being provided. This is another good example where documentation is evaluated as a measure of the implementation of a control to address the given requirement. It will be interesting to see how this requirement plays out because it is focused on "electronic commerce arrangements" - so in many cases this item might be N/A if the assessed system does not include electronic commerce functions. However, in my experience, marking anything as N/A is a bit of a gamble because there have been many times where I thought something that was clearly N/A, was not considered N/A by HITRUST during QA - so worth a conversation with your assessor in terms of how to approach that.

Overall Feedback: ??

This domain has typically been very straight-forward in terms of requirements and testing. If you are implementing appropriate protocols, encryption algorithms, key management and session integrity mechanisms, you are well over halfway to a strong position in this domain. Add some basic email security functions, and you're well over 80% of the way there. That said, don't just assume that things are in place - make sure you test them on your own - there are many times I've found issues with TLS or SPF implementations that the client never saw because they had just assumed because they had configured everything, it was operating effectively.

Domain 10 - Password Management ???

Password management remained the same in terms of size, holding at 6 requirements or 3% of the overall assessment while containing 4% (24) of the evaluative elements within the assessment. One requirement was brought over from v9.6 and five are new to v11 of the i1.

What's New? ??

With the bulk of the requirements being "new" ((there are a few that are actually just reworked to be more general in nature), it's important to note what requirements might not have been previously considered. One important concept is that password "policies" must be enforced via technical means - this requirement existed previously but it was constrained to mobile devices. Another new requirement relates to the need to verify user identities prior to performing a password reset - this is a requirement that has been typical in r2 assessments, but has not been seen in i1 assessments before now. There's also a fresh requirement for the requirement for passwords to be communicated through secure means.

What Went Away? ??

Password history and a minimum number of characters being changed was dropped as a requirement. This requirement tied closely to 800-171 and many organizations found it hard to comply not with the password history aspect, but the minimum password change as part of password rotation.

The Basics:

There is one requirement which covers several specific topics within the realm of password management and covers items such as:

- Communicating password policies to users

- Secure password management/storage (no post-it notes)

- No sharing of passwords or accounts

- No reuse of passwords

- Select "quality" passwords.

Interestingly, HITRUST does not provide a quantitative mechanism to measure what is considered a "quality" password, so this is an example where a highly subjective requirement can lead to complications during the assessment - as I stated during my previous breakdown article, I would have preferred a minimum level of entropy be defined to allow for objective measurement of password quality.

Domain 11 - Access Control ??

Under v9.6 of the i1, Access Control was an excessively large domain with 29 items. Fortunately, HITRUST reduced the size of this domain in the v11 of the i1 down to 21 requirements, or 12% of the assessment - which is still the largest domain, but more reasonable. In terms of evaluative elements, the domain is more in line with others with only 8% (48) of the evaluative elements. seven of the requirements were carried over from v9.6 and 14 items were added.

What's New? ??

One significant change is that a requirement associated with user access reviews. The requirement has been loosened up from every 60 days for admin accounts and every 90 days for regular user accounts to (at least) annually for all accounts.

What Went Away? ??

The requirement associated with session login banners has been removed - and while there are some minor items that were removed, in most cases, the existing requirements were just tweaked and reintroduced in v11 as generalized versions of the prior requirement. MFA is an example of this as there were two v9.6 i1 requirements associated with MFA, but in v11 the two requirements were just slightly modified and given new unique IDs. So as we've seen with many other domains - the number of requirements was reduced and the remaining requirements were modified to be more general in nature.

What Does All This Mean? ??

Access Control is a large domain, and the bulk of the requirements are associated with how organizations request, authorize and communicate access mechanisms and then at the end of the life-cycle, how accounts are terminated upon separation. There are other various requirements associated with admin account usage, session limits, the usage of unique IDs, and other typical requirements. The evaluative elements within this domain are distributed pretty evenly with the largest requirement holding five evaluative elements and relating to clean desk and clean screen policies.

Domain 12 - Audit Logging & Monitoring ??

HITRUST took an ax to this domain in preparation for v11 of the i1 assessment! A domain that previously contained 19 requirements has been reduced by 53% and was slashed down to only 9 requirements, or only 5% of the assessment. In terms of evaluative elements, this domain contains only 20 evaluative elements, or 3% of the assessment. 3 of the requirements were held over, and 6 are "new" to the assessment, although most of them represent simplified versions of previous requirements.

What's New? ??

The most significant change is the fact that while the previous set of requirements was so detailed and complex that it would have been virtually impossible to obtain a passable score without a robust SIEM solution in place, the new set of requirements is general enough that while having a SIEM solution would be beneficial, it is not absolutely required to obtain a passable score.

The Basics ??

To be successful in demonstrating compliance within this domain, there are several key items organizations should be performing:

1 - Detailed audit logs should be maintained for system access as well as access to sensitive data for both users and administrators.

2 - Logs should contain enough information to be able to reconstitute the scenario in which the event occurred, and what user triggered the event.

3 - Audit logs (or archival copies of log data) should be protected against unauthorized modification or deletion.

4 - The organization should monitor logging capabilities for any logging or processing failures.

But Don't Forget ?

This domain contains a specific requirement associated with time synchronization. This is a great example of how changes were made between v9.6 of the i1 and v11 - this same essential requirement existed in v9.6, but the requirement was re-worded to clarify expectations for implementation for v11, and as a result was considered "new" to the v11 i1 even though the basic concept of time synchronization was maintained between versions.

Domain 13 - Education, Training and Awareness

Undergoing a moderate decrease from 9 requirements under v9.6 to only 6 items, or only 3% of the i1, this domain contains 19 evaluative elements, or 3% of the overall assessment. 2 requirements were held over from v9.6, 3 Requirements were added, and one item was modified.

What's New?

Phishing awareness was added as a specific requirement, which was based partially on the commitment by HITRUST to maintain the i1 as a threat-adaptive assessment. I have also started to see coverage of phishing simulations and training in more SOC 2 reports, so there's good harmony in place for that topic.

The Basics:

To be successful in demonstrating compliance within this domain, there are several key items organizations should be performing:

1 - Role-based security awareness training that covers information security, privacy, data handling, acceptable use and phishing requirements.

2 - Initial training upon hire and no less than annually thereafter.

3 - Additional role-specific training for individuals with elevated privileges or responsibilities.

But Don't Forget!

There are two items which are worth addressing specifically in this domain. The first relates to rules of behavior (which should sound familiar with .gov/.mil folks), and discusses usage of social media, networking, and other public platforms. Secondly, there is an awkwardly-placed requirement that addresses the technical requirements prohibiting the installation and usage of unauthorized software as well as the technical prevention of auto-run capabilities - this requirement is largely out of place considering the relatively administrative nature of most other controls we'll see to address this domain, so don't let it sneak up on you.

Domain 14 - Third Party Assurance ??

Third party assurance is one of the three domains which actually grew in size during the transition from v9.6 to v11, growing from 6 to 8 requirements. It now holds 37 evaluative elements, which is a disproportionately large number since it holds 6% of the evaluative elements compared to 4% of the requirements. One requirement was held over from v9.6 and 7 requirements are new.

What's Notable ??

There is a simple requirement focusing on exchange and data sharing agreements which contains nearly one-third of the evaluative elements for the domain. As a result, there are several requirements with only one or two evaluative elements focusing on areas including change management requirements for third parties, management of supplier a access and reviews of SLA compliance. Remember that mathematically, requirements with few evaluative elements are more important since those elements carry more weight.

The Basics ??

The primary focus of this domain is on formal agreements, vendor monitoring activities and ensuring responsibilities maintained by third parties are documented and followed up on. More than half of the evaluative elements in the entire domain focus on the contents of agreements, so pay particular attention to that.

But Don't Forget ??

If your organization obtains services from a managed service provider or outsources software development activities, there are applicable requirements which dictate the responsibilities of the assessed entity regarding the oversight the assessed entity must perform. Remember that old saying that you can't outsource risk. HITRUST has taken note than third party access to sensitive data is one of the most likely sources of a breach for organizations, and the requirements in this domain reflect that.

Domain 15 - Incident Management ??

Incident management is one of four domains which remained the same size in terms of requirements, consisting of 7 requirements or 4% of the assessment. The domain contains 23 (4%) of the evaluative elements in the v11 i1 assessment. Of the 7 requirements, 5 are considered "new" and two were held over from v9.6 of the i1.?

What's Notable ?

This domain contains another example where one requirement contains a disproportionate number of evaluative elements, with one requirement consisting of 10 evaluative elements and all others consisting of 3 or less. It should be no surprise that the largest item focuses on incident response plans (from an administrative standpoint) as well as technical capabilities to perform detection and analysis, containment, eradication, and recovery.

The Basics ???

This is a rather simple domain in terms of what is expected, and organizations can evaluate their own alignment with the requirements in this domain by ensuring:

1 - A comprehensive incident response plan is formally defined.

2 - Roles and responsibilities associated with IR are defined and communicated to personnel.

3 - POCs and mechanisms for reporting potential incidents are known to personnel and are easy to access.

4 - Technical incident response capabilities are in place and personnel are trained on their use.,

5 - Incident response testing is performed on a regular basis and lessons-learned are used to formulate improvements to the IR program.

But Don't Forget ??

This domain also contains a requirement associated with collection and retention of evidence to support investigations and other legal actions which may be beyond most basic IR documentation maintained by organizations, so pay special attention to this requirement.

Domain 16 - Business Continuity and Disaster Recovery ??

Business continuity and disaster recovery underwent a slight reduction in number of requirements from 11 down to 10, or 5% of the overall assessment. With an above-average number of evaluative elements at 38, or 6% of the overall assessment, the domain consists of 5 new items and 5 which were carried over from v9.6.

What's Notable ??

There are essentially three areas of this domain: 1) Backups, 2) BC/DR Planning and 3) Testing. Time and time again we have read studies which show that having a BCP/IRP and testing BC/DR/IR capabilities is one of the primary things organizations can do to reduce the financial and security impact of breaches. A BCP/DRP/IRP is pretty much worthless if it hasn't been tested, especially if the testing was only a "tabletop" exercise. While not specified in the requirement, the organization should at a minimum engage in some form of simulated testing activities (which is a FedRAMP requirement, FYI).

The Basics ??

1 - Define backup requirements. Create backups, keep copies of backups in a physically separate location, and protect backups.

2 - Identify critical assets and business processes requiring contingency operation support.

3 - Develop, maintain and train personnel on the business continuity plan.

4 - Test the business continuity and backup processes frequently.

But Don't Forget ??

There is one very-new requirement in this domain which calls for offline backups of data and systems to be in place. It will be interesting to see how this requirement can be implemented in cloud-heavy environments, and some organization's may find complying with the "letter of the law" for this item to be difficult. I don't disagree that it is an important requirement for protecting against ransomware and other threats, but this one is likely to cause some growing pains and some disagreement regarding what is truly "offline" - I may do a follow-up post after I spend some time researching this one.

Domain 17 - Risk Management

Risk Management is one of the three domains which grew between v9.6 and v11 of the i1, going from 8 to 10 requirements, or 5% of the assessment. In terms of evaluative elements, it is in line with the number of requirements, containing 34 (5%) of the evaluative elements in the entire assessment. Only 2 requirements are carried over from v9.6 while 8 are "new" to v11 of the i1.

What's Notable

This is one domain where I feel that instead of generalizing the requirements and becoming less prescriptive, the requirements have actually become more detailed, providing more prescriptive guidance on the implementation of controls to meet the defined requirements, most specifically in relation to classification guidelines for systems and data.

The Basics

1 - The organization should maintain a comprehensive program to identify and manage risk over time in a manner which addresses all areas of the HITRUST CSF (this is a significant simplification of approximately 20 evaluative items covering risk assessment).

2 - Assessment of risk should be included in the change management process.

3 - Information security controls covering a broad spectrum of control types (i.e. layered, preventative, detective, corrective, and compensating) and these control types should be considered as part of the systems development/acquisition process.

But Don't Forget

There's an odd requirement that addresses the requirement to maintain a listing of POCs associated with incident response and business continuity - not sure why this got dropped into the domain, but it has a related requirement that also addresses the organization's usage of external information sources, training, threat feeds, ISCs, etc. to maintain situational awareness of threats within the industry.

Domain 18 - Physical and Environmental Security

Physical and environmental security was reduced significantly from 21 requirements in the v9.6 i1 down to 15 requirements in the v11 i1, but it's still a larger-than-average domain with 8% of the overall requirements and 49 (8%) of the evaluative elements within the assessment. 4 of the requirements were carried over and 11 were considered new - but to recognize a consistent pattern, many of the requirements are just massaged and generalized requirements that were previously in v9.6.

What's Notable ??

In the prior version, there were a few specific requirements that were an awkward fit for many organizations (i.e. the requirement associated with lightning protection). In this version, the requirements are more generalized but still fall into three main categories: 1) Controlling access to areas in which sensitive data is stored, transmitted or processed, 2)?Controlling the movement and storage of equipment as part of the asset life-cycle, and 3) Controlling and managing physical and environmental protection mechanisms.

The Basics ???

1 - Secure facilities and equipment which store, process, transmit sensitive data, and restrict access to personnel with valid need to access them based on role.

2 - Ensure that systems no longer in use are wiped and securely disposed of (and that you keep records of such activities).

3 - Ensure appropriate physical and environmental controls are in place including redundant power systems and those which address life safety (i.e. HVAC, Fire Suppression).

But Don't Forget ??

There is one requirement which requires that health and safety regulations and standards are taken into consideration when securing facilities. It's interesting for this to be included as the actual health and safety regulations would be largely dependent on locality, so this could vary widely around the world.

Domain 19 - Data Protection and Privacy ??

Data Protection and Privacy took a proportional reduction, going from 12 requirements down to 10 of 5% of the i1 under v11. With 38 evaluative elements, this domain represents 6% of the elements within the assessment. 5 requirements were carried over and 5 are new to v11 of the i1.

What's Notable ??

Since the i1 does not specifically focus on Privacy, the data protection element of this domain is the more relevant set of requirements. Much of the domain focuses on proper data protection activities including data classification, handling and protection.

The Basics ??

1 - Data and media classification, labeling and handling policies are an absolute must for this domain.

2 - To go along with the policies, the organization must have technical controls in place to control the movement of data within the environment as well as protections while at rest.

3 - Lastly, encryption policies should be defined to identify acceptable encryption mechanisms and the organization should enforce the encryption of data in transit and at rest.

But Don't Forget ???

There's an unique requirement that is new to the assessment which indicated the usage of open source software should be restricted through organizationally-defined limitations. While I agree that organization's should be mindful of the risks associated with FOSS, this domain was an odd place to drop it. I would have preferred to see a requirement focused on the usage of a software bill of materials - but maybe that would be too specific.

The Final, Final Thought:

I do not work for HITRUST and I do not speak for or on the behalf of HITRUST as it relates to the interpretation, analysis or judgement associated with any given requirement. My opinions are my own and are highly dubious at best; I'm just a recovering IT guy who found a new life as an auditor and has picked up over a decade of of experience building infosec programs and conducting audits covering a broad range of frameworks and other requirements including NIST, ISO, PCI, SOC 2, CJIS, LADMF, 21 CFR Part 11, HITRUST and others. If you're looking for a cheerleader, coach or sherpa to help you along your HITRUST journey, reach out and connect so we can get the conversation started.