Most internal audit functions are running before anyone writes down what they are. The audits happen, the findings get raised, the committee sees a deck once a quarter — and if a regulator asks what the function’s authority is, or how the year’s work was chosen, the answer lives in three documents, two of them out of date, none of them anywhere obvious.
The IIA’s framework is unusually concrete about this. A function has a charter that states its mission, scope, authority and independence. It has an annual plan, risk-based, approved by the audit committee. It has an audit universe — the register of what could be audited at all. And it has a quality assurance and improvement programme, self-assessed periodically and externally validated at least every five years.
Four documents. Each one is the answer to a question somebody will eventually ask.
The four, and who asks about each
The charter answers “what are you allowed to do?” (Standard 1000.) It is the document that gives internal audit unrestricted access to records and people, and states that the function reports functionally to the audit committee rather than to the executives it audits. Without it, independence is an assertion. With it approved by the committee, it is a decision somebody made on a date.
The annual plan answers “why these audits and not others?” (Standards 2010 and 2020.) A plan nobody approved is a to-do list. A plan the committee approved is a mandate, and the difference shows up the first time an auditee argues that this quarter is a bad time.
The audit universe answers “what did you decide not to audit?” (Standard 2010.A1.) This is the one most functions skip, and it is the one that makes the plan defensible: a list of five engagements proves nothing on its own, but a list of five engagements drawn from a register of forty entities, each scored for risk, is a statement about coverage.
The QA programme answers “how do you know you are any good?” (Standards 1300 and 1312.) Internal self-assessment on a cadence, plus an external validation at least once every five years. It is the part that most often exists as an intention rather than a record.
One page, six tabs
The dashboard reads live from the four records: a charter active at version 1, a plan in execution with one of its seven engagements complete, an entity in the universe already overdue, hours tracking against what was budgeted, and the last quality assessment with its rating.
What is not visible here is the behaviour underneath, and it is worth stating. Every figure is either a real measurement or an explicit blank. A charter with no approval reads as no approved charter rather than a zero; an audit universe with nothing registered in it says exactly that instead of reporting nought overdue in a reassuring green. “0 overdue of 0 entities” and “0 overdue of 40 entities” are opposite states, and a dashboard that renders them identically is telling you that you are fine when it means it has nothing to go on.
The charter
A charter here is a versioned record with a lifecycle: draft, submitted for approval, active. Drafting one is a form with five statements; approving it is a separate act, and it requires naming the audit or board committee that approved it.
That requirement is not decoration. Standard 2020 expects the plan and the charter to be approved by the board or its audit committee, and a charter whose approval cannot be traced to a committee is an internal document rather than a mandate. Talarity refuses the approval rather than recording it loosely — if the organisation has no audit or board committee yet, the approval dialog says so and points at where to create one, instead of failing on submit with something unhelpful.
Approving a new version supersedes the previous one automatically, and only one charter is active at a time. The old versions stay in the history table, because “what did the charter say when that decision was taken?” is a real question with a date attached.
The annual plan
A plan is a fiscal year, a risk-assessment methodology, and a roster of engagements. Each engagement carries a type, a priority, a quarter or planned dates, an estimated effort and a lead auditor.
The lifecycle mirrors the charter’s — draft, submitted, approved — with the same committee requirement, and one additional rule worth knowing: a plan with no engagements cannot be submitted for approval. An empty plan is not a plan, and asking a committee to approve one wastes their meeting.
Two things about the figures. Completion counts engagements that reached completed, and hours compares logged effort against what was estimated — so both depend on somebody moving an engagement through its states and recording the time as the year runs. Editing an engagement is where that happens, and the states it can move to are only the ones that make sense from where it is. Deferring or cancelling one requires a reason, because “why did that audit not happen?” is exactly the question the plan exists to answer, and an engagement that quietly disappears from a year takes the answer with it.
Roll forward clones an approved plan’s roster into a fresh draft for the next year, clearing approvals and actuals and carrying scope and leads across — most annual plans are last year’s plan with three things changed. Archive retires a year once it is finished, which releases that fiscal year so a new plan or a roll-forward can take its place. Only one plan per year can reach approved or beyond, which is what stops two competing versions of the same year’s mandate; drafts for a year can sit alongside it.
The audit universe
The universe is the register of what could be audited — processes, systems, vendors, locations, functions, products, subsidiaries — each scored for risk and given an audit frequency. Next-due dates are computed from the last audit and the frequency, and anything past due is highlighted.
You do not have to type it from nothing. Add from catalogue offers twenty entities most organisations audit — accounts payable, logical access management, IT change management, vendor management — each with a suggested frequency, and marks the ones your register already holds so you are not offered a duplicate. What it adds arrives unscored, on purpose — the frequency comes across as a starting point, but the risk score is the judgement, and the whole argument of the next section is that the judgement is yours. It is the fastest way past the blank page, and the blank page is where most audit universes die.
The register is the one table here built to grow: it has a search box, filters for entity type and “overdue only”, and pages at twenty-five. The two filters run against the whole register rather than the page in front of you — which is the difference between a filter and a convenience once you are past the read limit — and Overdue only is the one that earns its place, because “what is late?” was otherwise a question you answered by sorting a column and reading. The search box queries the register itself, matching an entity’s name or its business unit — so it finds rows the page in front of you has not even loaded.
The suggested score column is the interesting one. You tell an entity which risks it is exposed to — picking them from your live register when you add or edit the entity — and any engagement that covers the entity carries its own linked risks in too. Talarity then takes the highest residual risk across that set and scales it onto the universe’s nought-to-ten range. It writes that as a suggestion and never as the score. Accepting one is a separate click.
This is deliberate, and worth stating plainly: a risk-based plan whose risk scores were set by an algorithm nobody reviewed is not defensible, and the moment the suggestion becomes the score automatically is the moment the auditor stops being able to explain their own plan.
There is a second way a suggestion can appear, and you should know about it before you accept one. When nothing is explicitly linked, Talarity falls back to inference, and it does so two ways. It matches a risk’s category against the entity’s name — so an entity called “Financial reporting process” quietly collects every risk categorised Financial — and it also sweeps in every risk that shares the entity’s business unit. Either is a reasonable prompt and a poor score: one is pattern-matching on a word, the other on an org chart, and neither is a judgement about exposure. Both matter when you go to check one, because an inferred score whose match came from the business unit will show no category overlap at all, and a reader who only knew about the name rule would conclude the figure was broken. The column says which one you are looking at: from 3 linked risks where you made the connection, inferred, not linked where the system guessed — and the second is toned as a caution, because it is one. Treat it as a question rather than an answer.
Both of those labels are controls, not captions. Press either and you get the risks themselves, with the one carrying the highest residual — the one that actually set the number — named as such, and a note where a cited risk has since left the register. The inferred one opens under a different heading, “Risks this suggestion matched”, because what it lists is a guess rather than a connection you made. Provenance you cannot inspect is an assertion, and you are being asked to accept a score on the strength of it — most of all on the row the product itself tells you to question.
Where neither path finds anything, the cell says no linked risks rather than showing a low number — an entity nobody has assessed must not read as an entity nobody needs to worry about, and a bare dash makes a reader wonder whether the feature is broken instead of telling them what to do next. A row that has never been through a refresh says that instead, which is a different fact and a different fix.
Next-due dates are computed, not typed, so each one carries the cadence that produced it — every 12 months beside the date, or no cadence set where there is none. A derived date whose input appears nowhere cannot be checked, and an entity with no cadence is the one case where recording an audit leaves the date exactly where you put it.
The clock starts when you adopt the entity, not when you first audit it. That sounds like a detail and is the difference between a register that works on day one and one that does not: if a due date needed a previous audit to exist, then a function being stood up — which by definition has audited nothing yet — would have no due dates at all, nothing could ever be overdue, and the plan would have nothing to prioritise from until somebody hand-recorded an audit that never happened. Give an entity a cadence and it is on the clock from the day it enters the register. An entity you add today is therefore due a cadence from today — not immediately. What can be overdue on the day you look is an entity you record a past Last audited date against, which is exactly how a function that has been auditing for years loads its real history in.
Entities can be retired when a process is outsourced or a system decommissioned. They stay in the register, marked, because the history of having audited something is part of the record — and they stop counting towards the figures. That is why the dashboard’s entity count is smaller than the number of rows in the register: one is what you are responsible for auditing, the other is what you have ever been responsible for. A retired row also stops offering Mark audited and says “not scheduled” where the others state a cadence, because a decommissioned system is not on a cycle and should not be recording audits against itself.
Quality assurance
An assessment covers a period, names who performed it, and ends with a conformance rating — generally conforms, partially conforms, or does not conform. Submitting it locks the rating and computes when the next one is due: twelve months for an internal assessment, sixty for an external validation, per Standard 1312’s five-year expectation.
One rule the form enforces, and it is the point rather than paperwork: a rating below “generally conforms” requires at least one principle finding — the rating is an assertion that something did not conform, and the assessment has to say what.
Alongside the findings, the assessment carries a separate list of improvement actions, each with an owner and a due date. Both lists start at three rows and Add another extends them, so an external validation that raised five principle findings records five. Be clear about what that is and is not, though: the two lists sit side by side rather than joined, so nothing records which action answers which finding, and the owner is a name typed into a box rather than a person the system can chase. It is a record of what you intend to do, not a tracker that will follow it up.
Submitting an assessment is also what starts the external-validation clock. Until it happens the next due date is blank, which means an overdue external validation cannot be flagged — the record has to exist before anything can be measured from it.
A submitted assessment then goes to the committee, and what comes back is recorded against it: Record acceptance closes the assessment against the audit or board committee that received it, the same way the charter and the plan are approved. That matters for the same reason it matters there — an assessment the committee has seen and one that is merely finished look identical otherwise, and only one of them answers Standard 1300.
The calendar
The calendar places each engagement in a quarter by its planned start, falling back to the quarter it was scheduled into, and marks the universe entities coming due in the same year alongside them. It is the view that answers “is this plan actually deliverable?” Above, Q4 carries three of the year’s seven engagements and two entities coming due — the heaviest quarter, and visible as such in February rather than in October. A year that stacked twice that into one quarter would be a resourcing problem, and this is the only screen that would say so before it happened.
Every card and every marker opens the thing it names — the engagement, or the register entry falling due. A screen whose job is to point at what needs attention should be the place you act on it, not a place you read a name and then go hunting for it in a list. An entity whose due date fell in an earlier year and has passed surfaces in Q1 rather than dropping off the schedule entirely — the oldest overdue work is the last thing that should be invisible here.
One thing to be clear about, because the heading says “FY”: the quarters are calendar quarters, and the page says so under the grid. There is no fiscal-year-start setting — an organisation whose financial year opens in April sees January-to-March as Q1, the same as everyone else. If you use this alongside a non-calendar financial year, read the columns as calendar quarters of the plan year and not as your own Q1 through Q4.
Where the feature ends
Worth being plain about the boundaries, because they are the difference between a system that records your audit function and one that runs it.
Nothing here reminds anybody of anything. A charter review date, an entity going overdue, an external validation coming due at five years — every one of those is computed and none of them notifies you. They appear when you open the page. The data model was built for reminders that have not been written, and a function relying on this today needs its own calendar entry for the annual charter review.
One table filters and pages; the other four do not. The audit universe — the register that actually grows — has a search box, filters for type and “overdue only”, and pages at twenty-five. The type and overdue filters are applied across the whole register rather than across the page in front of you, which matters once you are past the read limit; the search box refines what comes back, and matches what you can see, including the “retired” marker on a decommissioned entity. There is no business-unit filter, deliberately: its values are free text, so any dropdown would have to be built from the entities already loaded and would silently omit the ones beyond them. The charter’s version history, the plans list, a plan’s engagements and the QA assessments are all still a single unbroken list. At forty rows that is fine; at four hundred it is a long page. Every read here is capped — past five hundred entities, or a thousand engagements on one plan — and each screen that hits its cap says so, including the calendar, rather than quietly showing you less than you have.
Nothing exports from these screens — but the records are reportable. There is no CSV button and no print view on the charter, the plan, the register or the QA tab; if you want the register in a spreadsheet from this page, you are copying it out by hand. What you can do is build a report. Each of the four documents is a dataset in the reporting module — engagements already were — so an audit universe with its coverage dates, an annual plan with its hours and engagement counts, the charter’s full version history and the QA programme with its five-year clock can each be queried, grouped and put in front of a committee through the same surface every other part of the product reports through. All five record types are in global search too, so typing an engagement name or an entity name finds the record itself rather than only the page it lives on.
The committee brief is the artifact this feature produces, and it goes somewhere useful. Present to committee generates a PDF from an approved plan or a submitted QA assessment and attaches it to a scheduled committee meeting. It is then filed twice over: as a retained artifact against that agenda, and as a compliance report in the evidence library — so the brief is citable as evidence elsewhere in the product rather than only browsable from the meeting it was attached to. That matters more than it sounds, because a committee brief is precisely the document an assessor asks for when testing whether an audit function reports to anybody.
The links run one way, and there is no link graph behind them. Starting fieldwork on an engagement creates the audit in Audit Management — scope, period and lead auditor carried across, linked in one action — and from there it carries workpapers, findings and evidence. That direction works well. The other does not: a control does not list the audits that covered it, and a risk does not list the auditable entities pointing at it. Be precise about why, because the two halves differ. “This audit covered that control” is already recorded — mapping controls into an engagement’s scope writes it — so what is missing there is only the read: nothing on a control’s own page lists the audits that covered it. The other half needs one thing more: the link table’s vocabulary has no term for an auditable entity, so “this risk is watched by that entity” has nowhere to be recorded until that term is added. Both halves are unbuilt work rather than a design limit — one is a read nobody makes, the other a word nobody has added — but they are not the same size of missing.
Records can be created and advanced, but not always corrected. A plan, an engagement and a universe entity can each be edited. A charter cannot: the only path is a new version, and if you want to fix a typo in a draft you discard it and retype five statements. A draft plan created by mistake cannot be removed at all: there is no delete, and archiving explicitly refuses anything still in draft, so it stays in the plans list permanently with no terminal state available to it. A QA assessment cannot be edited or removed at any status — not once submitted, and not while it is still in progress. None of this loses data, and all of it is the kind of thing you notice on the day you make a mistake rather than the day you read about the feature.
Two people editing one engagement will overwrite each other. Every mutation here reads, checks and writes, with no version check between — so the second save wins silently. On a plan reviewed by one team in one sitting that is invisible; on a function where a manager and a lead auditor both keep the roster current, it is a real way to lose an afternoon’s edits without an error message.
What you walk away with
- A charter that names its own authority, approved by a committee, versioned, with the previous version still readable.
- An annual plan you can defend — engagements chosen from a scored register, approved by the people who have to approve it, with a real completion and effort picture as the year runs.
- A universe that says what you decided not to audit, which is the half of coverage most functions cannot evidence.
- A quality programme with dates on it, including the five-year external validation the standard requires and most functions discover late.