Executive Summary

The previous article in this series ended with a rule every well-governed board eventually adopts: for each material cyber assertion, the board must be able to answer “how do we know that is true?” Much of the answer flows through one function — internal audit. Yet in most Caribbean organisations, internal audit and cybersecurity have grown up in different worlds: one rooted in financial controls, compliance and committee reporting; the other in networks, tooling and technical operations. Each speaks a language the other only partly understands, and the result is an assurance gap hiding in plain sight — audits that stop at policy and process, and technical tests whose findings never reach the audit committee in a form it can govern.

This article introduces the model that closes the gap: the integrated cyber audit, in which internal audit’s risk-based discipline and cybersecurity’s technical realism operate inside a single engagement, under one methodology, producing one risk narrative for two audiences — the board that must govern and the technicians who must fix. It examines why the two disciplines separated, what each sees that the other misses, how an integrated engagement actually runs, and what the model demands of chief audit executives, audit committees and testing teams. It closes with practical first steps and eight questions every audit committee should now be asking its internal audit function.

Why Have Internal Audit and Cybersecurity Lived Apart?

The separation is historical, not logical. Internal audit grew out of financial stewardship: its people were trained in accounting, controls and evidence; its instincts are risk assessment, sampling, workpapers and reporting to those charged with governance. Cybersecurity grew out of technology operations: its people were trained in systems and attacks; its instincts are tooling, configuration and response. In larger markets, decades of investment have partially bridged the two. In the Caribbean, where internal audit functions are typically small and technical cyber skills scarce and expensive, the bridge was rarely built at all.

The consequences show up on both sides. Internal audit functions, uncomfortable in technical territory, audit what they can reach: policies, governance documents, user-access listings, the existence of a firewall rather than its configuration. The audit committee receives cyber “coverage” that has never touched the attack surface. Meanwhile, whatever technical testing the organisation buys — a vulnerability scan with the insurance renewal, a penetration test demanded by a customer — arrives as a standalone technical report, unconnected to the audit universe, unrated for business impact, tracked by nobody, and invisible to the committee. Two streams of assurance activity; no integrated answer to the only question that matters.

What Does Each Discipline See That the Other Misses?

The case for integration is not that either discipline is deficient; it is that they answer different halves of the same five questions. Is the risk governed? Internal audit evaluates mandates, accountability, risk appetite and reporting; technical analysis reveals whether the actual exposure matches what the governance documents assume. Are controls well designed? Internal audit assesses design against the risk and recognised frameworks; technical review examines architecture and configuration — where design intentions go to die. Do controls operate? Internal audit tests operating effectiveness through evidence and re-performance; technical testing attempts to defeat the control outright, which is the most honest test of operation ever devised. Can the organisation respond? Internal audit examines plans, roles and escalation; technical exercises prove whether recovery actually works under pressure. Were the issues fixed? Internal audit brings action-tracking and closure governance; technical retesting proves the fix held.

Put simply: internal audit supplies the discipline — risk-based scoping, evidence standards, independence, committee-grade reporting and remediation governance. Cybersecurity supplies the realism — knowledge of how attacks actually unfold and the technical means to test whether defences survive contact. An audit without the realism is documentation review. Testing without the discipline is a technical report in a drawer. Only together do they produce what Article 2 defined as cyber assurance: independent, evidence-based conclusions a board can rely on.

THE INTEGRATION PRINCIPLE Internal audit without technical depth audits the paperwork. Technical testing without audit discipline never reaches the boardroom. The integrated cyber audit does what neither can do alone: prove whether controls survive attack — and report it in a form the audit committee can govern.

 

What Does the Integrated Model Look Like in Practice?

An integrated cyber audit runs as one engagement with five connected movements. It begins with risk-based scoping: the audit is planned from the organisation’s business loss scenarios — the ransomware event, the payments fraud, the data theft — not from a generic checklist, so that the areas examined are the areas that would actually hurt. Second, control evaluation: the audit team assesses whether the relevant controls are well designed and operating, using internal audit’s established methods — walkthroughs, evidence inspection, re-performance — anchored to recognised frameworks such as NIST CSF 2.0 and conducted under the IIA’s Global Internal Audit Standards.

