13.2 Continuous Monitoring, Dashboards, and Embedded Audit Modules
Key Takeaways
- Continuous monitoring is management's ongoing oversight of processes and controls; continuous auditing is internal audit's independent automated or frequent testing to develop assurance — they are not the same owner or the same conclusion
- Dashboards are for exception follow-up, not standalone engagement conclusions; a green tile is not proof of effective controls
- Embedded audit modules are application hooks that flag or record specified transactions; they support findings only after completeness, silent-disablement, bypass, and change-control tests
- Reliability of dashboard or module output depends on the control environment of the system producing it (GIAS Standard 14.1) plus IPE completeness and logic tests
- Efficient always-on tools become effective for findings only when exceptions are followed to source documents and compared to evaluation criteria
13.2 Continuous Monitoring, Dashboards, and Embedded Audit Modules
Quick Answer: Continuous monitoring is management's ongoing oversight of processes and controls. Continuous auditing is internal audit's independent, automated or frequent testing used to develop assurance. Dashboards are for exception follow-up, not standalone conclusions. Embedded audit modules are hooks inside applications that flag or record specified transactions. All of these can be efficient. They become effective for findings only after you test completeness, logic, and the control environment of the system that produces them. A green dashboard is not proof of effective controls.
B3's remaining options — continuous monitoring, dashboards, and embedded audit modules — look like they finish the engagement because they run while you sleep. CIA Part 2 still scores evaluate the option: can this output develop and support a finding under GIAS 14.1–14.5? Chapter 14 will teach analytical methods and process maps. This section is about always-on pipes and screens, and about not confusing a tile color with a conclusion.
Continuous monitoring is not continuous auditing
The IIA's Global Practice Guide Continuous Auditing and Monitoring (3rd edition) keeps a clean ownership line that the exam writes as a trap.
| Attribute | Continuous monitoring (CM) | Continuous auditing (CA) |
|---|---|---|
| Owner | Process owners, first line, and often second-line risk/compliance | Internal audit (third line) |
| Objective | Detect and correct exceptions in operations; run the control | Independently test controls and transactions to support assurance |
| Typical output | Alerts, queues, management dashboards, metrics | Engagement findings, documented tests, conclusions |
| Typical technology | Embedded system alerts, workflow tools, operations dashboards | Audit analytics, repeatable scripts, modules internal audit governs |
| What it can support on Part 2 | A lead, and — after you test it — evidence that a monitoring control operated | Direct support for findings if IPE, logic, and follow-up are in the file |
They should be aligned, not duplicated. If management already flags exact duplicate invoices every night, internal audit's efficient move is often to test that monitor (completeness, threshold, follow-up) and reperform a period rather than rebuild the same rule from scratch and ignore the first line. Efficiency is not a waiver. If you never test the monitor, you have inquiry plus a screenshot.
Worked example: the nightly duplicate job
Shared-services AP runs a 02:00 job that lists same vendor + same invoice number + same amount. The AP manager clears the queue by noon. That job is continuous monitoring. It does not belong to internal audit just because the chief audit executive thinks it is a good idea.
Internal audit's continuous auditing (or engagement testing that uses the same data) looks different: independently obtain the year's postings after IPE tests; reperform duplicates; inspect a sample of CM alerts for whether they were complete (did every true duplicate appear?) and whether follow-up was real (cleared with a reversing entry and a root cause, or snoozed to keep the dashboard green). The finding, if any, is about missed duplicates or a monitor that does not work — supported by postings and tickets, not by the existence of the job.
Copying monitor in place — 12 months green into the workpapers as the operating-effectiveness conclusion is the ownership mix-up the exam wants.
Dashboards: follow the exception, do not worship the tile
A dashboard is a visualization of key performance indicators, key risk indicators, aging, or exception counts. It is an efficient way to see where to look this week. It is not a population, not an evaluation criterion, and not an engagement conclusion.
To use a dashboard to support a finding or a no-exception story, test the pipe, not the color:
- Completeness. Are all in-scope company codes, plants, parked invoices, one-time vendors, and reversing entries in the extract behind the tile? A filter labeled active vendors that drops vendor category TEMP will hide the exact duplicates you care about.
- Logic. What is the join key? What is the threshold? A duplicate tile that only counts items of $10,000 or more will stay green while $9,999 duplicates pay all year.
- Integrity. Who can change the filter, the query, or the published dataset? Is there a change log? A dashboard anyone in AP can retune is weak internal evidence (Chapter 12's control-environment factor).
- Follow-up operation. Red tiles that auto-age to gray without a ticket are not a detective control. Inspect a sample of alerts through to disposition.
- Control environment of the producing system. GIAS 14.1 says reliability is enhanced when information is gathered from a system with effective governance, risk management, and control processes. That is reliance with testing, not a substitute for testing. If the ERP's access, change, and IPE controls are weak, the dashboard inherits that weakness.
Exam trap — a green dashboard as proof of effective controls. Twelve green months can mean (a) the control worked, (b) the tile is incomplete or mistuned, (c) someone filtered the pain away, or (d) exceptions were closed without remedy. You cannot tell from the color. Untested green is not sufficient, not reliable, and often not even relevant to the criterion you locked in planning.
Worked example: vendor-master segregation of duties
Management presents a year of green no SOD conflicts on the identity dashboard. You test logic and find the report matches on display name, not unique user ID. Three plant clerks share the account VENDOR_ADMIN. The tile never saw a conflict because it never saw three people. Completeness and logic fail. You do not conclude SOD is effective because the dashboard is green. You also do not skip the test because the dashboard is green. You may write a finding on the monitoring control itself, then test actual access lists another way.
That is B3 effectiveness: the dashboard was an efficient place to start and an ineffective place to stop.
Embedded audit modules
An embedded audit module (EAM) is code — a hook — inside the live application that flags or records transactions of audit interest as they occur. Classic uses:
- Write a copy of every payment above $50,000 that sits within 24 hours of a vendor bank-account change to a protected audit file.
- Snapshot before-and-after images when a credit limit is overridden.
- An integrated test facility that processes dummy vendors alongside live transactions so you can see whether programmed controls fire.
| EAM strength | EAM failure mode the exam likes |
|---|---|
| Captures the event at processing time, not from a later, filterable report | Hook fires after a reversible posting, or only in module A while clerks pay through module B or a spreadsheet upload |
| Can cover a defined full population of a high-volume risk | IT or the vendor can silently disable the module in a patch; internal audit is not in the change path |
| Harder to alter after the fact if the audit file is write-once | Completeness never tested — you trust the hook because it is in the ERP |
| Efficient once built | Upgrade breaks the hook; nobody notices for two closing cycles |
EAMs are internal evidence from the production system. Reliability still follows Chapter 12: better if you obtained the audit file yourself, if the module is change-controlled, if bypass paths are in scope, and if IPE-style completeness tests show that transactions that should have been captured were. A monitoring-and-control layer that sits outside the application (extract-and-test without modifying production code) is a cousin technique — more flexible, sometimes easier to maintain, still subject to the same completeness and logic tests. Do not treat either architecture as self-proving.
Worked example: same-day vendor change and payment
You confirm an embedded hook: any AP payment of $50,000 or more posted the same calendar day as a vendor-master bank-account change is copied to an audit file. Efficient for that exact fraud pattern. Effectiveness procedures: (1) from a tested AP population, reperform the rule and match to the audit file — misses are completeness failures; (2) confirm the hook cannot be switched off without a logged change that internal audit sees; (3) include payments initiated from the treasury workstation and from emergency IDs, not only the standard AP workflow. If 4 of 19 qualifying payments are absent from the audit file, the module does not support a no same-day-change-payments conclusion. It does support a finding that the embedded module is incomplete.
Efficiency and effectiveness together
| Option | Efficient use | Effective finding support | Ineffective use |
|---|---|---|---|
| Continuous monitoring | First line clears true exceptions quickly; internal audit tests the monitor instead of ignoring it | Documented tests of completeness, threshold, and ticket disposition | They have a monitor, so we can conclude |
| Dashboard | Directs fieldwork to this week's red tiles | IPE + logic + follow-up + source documents | Screenshot of green as operating effectiveness |
| Embedded audit module | Real-time capture of a rare, high-impact pattern | Reperformance of the hook, bypass testing, change control | Trusting the audit file because it lives in the ERP |
Always-on technology is how you stop sampling 25 invoices and missing the 26th duplicate. It does not replace condition versus criterion. Test the pipe. Follow exceptions to source. Then write the finding. Untested green remains a color, not a conclusion.
Which statement correctly distinguishes continuous monitoring from continuous auditing?
Management provides a 12-month no-duplicate-payments dashboard that is green every month. The auditor's best next step to support an operating-effectiveness conclusion is to:
Which description best fits an embedded audit module used to develop and support findings?