How Compliance Can Be Your Biggest Business Enabler

This is the story of how a compliance requirement became one of the most strategically valuable things my team has ever done, and what I think other practitioners can take from it.

It Started With a Business Requirement, Not a Security Mandate

Most compliance initiatives I've been part of began with a risk register, a regulatory deadline, or an audit finding. This one was different. The trigger was a market expansion opportunity.

The organisation I work for was pursuing a significant new market, and the prospective partners in that region required evidence of a functioning Business Continuity Management System aligned with ISO 22301. No certification, no deal.

That framing changed everything. Suddenly, this wasn't a security team project asking for budget and cooperation from the rest of the business. It was a revenue-critical initiative with visible executive sponsorship. Governance was not the obstacle, it was the engine.

This first lesson is worth sitting with: compliance, when positioned correctly, is not just about avoiding negative outcomes. It can be a direct enabler of business growth and customer trust.

How Frameworks Build on Each Other

One of the most powerful realisations from this experience was how much existing maturity accelerated the new implementation. The organisation already held ISO 27001 certification, and that foundation proved invaluable.

What ISO 27001 had already given us:

A defined organisational scope and documented stakeholder landscape
A risk assessment methodology and risk treatment process
Structured documentation habits, internal audit routines, and a culture of continuous improvement

ISO 22301 didn't replace any of this, it expanded it. Where ISO 27001 focused on the confidentiality, integrity, and availability of information, ISO 22301 broadened the lens to resilience across all disruptions: supplier failures, operational outages, events that impact customers regardless of whether the root cause is a cyberattack or a critical system going down for entirely non-security reasons.

I think of this as a synergy cycle of compliance: each framework you implement properly makes the next one cheaper, faster, and more effective. You're not starting from zero, you're extending a system that already has governance structures, documentation habits, and a risk-aware culture embedded in it.

This synergy cycle illustrates how each framework implementation properly makes the next one cheaper, faster, and more effective.

The practical payoff was significant. By reusing our existing risk assessment methodology and extending it to cover business continuity suppliers, we avoided rebuilding processes from scratch. By leveraging our document management and internal audit practices, we didn't have to teach the organisation new habits, just new scope.

Getting to NIS2 Without Really Trying

There's a third layer to this story, and it's one that matters increasingly to organisations operating in Europe.

The NIS2 Directive, which came into force across EU member states and carries real teeth in terms of management accountability, reporting obligations, and supervisory scrutiny, has significant overlap with what a well-implemented ISO 22301 programme delivers.

Incident handling processes? Built and tested. Supply chain security assessments? Done. Business continuity and crisis management capabilities? Fully documented and exercised.

None of this was accidental. But it also wasn't planned as a NIS2 project. It was a natural outcome of doing ISO 22301 seriously.

This illustrates an important distinction that often gets lost in compliance conversations, the difference between reputation-based governance and compliance-based governance:

ISO 22301 certification is reputation-based governance. It signals maturity and reliability to partners and customers. It creates market access. It is chosen, not mandated.
NIS2 is compliance-based governance. It is mandatory, carries regulatory consequences, and places accountability directly on senior management.

The insight here is that investing in reputation-based governance, doing it properly, not as a checkbox exercise, dramatically reduces the future cost and effort of compliance-based governance. You're building real capabilities, not just documentation. And real capabilities transfer.

Where Governance Actually Gets Tested

None of this happened automatically. There were genuine challenges, and they were mostly human challenges, not technical ones.

The Business Impact Analysis

The most demanding and ultimately most valuable step was the Business Impact Analysis (BIA). This required engaging around ten to fifteen department heads across the organisation, each with their own priorities, deadlines, and varying levels of enthusiasm for a governance project.

The challenge wasn't gathering data. It was achieving alignment on what mattered most and what levels of disruption were acceptable. Different departments had different views on what counted as a critical business activity, different risk tolerances, and different assumptions about recovery expectations.

