Best Practices for Achieving Cyber Resilience Act (CRA) Compliance

Businesses face mounting pressures to safeguard their operations against the growing tide of cyber threats. Compliance with regulations such as the EU Cyber Resilience Act (CRA) is no longer just a legal necessity but a cornerstone of robust business continuity.

Defining Cyber Resilience under the CRA

Cyber resilience under the CRA goes beyond traditional cyber security. It encompasses an organisation’s ability to prepare for, withstand, recover from, and adapt to adverse cyber events. At its core, the CRA aims to ensure that businesses can defend against attacks, maintain critical functions during disruptions and recover swiftly.

 

Key Principles:

  1. Proactive risk management: Organisations must identify and mitigate vulnerabilities before they can be exploited.
  2. Secure product development: Ensuring cyber security is embedded throughout the product lifecycle.
  3. Incident readiness: Establishing protocols for swift detection, containment, and recovery from cyber incidents.
  4. Accountability: Clear documentation and demonstration of compliance efforts to regulatory bodies.

By adopting these principles, businesses can create a culture of resilience that satisfies regulatory demands and builds trust with stakeholders.

Ryan Hides, Senior Consultant at CRMG, notes: “CRA compliance is not just a tick-box exercise. It’s about embedding resilience into your organisation’s DNA, ensuring you can weather the storm and emerge stronger.”

 

Implementing Secure Development Lifecycles (SDLCs)

The CRA places significant emphasis on the security of software and systems, mandating organisations to integrate cyber security considerations into their development processes. A Secure Development Lifecycle (SDLC) is essential for achieving this.

 

Steps to Implement SDLC:

  1. Implement secure development practices, version control, and quality management measures into all system development processes, including agile iterations. Ensure the use of code management, secure coding techniques, and iterative code reviews.
  2. Create a set of Project Initiation Documents (PID) for each development project, addressing essential project management elements such as scope, costs, timelines, quality, benefits, project risks, and acceptance criteria. Support each project with a documented set of project plans, based on approved functional and non-functional business requirements, including information security.
  3. Adhere to a stringent process for releasing and deploying new or updated systems and applications to the production environment. Ensure they undergo thorough testing, including security checks, and meet strict acceptance criteria.

“A robust SDLC doesn’t just enhance security; it also improves the overall quality and reliability of software. This dual benefit is invaluable in today’s digital economy.”

Simon Rycroft, Co-Founder CRMG

 

Risk Management Strategies for CRA Compliance

Effective risk management is a cornerstone of cyber resilience and a critical requirement under the CRA. Organisations must adopt structured methodologies to identify, assess, and mitigate risks.

Best Practices:

  1. Conduct regular evaluations to identify vulnerabilities, threat actors, and potential impact.
  2. Use frameworks like NIST or ISO 27001 to prioritise risks based on likelihood and severity.
  3. Assess and monitor the security posture of suppliers and partners to minimise supply chain risks.
  4. Develop and implement detailed plans to address identified risks, including technical controls and organisational measures.
  5. Leverage tools and dashboards to maintain real-time visibility into your risk landscape.

By adopting a risk-based approach, organisations can allocate resources effectively and ensure that their security investments yield maximum impact.

 

Integrating Continuous Security Testing and Incident Response Protocols

In the face of evolving cyber threats, continuous security testing and well-defined incident response protocols are indispensable for maintaining resilience. These measures fortify defences and enable organisations to respond effectively when incidents occur.

 

Continuous Security Testing:

Rigorous security testing must be performed on a regular basis on critical target environments, including both systems under development and live systems. Testing the security of these environments must include determining the effectiveness of security controls, performing specific attack tests to identify weaknesses, using test data, resolving identified security weaknesses, threat intelligence, and root cause analysis of security incidents.

The use of reputable sources for common security-related software weaknesses, such as the OWASP Top 10 Web Application Security Risks, SANS/CWE Top 25 Programming Errors & MITRE ATT@CK Framework is highly recommended.

 

Incident Response Protocols:

Develop an information security incident management framework that encompasses a documented process, specialised personnel or teams, relevant information, and tools. Consistently identify, respond to, recover from, and follow up on information security incidents.

The forensic investigation of information security incidents or events is important to identify perpetrators and preserve evidence. It is essential to be prompt and effective in testing, reviewing, and applying emergency fixes to business applications, systems, networks, and endpoint devices.

 

Meet Our Leadership Team.

At CRMG, our senior leadership team brings a rich history and deep expertise in cyber security. Spearheaded by consultants who are influential figures in the industry, our leaders are highly networked and well-established, with backgrounds in the ‘Big- Four’ firms.

LEARN MORE

Simon Rycroft

CO-FOUNDER AND CEO

Former Head of Consulting at the ISF. On a journey to bring accessible risk management to growing enterprises.

Nick Frost

CO-FOUNDER AND CHIEF PRODUCT OFFICER

Former Group Head of Information Risk, PwC. Motivated by the need to implement cyber risk principles for the real world!

Dan Rycroft

DELIVERY DIRECTOR

Former Head of Delivery, Cyber Security at DXC. Delivers risk-based cyber security programmes with maximum efficiency.

Matt Brett

DELIVERY LEAD – CYBER RISK SOLUTIONS

Former Portfolio Director, Tech Security & Risk, GSK. Specialises in implementing efficient, pragmatic cyber risk solutions.

Martin Tully

DELIVERY LEAD – GOVERNANCE AND COMPLIANCE

Twenty years’ experience in delivering fit-for-purpose cyber governance initiatives.

Louis Head

