Risk Template: Compliance (Part 1)

Compliance requirements are often the first dip by an organization into the security/privacy ocean. These requirements often provide detailed control requirements to help an organization be more secure. The following template will help you determine, document, and communicate your organization's compliance risks. 

This is the first in a series of articles to cover risk areas (e.g., compliance, breach, availability). Although there are many great resources that can help you complete a risk analysis (such as ISO31000 and NIST), there are limited resources on examples on how to put together your risk report. The template below provides a starting point with verbiage for you to edit for your organization's requirements.

Process

The template below shows the order of how to document your findings. However, the analysis steps are different. Check the template for more detailed directions for each step below.

1. Determine scope - What data and what data owners are handled by your organization. Please note that even if you do not retain the data, you are still subject to the regulations. See 2 sections labelled "Solution Scope" and "Regulatory Scope".
2. Review each sub-risk to uncover your vulnerabilities. Consider the threat actors (both organization resources and business partners) See Sub-risks Section for Risk A - Risk D.
3. Determine the risk ranking. See Risk Ranking Section.
4. Complete the template

Once you have completed your annual security risk assessment, distribute it to the Board of Director members and executives. Resolve risks found focusing on highest risks first. Keep leadership apprised of progress with regular updates throughout the year.

Finally, remember to complete risk assessments throughout the year when there is a significant change planned for the technical, physical or administrative environment.

TEMPLATE WITH SAMPLE VERBIAGE

Risk Description 

Here is some verbiage you may edit for your risk report.

• Exposure to legal penalties, financial forfeiture, and material loss should the organization fail to act in accordance with applicable laws, regulations, and contract agreements.

• Unable to take advantage of attractive revenue opportunities until compliance with applicable security requirements can be demonstrated. 

Context

The purpose of this section is to provide compelling examples that investment in reducing the organization's compliance risks is warranted.

• Highlight the most egregious risks found during your analysis
• Provide statistics and illustrations of challenges your organization faced throughout the year. For example, compared to last year there was a 24% increase in inquiries. The type of evidence for compliance was broad and deep.
• Add case studies from other organizations in your space that had compliance issues that caused significant impact. For example: Company Z was fined $2M and must achieve compliance in 90 days.
• Regulators consider robust risk assessments the cornerstone to compliance. For example, The Department of Health & Human Services’ (HHS) Office for Civil Rights (OCR) has levied multi-million dollar fines on organizations that perform risk assessments infrequently or poorly; even those organizations where only a small amount of protected data was breached receive significant fines. 

Risk Ranking

Once your analysis is complete (see sub-risk section), then describe the range of risks. Settle on consolidated risk.

• Likelihood - Low, Medium, High. Select one.
• Typically compliance risks vary where some are more likely such as inconsistent use of controls and less likely that there are no policies. Provide examples of different likelhood events.

• Impact - Low, Medium, high. Select one.

• The impact varies because there are a variety of probable events. For example, a deficiency uncovered may be easily corrected (low impact event) or the deficiencies uncovered may be significant and need to be corrected before the organization is allowed to continue with a service (high impact event).  

Threat Actors

• The organization's employees and contractors
• Business partners who support, access or handle data from in-scope systems

Sub-Risks 

The following list defines the different ways your organization may not satisfy its compliance obligations. You can then document specific examples from your analysis to highlight your organization's risk areas. The risk report does not need to be a comprehensive laundry list, the risk log should capture each risk. The intention is to be representative and relatable to executives, leaders and colleagues.    

Risk A: Incomplete policies and standards

Check if policies and standards:

1. Are organized such that it is easy for business and technical owners to understand the security requirements.
2. Inventory of compliance requirements. Business contracts are often overlooked and may detail specific security and privacy requirements.
3. Indicate the third-party requirements covered (e.g., NIST, GDPR, ISO, HIPAA, NY CYBER, CCPA, etc.)
4. Set specific and measurable guidelines such that evidence that the control has been achieved may be collected and reviewed.
5. Reviewed at least annually or when new guidance is provided by regulators or new risks are uncovered.

Risk B: Controls not fully Deployed or maintained

Check if:

1. Inventory of assets that are in-scope for controls. Assets include data, technology, processes, roles, facilities, organizations 
2. Documents how controls are deployed and that in-scope assets from inventory are covered. 
3. Maintains cross reference to polices, standards and procedures. 

4. Annual reviews are completed or more frequent if new risks. 

5. Regular upgrades are made if using a tool to satisfy the control.

Risk C: Limited written procedures

Check if procedures:

1. Indicate which controls the procedure supports.  Describe scope and not in-scope, roles and responsibilities, activities including who performs, when performed, how performed, workflow diagram
2. Produced and maintained by the team(s) responsible for carrying out the procedure. Multiple procedures may be required for a control. For example, patching practices may be different by technology.
3. Provide sufficient detail that would allow a new employee to carry out the procedure.  
4. Reviewed at least annually or when there is a change in the environment

