Cybersecurity audit: balancing risks and applicable requirements

A long-standing and legitimate debate

The arguments are sound. Cybersecurity is too vast a field to be the subject of a credible overall opinion in a single assignment. It encompasses a multitude of controls whose failure would have only a marginal effect on the organisation's objectives. Above all, a technical weakness can be offset by other controls, manual or automated, located elsewhere in the processes: evaluating IT risk in isolation therefore leads to an overestimation of actual exposure.

What the IIA framework actually requires

On 5 February 2025, the Institute of Internal Auditors (IIA) published its thematic framework on cybersecurity (Cybersecurity Specific Requirements), which came into force on 5 February 2026. It sets out a minimum framework for assessment covering three areas: governance, risk management and control activities relating to cybersecurity.

Three characteristics are worth noting, as they are often misunderstood:

• It is compulsory for assurance engagements of functions conforming to the Global Internal Audit Standards, and recommended for consulting engagements.
• It applies at mission level, not at plan level. It is triggered when the subject of an engagement is included in the audit plan, when a cyber risk is identified during the engagement, or when a request is made for an unplanned engagement.
• He accepts the exclusions, provided they are documented. Each requirement must be assessed for applicability; where a requirement is excluded, the justification must be documented and retained.

An important point regarding quality assessments: compliance with the current thematic standards is assessed during evaluations carried out after their effective date.

Why this contrast is partly misleading

Presenting the issue as a choice — a risk-based approach or referential — does not withstand a reading of the text. The referential does not dictate the content of the audit plan: it does not compel a function to include a cyber assignment, nor to rule on the entire domain. It defines what must be covered when'one of the tasks relates to cyber risk.

In other words, the selection of assignments continues to be guided by the most significant risks to the organisation. It is the conduct of the assignment that is regulated. The two approaches operate at different levels and complement one another: the risk-based approach determines what is audited, the structural framework How do you audit it?.

Indeed, the framework aligns with the concerns of proponents of the risk-based approach on one key point: it requires an assessment of whether the organisation’s risk assessment processes take cyber threats into account and their impact on the achievement of strategic objectives. This requirement specifically prohibits a siloed reading.

What the European framework brings to Luxembourg

For regulated financial sector entities, a third constraint applies — and it is non-negotiable. Regulation (EU) 2022/2554, known as DORA (Digital Operational Resilience Act), applicable since 17 January 2025, imposes an IT risk management framework overseen by the management body, a register of agreements with IT service providers, enhanced contractual requirements and a resilience testing programme. The Commission de Surveillance du Secteur Financier (CSSF) ensures its monitoring.

These obligations exist irrespective of any risk-based assessment: a regulated entity cannot decide that the matter does not warrant attention. On the other hand, the depth and the priority audit work on these devices is indeed a matter of risk-based judgement.

Bringing the three approaches together in practice

• Start from the business risks. Identify IT failures capable of genuinely affecting the organisation's objectives, taking into account compensating controls existing elsewhere in the processes.
• Query the management risk assessment first. If this measures IT asset exposure without linking it to business objectives, that in itself is a finding to bring to the attention of management and the audit committee.
• Align the missions with the framework. As soon as a mission involves cyber risk, roll out the applicability assessment for each requirement — and document any exclusions.
• Treat DORA as a baseline, not a variable. Registers, contracts, governance and testing must be covered; their frequency and depth are adjusted according to the risk.
• Widen the scope when necessary. A mission involving a cyber risk often leads to the examination of downstream business controls: it is better to acknowledge this in the scoping phase than to discover it along the way.

Common pitfalls

• Treat the repository as a checklist to be run through entirely, without evaluating applicability — the opposite of its intended spirit.
• Use the risk-based approach to bypass applicable requirements without documenting the justification.
• Aiming for a global opinion on «cybersecurity», when the field is too vast for credible assurance in a single assignment.
• Relying solely on the IT provider's technical framework, which measures asset exposure rather than the achievement of objectives.
• Neglecting the documentation of design decisions, reviewed during external quality assessments.

The ARCAD approach

ARCAD conducts IT and DORA audits based on the organisation's business risks, framed by applicable requirements and documented for quality assessment purposes. Our starting point is the entity's actual exposure — not a generic technical control checklist applied indiscriminately.