top of page
  • Phil Venables

Regulatory Relationships

For some reason there have been a few people already in or moving into highly regulated industries, like finance or healthcare, that have asked for my perspective on how to manage regulatory relationships. So I thought I would put that perspective into this short post. This is built on many years in many different parts of financial services and multiple geographies but also from a lot of wider experience of working with and advising multiple other sectors too.


This is not a post about how to maintain the mechanics of regulatory compliance, or the difference between compliance and security. I cover some of that here. Also, in this post I am specifically talking about the relationship with regulators at a micro-level, specifically the relationship between the people at the regulator and the people at the regulated organization who interact regularly. This is not a post about the macro-level relationship between a whole industry, the regulatory organization and legislative bodies. That's a whole different level of discussion.


As many of you might appreciate, there is a wider approach to working within highly regulated industries where the regulations themselves are often principles based. But, even if they are prescriptive they are still open to interpretation in the context of the situation. This is always going to be so as even those prescriptions might not be able to adjust quickly enough to accommodate the rate of risk or technology change. In many cases a lot of the detailed expectations are encoded as guides for the regulatory examiners themselves rather than direct rules. For example, in US financial services there are the FFIEC IT Examination Handbooks, which are a comprehensive set of guides for regulatory examiners to use to determine the sufficiency of controls when inspecting a financial services organization. In practice, though, they are often interpreted by organizations and examiners as standards.


The bottom line here is that in every regulatory context we are ultimately dealing with a discussion between people on both sides of the regulator and regulated table. So, it eventually comes down to how this relationship is managed and made to be constructive. This is true even for lightly regulated industries as well as being applicable to relationships with auditors and other types of examiners.


