Let’s address the elephant in the room, when it comes to compliance there are about 50 Shades of compliance: regulatory, laws, contractual (client, business partners), framework…
Let’s illustrates with three example: financial institutions (bank, insurance and associated entities) laws, cyber insurance contract requirements and PCIDSS regulated entities. While we will explore these 3 aforementioned examples there are plethora others think about Intellectual Property/software licences compliance or customs compliance (pretty common one for logistics/transport/shippment/export/agrofood/FMCG industries while quite rare elsewhere) for instance, I mentioned 50 Shades did I not?
- Financial institutions laws compliance: Banking/finance as a whole is one of the most regulated industry I had the opportunity to work with (think about for instance: SOX/BASEL/SOLVENCY II, SWIFT, EU DORA…). This is for goods reasons: on the one hand finance and especially banking is a business tremendously relying on (consumer) trust and on the other hand finance manage ridiculously huge amount of money and unfortunately corruption is always closely following money… You simply cannot call your business a bank let alone running financial operations without an horrific amont of compliance (paper) work, the size of your organization will not really matter in this regards (hello fintech startups 👋). This work will involve a whole control mechanisms (this will definitely be the subject of a dedicated article because working for a financial institutions or not there is good within these processes and most technical infosec professional who never worked with finance might miss a significant part of what their organization might soundly expect them to perform) ensuring you are able to demonstrate your compliance at any point in time, if not your regulator would revoke your banking/finance agreement and you will have to close this part of your business. Having understood that it is not an under statement to outline that compliance is of paramount important for financial institutions they might even refer to it as a “buy-in” ticket into financial world.
- Cyber insurance requirements compliance: with this one we switch from law compliance to contractual compliance. Should your organization holds an infosec insurance contract it will involve at minimum: annual fees, annual renewal audit, guarantees limitations that might be conditioned by infosec requirements*.
* Common conditions include that your guarantee would be halve by every month of patching delay. Considering the cost of such policies it might be best to avoid being the one announcing your CEO that the security incident/fraud/intrusion was possible due to 36 months old vuln which are not as uncommon on real life production environments (hello business critical legacy ICS 👋👋).
- PCIDSS compliance: let’s wrap this introduction with a third example sort of combining the other. PCIDSS is a framework aiming at securing credit/debit card transactions. Similarly to cyber insurance we are talking about contractual compliance here. As an organisation operating payment you must have a relationship to a banking agent. It is this partner that might (depending on your transactions volumes hence the magnitude of the risk they take accepting your business) bring PCIDSS compliance to the table. It will most likely come as a commercial discussions. Should you be able to demonstrate your PCIDSS compliance you will get a discounted commission per transaction. Trust me on this one, having assisted organisation processing billions of transactions per year (think about ecommerce website upon black friday week and your might get vertigo…) I can ensure you that even 1 cent might mean live or death of your business… As such it is not de jure a buy-in ticket (as opposed to banking laws) but it looks a lot like a de facto buy-in ticket…
Following this rather lengthy introduction let’s get back to the main question this article aims at answering shall we? So what comes first? Infosec or compliance? A simple rule of thumb might be that it all comes down to two stuff: the vertical your organisation operates into and your organisations’ maturity.
- Should your vertical impose regulatory compliance as a buy-in ticket then it will most likely always come first (remember what we mentioned in introduction regarding financial institution? You might think about aiports, oil/energy industries as well, etc.)
- If not, it will depends on your organisation infosec maturity. Why? Because compliance is always a target to reach (or at the very least to aim at), it might even be your infosec program starting point in the beginning of your organisation journey (remember the cyber insurance example? It used to be the main driver of my current organisation’s program). However it might not suffice to cover your actual infosec stakes / business needs. Even worst, it might prove challenging to steer your program solely based on compliance. For instance should you be targeting ISO27k how would you seamlessly integrates PCIDSS compliance should your business suddenly requires it? In my now bygone consultancy days I see this situation times and times again… It’s never easy, almost every single time involve lots of headaches especially if you do not rely on ad-hoc GRC tools to assist in frameworks mapping.
Furthermore, as Gartner’s analyst Bart Willemsen puts it “Regulations won’t matter to threat actors and rogue states” what essentially means that regulation, despite being important, involves lots of legal discussion hence articulates a long term views whereas malicious actors are quick to evolve. As such should the sole aim of your infosec program be reaching/maintaining compliance it will simply not be enough on the long run. This is why I would propose that you might initiate your program with compliance as a starting goal but you might have at some point to evolve into infosec being the driver achieving compliance and not the other way around.
To summarize it all comes down to the proper consultant maxim: it depends (remember the egg or the chicken? Same situation here).
Two things are for certain, first: framework to comply to/policy makers are getting better at grasping infosec concepts as time progress (think about Basel II vs DORA for example), second: as an infosec profession it is necessary to nurture relationships within your organization with legal/compliance teams. Relationship might be an interesting topic to address in a future article 😉
Leave a Reply