How do top security managers respond when the CEO asks: “Are we compliant?” Will the response change if a regulator asks the question during an examination? Or an attorney at a deposition?
Companies must comply with laws and regulations, so it’s a question to prepare for, particularly if the company works in a heavily regulated industry such as financial services, pharma, food and beverage, or energy. Those companies can have thousands of requirements to comply with, ranging from data privacy and cybersecurity to HR and accounting.
As a former chief compliance officer and regulatory attorney, I avoided answering the question yes or no whenever possible, as it’s loaded with unknowns: At what point in time? In which area? Of which requirement?
What does compliance even mean?
Defining compliance becomes particularly problematic when talking about IT and security requirements. There’s no shortage of regulatory requirements imposed on companies to develop, manage, and enforce effective security and technology controls. If a single control fails, does that mean the organization has gone out of compliance? What if the control failed for only one minute before being detected and corrected by the firm?
Companies can have more controls than regulatory requirements. If one of 5,000 controls fails for a very short period of time, it certainly could mean the company was not out of compliance. However, I have seen first-hand how technology control failures cause significant consequences in a matter of milliseconds.
Four ways to better manage compliance risk
Rather than trying to answer the question yes or no, it’s better to frame the company’s response in terms of the steps taken to demonstrate compliance with known requirements. Here are the steps I followed while working for and advising highly regulated companies:
- Know the company’s requirements and track them over time.
To help ensure the company complies with requirements over time, security managers must first know what those requirements are. This becomes more difficult at larger and more geographically dispersed companies. A multi-national agribusiness company, for example, might have thousands of requirements across international, national, state and local levels. While a daunting task, security and IT professionals are not likely to be held responsible for coordinating this effort. Rather, it should fall on the shoulders of the company’s legal or compliance groups. Also, many requirements are similar to one another. The legal and compliance team can group them together so that the security team deals with a single requirement (e.g., encrypt passwords) as opposed to 15 different rules across various country, state and local authorities. Maintain the consolidated set of requirements in a centralized location suitable for the size and scale of your operations. Larger companies will likely invest in some form of a relational database or digitized application. Smaller companies might get by with a spreadsheet.
- Align requirements to policies, procedures, and controls.
Once the company has identified and centralized requirements, it should align them to policies, procedures and written controls. It’s an important step as it tacitly demonstrates how the company complies with requirements. Start by adding a field in the database to enter the name of the document that explains how the company complies with a requirement. Then fill in gaps where no document exists, a much harder task. It’s difficult to maintain this work over time as requirements and business operations evolve. No capable regulator, auditor or board member will want to hear that the company created a policy and aligned it to a requirement 10 years ago, but have not since reviewed it. The legal and compliance groups will develop proper governance to help the security team review and document the review at an appropriate cadence.
- Develop a methodology for scoring compliance activities over time.
While the first two steps will vastly improve the security team’s ability to answer the “are we compliant” question, documents alone do not encrypt passwords. The team will need a mechanism to show that the company actually encrypts passwords. For smaller operations with relatively few requirements, it might be fine simply showing actual evidence. However, more sophisticated enterprises should develop a proxy for measuring its compliance activities. Security teams can do this by categorizing requirements and creating an index for measuring compliance related activities within each category. The categories should be tailored to the business, such as financial, cybersecurity, technological, HR, and manufacturing. Then within each category, score the types of activities that demonstrate the company’s awareness of the requirements within each category and complies with them. Examples can include rating: whether controls are manual (zero) or automated (one); whether the company tests its controls (one) or not (zero); when the organization last reviewed governing policies, procedures and controls; whether an area has received internal audit findings in the past year, as well as whether the finding has been remediated.
Once in place, the company needs to execute on it regularly. If it does, the security will be well prepared to answer the tricky compliance question. Rather than answering with a binary yes or no response, the team can demonstrate the company’s awareness of its requirements, taken steps to document how it will comply with those requirements, and that it does so effectively over time.
While it takes some planning and coordination across departments, it’s well worth the effort and the team won’t have to sweat it out the next time the boss asks if the company’s in compliance.
Joe Adamczyk, president, Exchange Analytics