We adapted our approach significantly. Instead of sending questionnaires and waiting for responses, we ran workshops and facilitated brainstorming sessions. The process became a conversation, not an audit. And through that conversation, we arrived at something genuinely valuable: a shared organisational understanding of what we must protect and what level of disruption is actually acceptable.

From a GRC perspective, the BIA translated business priorities into explicit risk tolerance decisions. That's not a compliance artefact, that's operational intelligence.

Harmonising Incident Handling

Before the BCMS implementation, there was a conceptual and operational separation between security incidents and operational incidents. ISO 22301 doesn't recognise that distinction. An incident that disrupts a critical business service is a business continuity incident, regardless of whether the root cause is a cyberattack, a third-party outage, or a software failure.

Working towards a unified incident handling approach was, and continues to be, challenging. Processes had been built independently. Teams had their own communication channels and escalation paths. Merging them without creating confusion required careful governance design.

The outcome was worth the effort. Clearer coordination between incident response procedures and better integration of lessons learned into continuous improvement activities are the kind of governance outcomes that compound over time.

Who Decides in a Crisis?

ISO 22301 also forced the organisation to answer questions that had never been explicitly addressed. Who leads a crisis? Who steps in if that person is unavailable? Who has the authority to make a time-critical decision at 2am when normal escalation paths are asleep?

Formalising deputies, decision rights, and a responsibility matrix that ties roles to training requirements sounds like process overhead. In practice, it's the difference between a crisis response that works and one that stalls while people figure out who should be talking to whom.

Oversight That Actually Builds Culture

The final piece, and the one I think is most underappreciated in compliance frameworks, is the exercise programme.

We built a structured programme to test our business continuity plans. Tabletop discussions, disaster recovery runbook validations, and cross-functional exercises now run on a regular cadence. Each one produces evidence of gaps, which feeds back into plan updates and training.

But beyond the governance evidence, something else happened. Business continuity stopped being an IT security concern and became a shared operational responsibility. Teams started to internalise the importance of what they'd been doing in workshops. Leaders practised decision-making under pressure with incomplete information. The lessons-learned process became a habit.

That's a culture shift. And culture is what determines whether your BCMS actually works during a real disruption, not just during an audit.

What I'd Tell Anyone Starting This Journey

A few things I'd share with practitioners about to undertake something similar:

Anchor it to a business outcome from the start. Compliance projects that are positioned purely as risk reduction or regulatory obligation struggle for resources and engagement. Find the business value, the market access, the customer trust signal, the regulatory readiness, and lead with that.

Invest in your foundation first. If you haven't implemented ISO 27001, the governance infrastructure it provides will make every subsequent framework faster and cheaper. The synergy cycle is real, but only if the first framework is done properly.

Take the BIA seriously. It's the hardest part and the most tempting to shortcut. Don't. A shallow BIA produces shallow recovery targets and plans that don't reflect actual business priorities. A rigorous BIA produces organisational intelligence that is valuable far beyond the compliance project itself.

Build the exercise programme before you think you need it. Testing plans before they're needed is what builds confidence and reveals gaps in a low-stakes environment. Waiting until after certification means your first real test of the system might be an actual incident.

Document the connections between frameworks explicitly. When you complete ISO 22301, map what you've built against NIS2, DORA, or whatever your next relevant obligation is. The gap will be much smaller than you expect, and having that map saves significant time when the next project begins.

Closing Thought

The most visible success of this implementation was achieving certification within a challenging timeframe and unlocking a significant market opportunity. But the deeper success, the one that will continue to compound, was establishing the governance mechanisms, cultural habits, and documented capabilities that keep the system effective over time.

Compliance done right isn't a cost centre. It's an investment in organisational resilience that pays dividends in market access, regulatory readiness, and operational confidence.

The question worth asking isn't how do we pass the audit? It's what capabilities do we want to genuinely have, and which framework helps us build them most efficiently?

Answer that question well, and the certificate follows naturally.