Risk D: Inconsistency in operations with limited evidence of control adherence

Check if:

1. Controls are used consistently.  For example, patching is carried out at regular intervals as defined in the patching standard.  
2.  Exceptions are documented with credible rationale such as mitigating controls used instead to reduce risk. That the control is too costly, or resources are unavailable is not valid rationale. 
3. Maintain consistent records. For example:
• Training / testing was completed by individual 
• System and application changes tested, approved, and deployed 
• Access requests/ approvals 

Bright Spots

The nature of a Risk Assessment Report is to focus on deficiencies. It also helpful to include a "Bright Spots" section to provide recognition of progress.  The Bright Spots section lists areas where the organization is mitigating its security risks. Note if some of the capabilities listed require further rollouts, tweaks and continued maintenance to remain strengths.

If the bright spots are minimal per risk topic (compliance, breach, availability, etc.), then you may want to gather together and summarize for all risk topics.

Solution Scope

Describe the systems, data, and organizations that are part of the scope. If your organization is subject to multiple regulations and different solutions have been deployed then organize accordingly. A simplified diagram (executive level) is helpful. 

Regulatory Scope: Third Party Regulations and Frameworks 

Here is a list of information security and privacy regulations that your organization may need to comply with depending on the type of data handled and the residency of the data owners. Delete those that don't apply. Check with your legal counsel to ensure that you have a complete list for your organization.

Basic data breach regulations have been enacted in all 50 states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands. The state laws require organizations to notify the state attorney general and individuals of a security breach that contains personally identifiable information. Typically the protected data is name combined with SSN, driver’s license (or state ID), and financial account numbers. 

The New York State Department of Financial Services (NYDFS) Cybersecurity Requirements for financial services companies including insurers and brokers handling New York consumers. (23 NYCRR 500).

National Association of Insurance Commissioners (NAIC) developed a Data Security Model Law (#668). The model law with minor modifications has been adopted in the following eleven states: Alabama, Connecticut, Delaware, Indiana, Louisiana, Mississippi, Missouri, New Hampshire, Ohio, South Carolina and Virginia. The federal government has urged states to adopt the model law. 

California Consumer Privacy Act (CCPA) is a privacy law that includes some security regulations which are similar in scope to NYDFS and NAIC security model. It covers all California residents.

The Payment Card Industry Data Security Standard (PCI DSS); PCI is a robust framework with a more extensive set of security controls than NYDFS, NAIC or CCPA. It focuses on the secure handling of credit card data.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA);
The Health Information Technology for Economic and Clinical Health (HITECH) Act;

These two legislative acts cover the secure handling of health data by providers and insurers. In recent years, CMS has provided more detailed guidance on HIPAA and HITECH requirements by mapping to NIST controls.

National Institute of Technology (NIST) 800-53 Moderate: Provides specific guidance on implementing HIPAA/HITECH. NIST 800-53 Moderate is also intended to be a general framework.

General Data Protection Regulation (GDPR). A comprehensive privacy and security law that applies to all organizations that target or collect data related to persons in the European Union (EU).

SOX (Sarbanes-Oxley Act) requires all U.S. publicly traded companies to maintain financial records for up to seven years. There are access control and other requirements that intersect with InfoSec.

GLBA (Gramm-Leach-Bliley Act) mandates that financial institutions such as commercial banks, brokerages, financial advisors and insurance secure the private information of clients and customers. 

FISMA (Federal Information Security Modernization Act of 2014) mandates that all federal agencies develop a method of protecting their information systems.        

FedRAMP (Federal Risk and Authorization Management Program) provides requirements for deployment of cloud services including vendors and service providers across the Federal Government.     

FERPA (The Family Educational Rights and Privacy Act of 1974); Section 3.1 of the act provides requirements for protecting the education records of post-secondary school students.

COPPA (Children’s Online Privacy Protection Rule) covers the online collection of personal data of any child under 13 years of age under U.S. jurisdiction.    

NERC CIP Standards (NERC Critical Infrastructure Protection Standards) provides a set of controls to enhance the security of North America’s power system.

SOC2 sponsored by AICPA (American Institute of Certified Public Accountants) is intended for service providers that process user data. This is often specified in contracts.

ISO 27000 Family / 31000 Family (International Organization for Standardization). The 27000 family of standards provide security requirements and 31000 family focuses on risk management. These broad set of controls may be used by any business to assess and improve its security practices.

CIS Controls (Center for Internet Security Controls). A small set of controls based on high-risk attacks. Even if your organization falls under other regulations and frameworks, CIS may help you prioritize which controls to focus on first.  

The HITRUST Common Security Framework (CSF) is an industry framework. Some business partners may require HITRUST compliance. HITRUST covers all applicable regulations and frameworks previously outlined.