Arkferos Security Solutions

Finding the right kind of GRC tool to threat model your organisation

Throughout this series I’ve mentioned the need for a Governance, Risk and Compliance (GRC) tool, and some of you may not know what that is, or what that means. Also, in my experience, there is a WIDE variety of tools out there that are labelled as GRC tools, but they have different focuses, and many (sadly) won’t help with the level of integration I often build in organisations. Thankfully, there are some products that do. So without further adieu, It’s time to dive deeper into what I think a good GRC tool is, and how to use it.

A Single Pane of Glass

In my Asset Centric Risk model, the GRC tool is designed to be the aggregator of key security information such that you can use it as a way to instantly view your security posture across a broad scope of your ISMS. In essence, all GRC tools are built to help you do this, but how they do it is different. But because I have a specific approach to security, there are some features that are required to fully deliver on the Asset Centric Risk model.

Dashboards & Charts
First is decent dashboarding. Everybody loves decent visual dashboards, which can be customised for their purposes. I’m talking Pie Charts, Bar Charts, Line Charts, World Maps, Heat Maps, Numbers and Trend charts…. if excel can do it – I WANT IT. And so do you. This is because looking at data in tables and making sense of it is hard for most of our monkey brains (especially ones that are as smooth as mine), but a pictures can quickly tell us stories about data, and give us context to what the numbers mean.

Infinitely Customisable fields
Underpinning that dashboard is reams of rich, full of usable (visualisable) data. This means the ability to create multiple types of records, which themselves hold any number of customisable fields, themselves being of different types. This means numerical fields, formula based fields, single-choice fields, multiple choice fields, open text fields, and fields which are linked/related to other record types. These fields themselves should also have metadata (P.S: I have yet to see this in a product) so that they can be tagged or related to requirements, controls and or regulations.

Automated assessments
A database of records with custom fields is all but useful if you need to do all the data entry yourself. Instead, a good GRC system will allow you to build automated assessments that can be sent to respondents, which then fill in your records, including the custom fields. These assessments should be have customisable flows for review and approval, and should support rules within the assessment which can

1. Hide / reveal sections of the assessment based on known data or previous answers,
2. Warn assessors, or people filling out the form if there are issues
3. Allow for back and forth communication on an assessment (questions and answers), as well as the storage of other meta data (comments, attachments)
4. Automatically trigger other actions in the platform like other assessments, or workflows
5. Highlight or create risks & issues

Integration
Of course, it can’t be a single pane of a glass without being API driven, and supporting integrations. That means either being able to interact with field contents via API (read, write, delete, update) or having direct integrations where it can fetch information from various sources, and add that into fields.

A Web of Relationships

In my last post “Madness – Embracing Complexity” I outlined a core process by which you can drive security assurance in your organisation. In that I hinted at many of the things that would be in this article. That core process relies (or at least heavily benefits from) a GRC tool which can create and maintain relationships between several different pieces of information. Below is my visual representation of that complex web

If you just looked that and thought “what the actual #@%¤!?” … just let me explain!

From the diagram, you can see what I believe is a core feature of a good GRC – that any one of these records can depend upon other records of the same type. This is an important feature, as realistically every service is a web of dependencies. As an analogy, in a strong Secure Software Development LifeCycle (SSDLC) , you’ll have Source Composition Analysis (SCA) tools which inform you of the vulnerabilities in the packages and libraries you employ in your code base. We’re basically taking the same approach, but instead of packages, we’re talking about data sets, about other services, and entities and using them to discover features at a lower level, which can turn into risks at a higher level.

When you sell a product to a client, it is reliant on a set of your assets, each with their own properties. This is why relationships are so important in a good GRC tool. This also means that inheritance is also important. Take for example a risk affecting and asset that is itself a dependency for another asset, which itself is used as client service. That risk should be inherited and presented at the top level asset record, as well as at the client level record. Knowing the sum risk of that service offering to a client means understanding the sum of all the underlying dependencies. Again, this isn’t a feature of all tools, but there are some that do this.

