Written by: Frank Berke
HITRUST Common Security Framework (CSF) certification, a comprehensive quality assurance program, is widely known as one of the most rigorous information security frameworks. The HITRUST CSF certification process can certify or reject assessments outright and holds a strong position in the relationship between an Assessed Entity (AE), External Assessor (EA), and certification authority (HITRUST). As a HITRUST CSF assessor, we at Wolf & Company have outlined several common assessment challenges faced in the HITRUST CSF certification process. By avoiding these pitfalls, organizations can create less friction with HITRUST during the submission and quality assurance (QA) phases of the validated assessment. Here are our top four considerations for organizations to keep in mind.
Common Pitfalls to Avoid in HITRUST Assessments
- Declaring requirements “Not applicable” in MyCSF
Use caution when declaring a requirement “Not applicable” in MyCSF. With the release of MyCSF version 9.6, HITRUST has expanded upon the “factors” scoping utility, with the goal of excluding any not applicable requirements from an R2 assessment entirely. Similarly, i1 assessments are written in a way in which one condition or element may be applicable to the organization, while most of the requirement is not applicable, forcing the requirement to be scored. HITRUST has become significantly more scrutinous in recent years regarding the acceptance of not applicable requirements and their associated justifications.
If the AE wishes to set a scoped requirement to not applicable, a clearly defined justification is required. When evaluating these justifications with an EA, ensure that the HITRUST definition of terms is understood. These definitions can be found in the HITRUST glossary.
It is recommended that organizations add the not applicable justification to the subscriber comments section of the requirement in MyCSF. Only enter the justification itself and do not append “NA” or “Not Applicable” to the comment or this will create tasks to remove that verbiage during HITRUST QA. The not applicable status is denoted by the NA checkbox at the top of the requirement.
- HITRUST’s unique interpretation of common industry terms
HITRUST has several unique interpretations of terms that can be misunderstood during an assessment. The four most common misinterpretations are listed below. Use the HITRUST glossary when seeking the definition of terms within an assessment. Additionally, engage your EA to provide clarity if ambiguity still exists. It is common for a subscriber to set a requirement to not applicable due to a misunderstood term in the requirement statement. These requirements receive additional review during HITRUST QA and are often scored at 0% when discovered.
A. Transaction: HITRUST considers a transaction or online transaction not to be restricted to e-commerce but to include actions like API calls or remote authentication requests.
HITRUST Definition: “A discrete event between a user and a system (including, but not limited to, an online or e-commerce exchange) that supports a business or programmatic purpose, and contains various degrees of exposure (i.e., occurring within a single system, a single network, or externally between two or more separate systems) to which risk is evaluated upon.”
B. Mobile Devices: HITRUST considers laptops to be mobile devices. Any requirements that reference mobile devices should be evaluated for all types of mobile devices, including laptop workstations.
HITRUST Definition: “A computing and communication device that allows for portability (can operate without the use of an external power supply) and has the capability to store and process information, such as notebook/laptop computers, personal digital assistants, smart phones, tablets, digital cameras, and other Wi-Fi-enabled devices, etc. Mobile devices do not include portable storage devices (e.g., thumb/flash drives, external/removable hard disk drives, etc.).”
C. Mobile Code: Think of this as fileless-attacks. These include RAM-based exploits, web-browser or browser-extension attacks, embedded scripts, malicious macros, and Java/JavaScript. Modern endpoint protection platforms such as SentinelOne and CrowdStrike have configurable settings to detect these types of attacks.
HITRUST Definition: “Software programs or parts of programs obtained from remote information systems, transmitted across a network, and executed on a local information system without explicit installation or execution by the recipient.”
D. Covered Information: HITRUST was initially written for the healthcare industry, which has a very specific definition for the term “covered information.” For HITRUST’s migration to be an industry-agnostic framework, they have changed the definition of this term. Use caution when excluding controls relating to covered information as HITRUST’s definition for this is very different than the commonly accepted definition used in healthcare.
HITRUST Definition: “Any type of information subject to security, privacy, and/or risk regulations that is to be secured from unauthorized access, use, disclosure, disruption, modification, or destruction to maintain confidentiality, integrity, and/or availability.”
- Automatic triggers for additional quality assurance
- Using placeholder language such as not provide(d), no(t) evidence, TBD, awaiting evidence, unconfirmed, and follow up
- Using indeterminate language for controls scored 100% such as partially, partial, somewhat, and mostly
- Use caution when linking evidence artifacts to three maturities (policy, procedure, and implementation) as this will trigger additional layers of QA checks. This is particularly apparent when using a policy or procedure document for all three Avoid this practice wherever possible.
- Some requirements will not operate during the assessment period or have a “zero-population” regarding a sampled inventory test. A good example of these are the requirements referencing contractors with access to the scoped environment. HITRUST expects these controls to still be evaluated by the EA and scored. A policy and process stating the organization does not permit access to contractors, volunteers, or non-employees would be expected. A statement from organizational leadership, ideally on letterhead, expressing that no contractors have access to the scoped environment will suffice to score the implementation maturity at 100%.
HITRUST version 9 has implemented automated QA checks that run during the submission of an assessment. These automated checks are continuously being expanded and improved upon. Requirements that trigger these automated checks receive a deeper level of manual QA validation. It is recommended to minimize hitting these triggers wherever possible. Triggers that Wolf & Company have identified are listed below. Note that HITRUST does not disclose these QA triggers. The list below includes triggers that have been discovered by Wolf and is not exhaustive of all triggers used by HITRUST.
External assessor verbiage triggers:
Linked document triggers:
- Sampling lead sheets
Ensure HITRUST is provided with a sampling lead sheet, which identifies not only the inventory populations (servers, users, workstations, etc.) included in the assessment but also identifies the inventories excluded and provides a justification. For example, requirements that reference third-party interconnections are not applicable, and one could state, “No third-party interconnections in the scoped environment for that inventory are listed within the inventory spreadsheet.” Providing a comprehensive sampling lead sheet will reduce the number of tasks generated during HITRUST’s QA.
Conclusion
A HITRUST validation assessment can be an intense process, but it’s essential to provide reasonable assurance that your environment is operating effectively and in alignment with HITRUST CSF certifications. For questions on how to meet your organization’s specific HITRUST needs, our industry-leading team at Wolf can help – please contact us for assistance.
