What the Audit Module Does
Audit Management covers the internal audit lifecycle end to end — risk-based planning, fieldwork and workpapers, findings, remediation, and audit committee reporting — on the same data model as the risk register and control library.
That shared model is the point. When internal audit runs its own private system, audit and compliance end up holding contradictory views of the same control, and the contradiction is usually discovered by an external party.
Risk-Based Audit Planning
A plan that audits the same areas each year is a cyclical plan wearing risk-based clothing. ActiveERM derives coverage from the enterprise risk register: highest residual risks attract audit attention, areas with recent incidents or control failures can be pulled forward, and areas untouched for years become visible precisely because nobody has looked.
Because plan and register share data, the audit committee's first question — why these audits — has an answer they can reconcile against the risk picture they were shown last quarter.
Fieldwork and Workpapers
Workpapers carry preparer and reviewer sign-off with a review-note workflow that resolves before issue, so the file supports re-performance by a third party.
Sampling is supported with retained populations, because auditors test population completeness and an incomplete change log invalidates every sample drawn from it. Time and resource are tracked against the plan.
Audit's working papers are not editable by auditees — independence enforced by the system rather than by convention.
Findings and Remediation
Each finding carries severity against defined criteria rather than individual judgement — without that, the register cannot be aggregated meaningfully — plus root cause, agreed management action, owner, due date and status.
Findings link to the control and risk they concern, so a finding updates the residual risk picture rather than sitting in a parallel list.
Remediation runs assign, remediate, verify, close. The verification step is the one most often skipped elsewhere: an action is not closed until evidence shows the finding is actually resolved, and re-testing happens after the fix has operated long enough to sample.
Compliance Testing in the Same Place
Control testing performed for ISO 27001, SOC 2, SOX or DORA uses the same controls internal audit examines. Test once, and the evidence serves both the framework and the audit — instead of two teams testing the same control and reaching two conclusions.
Reporting
Role-based dashboards cover coverage against plan, open findings by severity and age, remediation status, and trend. Committee packs are generated rather than assembled by hand.
The metric worth watching is repeat findings. A rising repeat rate means remediation is closing tickets rather than fixing causes — and audit committees tend to notice it on their own.
Who It Suits
Internal audit functions running a formal plan with a committee to report to, and compliance teams whose control testing has outgrown spreadsheets. It suits organisations wanting audit, risk and compliance on one data model rather than three tools with an export habit.
A one-person function running two audits a year will find this more machinery than the job needs.
Implementation
- Get plan, execute, find, remediate working end to end before adding integrations.
- Migrate open findings only — closed items from three years ago dilute the register.
- Agree severity criteria before migrating, because re-scoring later destroys trend data.
- Run one full audit through the system before extending to the whole plan.
- Report from the system; as long as the committee pack is built by hand, the platform is a filing cabinet.
Related
- Internal audit management software — what to look for and how to roll it out
- SOC 2 readiness checklist — what auditors ask for
- Financial and sector regulation — SOX, PCI DSS, DORA
Request a demo to see the plan, workpaper and findings workflow with your own audit universe loaded.