Technology-Driven Compliance

“Compliance” may sound boring and useless – consultants and lawyers are telling you how you should do things and then go around with checklists to see if everything fits a predefined vision of how a certain business should operate. And there are all sorts of compliance requirements – from regulations (GDPR, PSD2, AML, Regulation (EU) 575/2013, etc. etc.), through industry-specific standards (Basel III, PCI-DSS) to general-purpose standards (ISO 27001, ISO 20889).

But compliance is there for a reason – it is the agreed-upon set of best practices in a given domain. Yes, it is imperfect and sometimes too strict and indiscriminately burdening smaller players, but nobody can really reject the idea of compliance. The question is how to make it more manageable for organizations and at the same time make it more efficiently reaching the initial goals of the compliance process.

Because if you are GDPR, PCI-DSS and ISO 27001 compliant, and your company has spent millions for compliance, but you still suffer major security incidents and data breaches, then something is not right. And from our experience what is not right is the compliance process – it relies too heavily on documents and procedures rather than on actual technical solutions.

Documents and procedures are important, of course, as they lay the groundwork for anything that a company does. But they are not sufficient. Compliance should be driven by technology where that’s possible. The software should guide you and limit you instead of lawyers and consultants. Because that makes it more likely that the best practices will be followed properly.

Take the example of the logging requirements by PCI-DSS and ISO 27001. They prescribe that logs should be protected from tampering. How is that usually solved? By having a written procedure that copies of logs are kept in separate locations with separate admins having access to them. And that’s compliant, in theory. In practice, however, it leads to many risks, including misconfiguration, admins conspiring, or simply not following the rules.

A purely technical solution to that problem, like our SentinelTrails product, eliminates all those risks. There’s no risk of admins conspiring, there’s no risk of misconfiguration, and there’s no risk of someone not following the rules. The software itself guides and limits what is possible, and therefore gives you compliance with that particular bit automatically.


Another simplified example is the prevention of data breaches. There is a difference between “admins are not allowed to select and export large chunks of data” and “admins can’t possibly select and export large chunks of data, because they are encrypted“. Technical solutions can cover the cases where procedures, rules and laws can’t reach.

Not all requirements can be automated by software means, of course. Each standard has organizational and technical measures, and each regulation has a legal side in addition to that. But the more requirements you shift from “organizational” and “legal”, to “technical”, the better. And “better” here means two things – more compliant, and requiring less long-term overhead. And long-term overhead comes from the constant need to make sure that procedures are followed. If that box is ticked automatically by having a software in place, you can spare a significant amount of man-hours.

There is risk, though, with too much reliance on software – it can introduce clutter and be expensive to support. If your compliance is based on 15 different software products rather than a big pile of documents that the compliance department has to enforce, you are basically shifting compliance costs to the IT department. And chances are, they will be more expensive and managing them will be a complex task itself. Having an automated period vulnerability scanner, automated pen testing tool, secure audit trail solution, database encryption tools, a SIEM, a personal data monitoring proxy (for GDPR), a GDPR-specific dashboard, a PSD2-specific dashboard, an automated password algorithm detector, etc, might seem as harder and more expensive. On the other hand “all-in-one” solutions either do not exist, or if they do, they do a poor job and lock you in practically forever.

But these problems are manageable with a competent IT department, and it is a strategically good idea to have a competent IT department, as digital transformation is not going to slow down.

We’ve discussed here mostly the technically-relevant standards and regulations, although even the ones that have nothing technical (e.g. accounting standards) can really benefit from software-driven compliance – if your accounting software doesn’t let you do accounting “the wrong (non-compliant) way”, you don’t have to worry about compliance that much.

There is no silver bullet to anything in life. But there are better and worse approaches. And we believe that technology-driven compliance is much better than document-driven compliance. Because it’s often harder to cheat technology than to cheat procedures (at least if the software is done right). And this is probably the reason we are seeing more and more investments in RegTech companies that try to automate certain aspects of compliance. And we believe this is a direction that organizations should move to.

Like this article? Share it with your network!