Business assurance, components

This post is an exercise to map some of the main components of the assurance side of a company. The maps are out of context but it would apply to major business companies.

The main map

When we talk about quality assurance, internal audits, cybersecurity, regulations, and we forget about the purpose, the users and their needs.

So this map is focused on the main overall reasons because companies put in place all these processes, people and tools.

So, let’s start with the purpose of business assurance: protect your company.

Then, let’s see the users. Well, here there are so many type of users:

Now, let’s go to the main map:

It’s important to remind that some actions, from any of the identified users can launch a trigger that provokes an undesired effect that exploits a negative consequence for the company.

I have drawn the main components as pipelines, and there it fit so many other components concrete to each company.

At the bottom of the map we have the company capabilities (a pipeline again): Information Operations.

Business Operations / Business Assurance

If you work on a big company you probable have an unit called Business Operations, business assurance, information operations, or any other similar name.

The work done by these guys has evolved during the last 20 years (that is the personal view I have). For instance, cybersecurity was not a key element when I started to work in 2000, but now it’s one of the more visible ones.

Anyway, let’s see the map:

First, I have highlighted under a circle some main components that should be managed and lead by the executives in charge. They are all related to the protection of the company in some way, and the right integration of them enable efficiency and common approach in front of the CEO.

In the market there are so many tools under the name of “GRC” and they already include all these concepts. They now include “security” but in the past “security” was a secondary priority. So some valid questions would be:

• What is the next thing companies need to be protected?
• What is the next component that should be included in “Business Assurance”?

Below I have added a bunch of components that I think they are common in any industry. Please note that to draw a map without a specific context is very difficult, so consider that these components, their value, their maturity are completely different in any company.

Some brainstorming ideas

The following pictures are brainstorming ideas, they are not maps as there is no anchor. Hopefully they will be useful some day. They are all at Level 2 from the main map.

Business Assurance, Enterprise Risk Management (L2)

Business Assurance, Security Engineering (L2)

How to approach all these needs?

The implementation of compliance changes is mainly done on software that support processes of execution of the business. At this point, there are so many ways to implement these changes.

Below, some of my thoughts when I have worked on this type of initiatives.

First, you need a good catalog of assets and understand where each relevant process is executed. Then you have to understand with the stream teams how the data is being organized and how it can be used by compliance.

Second, you have to assign budget to these initiatives. The old style of adding compliance work on top of the business plate the teams have to digest provokes so many negative consequences. The facilitation of the execution of this work, anticipating it as much as possible, assigning budget and other resources is a better way to approach it.

Third, communicate how the requested job is linked to your company. Go through the linked business components and determine the consequences for the company of not having it done or deliver inaccurate information.

Fourth, leadership has to be engaged and pay attention. People do not have problems to recognize the importance of the things, but a day full of things to do provokes that individuals make decisions about what to attend. Here the maturity of the organization and its leaders is important.

Fifth, the use of enabling teams (as per Team Topologies convention) is one way to interact with the different stream teams and enable a quick construction of the requirements while you interrupt the business speed of creation as less as possible.

Sixth, compliance requirements create boundaries when they are implemented on the IT systems. When a requirement is defined you have to analyze the approach you are using to implement the required changes on systems and what boundaries create on them. The generation of IT debt on these implementations is very common: you start attending a small requirement that becomes huge and the initial approach has to be discarded and replaced by other one.

Any question or feedback is welcomed!