That’s right, none. Not until you’ve done a LOT of homework first. Even then, the most you’ll get from me are the right questions to ask to move forward, and [eventually] help with your vendor due diligence.
Besides, true security consultants should never ‘recommend‘ a specific technology by name, let alone by vendor. Our job is to provide you options based on a detailed breakdown of the security control function gaps that require filling, which in turn were determined from the results of an appropriate risk management life cycle. i.e. [simplified]:
- Risk Assessment;
- Gap Analysis;
- Control Function Gap Definition;
- Risk Treatment; and
In my experience, the first thing a risk assessment related to a GDPR compliance project would likely show is that you have absolutely no idea; a) where all of your data is (asset management), b) who has access to it (access control), and 3) what you’re doing with it (business process mapping). Until you know those things nothing can help you, certainly not a GRC tool.
“Technology cannot fix a broken process, it can only make an already good process better.”
For example, collecting log files from all of your systems and reviewing them is a good process, in that it is standardised, procedurised (new word), and operational. But, without the technology of a SIEM it will likely never be an appropriately effective process, so technology makes it better.
As for the GRC tools themselves, every GRC tool on the market [that I’ve seen] approaches things in the entirely opposite way from how both security and privacy compliance projects start; which is with the data. Data is just another asset, and if you were managing your assets properly you would know how the controls around them compare to the baselines established by your policies and standards.
If your baselines are set against the most restrictive of the regulations affecting your organisation, you can be reasonably assured that you are meeting them all. This may not be appropriate for all of your your data asset types, but your classification policy should accommodate for that.
It’s only when you have all of your assets mapped to business processes and data flows, baselined against your known-good profiles, that GRC tools can add significant benefit. However, when choosing a tool you have to decide which of the following features are most important because not one does them all [again, that I’ve seen]:
- Some form of document management – You’ll want to manage and distribute your policies from here, as well as expose your standards parameters for [hopefully automated] comparisons against system profiles (e.g. passwords must be 7 characters).
3rd Parties are also assets and part of the data flows, so record of contract commitments and regulatory responsibilities should be close to hand;
- Asset Management – As alluded to above, this is at the center of every project to achieve compliance with ANY security or privacy regulation, and well as the key to staying compliant with or without a GRC tool. This is not just a list of devices with type / hostname / IP address etc, it’s everything from software, to data, to 3rd parties, even individual skill-sets. It should also have indications against asset of highest data classification, criticality, applicable regulations, ownership and so on;
- Business Process / Data Flow Mapping – A list of assets is of little use if you don’t have context. That context is in the form of device dependencies and data flows. In other words, a business process. For things like GDPR, if you don’t know your business processes you can’t ‘legalise’ them;
- Change Control – Nothing in an organisation should change outside of an approved and authorised process. With both asset management and business processes fully defined, change control can be done with an understanding of its context, impact, and required management sign-off;
- Trouble Ticketing / Incident Response Workflow – Incidents of any sort will, in some way, refer to an asset. A GRC tool cannot be a stand-alone manually operated collection of information, it must receive input and make decisions on alerting. You should already have all of the assets baselined, so providing a workflow around the non-compliance alerts the GRC tool (or others) generates just makes sense;
- Overlay of relevant regulations – Not much point having a GRC tool without the requirements of the applicable regulations mapped out for you. Unfortunately these generally come first in most GRC tools, but in reality they are driven by the assets, especially the data. These absolutely must be customisable;
- Import of system settings and/or system alerts – Last on the list but one of the most important aspects of whether a GRC tool is of benefit. You know what the known-good baselines are for each of your assets, so unless you can automate the import of end system data how are you going to run the comparisons? Manually?
For example, if you can import the GPO from Windows AD you’ll know the settings for every Windows system; password length / complexity, timestamp, log settings, and so on.
Export is equally as important as you may already have tools to do some of the above to which you want to send contextual data.
For tracking PCI compliance in a GRC tool, it’s relatively straightforward. All of the controls are written down for you and you know exactly what evidence is required to validate that the control is in place. But things like GDPR compliance are a little more ethereal and based on YOUR definition of ‘appropriate’ and ‘reasonable’. Nevertheless, by starting at the asset level you can make the compliance process cumulative over time as opposed to trying to force it from the top down with little understanding of context.
Done properly, a GRC tool can be extremely valuable in not only the maintenance of regulatory compliance, but achieving it in the first place. If and ONLY if you know what to look for before you start.
Start by asking the right questions, or find someone who can do it for you.
[If you liked this article, please share! Want more like it, subscribe!]