Audit management systems are sold on demonstrations and bought on relationships, which is why so many functions end up with a tool that fits the vendor’s idea of an audit rather than their own. This guide is a method for buying one properly. It does not rank products, because a ranking is useless to a five-person function comparing itself with a bank’s fifty, and because products change faster than an article can. Instead it gives you the decision in the order it should be made: whether you need a system at all, what you should require of one at your size, an RFP requirements template you can issue as written, a scripted demonstration that stops vendors showing you what they want you to see, the reference-check questions that get honest answers, the pricing structures and the costs that hide inside them, a migration plan that does not lose the open issues, and a worked example of a small function choosing its first system.
Everything here is vendor-neutral by design. Where we describe how products behave, the description covers the market as we have seen it across implementations, not any one product. Where we give weights and thresholds, they are starting points to be argued with, and the argument is the point: a function that can explain why it weighted issue tracking above analytics has done most of the work of choosing. For the audit operations the system has to support, the planning method in how to build the audit plan and the quality program in the QAIP playbook are the two guides this one assumes.
In this guide
- Whether you need a system at all
- What to require, weighted by the size of the function
- The RFP requirements template
- The scripted demonstration
- Reference checks that get honest answers
- Pricing structures and where the costs hide
- Migration and implementation planning
- Worked example: a six-person function buys its first system
- Related guides
Whether you need a system at all
An audit management system does four things a document library and a spreadsheet do badly once the function passes a certain size: it holds the audit universe and the plan in one structure with the risk assessment behind them; it runs engagements through a workflow with review evidence, sign-off and version control on every workpaper; it tracks issues and management actions to closure with owners, dates and escalation; and it reports on all of that to the chief audit executive and the committee without someone rebuilding the numbers by hand. If the function does those four things adequately today, a system will make them tidier but not better, and the money is better spent on people or analytics. If one of them is failing, the failure usually has a name in the last quality assessment or the last committee meeting, and that name is the first requirement.
| Function | What usually works without a system | The trigger that changes the answer |
|---|---|---|
| One to five auditors | A structured document library with a locked folder template per engagement, a plan and universe workbook, an issue log with a monthly review; see the audit issue log template | Past-due actions that nobody escalated, workpapers that cannot be shown to an external assessor with review evidence intact, or a CAE who spends a day a month rebuilding the committee pack |
| Six to twenty-five auditors | The same, with discipline, for a year or two; after that the review trail and the issue population outgrow the tools | Two or more teams working in parallel, a co-source partner who needs controlled access, a first external quality assessment on the horizon, or issue counts in the hundreds |
| More than twenty-five auditors | Nothing, for long. Functions this size that run on shared drives have usually built a home-grown database somebody is afraid to touch | The function already has a system; the question is whether to replace it, and the trigger is a renewal date, a vendor’s end-of-life notice or a merger |
| Any size, regulated industry | Manual methods survive until a regulator or assessor asks for evidence of the review trail across the population rather than a sample | A finding from an assessor or regulator about the function’s own records is a trigger no business case has to argue with |
Three honest reasons not to buy, even with a trigger. A function whose methodology is unsettled will encode its confusion; the system forces decisions about phases, review levels and rating scales that should be made first, in the manual, using the structure in GIAS Domain V as the checklist. A function about to be merged, outsourced or restructured should wait, because the buyer’s requirements will not be the seller’s. And a function without the time to implement, realistically 200 to 500 hours of its own effort for a mid-sized function over four to six months, will buy shelfware; vendors will not tell you this, and reference customers will.
What to require, weighted by the size of the function
Every system on the market will claim every capability on a requirements list, so the list is not where products separate; the weights are. The weights below are our starting point for three sizes of function. They add to 100 in each column and they are deliberately uneven, because a small function that weights integration and analytics as heavily as a bank does will buy a bank’s system and use a tenth of it. Move points between rows with a reason written next to the move, and keep the reasons; the committee will ask why the cheaper product lost.
| Requirement area | What it covers | 1 to 5 auditors | 6 to 25 auditors | More than 25 |
|---|---|---|---|---|
| Universe, risk assessment and planning | Auditable entities with attributes, risk scoring you can change, plan versions, resource and hours planning, plan-to-actual | 15 | 15 | 12 |
| Engagement workflow and workpapers | Engagement phases, work program library, workpaper templates, review notes and clearance, sign-off with timestamp and identity, version history, locking on report issue, offline or low-bandwidth working | 25 | 22 | 18 |
| Issue and action tracking | Issues with ratings, actions with owners and dates, management self-update with audit validation, escalation rules, evidence of validation, ageing and past-due reporting | 25 | 20 | 15 |
| Reporting and dashboards | Committee pack outputs, plan status, issue population views, configurable without the vendor, export to the formats the committee actually reads | 15 | 12 | 12 |
| Analytics, integration and data | Import and export in open formats, API, links to GRC or risk systems, analytics results attached to engagements, bulk operations | 5 | 10 | 15 |
| Security and administration | Single sign-on, role-based access including read-only for auditees and co-source partners, audit trail on records, data residency, retention and legal hold, vendor security assurance such as a SOC 2 report | 8 | 10 | 13 |
| Usability and adoption | Time for a new auditor to become productive, number of clicks in the daily tasks, quality of search, mobile use in the field | 5 | 6 | 5 |
| Vendor viability and service | Financial stability, customer base in functions like yours, release cadence, support hours in your time zone, exit terms and data return | 2 | 5 | 10 |
Two rows deserve a note. The security row includes the vendor’s own assurance because the system will hold every finding the function has ever written, which makes it one of the most sensitive third-party arrangements in the organization; the review method in how to review a SOC 2 report applies to the vendor in full, and the IIA’s Third-Party Topical Requirement will apply to the function’s own oversight of it. And the usability row is weighted low not because it matters little but because it is measured in the demonstration rather than the RFP, where every vendor scores itself full marks.
The RFP requirements template
The template below is the requirements section of an RFP, written to be issued as it stands with the function’s own numbers filled in. Its two design choices matter more than its content. First, every requirement carries a priority: M for must, meaning a product that cannot meet it is out regardless of score; S for should, which scores; and C for could, which breaks ties. Second, vendors must answer each line with one of five codes rather than prose: Standard (available now, in the base product, shown in the demo), Configuration (achievable by an administrator without vendor involvement), Customization (requires vendor development or professional services, priced separately), Roadmap (not available; give a committed release date), or Not available. Prose answers are where “yes” becomes “yes, with services”. The codes are also the scoring key: Standard scores full marks, Configuration three-quarters, Customization one-quarter, Roadmap and Not available zero.
Section A: Universe, risk assessment and planning. A1 (M) Maintain an audit universe of auditable entities with configurable attributes (owner, process, location, system, regulatory relevance) and a history of changes. A2 (M) Score entity risk using factors and weights the function defines and can change without vendor involvement; retain prior-year scores. A3 (M) Build an annual or rolling plan from the universe with hours, staff assignment and status; hold approved versions and in-year changes with reasons. A4 (S) Report plan-to-actual hours and completion by engagement and by quarter. A5 (S) Record coverage of each universe entity over a configurable cycle. A6 (C) Link entities to an enterprise risk register held in this or another system.
Section B: Engagement workflow and workpapers. B1 (M) Run engagements through configurable phases with a work program drawn from a library the function maintains. B2 (M) Attach workpapers of any file type with version history; hold the reviewer’s notes, the preparer’s responses and clearance with identity and timestamp on each. B3 (M) Enforce sign-off sequences (preparer, reviewer, engagement lead) that the function defines, and lock the engagement on report issue with an auditable unlock. B4 (M) Provide workpaper referencing and cross-referencing that survives file replacement. B5 (S) Allow work offline or on low bandwidth with synchronization; state precisely what is and is not available offline. B6 (S) Support a co-source partner or guest auditor with time-limited access scoped to one engagement. B7 (C) Generate a draft report from findings recorded in the engagement using a template the function controls.
Section C: Issues and actions. C1 (M) Record issues with the function’s rating scale, root cause categories and the five elements of a finding, linked to the engagement and the universe entity. C2 (M) Record management actions with owner, due date, status and revised dates with reasons; keep the original date visible. C3 (M) Allow action owners outside internal audit to update status and attach evidence through a role that sees only their actions; require internal audit validation before closure. C4 (M) Escalate past-due actions automatically according to rules the function sets (days past due, rating, owner level). C5 (S) Report the issue population by rating, age, business unit and root cause, with trend over time. C6 (C) Support repeat-finding identification across engagements.
Section D: Reporting. D1 (M) Produce the audit committee reporting the function specifies (plan status, issue population, past-due actions, function metrics) from live data without manual rebuild, exportable to the office formats the committee uses. D2 (M) Allow an administrator to build and change reports and dashboards without vendor involvement. D3 (S) Provide role-based dashboards for the CAE, engagement leads and action owners. D4 (C) Schedule and distribute reports automatically.
Section E: Data, integration and analytics. E1 (M) Import the function’s existing universe, plan and open issues from spreadsheets during implementation, with a documented mapping. E2 (M) Export all function data, including attachments and audit trail, in open formats at any time and at contract end without additional charge. E3 (S) Provide an API with documentation for read and write of universe, plan, engagement and issue data. E4 (S) Support single sign-on through the organization’s identity provider. E5 (C) Attach analytics results or link to an analytics platform at engagement level.
Section F: Security, administration and vendor. F1 (M) Provide a current SOC 2 Type 2 report or an equivalent independent assurance report, and describe the controls the function must operate. F2 (M) State data residency options, encryption at rest and in transit, retention controls and legal hold. F3 (M) Maintain an audit trail on all records showing who changed what and when, available to the function. F4 (M) State support hours, response targets by severity and the escalation route, with the customer base in functions of similar size and industry. F5 (S) Describe the release cadence and how customers influence the roadmap. F6 (M) State the exit provisions: notice, data return format and timing, deletion certification.
Issue the template with a short covering section that states the function’s size, its engagement volume, its current tools, the go-live date it needs, and the pricing information required, in the structure described later in this guide. Give vendors two to three weeks and require the response in a spreadsheet with one row per requirement and one column per code, because the scoring is done by formula and a forty-page PDF cannot be scored. And say, in the RFP, that the demonstration will follow a script the function supplies; the vendors that object are telling you something.
The scripted demonstration
A vendor demonstration left to the vendor is a tour of the product’s best rooms. The script below replaces it with a day in the life of the function, performed on the function’s own sample data, which is supplied to every shortlisted vendor two weeks in advance: a universe of thirty entities, a plan of ten engagements, one engagement’s work program and workpapers, and forty open issues with actions. Every vendor performs the same scenes in the same order in front of the same panel, and the panel scores each scene on a four-point scale (does it as we work, does it with a workaround, does it with vendor services, cannot) before discussing anything. Two hours is enough. A vendor who cannot run the script on your data in two hours is showing you the implementation you would get.
Scene 1 (15 minutes): Plan the year. Add a new entity to the universe, change one risk factor’s weight, show the effect on the ranking, add the entity to the current plan with hours and a lead, and produce the plan-to-actual view. Then show the plan as it stood before the change.
Scene 2 (25 minutes): Run an engagement. Open the supplied engagement, add a step to its work program from the library, upload a workpaper, have a second user review it and raise a note, have the first user respond and replace the file, clear the note, and sign off. Show the version history and who did what. Then try to change the workpaper after sign-off.
Scene 3 (15 minutes): Raise and track an issue. Record a finding from that engagement with rating, root cause and an action with an owner outside internal audit. Log in as the owner, update the status, attach evidence and request closure. Log in as the auditor and validate. Then move the due date and show what the record retains.
Scene 4 (15 minutes): Escalate and report. Show the past-due actions in the supplied data, the escalation that the system generated or would generate, and the issue population by rating and age. Produce the committee pack from the supplied data in the format the panel specified, without leaving the product.
Scene 5 (15 minutes): Administer. As an administrator with no vendor help, change the rating scale, add a phase to the engagement workflow, build a new dashboard tile, and add a read-only guest user scoped to one engagement. Time each task.
Scene 6 (15 minutes): Leave. Export the complete supplied dataset, including attachments and audit trail, and open the export outside the product. Then show search: find every issue in the supplied data that mentions a given system.
Scene 7 (20 minutes): Questions from the panel, restricted to things seen in the previous six scenes.
Score the scenes weighted by the requirement areas they exercise, and keep the demonstration score separate from the RFP score until both are complete; combining them early lets a strong demo forgive a weak written answer, which is exactly the sales dynamic the script exists to prevent. The tasks the panel should watch most closely are the ones performed by the least technical member of the function, and the timings in Scene 5, because administration effort is the cost that arrives every month for the life of the contract.
Reference checks that get honest answers
Vendors supply happy references, and happy references are still useful if the questions are specific enough to make happiness quantifiable. Ask for three: one function of your size and industry, one that went live in the last twelve months, and one that has been on the product for more than three years and through at least one major upgrade. Speak to the person who administers the system, not only the CAE. And ask the questions below in this order, because the early ones are easy to answer honestly and set the tone for the later ones.
| Question | What a good answer sounds like | What to probe if it does not |
|---|---|---|
| How many hours of your own team’s time did implementation take, from contract to go-live, and how long in months? | A number, with a breakdown between configuration, migration and training, and a go-live within a month or two of the original date | A vague answer means nobody tracked it, which usually means it was more than planned; ask what slipped |
| What did you migrate, what did you leave behind, and what do you wish you had done differently? | Open issues and the universe migrated; historical workpapers left in the old system or archive; a specific regret about data cleaning | “Everything” migrated is a warning; ask how long the historical workpapers took and whether anyone has opened them since |
| Which requirement did the vendor answer as Standard or Configuration that turned out to need services? | One or two specifics, named, with what it cost | “None” from a customer of more than a year is unusual; ask about reporting, which is the commonest gap |
| How much administrator time does the system take each month, and who does it? | A figure in hours, from the administrator, with the tasks that consume it | If the CAE does not know, ask to speak to the administrator |
| When you last raised a severity-one support case, what happened and how long did it take? | A story with times and a resolution | No severity-one case in three years is possible; ask about the last upgrade instead |
| What did the last major upgrade break, and how much notice did you get? | Something small, with notice measured in weeks and a test environment to try it in | Reports and integrations are what upgrades break; ask specifically |
| What has the price done since you signed, and what triggered the change? | Increases in line with the contract’s stated cap, tied to the index or percentage in the contract | Uncapped renewal increases and per-user creep are the two most common surprises |
| If you could leave without cost, would you, and what would you choose? | A reasoned “no” with one or two things they would change | An enthusiastic “no” with nothing they would change is a reference, not a customer; weigh it accordingly |
| Has an external quality assessor or regulator reviewed your records in the system, and what did they say? | Yes, with the review trail and issue evidence accepted without rework | If not, ask whether the audit trail has ever been exported for anyone outside the function |
Write the answers up the same day, score nothing, and circulate them to the panel before the final scoring meeting. Reference calls rarely change the ranking; they change the contract, because the surprises the references describe become the clauses the function negotiates.
Pricing structures and where the costs hide
Audit management systems are almost all sold as subscriptions now, and the subscription is the visible part of a cost that has five or six parts. The RFP should require every vendor to price the same scenario in the same structure, over five years, with every line below stated even when it is zero, so that the comparison is between totals rather than between the numbers each vendor chose to lead with.
| Cost element | How it is usually structured | What to watch for |
|---|---|---|
| Subscription | Per named user per year, per concurrent user, tiered by number of users, or by module; auditee and read-only users sometimes free, sometimes not | Who counts as a user. Action owners updating their own actions can turn a twenty-user function into a two-hundred-user bill; get the definition in writing |
| Implementation and configuration | Fixed fee or time and materials, commonly a substantial fraction of the first year’s subscription; sometimes bundled to disappear into a multi-year commitment | Time and materials with no cap; ask what the fixed-fee scope excludes and price the exclusions |
| Migration | Priced by data set (universe, plan, issues, workpapers) or by hour; often the first thing descoped to hit a budget | Workpaper migration is the expensive line; decide before the RFP what history goes in, and see the migration section |
| Training | Per session, per seat or included; administrator training usually separate and more valuable | Whether training is recorded and reusable for new joiners, or paid for again each time |
| Support and success | Included at a base level; premium tiers for faster response, a named contact or extended hours | Which tier the reference customers bought, and whether the base tier’s response targets are acceptable for a report deadline week |
| Customization and integration | Professional services at day rates; connectors sometimes licensed separately | Every requirement answered Customization is a services line; total them before scoring the price |
| Renewal and escalation | Annual increases at a stated percentage, an index plus a margin, or uncapped “then-current list price” | Uncapped renewals; negotiate a cap and a price-hold for the first multi-year term, and price the five-year total on the capped assumption |
| Exit | Data return in open formats; sometimes an extraction fee or a limited window after termination | A fee for your own data, or a window shorter than the time it takes to import it elsewhere; both belong in the contract, not the renewal conversation |
The hidden costs on the function’s own side are larger than most of the vendor’s lines and never appear in a proposal: the hours of the auditors who configure, migrate, test and learn the system, and the engagements that slip while they do. Estimate them at the outset with the same honesty the guide on the true total cost of an internal audit brings to engagement costing, and put them in the business case, because a system that saves a day a month of committee-pack rebuilding and costs three months of a senior’s time to implement has a payback the CAE should be able to state.
Migration and implementation planning
Implementations fail in the same three places: the function tries to migrate its whole history, the methodology decisions are made inside the tool under time pressure, and go-live is scheduled for the busiest quarter. The plan below is sequenced to avoid all three. Its central rule is that history stays where it is. The audit universe, the current plan, the open issues and actions, and the engagements in progress at cut-over go into the new system; closed engagements and their workpapers stay in the old system or a read-only archive, indexed, for the retention period. Nobody opens a five-year-old workpaper often enough to justify migrating ten thousand of them, and the reference customers will tell you so.
| Phase | Duration (mid-sized function) | What gets done | Exit criterion |
|---|---|---|---|
| 0. Decide the method first | Before contract | Engagement phases, review levels, rating scale, root cause categories, issue and action fields, escalation rules, report formats, all written into the methodology manual | The manual describes the process the system will enforce; nothing is left to be decided in configuration |
| 1. Configure | 4 to 6 weeks | Administrator training first; then the vendor configures with the function’s administrator alongside, so the knowledge stays; test environment stood up | The demonstration script runs end to end on the function’s data in the test environment, performed by the function’s staff |
| 2. Clean and migrate | 4 to 8 weeks, overlapping | Universe and risk scores cleaned and loaded; plan loaded; open issues and actions reconciled to the committee’s last reported population and loaded with original dates preserved; in-flight engagements loaded at their current phase | Issue and action counts in the system equal the last committee pack, signed off by the CAE; every migrated record has its original dates |
| 3. Pilot | One engagement, 4 to 6 weeks | A real engagement run entirely in the system by one team, with the administrator resolving problems and a daily list of what was changed | The engagement’s workpapers, review notes and sign-offs are complete in the system with no parallel file store |
| 4. Train and cut over | 2 weeks | Role-based training for auditors, engagement leads, action owners and the committee’s secretary; old system frozen read-only on a stated date; new engagements start in the new system only | No new workpaper is created outside the system after the cut-over date, and the CAE checks |
| 5. Stabilize and report | First quarter after go-live | The first committee pack produced from the system, reconciled to the previous one by hand once; escalation rules switched on; a fortnightly issues list worked down; the vendor’s implementation team released only when the list is empty | The committee has received a pack from the system, and the administrator can produce the next one without the vendor |
Two rules for the people side. Give the administrator role to someone who will stay, and give them the time in the plan; a system without an owner inside the function decays within a year into a filing cabinet with a login. And expect the workpaper discipline to tighten, because the system makes review evidence visible in a way a shared drive never did. Auditors who have read workpaper best practices and worked through a full workpaper example will find the system enforces what they already do; the ones who have not will find it enforcing what they should have done, and the CAE should be ready for that conversation in the pilot rather than at the external assessment.
Worked example: a six-person function buys its first system
MidState Beverage’s internal audit function ran for years on a shared drive, an engagement folder template and an issue log in a spreadsheet, and the arrangement held until the function built its quality program. The first self-assessment against the Global Internal Audit Standards found three partial conformances, and one of them was about the records: three of fourteen open actions were past due without anyone having escalated them, because the spreadsheet did not know what a due date was. With the first external quality assessment scheduled for FY28, the chief audit executive put a system into the FY28 budget and, having read enough vendor material to distrust it, ran the method in this guide.
The requirements went out to five vendors with the six-to-twenty-five weights above shifted toward the function’s own pain: issue and action tracking raised to 25, integration cut to 5, with the reasons recorded on the scoring sheet. Three responded in the required spreadsheet form and were shortlisted: a GRC platform with an audit module, a mid-market product built for audit functions, and a lighter product aimed at small teams. Their RFP scores were 71, 84 and 78. The demonstrations, run to the script on MidState’s own universe and forty of its issues, separated them further. The GRC platform’s presenter needed vendor help in Scene 5 for every administration task and took eleven minutes to add a workflow phase. The lighter product ran the script cleanly but could not express the escalation rule the function needed, past-due actions on High findings to the CAE at fifteen days and to the committee chair at forty-five, without a manual step, and had no offline working, which mattered for auditors at depots with poor connectivity. The mid-market product did everything in the script; its weakness was a committee pack that needed a template built, which it answered as Configuration and the administrator confirmed in Scene 5 in under ten minutes.
Reference calls changed the contract rather than the choice. One customer of the mid-market product described a renewal increase well above what they had expected in year three; MidState negotiated a five-year cap. Another described action owners being counted as named users after a licensing review; MidState wrote the definition of a user into the order form, with action owners and read-only auditees excluded. The five-year total for the chosen product, with implementation, migration of the universe, plan and 31 open actions, training, and capped renewals, came in between the other two; the CAE’s business case set against it the day a month spent rebuilding the committee pack, the escalation gap the assessors would otherwise find, and roughly 320 hours of the function’s own time over five months, most of it the audit manager’s, who became the administrator.
Method decisions came first, as the manual had been rewritten during the quality program build and already defined phases, review levels and the rating scale. Configuration took five weeks; migration reconciled the 31 open actions to the last committee pack to the record, with original due dates preserved; the pilot was the depot rotation engagement already in progress; and cut-over fell in the quietest quarter. The first committee pack from the system reconciled to the previous one with one difference, an action closed in the spreadsheet that had never been validated, which the CAE reported as such. When the external assessors arrived, the review trail, the sign-offs and the action ageing were on the screen rather than reconstructed, and the partial conformance on follow-up was closed on the evidence of the escalations the system had sent. The system did not make the function better at auditing. It made the function able to prove what it did, which is what the assessment, the committee and, in the end, the budget were asking for.
Related guides
Related guides
- How to Build the Internal Audit Plan
- The QAIP Playbook
- Audit Issue Log Template
- Internal Audit Plan Template
- Workpaper Best Practices
- Audit Workpaper Example
- How to Review a SOC 2 Report
- The Third-Party Topical Requirement
- The True Total Cost of an Internal Audit
- GIAS Domain IV: Managing the Function
- AI Prompts for Internal Auditors
- Building a GRC Framework
- Audit Technology and Tools (category)
- Resources and Templates (category)
Leave a Reply