Many compliance audits start with the wrong question. People open their GRC tool, check which features are on the list, and stop there. But asking yourself if this tool can help demonstrate what happened and when, and who had authorized it, is the crucial difference between a protective stack and a protective-looking stack.
First, find the stack you have
Every organization has two technology stacks for compliance: the one they have, and the one they want to have. The former includes the spreadsheet, shared among employees, where policy sign-offs are recorded, the email where the manager approved an exception, the rogue software bought by the department to do their job faster – these are the tools that serve as enablers of the compliance process, unofficially and without proper security approval. Shadow IT is widespread.
Before you think about what tools you need, document every instance of compliance-related or supporting activity that you currently have in your organization. Talk to the people who perform them, not only to the ones who purchased the license to the policy management tool, and you will be surprised to hear about three or four more pieces of software that somehow process or store compliance data (and one of them is probably presented as the only source of truth, inaccessible to others). Now ask each of these tools one question: can you reconstruct the record?
Next, ask every tool one crucial question: can you reconstruct the record?
When you have the list of your current stack, try asking every single tool on it one simple question: if you had to demonstrate to a regulator what happened, when it happened, and who authorized it, could you do it within 1 hour?
For each of the processes you have recorded, find a few real-life examples: a policy attestation, a risk assessment, a remediation, and try and trace their history using the audit trail features of the tools you are using. Does the tool show who did what, when it was done, and what exactly was done? Is there a digital equivalent of a signature, timestamp, or version control to demonstrate that a certain policy version was officially adopted at a certain point in time? If someone starts explaining to you that, in order to demonstrate this, you would have to check several different places, you have a problem.
This is arguably more important than you might realize: the Ponemon Institute’s Cost of Compliance report found that the average cost of non-compliance was around $14.82 million per company, up from about $9.5 million a couple of years ago, with insufficient audit trails being one of the reasons cited. Not being able to demonstrate certain behaviors and decisions in a timely manner does not just lead to regulatory issues: it can be expensive.
Check if your evidence survives
Ask questions about the retention period of the audit trail and whether it can be exported in a usable format. What tools do you have to demonstrate that the entry in the log cannot be modified retroactively? Audit trail immutability is an important compliance feature, but it only goes so far if three admins can edit it without anyone being able to tell.
Retention schedules should be set in accordance with the regulatory requirements, not a default value set by the tool you picked five years ago. SOX, HIPAA, GDPR, ISO 27001, and other standards you might be required to follow, all have certain requirements regarding retention of evidence. If your stack’s retention rules were not updated to reflect that, that may be another weak spot to address before you even get to the next step.
Map the toolchains, not only the tools
While individual tools in your stack might have great internal audit trail features, the way they exchange data with each other can introduce weak points. Consider how the tools in your stack interact with one another: does the data pass from one to another seamlessly, or are there places where it is transformed, modified, or dropped? Are there data silos within your stack, places where one tool holds information that other tools do not have access to?
APIs, if used correctly, can mitigate some of these issues by creating a shared database that appears as a single entity, but a poorly implemented API can create multiple databases with no means of cross-referencing. For example, if your policy tool’s data is not synchronized with your training tool, or your risk management tool’s data is not shared with your vendor management tool, this can be a place where potential non-compliance issues and the associated corrective actions fall through the cracks.
Score what you find, and what you are going to replace it with
Create a simple scoring sheet and score each tool on it. Traceability, security features, ease of use, and cost can be important factors to consider for each of your compliance tools. Most organizations, when they start looking at their own stack, are surprised to realize how poorly the generic project management tools score in terms of traceability because, traditionally, they do not have this feature. Their very nature is to help manage tasks rather than create traceable records about policies.
This will also give you a baseline for the tools you are going to consider replacing them with: dedicated Compliance Software products usually score significantly higher on traceability and other factors, because their very nature is to build compliance processes around evidence rather than policies. Score your options according to the same criteria and keep in mind that traceability is often the most important factor, since regulators are interested in it most of the time. Use the same sheet to evaluate your options.
Build in adaptability
Regulatory requirements are constantly changing; your tools should be able to adapt to these changes without you having to contact an IT department and request a feature update or a security patch. Tools that rely on third-party code to comply with a specific regulation, such as certain cryptography standards, are especially at risk if that code is patched or removed from the master branch: your tool will stop being compliant. Your workflow automation tool, on the other hand, should allow you to modify approval chains and other aspects of its functionality on a case-by-case basis to reflect these changes without compromising security.
Another crucial feature to look for in a compliance platform is operational continuous monitoring. A spot audit can answer the question of whether you were compliant at some point in time, but regular day-to-day compliance checks are what will assure ongoing regulatory adherence. In fact, that is what many compliance officers mean when they say that the only way to know you are compliant is to undergo an audit. And if your tools cannot provide an audit trail on short notice, that is not a compliance tool, it’s just a collection of tools. The audit that you are doing on your tooling right now is the cheapest insurance policy you can buy against discovering this too late.
