How to set up a first line of defense & governance function – Part 2

In Part 1, I shared my thoughts on the three lines of defense model and listed key prerequisites for building an exceptional first line of defense function. I highlighted executive commitment and hiring the right resources as building blocks and shared ideas with regards to some techniques I use for interviewing candidates for the first line.

Part 2 focuses on specific actions I recommend for setting up a first line of defense function. As I mentioned earlier, a lot of these ideas could be leveraged to build and improve all three lines.

1. Create Your Roadmap:

Everyone in the company is excited about what was promised to them: An exceptional first line of defense function.

Your budget to build your function is approved. You hired a few new resources from the industry and convinced some good fellows to come over from other departments and join your team.

Life is good, but now what…

If “going with the flow” sounds like a good approach, think again. One of the key components of effective governance is knowing and articulating where you are going. At the risk of sounding like a consultant (heck – I used to be one), you should develop a roadmap and a timeline. 

I like roadmaps because they serve as a good communication tool for your team, executives or anybody interested in understanding how you’re building your function. A roadmap will show everyone else the progress you’re making. Also, it will help you course-correct faster if things are not going so well.

Your entire roadmap may span multiple years. 

A good roadmap should include interim milestones which, when achieved, will give everyone hope that things are on track. Life is too short not to celebrate our achievements – no matter how small they may be. 

2. Choose & Define Your Governance Framework:

I am a fan of frameworks.

A framework gives you the structure with which you can build your processes. It also gives a venue to define and articulate your scope of coverage. 

Best-practice frameworks such as COSO and COBIT 5.0 will help you think through what needs to be included and excluded in the scope of your function and roadmap. They will also make your life much easier when you communicate with external parties such as your regulators because most of them will already be familiar with most of them.

The framework I particularly prefer for IT Governance is the one from ISACA’s IT Governance Institute (ITGI), which can be used in conjunction with COBIT 5.0 - also from ISACA: 

A word of caution. A framework is as good as what you make of it. Adopting an entire framework as is could prove to be too big an undertaking for many companies. You should only use the parts that make sense to your organization and consider customizing it to fit your particular needs.

Finally, you may want to use a combination of frameworks to address different processes (ITIL for IT Service Management; PMBOK for project management; NIST 800-53 for information security etc.). 

3. Document, document & document (really):

Let me first catch you up on a couple of my definitions:

When I refer to documents, I’m talking about policies, procedures, standards, frameworks etc. Your own definition or scope could be different.

In layman’s terms, controls are the activities performed by people or systems to address risks. For example, looking both ways when crossing the street is a control that could save your life.

Over the course of my career, I advised and audited companies ranging from small pre-IPO start-ups to Fortune 10 giants. Regardless of the size or complexity of the organization, all of them benefited from formalization around their documents and controls (many times at my urging). The bigger the company, the more obvious the need around documentation.

How about smaller companies such as start-ups?

For starters, things happen and people leave. An IT director of a former client (small high-tech company) once told me that his team did not know how to properly maintain and upgrade an in-house developed software because the engineer (let’s call him Jim) who coded it had left the company. 

You guessed it – Jim did not bother documenting how the software worked, nor was he ever asked to. Jim was also not the only one not documenting stuff. Documentation was not part of the company culture which was all about going fast to the market and getting ready for an IPO.

Remember every organization will likely have to face an audit or go through regulatory scrutiny at some point of its journey. 

You  would like to start collecting credit card payments; then you need to think about compliance with PCI. You would like to serve European consumers; you’d better be ready for rigid European privacy regulations (does GDPR ring a bell?). You want to do business with government; you may need to start reading about FISMA.

A common theme about any regulatory requirement is that they all will require you to have documentation. If you have good documentation, you’ll be one step ahead in meeting those requirements and passing your audits.

To get ahead of these challenges, you may want to consider creating a formal program around documents. At the very least, having your key processes documented in written policies/ procedures/ standards will make your organization less dependent on individuals performing those tasks. If you also assign a formal documents program owner providing regular guidance and oversight, you would be in a great shape. 

Many public companies only limit their control libraries to SOX 404 controls, but my recommendation is to create a library that goes beyond the basic regulatory requirements. Creating an expanded control library will help you document control ownership and many other key attributes for additional areas of your business. It will also give you the means to spot-check or self-test those controls and remediate issues early. 

4. Perform Self-testing & Self-Assessments:

One of my current roles is to interact as the main IT point of contact with our IT regulators who perform periodic examinations of how we use and implement technology services and processes. In an “IT Exam”, regulators check the bank’s compliance against the Federal Financial Institutions Examination Council (FFIEC) Guidelines and other relevant regulations. The exam results in a long write-up accompanied by a report card telling us how we did.   

If you’ve been through one of those examinations, consider yourself lucky (seriously), because it is a great learning experience.

Many years of going through the “exams” has taught me that regulators’ interpretation of the three lines of defense model is much stricter than that of most organizations.

Here is a sample question you would dread answering: “We heard that your Internal Audit group (third line) has identified some issues. Can you please tell us why you (first line) had not found them before Internal Audit?”

There is really no good answer to this question at that point. Even if the answer is that you actually knew about the same issues sooner, the next question you will hear will be “Why haven’t you fixed it before Internal Audit came in?”  

Here is where regulators are coming from. They want the company to have good processes so that the issues surface much closer to the first line of defense who is responsible for operating the controls. 

A good first line should find and fix most meaty problems and fix them as quickly as possible. Self-testing of your controls (now that you have a control library) and self-assessments (risk or process maturity assessments) performed by the first line of defense will come handy in that quest. 

If you’re doing all the above, you deserve a pat on the back. There is always more you could do, but you should feel proud to have already built many key elements of an exceptional first line of defense function.