Third — and this is the departure from convention — technical validation is embedded, not appended. The technical team tests the same controls the auditors are evaluating: if the audit examines privileged access, the testers attempt to escalate privileges; if it examines backup and recovery, a restoration is actually performed; if it examines network defences, a controlled penetration test probes them. Fourth, integrated risk rating: every finding — whether it emerged from a workpaper or an exploit — is rated twice, once for technical severity and once for enterprise impact, because a technically critical vulnerability on an isolated system may matter less than a moderate weakness sitting on the payments pathway. Fifth, one report, two audiences: an executive and committee report that tells a single risk story in business terms, and a technical annex that gives IT teams exactly what they need to fix and verify. The engagement does not end at the report: findings carry owners and dates, and closure is confirmed by retest — the remediation discipline this series returns to in a later article.

What Changes for Chief Audit Executives and Audit Committees?

For the chief audit executive, the integrated model reframes three responsibilities. The audit universe must now genuinely contain cyber: not one line called “IT audit,” but the organisation’s actual cyber loss scenarios and the control domains behind them — identity and access, vulnerability and patching, cloud configuration, third parties, monitoring, backup and recovery, incident response — prioritised by risk like everything else in the plan. Capability must be addressed honestly: the choice is build, partner or co-source, and for most Caribbean functions co-sourcing is the rational answer — specialist technical resources working under internal audit’s mandate, methodology and quality control, so that the function directs assurance it could not staff alone. And professional conformance now demands it: the IIA’s Cybersecurity Topical Requirement, in force since February 2026, sets a baseline for cyber assurance that a policy-only audit approach cannot meet — the next article in this series examines the requirement in detail.

For the audit committee, the shift is from receiving coverage to interrogating it. The committee’s questions move from “did we audit cybersecurity this year?” to “did our cyber audits include technical validation? Were findings rated for business impact? Has closure been retested?” — the same verification instinct Article 3 asked of the full board, applied to the assurance engine itself.

What Changes for the Technical Testing Side?

Integration is equally demanding of the technical discipline. Testing is scoped by the audit risk assessment rather than by whatever the tooling finds interesting, which means testers must understand why a system matters before they probe it. Evidence moves to audit standard: findings supported by workpapers, screenshots, logs and reproducible steps, retained and reviewable, because a conclusion the committee will rely on must survive scrutiny. Safety becomes procedural: signed rules of engagement, agreed testing windows, stop conditions and client authorisation — the controls that let intrusive work proceed without creating the very disruption it is meant to prevent. And translation becomes part of the job: the technical team participates in rating findings for business impact and in the factual clearance of the integrated report, rather than delivering severity scores and departing. Technicians who learn this discipline become dramatically more valuable — their work stops dying in drawers and starts driving decisions.

How Should a Function Begin? Five Practical Steps

1. Map cyber into the audit universe. Take the organisation’s top loss scenarios and trace them to auditable control domains — then let risk, not comfort, set the plan.
2. Assess capability honestly. Inventory the skills the plan requires against the skills the function holds, and decide — build, partner or co-source — before the plan year starts, not during it.
3. Pilot one integrated audit. Choose a contained, high-value domain — privileged access or backup and recovery are ideal — and run the full model: audit evaluation plus embedded technical validation, one integrated report.
4. Adopt the dual rating. Agree with management and the committee a rating methodology that scores every finding for technical severity and enterprise impact — and use it for all cyber findings from any source.
5. Bring existing technical reports into governance. Every penetration test and vulnerability assessment the organisation already commissions should flow into audit’s finding-tracking and the committee’s view — orphaned reports are unmanaged risk.

The Dawgen Global Perspective