Let’s talk about some specifics…

Assets

By assets, I will repeat what I said in the first post in this series – it is intentionally vague. I usually think of this in terms of applications like an app on your phone, some program on your PC, or a website/webapp like Gmail or Asana. To me, they’re all applications. An application as I see it, is any product, solution or implementation that serves some purpose. It could be a set of infrastructure components, or a website. It could be a SaaS product, or a fat client on your PC. It could even be a script! For me, the trick is defining it in such a way that you can describe and categorise a lot of things, without calling everything 1 super application. That usually means something like treating microservices, or shared services as separate applications that another, client facing application depends on. You can be as granular as you want, or rather as is useful to you (for SCALE), but do as you will in your context.

Suppliers & Vendors

In 2025, I hope I don’t have to tell anyone how important 3rd Party Risk management is, and key to that is the security of your suppliers and vendors. Keeping good records about them as a business is important. But that’s not enough for me, and I believe a good GRC tool (and the application of it) should separate the asset a vendor sells to you, from the vendor itself (e.g. like a SaaS service). The reasoning is simply that the assurance questions are different for an organisation, then they are for an asset. Often if the asset is an application, you can configure it in a many different ways, some of which are not secure, and are not recommended by the vendor. That’s on you. Equally, a vendors internal security posture can affect your asset (for example, not having robust IR processes), and that kind of assurance is not something you typically get when focusing on the security of a particular application, product, or even architecture. Essentially, this is a recognition of the inherent or implied shared responsibility model we have when employing applications.

Data Processing Activities

As it’s name implies, this is all around tracking how and why data is processed. Tracking this is generally necessary for privacy regulations and ethical concerns. Increasingly, it should also be used to track how AI processes data as well (whichever type of AI you use). More importantly, it stands to reason that if you have an application that is doing anything, it is by definition processing some kind of data. Just like assets, this can get nuanced, but is probably best described at a higher level, with details being described as Data Sets

Data Sets

Data sets is as it’s name implies. This is the set of data used in a processing activity or by an asset. Having metadata records for these can be useful as they can describe what they contain. Also, data sets are often combined for a given use case, and by having records for multiple data sets this can be done without having to redefine a data set for a particular use case.

Entities, Clients & Other 3rd Parties

Ultimately assets are owned by a party, and are there to serve (often other) party. This is just a record of those parties and the relationships between them, and the other records.

Risks & Issues

While the metadata being gathered about your organisation is a very useful output of a GRC system, to me a list of risks and issues is the key output of the system. Ultimately, I want to identify where my risks are, come up with a plan to address, reduce and monitor them.

One of the side-effects of having a systematic approach is that it can produce a number of risks, and that can be alarming at times. This is why I also believe a good system has the ability to create related issues, which aren’t necessarily scored or weighted like risks, but which can still identify minor gaps.

Why Spin

For those of you who are into GRC, and the associated tooling you may notice that I’ve left out a lot of other popular features, like control mapping/testing, incidents, audit management and standards compliance (e.g. ISO27001). I’ve done this because while these are great features – the real meat to my approach (which is “Asset Centric Risk”) is determined by what I’ve laid out above. The whole point of the endeavour is to create an informed picture, of reasonable resolution of your estate, which then allows you to do those other things.

I suppose what I’m saying, and this probably goes hand in hand with the name of this series, is that I believe those other features (like audit management) is just smoke and mirrors unless you have a clear picture of what’s actually going on. Spinning this complex web is the way to catch the reality of your organisation. Will you catch everything – nope. That’s nigh on impossible! But you will systematically catch a lot that you can action reliably.

Ultimately, what you’re looking to do with this approach, and with a good GRC tool is to threat model your organisation. Find the problems that keep resurfacing, and start focusing your attention on the most strategic blockers.