One: Compliance Requirement Management

Today, I would like to shed some light on things, I feel to be a basic starter for every compliance management approach - be it information security, data protection, business continuity, quality management or other domains.

Background

As an auditor and consultant, I've had the opportunity to work with a variety of companies of different sizes (from 50 million to over 20 billion EUR in annual revenue), across various industries and maturity levels. Especially in the time between 2013 and 2016, being part of an IT audit team, I usually switched mandates once or twice a week, always applying the same pattern of audit procedures. There have been various levels of maturity around when it comes to (IT) compliance management. From "What's that" to "This is how we report our level 5 CMM indicators to different levels of stakeholders" it's been a variety of performances and always a suprise what's waiting for us as an audit team.

For most of my mandates though, the investment into compliance management was not based on a monitored requirement management. Meaning, people have been invested and have been doing primarily the right things - not necessarily the needed things and not necessarily in the right order. Surely, almost all of them got the job going and they succeeded with their compliance management, leading to a decent posture (of course, there are always outliers in both directions).

Application and Learning from Mistakes

After ending my time in audit and consulting, the first thing I did with my new employer was to create such a basis. Create a register for requirements from all kinds of sources, rank them and then track each and every one of them for their degree of fulfiment.

Well, learning from mistakes is key. Although the idea was sound, our ambitions were perhaps too lofty. What we did was to meticulous; we swamped the organisation with requests, roused all kinds of teams throughout the org chart (account & partner management, tech, operations, HR and more). In the end, we did not have a compelling, comprehensive result and did not manage to come up with a process to continuously maintain the register.

Still, requirement management should be the cornerstone of your compliance strategy, forming the basis against which your compliance posture is measured. Compliance does not have an end in itself, it's a business enabling function (yes, it is!), it has to follow where the business, where strategy is heading to. Short: If you are doing something in comliance management and cannot tell why you are doing it, then leave it or back it.

7 Keys for Compliance Requirement Management

To make a long story short, this is what I learned so far when it comes to requirement management:

1. 👉 Make sure to use all relevant sources for the identification of requirements. That could be local laws, supranational regulations (e. g. EU), industry regulations, client contracts, policies from the parent company and more. This might be quite a bulk of issues to scan - leading directly to the second point.
2. 👉 Make it a process to approach such documents. It's nice to have them scanned once. But time is not standing still, matters update or expire. You need to find a hook to make your process as far as possible an overlap with existing functions - where the documents are initially progressed. A good example for such is the contract workflow where Sales is drafting, closing and archiving contract documentation. This helps you to directly tie yourself to the natural lifecycle of things, e. g. "this damn contract annex". For things that nobody else is monitoring, you might want to make use of tools (e. g. regchange tools).
3. 👉 Apply criticalities to requirements. Not everything is of the same importance. During the process you will likely find more individual requirements than expected. Work at least with three tiers (low - high). Mind to apply business criticality. Personally, I used to tend to apply the scale of a compliance nerd with all its strictness and lack of understanding for even tiny non-conformities.
4. 👉 Connect your meta model to your requirements. This is one for the more mature organizations but if possible it is a pivotal change for your compliance management (from drafting over auditing to reporting; especially regarding communication to your stakeholders). Knowing which requirements is paying into which facet of your organization is key - from capability down to more detailed object types. Also, when it comes to certifications and external audits, it's way easier to lay your path to conformity.
5. 👉 Document your internal SMEs. Requirements migt stay for a longer time, maybe decades. Once discovered and adjusted, everything might be running smooth. When parts of the equation change after a longer period of time, it will be hard to re-adjust all the tiny bits. Knowing "who knows" helps a lot. When first creating the rundown for a requirement, the SME name will pop up anyways, document it.
6. 👉 One thing, we did very wrong in our first run: Scan on a low level, implement on a high level, do not put all your resources into the single requirement. For way more than half of your requirements you will find more than one source stating essentially the same. Even though it's good to know how often and from whom you are required to establish a central log management in your tech landscape, you should surely not implement a central log management five times but once. Make yourself familiar with the bigger picture and then cluster. In vucavoid, we call this "Requirement" for the cluster and "Reference" for the single sources. This also helps you do two things:

• 👉 You can level out peaks in requirements that might not be of a very high business importance by clustering them in a pile of (very) similar requirements.
• 👉 You avoid duplicates in work. My example of the central log management might have been an apparent one but there are things that might not be this self-evident by itself. Digging through hundreds of documents might make your dull to seeing similiarties. Asking other departments for a similar fulfilment review in different calls might impair the acceptance of your approach.

7. 👉 Last but not least: Some requirements might be high-level, might be abstract. Example for such might be the Digital Operational Resilience Act (DORA). You might be asking yourself what to do; how to track the implementation level of it. Ask, get consultants onboard. Better have an external opinion for interpreation than doing guesswork.

✔️ That's it. I hope this post offers valuable insights for improving your compliance posture in the short and long term

I've incorporated these experiences into vucavoid, which features a comprehensive tool for recording and managing compliance requirements as discussed above. If you feel for it, check it here: https://vucavoid.com/documentation/requirements