1. Mandate and applicability
Question: Is internal audit required, who approves it, and what is the reporting line?
Output: Applicability note, charter reference, audit universe and governance owner.
Applicability checker ->Internal audit quality improves when the file follows one connected operating model: applicability, SOW, plan, kickoff, walkthrough, RCM, sampling, fieldwork, monitoring, report, ATR and follow-up. This map shows which public CORAA resource belongs at each stage.
Download the lifecycle map as an editable Excel workbook or PDF. The Excel version includes stage outputs, public resource links, product-reuse shape, cycle workbook map and evidence rules.
Question: Is internal audit required, who approves it, and what is the reporting line?
Output: Applicability note, charter reference, audit universe and governance owner.
Applicability checker ->Question: Which cycles, locations, systems, exclusions and deliverables are approved?
Output: Scope of work, cycle coverage, deliverables list, exclusions and first data request.
SOW generator ->Question: Which reviews matter most, and can the team actually execute them?
Output: Risk-ranked annual plan, quarter loading, reviewer map and capacity gap.
Annual plan generator ->Question: Who owns evidence, access, timelines, blockers and escalation?
Output: Kickoff pack, stakeholder RACI, data request tracker and escalation protocol.
Kickoff pack generator ->Question: How does the process actually run before controls are tested?
Output: Walkthrough memo, document trace, system map and control design gap register.
Walkthrough memo generator ->Question: Which risks, controls, tests, evidence and sample basis will be used?
Output: RCM, audit programme, evidence expectations, analytics and reviewer prompts.
RCM builder ->Question: What population is tested, what sample is selected, and what did the evidence show?
Output: Sampling plan, fieldwork tracker, exceptions, evidence blockers and reviewer conclusion.
Sampling plan generator ->Question: Which exceptions should be tested repeatedly from source data?
Output: Rule register, source data map, threshold log, false-positive clearing and validated exceptions.
Monitoring rules repository ->Question: Which validated issues deserve reporting, and what will management do?
Output: Observation register, report shell, rating matrix, management response, dashboard metrics and committee summary.
Report pack ->Question: Was the agreed action implemented and evidenced after report issue?
Output: ATR, closure evidence, follow-up test, repeat-finding flag and auditor conclusion.
ATR tracker ->Vendor master, PR, PO, GRN, invoice match, GST/TDS/MSME, payments, advances and access.
Customer master, credit, dispatch, billing, GST, collections, credit notes, receivables and cut-off.
Close calendar, manual journals, reconciliations, provisions, reporting, tax tie-outs and access.
Bank mandates, receipts, payments, BRS, petty cash, deposits, cut-off and bank portal access.
Hiring, employee master, attendance, payroll, PF/ESI/PT, salary TDS, exits and HRMS access.
SKU master, GRN, issues, transfers, counts, ageing, NRV, costing, scrap, cut-off and access.
Capex, CWIP, FAR, physical verification, depreciation, disposal, impairment, insurance and access.
Bank mandates, cash forecast, borrowings, covenants, investments, BG/LC, forex, payments and BRS.
GST, ITC, TDS/TCS, income tax, ROC, payroll statutory, notices, portal access and monitoring.
Access, SoD, privileged users, changes, backups, interfaces, logs and report reliability.
Every sample should name the population, source report, extraction date, filters and control total used for selection.
Every observation should trace from condition to criteria, cause, effect, recommendation, management response and evidence.
Every monitoring exception should show rule logic, threshold, source data, false-positive clearing and reviewer conclusion.
Every ATR item should carry owner, target date, revised date, closure evidence, follow-up test and final auditor conclusion.
Every reusable template should carry version, change note and reviewer approval before it becomes methodology.
The website build should stay public, searchable and useful on its own. The internal-audit product build should be separate: it can reuse the same resources as product specifications, control libraries, rule logic, workflow states, export formats and dashboard requirements.
| Website resource | Separate IA product shape |
| Applicability checker | Entity setup, applicability logic and governance profile |
| SOW and kickoff tools | Engagement setup, scope lock, owner RACI and PBC workflow |
| RCM/checklist/workbook library | Control library, procedure library and cycle execution modules |
| Monitoring rules | Connector-backed exception engine and recurring rule queue |
| Report pack and ATR tracker | Issue workflow, management response, closure evidence and committee dashboard |
| Dashboard KPI pack | Command centre metrics, committee packet, emerging-risk coverage and monitoring dashboard |