Cracking the Code:

The Challenge: A Fragmented Cybersecurity Landscape

Look at the global cybersecurity regulatory landscape, and it’s easy to feel overwhelmed. While well-intentioned, the proliferation of cybersecurity standards and regulations emanating from Governments, regulators, and industry bodies have left compliance teams scrambling to keep up — often at great expense. This patchwork of frameworks presents several challenges:

1. Conflicting Perspectives and Focus Areas

Standards and regulations vary widely in their emphasis. Some prioritise operational resilience, like the EU’s DORA, NIS2, and the upcoming UK Cyber Security and Resilience Act. Others, such as ISO 27001 or NIST CSF v2, come from a more holistic perspective. Then, there are industry-specific standards like PCI/DSS, with a narrower focus on technical controls. While they all feature proven cybersecurity principles at their core, they all bring their own slightly different perspective, often resulting in duplicated compliance efforts.

2. Jurisdictional Complexity

Some regions have introduced multiple overlapping frameworks. In Saudi Arabia, for instance, organisations may need to comply with the NCA Essential Cybersecurity Controls (and its many offshoots — TCC, OTCC, OMSACC, etc.), SAMA’s Cybersecurity Framework, CMA’s Cybersecurity Guidelines, the PDPL.. and several others — each with different compliance expectations.

3. Terminology and Structure Differences

Standards can differ in structure, wording, and even intent. Some refer to one control from within another, making it hard to interpret individual requirements in isolation. Others are vague. Take ID.AM.07 of the NIST CSF (v.2) as an example: “Inventories of data and corresponding metadata for designated data types are maintained”. Only once you take a look at the related implementation examples do you realise that this is where a fundamental discipline – information classification – is buried. The control is anything but clear.

Some controls are direct and practical (e.g. “conduct penetration testing every six months”), while others are ambiguous or inconsistent, leading to varied interpretations – even within the same framework.

These documents are, after all, produced by humans, often via some form of committee process. Sometimes this is evident in the result. Just as there are “Friday afternoon” cars, we’ve encountered “Friday afternoon” standards.

4. Diverse Approaches to Audit and Enforcement

In Europe, regulators tend to take a pragmatic, qualitative approach to regulatory conformance. Legislation such as the EU’s DORA even formalises this flexibility, requiring that a risk-based approach be taken in scoping how compliance should be achieved (see Article 4: The Proportionality Principle). What matters here is that you apply a structured approach, can justify your decisions and can provide documented evidence the process you followed was thorough and had inherent integrity.

Elsewhere, especially in regions with newer or stricter enforcement practices, regulatory compliance can be more literal, particularly where the person doing the auditing is less seasoned. This can result in anomalous outcomes. More so where the control being assessed is itself ambiguous. Take the following example:

“Re-classify data to the least level possible to achieve the service objective before sharing it with third parties using data masking or scrambling techniques.”

If you were to implement this control as written, you’d potentially end up downgrading data classification (and it’s potential level of protection) merely to meet the need for the data to be shared – which I’m sure isn’t the underlying intent. For a less experienced auditor who is not confident in probing the real substance of the control, this could prove to be problematic.

The Case for Harmonised Control Frameworks

Given the challenges, it’s no surprise that many organisations are adopting harmonised cyber security control frameworks to help cut through the complexity of compliance.

When they work well, harmonised control frameworks:

• Eliminate duplication
• Improve clarity
• Increase efficiency
• Support clear control ownership and control assurance
• Simplify regulatory alignment

Sounds ideal, right? Well yes, the principle is sound. However, creating an effective harmonised control library isn’t simply a matter of combining all the requirements from multiple frameworks into one place. A genuinely practical harmonised framework must still account for regional nuances, regulatory quirks, and your organisation’s risk profile.

And that’s where things can get complex.

Getting Started: Questions You Must Answer

Before adopting a harmonised control framework, it is important that you define your objectives and identify any constraints. Start by answering these three questions:

Q1. Is your goal to achieve broad conformity or strict compliance?

This will determine the size and complexity of your framework.

• If your aim is to demonstrate conformity with standards like ISO 27001, NIST CSF, DORA and NIS2, you might manage with a core set of ~200 well-written controls.
• If you need to support detailed, line-by-line compliance – especially in regions with stricter enforcement (e.g., the Middle East) – your framework may need to scale to 600+ controls.

At CRMG, we’ve built both types. Our ‘conformity-focused’ library includes:

• Clear, action-oriented controls
• Mappings to major standards
• Suggested evidence for audits
• Maturity questions for each control.

This approach works well in most regions. But for stricter regulatory environments, we’ve developed more granular frameworks that align precisely with local expectations – especially in Saudi Arabia, where a strict (more literal) approach to regulatory compliance is applied.

Regardless of the approach you take, your control framework should:

• Use direct, imperative language
• Avoid cross-references (each control should standalone)
• Reflect opportunities to merge multiple tightly aligned controls into one
• Split complex, multi-part controls into separate traceable controls.

Q2. If compliance is your priority, which standard matters most?

When compliance is key, it’s helpful to triage your requirements into tiers.

• Tier 1: Your most critical regulatory requirement — e.g., NCA ECC in Saudi
• Tier 2/3: Other relevant standards where broad alignment is sufficient

Knowing your Tier 1 requirement helps streamline your framework and prevents over-engineering controls that aren’t mission-critical.

Q3. How are your audit and compliance teams structured?

Smaller organisations may prefer to group controls together to reflect a simpler approach to implementation. Larger or more decentralised teams may require granular controls with distinct owners and implementation paths.

Either way, a centralised approach to managing GRC is likely to be important. Spreadsheets alone often don’t scale effectively. That’s why we work flexibly — partnering with platform providers such as Diligent, and others in the UAE and beyond, to embed CRMG’s harmonised control libraries into their systems. We also support organisations who prefer to manage their control frameworks independently, enabling tagging, filtering, attestation, and reporting in a way that fits their needs.

Making It Work: The Joy of Tagging

Once your harmonised framework is in place, tagging becomes your secret weapon. Smart tagging transforms a control library into a living compliance tool.

Here’s how tagging can help:

• Source Standards
  Tag each control with its source(s) — ISO, NIST, ECC, etc. — to maintain traceability and keep auditors happy.
• Environment Type
  Does a control apply to all environments, critical systems, or a specific function (e.g. remote workers or the social media team)?
• Frequency
  How often does a control need to be applied or reviewed? (quarterly pen tests, monthly privileged access reviews, etc.) Tagging by frequency supports scheduling activities.
• Territorial Restrictions
  Some regulators apply strict territory-related restrictions, such as national CISOs or in-country data hosting. Tag these as non-negotiables.
• Risk Assessment Requirements
  Identify controls that trigger risk assessments — e.g., at the outset of new technology projects or before remote access to a new system is allowed.
• Information Classification
  Specific controls may only apply to ‘highly confidential’ or ‘top secret’ data. Tag accordingly to align with your information classification scheme.
• Control Ownership
  Clarify who owns each control (e.g. the relevant business owner) and who is responsible for its implementation via RACI tagging.

This level of filtering and categorisation allows you to assign ownership, monitor compliance and prepare for audits with far greater ease.