This tip is part of SearchSecurity.com's Compliance School lesson, Automated compliance in the enterprise. Visit the Automated compliance in the enterprise main page for related materials, or check out the Security School Course Catalog for more learning content.
It goes without saying that managers in any regulated organization face a perpetual burden in the form of the logistics associated with "compliance," whether that be compliance with applicable laws, regulations or even internal policies. Often a case can be made that an enterprise spends so much time ensuring compliance that it loses sight of why compliance is important in the first place.
In the quest for efficiency in managing compliance, many companies seek ways to automate the process with technology, thus easing the burden on operating staff while hopefully increasing accuracy at the same time. This represents one of the greatest of double-edged swords in business.
Process management automation is a good thing in IT, and compliance is no exception. It enables efficient use of technology, allows for the observation of massive amounts of data in a short period of time, brings numerous resources to bear, eases what often is tremendous complexity and executes "rulesets" relentlessly and accurately. However, there is a downside to automated compliance activities if they become an excuse for ignorance. The purpose of this tip is to provide a series of concrete points to be considered when undertaking any attempt to leverage technology to initiate automated compliance processes.
Point 1: The risks must be fully understood. This point is critical and non-negotiable. The goal of compliance (at any level) is not the completion of a checklist, it's not even a process -- it is to manage a risk. This fact can never be lost in the process of compliance automation. If the source, likelihood and effects of a given event (e.g., server failure, unauthorized access, etc.) are not fully understood, then compliance should not be automated. Instead, begin by exploring and documenting these aspects, and use the findings as a foundation for exploring automation opportunities. The process never starts with the question "Is the data available?" It starts with "What is the risk?"
Point 2: The data must be sound. Once the assumptions pertaining to a risk have been carefully documented, the next question becomes whether there is sufficient data to support automation. In this exercise, "data" will typically be operational, which may include loss data, event logs (e.g., IDS logs), system activity (e.g., failed login attempts), governance data (e.g., timeliness of vendor updates such as PCI re-certifications), aging of open audit items, etc. When undergoing the data-evaluation process, pose the following questions about the data in question:
- Can the data truly be mapped to the risk? This takes discussion and agreement between IT and business units to validate that the data sufficiently correlates to the applicable risk. Just because it can be tracked doesn't necessarily mean it should be.
- Is the data available, credible and reliable? In order to automate a compliance process, all three of these criteria should be met. However, if any of these are suspect, that doesn't mean that the process cannot be partially automated, but it will have implications on the amount of manual intervention that will still be required.
- Is the data statistically significant? Automating a process to monitor and analyze a small handful of data points will rarely pass a cost-benefit analysis and will probably create more risk that it solves.
Point 3: The process must be sound. This point has several aspects that are key to compliance automation.
- There must be mechanisms in place to ensure that any automated process management will take place reliably. Too many fires have started because no one checked the batteries in the smoke detector. For any given process, this requires that a specific individual is clearly identified with responsibility for ensuring that the process is executed without exception.
- A clear process must exist for reviewing exceptions and responding accordingly. Depending on the environment and circumstances, "red," "yellow" and "green" alerts may mean different things and require different responses. And remember, all green for too long can be just as much of a warning as sudden red, perhaps even more so.
- Finally, and most critically, there must be flawless mechanisms in place to handle change. Even the most subtle change to an operating environment can have dramatic consequences on the availability, integrity (at any point in time) and reliability (over time) of data, which can severely compromise the compliance process, not to mention fail to mitigate or even exacerbate the underlying risk.
In the end, it is critical to remember that automated compliance technology can be part of the process, but it can never be the process. Effective compliance always requires the insight and intuition of seasoned professionals who understand the risks that compliance activities seek to subjugate and can identify and interpret the relevant data that is presented to them. However, when managed properly, technology can be used effectively to supplement and support an enterprise-wide compliance program.
About the author:
Eric Holmquist has more than 27 years experience in the financial services industry and is a frequent industry author and speaker. As president of Holmquist Advisory, he has experience in virtually every area of bank operations including: risk management, branch operations, IT, information security, finance and accounting. Named one of the "Top 50 Faces Of Operational Risk" by OpRisk & Compliance Magazine, he has developed risk management, MIS and information security programs and is an expert in creating operational efficiency and risk alignment. He can be reached at email@example.com.