The IIA’s Cybersecurity Topical Requirement became effective on 5 February 2026. Half a year has passed. For internal audit functions working with small teams and no dedicated IT audit specialist, a situation many practitioners here will recognise, this is a good moment to ask a plain question: what does conformance actually look like in practice?
The answer is more manageable than the phrase “mandatory requirement” suggests. But it does require you to do something, and doing nothing is the one option that is now closed.
What the requirement is — and what it is not
There is a common misreading worth clearing up first.
The Cybersecurity Topical Requirement does not oblige you to perform a cybersecurity audit. It does not add a mandatory engagement to your audit plan. What it does is set a minimum baseline for how the work is done if and when cybersecurity falls within the scope of an assurance engagement.
Topical Requirements are a mandatory component of the IIA’s International Professional Practices Framework. They sit alongside the Global Internal Audit Standards rather than within them, a distinction worth holding onto, because the two are often blurred in commentary. The Standards govern how you run and manage the internal audit function. A Topical Requirement tells you what a competent assessment of a specific high-risk topic must cover.
The requirement itself is built around three pillars: governance, risk management, and controls. As Grant Thornton’s summary sets out, the governance pillar reaches the organisation’s cybersecurity strategy, board-level reporting, policies, and how roles and responsibilities are assigned. Risk management and controls follow the same logic, a defined minimum, rather than a checklist that replaces professional judgement.
The IIA states plainly that Topical Requirements are mandatory for assurance services and recommended but not required for advisory services, and that conformance is evaluated during quality assessments conducted after the effective date.
The part that catches people out
Here is the provision that has the widest reach, and it applies even to functions that never audit cybersecurity at all.
The IIA’s questions and answers document is explicit: evidence that each requirement was assessed for applicability must be documented. If your engagement touches systems, data, or access, and you conclude that a particular requirement does not apply, that conclusion has to be recorded with a rationale.
The absence of cyber work in your file is not, by itself, an indefensible position. The absence of a documented assessment is the gap.
This is where most small functions will find their exposure. Not in failing to run a sophisticated cyber audit, but in having no record of having considered the question.
What this means for a small function
The concern we hear most often locally is capacity: we do not have the specialist skills, so how can we possibly conform?
Two points make this less daunting than it appears.
First, there is no expectation that a single comprehensive cybersecurity review covers the full breadth of the requirement. Coverage can be demonstrated across several engagements over time. A payroll audit that examines access controls, a procurement audit that looks at vendor system connections, an IT general controls review, together these can build coverage that no single engagement would achieve.
Second, the User Guide includes an optional documentation tool designed precisely to help teams record these decisions and show how coverage is being achieved. It also maps the requirement to the NIST and COBIT frameworks. Referencing those frameworks is not a requirement, but if your organisation already uses one, the mapping saves considerable work. The IIA’s separate Application Guidance covers applicability judgement, exclusions, and implementing several requirements at once.
Why the timing matters here
The Maldivian legal environment for cybersecurity is being built right now, and internal audit has an unusual opportunity to be early rather than late.
The National Cyber Security Agency was established in March 2024 by presidential decree, made under Article 116 of the Constitution. A Cyber Security Bill was submitted to the People’s Majlis on 11 May 2026, and in June 2026 Parliament approved the draft text for committee scrutiny alongside a first reading of a Digital Identity Bill. A Personal Data Protection Bill has been moving through the chamber in the same period.
The NCSA’s published outline of the draft shows a framework that includes a schedule identifying critical information infrastructure sectors, policies for securing that infrastructure, incident response provisions, and a chapter on the issuance of licences to cybersecurity service providers.
None of this is law yet. That is precisely the point.
Organisations that will fall within scope face a compliance question at some stage. An internal audit function that has already run a structured assessment of cybersecurity governance, risk management, and controls will be able to tell its board where the organisation stands before anyone asks. A function that waits for the legislation will be doing the same work under pressure, and with less credibility.
There is a further alignment worth noting. The IIA’s Risk in Focus 2026 Global Summary, drawing on 4,073 responses from senior internal auditors worldwide, reports that cybersecurity remains the perennial highest risk globally, with digital disruption including AI now in second place. This is not a topic where local practice can reasonably diverge from global priority.
Four things worth doing this quarter
Read the requirement and the User Guide. Both are free, and the IIA publishes them in more than twenty-five languages. These are short documents, not standard-length pronouncements.
Add an applicability question to your engagement planning template. One line: does this engagement involve systems, data, or access presenting cybersecurity risk? Then record the answer and the reasoning. This single change closes the most common conformance gap.
Map your existing coverage. Look back over your last two years of engagements and identify where cybersecurity elements were already examined. Most functions have covered more ground than they realise. Knowing what you already have makes the remaining gap far easier to discuss with your audit committee.
Where this leads
The Cybersecurity Topical Requirement is the first of a series, and the profession will spend the next several years absorbing the rest. What it offers Maldivian internal auditors is not a burden so much as a vocabulary, a defined, internationally recognised baseline you can point to when explaining to a board why a particular area deserves attention and what a credible assessment of it looks like.
For a profession still establishing its authority in many organisations here, that vocabulary is worth having. The functions that adopt it early will find the conversations that follow considerably easier.
Leave a Reply