A-10: Policy & Procedure FAQs & Examples

Our company has obligations to adhere to many different frameworks and/or regulations. We already have established policies. We now have a business need to perform a HITRUST assessment with the goal of achieving a HITRUST certification. Can we use our existing policies for the validated assessment, or do we need to create a separate set of HITRUST policies?
An Assessed Entity may leverage existing policy sets. It is not mandatory to create a new and/or separate set of policies. The HITRUST CSF leverages good security hygiene and leading practices that substantially cover authoritative sources, such as: NIST SP 800-171, HIPAA Security Rule, GLBA Safeguards Rule, U.S. Department of Labor EBSA Cybersecurity Program Best Practices, and Health Industry Cybersecurity Practices (HICP). Many organizations find success in establishing a foundation based upon the HITRUST CSF and adding, as needed, organization relevant policies. Conversely, the existing policy sets can be leveraged and adding, as needed, HITRUST CSF relevant policies not specifically addressed in the organization’s existing policies.

We would like to use the HITRUST requirement statements verbatim as our policies. Is that allowable?
This is allowable. However, for “Fully Compliant” Policy scoring in HITRUST CSF version 9.x assessments, the evaluative elements noted in the illustrative procedures for Policy must be incorporated. For “Fully Compliant” Policy scoring in HITRUST CSF version 11.x assessments, policies related to each evaluative element within the requirement statements must be incorporated.

There are many HITRUST requirement statements in which a procedure would seem obvious to our workforce. Can we simply use policy language for the procedure language?
HITRUST requirement statements are scored according to maturity levels. A procedure that might be understood by the staff from reading a policy, but a procedure addressing the policy that is not formally documented will lead to an undocumented Procedure score assuming the procedure was consistently observed. (See Chapter 9.2 Procedure Maturity Level)

We used a third-party report to support Implemented scores of 100%. However, the third-party report didn’t address policies and procedures. How can we score these?
Controls tested in third-party reports may address the operation of a control which will allow it to support scores at the Implemented level in a HITRUST assessment. However, these controls often do not sufficiently address whether the Service Provider maintained policies or procedures for all evaluative elements within a HITRUST requirement statement. In these instances, the Assessed Entity may maintain its own policies and procedures describing the expectations of the Service Provider to support scoring (similar to its own policies and procedures, these must also address all evaluative elements within each requirement statement).

The evaluative elements in a requirement statement within an e1 or i1 assessment refer to the organization having a documented policy or procedure. Does this mean that we would be testing the existence of the policy or procedure at the Implemented maturity level?
Yes. Although an i1 or e1 assessment does not include the Policy or Procedure maturity levels, HITRUST has identified the existence of certain policies and procedures as key baseline controls in those assessments. As a result, the External Assessor should follow the illustrative procedure for the Implemented maturity level and ensure that all evaluative elements have been appropriately tested including the existence of any expected policies or procedures.

In the HITRUST scoring rubric, it states that a documented procedure must address the “operational aspects of how to perform the requirement statement.” What is meant by this statement?
Each procedure should be documented at a sufficient level of detail to enable a knowledgeable and qualified individual to perform the requirement.

Examples of the operational aspects of “how” to perform the evaluative elements contained in a requirement statement may include documents that discuss:

• Tools / technology / system of record usage
• People or teams involved to carry out procedure
• Workflow description and / or description
• Technical / system / application configurations
• Check list items aligning to the requirement evaluative elements
• Triggering event(s) or condition(s) that would cause a need for the requirement to be carried out / operated
• Runbooks / step by step instructions
  

Procedures are not required to include all the items listed above, nor is the listing above exhaustive. The following examples include procedures and the corresponding HITRUST evaluation:

HITRUST Evaluation
This appears to be a fully compliant procedure because it articulates an operational discussion by describing:

• Who is carrying out the requirement – The network team uses Cisco and Netgear tools and technology

• When – at the deployment of WAPs

• What – Changing:

i. vendor default encryption keys – using tools and technology

iii. default SNMP community strings on wireless devices – using tools and technology

iv. default passwords/passphrases on access points – using tools and technology

v. other security-related wireless vendor defaults, if applicable (this is achieved by stating the workflow to be followed “The network team records the wireless solution’s security related features and any default settings are changed before being deployed into the production environment”)

HITRUST Evaluation
This is not a compliant procedure because it addresses only one evaluative element (changing of default password) and assumes this is completed prior to authorizing the implementation of the access point (rather than specifically stating it must be done prior to authorization of the wireless access point).