CONSULTANT – GOVERNANCE AND COMPLIANCE

An expert in everything ISMS-related, and how compliance works in practice.

Guy Asch

COMMERCIAL DIRECTOR

A seasoned Commercial Director, driving P&L business leadership through innovative strategies.

Ryan Hides

DELIVERY LEAD – THIRD PARTY RISK MANAGEMENT

Project Management and Six Sigma expertise. Specialises in turning effective third party risk management into a scalable reality.

Sarrah Ahmed

HEAD OF MARKETING

Bringing over 17+ years of marketing expertise, passionate about crafting innovative marketing campaigns.

Cracking the Code:

Understanding Harmonised Cyber Security Control Frameworks

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 has 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 that 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 its 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, for example, the nationality of the CISO or in-country cloud data hosting requirements. 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.

Understanding the Proportionality Principle in DORA:

A Balancing Act for Financial Entities

If you’re familiar with the EU Digital Operational Resilience Act (DORA), you’ll know it is framed in prescriptive language. However, within its detailed mandates, it also includes principles like this:

“Financial entities shall use and maintain updated ICT systems, protocols, and tools that are appropriate to the magnitude of operations supporting the conduct of their activities, by the proportionality principle as referred to in Article 4.”

In essence, Article 4 instructs financial entities to implement DORA’s requirements in a way that takes into account their size, overall risk profile, scale, and the type of services and operations they conduct. That’s a lot of subjectivity to work with.

This isn’t new for those well-versed in cyber security risk management. We’ve been using risk profiling to shape our security programmes for years. The term criticality is second nature to us. We’ve developed methodologies to quantify business impact and are accustomed to the language of threats, vulnerabilities, and controls, ensuring that security measures are proportionate to the risks we calculate.

Applying the Right Level of Resources

One key challenge for organisations is understanding how much resource allocation is required to meet DORA’s requirements. Some organisations may assume they need to dedicate extensive resources to compliance when, under the proportionality principle, they may fall into a category that demands a more measured approach. The thresholds outlined in DORA ensure that smaller or less complex organisations are not overburdened but instead apply a level of security and resilience appropriate to their specific risk landscape.

Conversely, organisations must also avoid underestimating their obligations. While proportionality provides flexibility, it does not mean minimal compliance. Each entity must carefully assess its position within the regulatory framework and ensure that its resource allocation is justified, efficient, and aligned with its true risk exposure.

For Mature Governance and Risk Functions

The subjectivity in DORA’s proportionality principle should be manageable for financial entities with well-established governance and risk management approaches. Many larger organisations already have the methodologies in place to assess risks in a structured manner – and to implement controls that are aligned with their risk profiles. These organisations will naturally integrate DORA’s requirements into their risk frameworks without much friction.

For Less Mature Organisations: No Easy Escape

However, for less experienced organisations or those without robust risk governance structures, the proportionality principle might seem like a loophole for a ‘light-touch’ approach. Some may attempt to use Article 4 as a justification for minimal compliance, arguing that they are tailoring their strategy according to their size and risk profile. In the long run, this approach won’t hold up under scrutiny.

Why? Because any decisions made under the proportionality principle (Article 4) will require backing up with sound logic and evidence. And to provide that evidence, organisations must:

  • Conduct thorough risk assessments
  • Apply reasoned judgment about security decisions
  • Develop clear documentation detailing exactly how they arrived at their conclusions.

Without these elements, regulatory bodies will likely challenge whether an organisation genuinely applies DORA’s proportionality principle in good faith.

Best Endeavours vs. Reasonable Endeavours

A helpful way to think about DORA compliance is in terms of best endeavours versus reasonable endeavours, a concept often seen in legal compliance. Regulators won’t necessarily expect perfection, but they will expect an organisation to demonstrate that it has taken its obligations seriously. This means that even if some aspects of an organisation’s approach are later deemed to be flawed, they must show that they acted with diligence, applied the right level of resources based on their risk environment, and made informed decisions throughout the process.

Failing to provide evidence of effort and structured thinking will make it challenging to claim proportionality as a defence in the event of an audit. Organisations must ensure they can substantiate their decision-making processes, proving that they acted in good faith and aligned their approach to the risk profile they determined.

The Opportunity within DORA

DORA is more than just another regulatory requirement—it represents a real opportunity. If approached correctly, it can act as a catalyst for significant improvements in:

  • Operational resilience
  • Cyber security and risk governance
  • Risk management effectiveness
  • An organisation’s ability to withstand external scrutiny.

When treated with care and respect, the proportionality principle allows organisations to implement DORA efficiently and in accordance with their unique risk landscape. However, it should never be misinterpreted as an excuse to do the bare minimum.

Different Approaches for Different Organisations

How an organisation reacts to DORA will depend heavily on its nature and business model. Large multinational financial entities with complex infrastructures will inevitably need a more rigorous and layered approach than smaller, more niche firms. However, regardless of size, the fundamental expectation remains the same:

Assess criticality and risk. Document your decisions. Be prepared to justify them.

The proportionality principle within DORA offers flexibility, but with flexibility comes responsibility. Organisations that properly leverage this principle will find themselves in a stronger position—not just for compliance but overall operational resilience. Conversely, those who see it as an easy way out may face increased regulatory scrutiny.

DORA challenges financial entities to prove they have taken a structured, risk-based approach to ICT and cyber security resilience. Whether you are a large or small entity, you must navigate the subjectivity of proportionality with diligence, thus ensuring that your security measures are appropriate, evidence-based, and defensible in the face of evolving threats and regulatory oversight.