Practically speaking, there tends to be a great deal of confusion around the topics of requirements vs. controls. We are all very familiar with the various marketing strategies for complying with the US National Institute of Standards and Technology (NIST), Payment Card Industry (PCI), the Health Insurance Portability and Accountability Act (HIPAA), International Organization for Standardization (ISO), and more. Conversely, out of this list, can you describe which of these are requirements or controls? If not, how do we know if we are genuinely compliant or have the appropriate safeguards or countermeasures in place?
Figure 1: The Basics: Requirements vs Controls
Requirements
What are requirements? Requirements are usually externally or internally imposed mandates such as laws, regulations, contractual obligations and even internal policies. Based on the activities your organization engages in, it may be subject to various mandates due to the criticality and sensitivity of the organization's data. Examples of requirements include HIPAA, the Payment Card Industry Data Security Standard (PCI DSS) and the General Data Protection Regulation (GDPR). Requirements are typically not prescriptive yet have significant fines and penalties associated with noncompliance. In short, requirements tell us what to do, but they do not do a great job of telling us how to do it.
Controls
Controls are safeguards and countermeasures that organizations employ to reduce identified risk within the enterprise's risk appetite and tolerance. Controls are step-by-step procedures applied to address risk. In this case, controls can address the risk of noncompliance. We classify controls as detective, preventive or corrective. Additionally, they include various types, such as administrative, technical and physical controls. Lastly, we categorize controls as either automatic or manual implementations. In figure 2, I have demonstrated how we can measure control effectiveness and associate it with NIST's functions. As assurance professionals, we must ensure a proper balance of control classes, types and categories. This strategy helps us sustain control risk within acceptable levels and identify appropriate compensating controls.
Figure 2—Curtis Control Effectiveness Diagram
OK, How Does This Help Me?
Understanding the difference between requirements and controls is essential for assurance professionals because misinterpretation of requirements can result in gaps and create risk. Now that we know that controls are required to address requirements, there is another essential factor we need to understand. There is not always a one-to-one mapping between requirements and controls. For example, consider the HIPAA’s Security Rule’s requirements in Appendix D.
Figure 3—NIST 800-66 Appendix D: HIPAA Standards and Implementation Specifications Catalog
One-to-One Mapping Example
Let us take a minute to interpret figure 3. 164.308(a)(1)(i) requires that the enterprise implements policies and procedures to prevent, detect, contain, and correct security violations. This requirement tells us what is mandated but not how to implement the necessary processes. NIST 800-53 controls provide details on how to meet this requirement. This time, HIPAA’s 164.308(a)(1)(i) requirement only maps to one NIST control, which is RA-1.
RA-1 provides the following guidance to meet the HIPAA requirement. The organization should:
- Develop, document and disseminate the following to organization-defined roles:
- A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance.
- Risk assessment procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls
- Reviews and updates the current:
- Risk assessment policy on an organization-defined frequency
- Risk assessment procedures on an organization-defined frequency
As you can see, NIST is more prescriptive and provides organizations with more specificity on how to interpret the vagueness of external requirements like the HIPAA Security Rule. Additionally, the supplemental guidance in NIST provides organizations with context and a better understanding of security controls. Finally, most controls have references to help the organization create their own processes. For example:
- NIST Special Publication 800-12: An Introduction to Information Security
- NIST Special Publication 800-30: Guide for Conducting Risk Assessments
- NIST Special Publication 800-100: Information Security Handbook: A Guide for Managers
One-to-Many Mapping Example
In our second example, we can see 164.308(a)(1)(ii)(A) requires the organization to conduct a risk assessment to identify risk to electronic protected health information (ePHI). Once again, HIPAA does not provide prescriptive guidance. However, this requirement maps to three NIST controls that comprise RA-2, RA-3 and RA-4, which essentially means that we can utilize these three controls to satisfy the HIPAA requirement.
RA-2, RA-3, and RA-4 provides the following guidance to meet the HIPAA requirement:
RA-2: The organization:
- Categorizes information and the information system in accordance with applicable regulations (e.g. HIPAA)
- Documents the security categorization results
- Ensures the authorizing official reviews and approves the security categorization decision
RA-3: The organization:
- Conducts a risk assessment
- Documents risk assessment results in security plan or risk assessment report
- Reviews risk assessment results on an organization-defined frequency
- Disseminates risk assessment results to organization-defined roles
- Updates the risk assessment on an organized-defined frequency or when significant changes occur.
RA-4: Withdrawn: Incorporated into RA-3
Conclusion
Practically speaking, whether you are conforming to PCI DSS, GDPR or HIPAA, it is important to construct an aggregated approach toward conforming to each mandate. Control frameworks like NIST 800-53 provide organizations with an aggregated methodology toward conforming to applicable requirements by leveraging the same set of controls. Lastly, more tactical guidance like the Center for Information Security’s (CIS) Critical Security Controls provides us with technical parameters and benchmarks. CIS's technical configurations help ensure our information systems, applications and infrastructure comply with external requirements.
Editor’s note: For further insights on this topic, read Blake Curtis’ recent Journal article, “The Impact of Poor IT Audit Planning and Mitigating Audit Risk,” ISACA Journal, volume 3, 2020.