Dawgen Global built its Cyber Risk Assurance & Resilience practice on precisely this integration, because the Caribbean’s structural reality demands it: few organisations in the region can employ, in one function, the audit discipline and the technical depth the model requires — but they do not need to. Through co-sourced delivery, Dawgen Global’s internal audit professionals and technical specialists work as one team under one methodology, extending a client’s internal audit function rather than bypassing it: the function keeps its mandate, its independence and its committee relationship, and gains the capability to put genuine technical evidence behind its cyber conclusions.

The result is assurance that serves both masters honestly — rigorous enough for the audit committee, real enough for the attack surface. The next article examines the professional standard now compelling every internal audit function in this direction: the IIA Cybersecurity Topical Requirement, what it demands, and what Caribbean functions must do to conform.

Eight Questions Audit Committees Should Ask Their Internal Audit Function

1. Does our audit universe contain our actual cyber loss scenarios — or one generic line called “IT audit”?
2. When did a cyber audit last include technical validation — testing, not just documentation review?
3. Are cyber findings rated for enterprise impact as well as technical severity?
4. Do penetration tests and scans commissioned elsewhere in the organisation flow into audit’s tracking and our view?
5. What is our capability strategy for cyber assurance — build, partner or co-source — and is it funded?
6. How will the function conform to the IIA Cybersecurity Topical Requirement this plan year?
7. When technical specialists support our audits, do they work under internal audit’s methodology and quality control?
8. Has the closure of last year’s cyber findings been confirmed by retest — or by management assertion?

Frequently Asked Questions

Can internal auditors audit cybersecurity without technical certifications?

They can audit its governance, processes and many of its controls — competently and to standard. What they cannot do without technical capability is validate that controls survive attack, which is why the integrated model pairs auditors with specialists rather than asking either to impersonate the other. The function’s obligation is to ensure the combined competence exists, not to hold every skill personally.

Is co-sourcing an admission that our internal audit function is weak?

No — it is the same judgement functions have always made for actuarial, valuation and forensic work: specialist depth is engaged where the plan requires it, under the function’s direction. A function that co-sources cyber capability is conforming to standards; a function that avoids cyber because it lacks the skills is the one with the finding.

Does penetration testing really belong inside an internal audit?

When the audit’s objective includes operating effectiveness of technical controls, yes — a controlled technical test is the strongest evidence of operation available. It must be properly authorised, scoped and safety-managed, and it does not replace audit procedures; it completes them.

How should we rate a finding that is technically severe but sits on a low-value system?

Exactly as the dual rating intends: record the technical severity honestly, rate the enterprise impact honestly, and let prioritisation follow the business. The discipline works in both directions — it also elevates technically “moderate” weaknesses that sit on the payments pathway or the member database, which single-scale severity scoring systematically under-ranks.

Move From Cybersecurity Assumptions to Independent Cyber Assurance

Dawgen Global combines cyber governance, risk-based internal audit, penetration testing, resilience assessment and remediation validation to help Caribbean organisations determine whether their cybersecurity controls are properly designed and operating effectively. To explore the integrated model for your organisation, request a cyber internal audit readiness and coverage review, or a co-sourcing discussion for your internal audit function.

 

About Dawgen Global

Dawgen Global is an independent, integrated multidisciplinary professional services firm headquartered at 47 Trinidad Terrace, New Kingston, Jamaica, serving more than 15 territories across the Caribbean. Founded and led by Dr. Dawkins Brown, Executive Chairman, the firm is independent and not affiliated with any international network. It delivers a full suite of professional services under one roof: audit and assurance; tax advisory; IT and digital transformation; risk management; cybersecurity; actuarial and insurance regulatory advisory; HR advisory; mergers and acquisitions; corporate recovery; business advisory and strategy; accounting BPO and virtual CFO services; and legal process outsourcing.

The proposition is simple: big-firm capability without the big-firm price. Dawgen Global’s integrated approach is built for the specific complexities and opportunities of the Caribbean market, helping organizations make sharper, better-informed decisions that drive measurable progress.

To explore a partnership, reach out:

• Website: dawgen.global
• Email: [email protected]
• WhatsApp (Global): +1 555-795-9071
• Caribbean offices: +1 876-665-5926 | +1 876-929-3670 | +1 876-926-5210