Here are a few practices and attitudes I’ve seen work well over the years:


  • Remember regulatory staff generally have positive intent. Depending on your perspective and experience this may seem either obvious or a surprising statement to make. In my personal experience, however, I have generally found people at regulators to have the best interests of the overall system at heart. When you approach a regulatory relationship with that in mind, to assume positive intent - for the wider market context - then you will likely find it easier to find common ground. Regulatory staff have important jobs, they work in stretched situations with less resources and even less access to in-depth expertise to assist their mission. It may not be the highlight of your day to deal with answering their questions but it’s an important function for society. So, maybe, put yourself in their shoes a little and cut them some slack.

  • Everyone is regulated somehow. All industries are regulated even if only transitively. No matter where you are in the supply chain you will have to spend time understanding the perspectives of regulators and your deeply regulated customers. To you, in your position in the supply chain, certain requirements might not make sense or be seen as not that important. However, to your customers, their customers, or regulators overall in their context they may be crucial to maintaining a license, satisfying an examination or being able to stand behind a truly critical control.

  • Relationships matter. The interpersonal relationships and dynamics are important. Having a mutually trusting relationship with one’s regulatory staff is important. Approaching the dialog in a courteous and professional way - respectful that the those staff might not be immersed in the detail you are. Similarly, regulatory staff should be understanding of the multiple pressures and conflicting priorities on the security teams and seek to help provide clarity on expectations over time.

  • Appropriate transparency: noise vs. facts. It is important to be reasonably transparent about the risks you are facing, the incidents that have occurred, the major issues that remain unresolved. But, there’s a limit to transparency in that you don’t necessary need or want to share literally every un-curated detail of your operations. I’ve often likened this to financial audits, you typically don’t share every single transaction of every single day, rather, you share a set of books that are "closed", checked and verified. You, of course, should be open and transparent into the financial controls process that led you to be confident in the integrity of those books. If you were to share the ebb and flow of every transaction, perhaps erroneously reconciled but yet to be corrected by a later process, and many of the other daily occurrences in running inventories, ledgers and accounts you would get a very different (and unfair) picture of the true state of controls. It’s the same for other control environments. Focus on the facts not the noise. The curated outcome of a controls view can provide truthful transparency, backed by evidence of the process under which that curation occurred, without the intra-cycle noise.

  • Educate. Spend time educating regulatory staff on new risks and technologies and especially the challenges and complexities of your role and situation. They may be able to help by sharing some experiences they’ve seen at other organizations that have similar challenges. In many cases this education could actually assist in shaping perspectives for new or amended regulation. Some regulatory staff I’ve seen have become very skilled at mediating between major organizations in a sector to encourage a collective upgrade of controls across various horizontal themes as well as driving communication and collaboration to protect the integrity of the market/sector overall.

  • Establish a regulatory liaison team. While the security, risk or other leadership roles should be the main points of senior contact, it’s also important to have someone (or a team for large organizations) designated to manage the logistics of the relationship. This is to make sure meetings are prepared effectively, action items followed up on, and regulatory issues tracked to completion on time. Also, that any examinations being held have a coordinated project team to make sure artifacts or other content are delivered on time and that follow up questions are answered. In my experience, one of the main causes of regulator distrust in a regulated organization is sloppiness in the logistics of the relationship, mainly around late delivery of previously agreed actions or inattention to effective production of materials in examinations.

  • Establish and use industry coordination. In most regulated industries there are one or more trade associations that, on behalf of the regulated organizations, drive a perspective on what new regulations should look like, or comment and respond to proposed regulations. It’s also useful for there to be a different type of dialog where it is a meeting of peer professionals between the regulators and regulated organizations to discuss current topics, to look over the risk horizon, and generally build a rapport. In US financial services, the partnership between the FBIIC and the FSSCC is a good example of this, and there's a current example of SEC Chair Gary Gensler’s recent remarks to a joint session of these organizations.

  • Develop the mechanics of incident sharing (fast and slow). In many regulated industries it is required to share information about incidents. Regulatory staff are often disappointed if they’re not among the first to hear about an event in such organizations. The problem with this though is the “fog of war”. In the first hours, even days, of an incident it may be unclear what the impact or consequence is and you may want to hold off sharing until you have the full detail. This is strictly speaking the right approach as you don’t want to share inaccurate or speculative opinions about what might or might not have happened or still be happening. But there’s a way through this that I suspect many of you have already figured out. That is to do a quick posting to the regulator when you know for sure something has happened (even so, this might still take time to know). This could be verbal, from leadership or more typically from the regulatory liaison team you’ve established, informing them that you are working an issue and you will keep them posted as the situation evolves and that you will have a more formal incident analysis in the right time. In my experience this is often met with understanding.

  • Incident analysis. After an incident has closed it is often required to then do a review with the regulatory staff assigned to your organization. I would not include them in your actual post-mortem meetings that shape such reports/analysis as this would inevitably work against the psychological safety needed for a blameless post-mortem. Besides, in the incident analysis you do with regulatory staff it’s important to also discuss where regulatory imposed controls may have helped or hindered your ability to prevent, detect, respond or recover from the incident.

  • The personal relationship. A lot of this post is about people, having good inter-personal relationships and paying attention to and dealing with tension. It’s important at all the levels of the relationships between all the regulatory staff and all of your team but it is especially important with the regulator’s lead person for your organization. These are often very senior and experienced people and will likely be dedicated to overseeing your organization (or you as part of a small number of such organizations) and will rotate coverage periodically. If you’re around long enough you’ll get to build a relationship with a few of these people over time. Now, as with any relationship you need to understand the person you are going to be working with. For example, do they like meetings to be focused on data, structure, formality or do they want an open dialog and be highly conversational to surface issues - with the details left to other meetings. Getting this right is key. I’ve seen (and unfortunately got this wrong once) where a prior lead felt it was important for this dialog to be conversational and felt concerned if the meeting was too structured because that was less likely to engender the right level of trust that would be important to have a truly open discussion about risk. The next lead appointed might want total structure and be very data driven and view such a conversational approach as flimsy, or at worst obfuscating. If you don’t figure this out you’re going to be tripped up. The good news is you don’t need magical powers to divine the approach needed. You just need to ask. Either ask the prior lead, other organizations that have encountered the new person or just flat out ask the person directly in the first meeting as to how they want the meetings to work. Sometimes the obvious approach is best. Channeling your Obvious Adams can help in this and many more things.

  • Multiple regulators. In most regulated industries you will get to deal with multiple regulators. These might be split across product lines, jurisdictions or both. Reconciling the different needs, attitudes, standards and guidance from all of them can be a challenge. This is also why you need a regulatory liaison team to make sure everything is coordinated and tracked. Remember, regulatory staff among different regulators will often discuss matters with each other, appropriately so, and so you need to be consistent. By this I mean you would, of course, never be intentionally inconsistent but without some formality it is possible to be carelessly inconsistent. In many cases, it is useful to encourage joint meetings with the various regulatory staff.

  • Design for regulation. As we’ve talked about here you can approach compliance with regulations as a compliance-as-code problem. Defining and maintaining a set of control objectives to drive control implementations independent of specific regulations is vital for efficiency and effectiveness of that control set. In reality, most of your organization doesn't need to know the specifics of every regulation or regulatory interpretation. They just need to know that the control objectives are important and to implement and sustain their controls. The risk, security, compliance or other team can map the control objectives to the specific regulations and determine minimum standards for continuous control monitoring and other assurance. This is to reliably detect control failure and evidence control performance under inspection.

  • Access to leadership. Regulated organizations should, within reason, make their leadership available to meet with regulatory staff. While this may not be a choice in certain industries, it’s a common courtesy for all. It’s not only important for the relationship overall but specifically is crucial to developing mutual trust which may help shape future regulation to be more in line with what is needed, while ensuring unintended negative consequences are kept to a minimum.


Bottom line: regulation is important in many industries. Regulatory staff have a tough job to do because of resource and other constraints. Approach the relationship with regulatory staff as, well, a relationship for which it is important to develop trust and understanding. This goes both ways.

1,733 views0 comments

Recent Posts

See All

Security and Ten Laws of Technology 

There are many well known, so called, laws of technology. Moore’s law being particularly emblematic. Let’s look at some of them and see what the security implications have been for each and what might

DevOps and Security

Each year, DevOps Research and Assessment (DORA) within Google Cloud publishes the excellent State of DevOps report. The 2023 report published in Q4 was as good as ever and in particular documented so

bottom of page