Most internal audit plans treat technology the way a map treats weather: acknowledged, unavoidable, and not really on the page. The plan lists processes and business units, and somewhere in it sits a line called “IT general controls” or “cybersecurity” with a few hundred hours against it, chosen because that is what was there last year. Meanwhile the organization runs on forty applications, six cloud accounts, a dozen SaaS providers and two legacy systems nobody dares touch, and the question of which of those the function will actually look at, and on what basis, has never been answered in writing. When the ransomware arrives, or the ERP migration goes wrong, or the external auditor asks why the payroll provider’s report was never read, the absence of that answer is the finding.
This guide is the method for building the IT audit plan as a layer of the enterprise plan: an IT universe assembled from sources that already exist, a risk assessment with ten scored factors that produces a defensible ranking, a coverage map that shows what is assured by whom and what is assured by nobody, cycle rules that turn the ranking into engagements and hours, and a way of reporting the result to the audit committee that makes uncovered risk visible. It folds the IT risk assessment into the planning method rather than treating it as a separate exercise, because in practice the two are one document. The worked example is MidState Beverage, a three-state drinks distributor whose six-person function built its first IT universe in 2026, scored 38 items, and used the result to place the ERP access, change management, backup and cybersecurity work that appears throughout this site’s IT guides. It assumes the reader knows the enterprise planning method and the risk assessment method behind it; this is the technology layer of both.
In this guide
- Why technology needs its own layer of the plan
- Step 1: build the IT universe from sources that already exist
- Step 2: the IT risk assessment, with ten scored factors
- Keeping the assessment alive: refresh triggers between planning cycles
- Step 3: the coverage map, and the assurance you can rely on
- Step 4: cycle rules, hours and the co-sourcing decision
- Step 5: from plan lines to engagement scopes
- Step 6: reporting IT coverage to the audit committee
- The IT universe and scoring worksheet
- Worked example: MidState Beverage builds its IT universe and plan
- Common mistakes
Why technology needs its own layer of the plan
The enterprise audit universe is organized by process and entity because that is how risk is owned: someone runs procurement, someone runs the Ohio depots. Technology risk does not respect that structure. A single ERP carries the procurement, revenue, inventory and financial close processes of every entity at once; a single identity directory decides who can do anything in any of them; a single backup failure takes them all down together. If the plan covers technology only as a component of each process audit, the ERP’s change management gets examined eleven times shallowly and its backup never, and the identity directory is nobody’s scope. If the plan covers technology only as a separate “IT audit” block, the block fills with whatever the IT auditor is comfortable with and the business processes lose the technology context that explains most of their findings. The IT layer of the plan exists to resolve this: a universe of technology items risk-assessed on their own terms, mapped to the processes they serve, and covered by a mix of dedicated technology engagements and technology scope inside process engagements.
Three external requirements make the layer harder to skip than it used to be. The Global Internal Audit Standards require, in Standard 9.4, a plan based on a documented assessment of the organization’s strategies, objectives and risks, updated as risks change; a plan that cannot show how technology risk was assessed does not meet it, and the GIAS guide covers the standard in full. The IIA’s Topical Requirements add mandatory minimum content when a topic is in scope: the Cybersecurity Topical Requirement, effective 5 February 2026, and the Third-Party Topical Requirement, effective 15 September 2026, each specify what governance, risk management and control elements an engagement on that topic must assess, which means the plan has to know when those topics are in scope and budget accordingly; the Topical Requirements guide explains the applicability triggers. And regulators and external auditors increasingly ask the direct question of what technology assurance exists across the estate, which is a question the coverage map answers and nothing else does.
Step 1: build the IT universe from sources that already exist
The IT universe is the list of technology items that could be audited. Nobody in the organization has this list, but several people have pieces of it, and building the universe is mostly reconciliation. The configuration management database, if one exists, holds infrastructure and some applications. The SOX system inventory holds the financially relevant applications. The cloud provider consoles hold every account and subscription. The vendor master and the contracts register hold the SaaS providers and managed-service arrangements. The project portfolio holds the migrations and implementations in flight. The security team’s asset inventory, the business continuity plan’s system list and the software licensing records fill in the rest, and each list will contain items the others lack. The table gives the seven layers of a complete universe, the usual sources, and the items that go missing.
| Layer | What belongs in it | Usual sources | Items that go missing |
|---|---|---|---|
| Applications | Every application supporting a business process, with the processes it serves, its owner, hosting model and financial-reporting relevance | SOX system inventory, application catalog, licensing records | Departmental tools, spreadsheets used as systems, acquired entities’ applications |
| Infrastructure | Data centers, server estates, cloud accounts and subscriptions, networks, directories, databases, end-user computing | CMDB, cloud consoles, network diagrams | Shadow cloud accounts, unmanaged network segments, operational technology |
| IT processes (the ITGC domains) | Identity and access, privileged access, change management, SDLC, operations and job scheduling, backup and recovery, incident and problem management, vulnerability and patch management, security operations, IT vendor management, IT asset management | IT policies, ITSM tool, security program documents | Processes run informally by one person; processes outsourced to a managed-service provider |
| Third parties | SaaS providers, hosting providers, managed-service providers, outsourced development, payment and payroll processors | Vendor master, contracts, accounts payable analysis, SOC report register | Providers paid by card or expense claim; subcontractors of primary providers |
| Data | Data stores holding personal, cardholder, health or financial data; data warehouses and reporting platforms; data flows across borders | Privacy records of processing, data classification, analytics platform inventory | Extracts held in file shares; reporting databases fed by uncontrolled interfaces |
| Programs and projects | ERP migrations, cloud moves, integrations of acquisitions, AI deployments, major upgrades | Project portfolio, steering committee papers | Projects run by the business without IT; vendor-led implementations |
| Enterprise technology programs | The cybersecurity program, business continuity and resilience, AI governance, data governance, IT governance itself | Program charters, board reporting | Programs that exist as policies with no owner |
Two rules keep the universe usable. First, every item has an owner in the business or in IT, a link to the processes it serves, and a hosting and support model; without those three attributes the item cannot be risk-assessed or scoped. Second, the universe is a working document with a version and a review date, refreshed at least annually and whenever the project portfolio changes, and reconciled each year to the sources it was built from. A universe of thirty to sixty items is typical for a mid-sized organization; several hundred for a large one. The number matters less than the completeness, and the completeness is tested by reconciliation, exactly as the backup audit reconciles the inventory to the backup jobs.
Step 2: the IT risk assessment, with ten scored factors
The IT risk assessment scores each universe item on a fixed set of factors so that the ranking can be explained, challenged and repeated. Ten factors are enough; more produces false precision, fewer misses the drivers that actually distinguish a critical system from a merely important one. Each factor is scored 1 to 5 against written criteria, the scores are weighted, and the weighted total ranks the universe. The weights are a judgment and should be recorded with the reasoning; a distributor with thin margins and a public company under SOX will weight financial-reporting impact differently, and both are right. The table gives the factors, the criteria that anchor the scale, and the evidence that supports the score, because a score without evidence is an opinion and the audit committee will eventually ask.
| # | Factor | Score 1 | Score 5 | Evidence for the score |
|---|---|---|---|---|
| 1 | Financial reporting impact | No financial data | Initiates, records or reports material transactions or balances; SOX in scope | SOX scoping, process mapping, transaction volumes and values |
| 2 | Business criticality | Days of outage tolerable | Hours of outage stop revenue, deliveries or payments; critical tier in the BIA | Business impact analysis; recovery objectives |
| 3 | Data sensitivity and regulatory exposure | Public or internal data only | Large volumes of personal, cardholder, health or regulated data; statutory breach obligations | Data classification; privacy records; contractual obligations |
| 4 | External exposure | Internal network only, no third-party access | Internet-facing; third-party or customer access; integrations with external parties | Network architecture; access inventory; penetration test scope |
| 5 | Complexity and customization | Standard package, no customization | Heavily customized or bespoke; many interfaces; undocumented logic | Custom object counts; interface inventory; documentation review |
| 6 | Change velocity | Rare vendor patches only | Continuous deployment; major project in flight; frequent configuration change | Change records; project portfolio; deployment frequency |
| 7 | Age and technical debt | Current version, supported | End of vendor support; unsupported platform; key-person dependency | Vendor support status; staffing; incident history |
| 8 | Third-party dependency | Fully in-house | Operated by a vendor with no assurance report or with exceptions; single provider with no exit | Contracts; SOC report register and review memos |
| 9 | Control history | No findings or incidents in three years | Open high findings, repeat findings, incidents or breaches, SOC exceptions in relevant objectives | Issue log; incident register; SOC memos; external audit comments |
| 10 | Time since last assurance | Assured within twelve months by a source we rely on | Never assured, or assurance older than the cycle rule | Coverage map |
Two inputs improve the scoring and are often left out. Management’s own IT and cyber risk registers, maintained by the second line or the security function, contain the risks the organization has already identified and rated; the auditor’s assessment should be reconciled to them, and disagreements recorded, in the same way the enterprise risk register and RCSA results feed the enterprise plan. And technical evidence, vulnerability scan results, penetration test findings, phishing simulation rates and patch latency metrics, gives factors 4, 7 and 9 an objective basis that an interview does not. The assessment is inherent risk adjusted for what is known about control; it is not the audit. Its output is a ranked universe with each score traceable to evidence, which is the document the rest of the plan is built on and the one to keep when the audit committee asks, two years later, why a system that failed was not on the plan.
Keeping the assessment alive: refresh triggers between planning cycles
An IT risk assessment dated January is wrong by June. Systems go live, providers change hands, a breach happens at a peer, a project slips its cutover into the quarter-end, the one administrator who understood the legacy platform resigns. Standard 9.4 expects the plan to be updated as risks change, and the IT layer is where change is fastest, so the assessment needs defined triggers that force a re-score of the affected items and a plan decision, rather than waiting for the next annual cycle. The triggers should be written into the planning procedure and monitored through sources the function already reads: the project portfolio, the incident register, the vendor management log and the second line’s risk register. The table gives the triggers that matter and what each does to the score.
| Trigger | Factors affected | Typical plan response |
|---|---|---|
| New system go-live or major upgrade | Change velocity, complexity, control history (reset), time since assurance | Post-implementation review within two quarters; automated controls re-baselined |
| Acquisition or divestiture | Every factor for the inherited items; universe completeness | Universe rebuilt for the acquired estate; access and backup assessed before integration |
| Security incident or breach, internally or at a peer | External exposure, control history | Targeted review of the affected domain; cyber program audit brought forward where the incident reveals a program gap |
| Vendor change, insolvency risk or SOC exception | Third-party dependency, control history | SOC review repeated; exit and contingency arrangements assessed |
| Regulatory change affecting data or resilience obligations | Data sensitivity and regulatory exposure | Compliance-driven engagement added; Topical Requirement applicability reassessed |
| Key-person departure on a legacy or bespoke system | Age and technical debt | Documentation and continuity review; migration timeline challenged |
| Project slippage past a financial period-end | Change velocity, financial reporting impact | Advisory engagement on cutover controls and interim manual controls |
Step 3: the coverage map, and the assurance you can rely on
The coverage map is a matrix: universe items down the side, the ITGC domains and assurance topics across the top, and in each cell the source of assurance over that domain for that item and the date of the last coverage. Its purpose is to show, item by item, what has been assured, by whom, how recently, and what has not been assured by anyone. Internal audit is one source among several. SOX testing by management and the external auditor covers ITGCs over in-scope systems every year. Service auditors’ SOC 1 and SOC 2 reports cover outsourced platforms, subject to the review method and their exceptions. Penetration tests, ISO/IEC 27001 certification audits, regulator examinations and second-line assessments each cover something. Standard 9.5 of the Global Internal Audit Standards allows the function to rely on other assurance providers where it has assessed their competence, objectivity and method, and the reliance criteria apply here as much as they do to compliance functions. A cell filled by a source the function has not assessed is a hope, not coverage.
| Universe item (score) | Access and SoD | Change management | Operations, backup and recovery | Security and vulnerability | Third-party assurance | Gap |
|---|---|---|---|---|---|---|
| Core ERP (4.6) | Internal audit FY27 (user access engagement) | Internal audit FY27 (within ICFR support) | Internal audit FY27 (restore test within acquisition integration) | External penetration test FY26; cyber program audit FY27 | Not applicable | Job scheduling and interface operations never assessed |
| Payroll SaaS (3.9) | SOC 1 Type 2 (CUEC gaps found FY27) | SOC 1 Type 2 (exception evaluated) | SOC 1 Type 2; customer-side export never tested | Vendor SOC 2 not obtained | SOC 1 reviewed FY27; hosting subservice report obtained | Customer-side data recovery; SOC 2 |
| Identity directory (4.2) | Internal audit FY27 (privileged access within user access engagement) | Never assessed | Never assessed | Cyber program audit FY27 | Not applicable | Directory change control; directory recovery |
| Acquired depot systems (4.4) | Never assessed | Never assessed | Internal audit FY27 (no backup found) | Never assessed | None | Everything except backup; migration planned FY28 |
| Fleet telematics (2.8) | Never assessed | Vendor-managed; no report | Not backed up (FY27 finding) | Never assessed | None | Full; low score, deferred to FY29 |
The map does three things at once. It stops the function from re-testing what the external auditor tested three months ago, which is the commonest waste in IT audit. It exposes the items and domains nobody has assured, which are the plan’s priorities regardless of their score, because an unassessed high-scoring item is exactly the finding the audit committee will not forgive. And it turns the reliance decisions into a record: which SOC reports, which penetration tests, which second-line assessments the function relied on, and on what basis, which is the evidence Standard 9.5 requires and the evidence an external quality assessment will ask for.
Step 4: cycle rules, hours and the co-sourcing decision
Cycle rules convert the ranking into a schedule. They are stated in advance, applied consistently and departed from only with a recorded reason, because a cycle rule that bends every year to whatever is convenient is not a rule. The table gives a workable set. The mandatory rows exist because certain coverage is required annually regardless of score: ITGCs over SOX systems, because the reliance decisions renew every year; privileged access, because it is the control that fails fastest; and, where the cybersecurity program is in scope in a given year, the full content of the Cybersecurity Topical Requirement. Everything else follows the tiers.
| Tier or rule | Criterion | Coverage cycle | Typical form |
|---|---|---|---|
| Tier 1 | Weighted score 4.0 or above, or any item with an open high finding | Every year | Dedicated engagement or substantial technology scope in the related process engagement |
| Tier 2 | Score 3.0 to 3.9 | Every two years, with continuous monitoring in the off year where analytics exist | Focused engagement on the highest-scoring domains |
| Tier 3 | Score below 3.0 | Every three to four years, or by reliance on other assurance | Reliance review, light-touch assessment, or inclusion in a thematic review |
| Mandatory: SOX ITGCs | Any system in SOX scope | Every year | Coordinated with management testing and the external auditor to avoid duplication |
| Mandatory: privileged access | Directories, ERP, cloud accounts | Every year | Within the user access engagement |
| Mandatory: Topical Requirements | Cybersecurity or third-party management in scope of an engagement | When in scope; program-level assessment at least every two to three years for most organizations | Engagement designed to the Requirement’s minimum content |
| Programs and projects | Any tier 1 or 2 item undergoing migration or implementation | During the project, at go-live decision points | Advisory or assurance on project controls, data migration and cutover |
Hours follow from the cycle through the capacity model in the planning guide: each planned engagement gets an estimate, the estimates are summed against the technology skills available, and the gap is closed by co-sourcing, deferral or scope reduction, in that order for tier 1 items and the reverse for tier 3. The co-sourcing decision is where most functions under-invest. A six-person function cannot employ a specialist in cloud security, ERP security and identity architecture, and it does not need to; it needs a co-source arrangement that supplies those skills for defined engagements under the function’s direction, and the co-sourcing guide covers the models and the contract terms. The plan should state the co-sourced hours per engagement and the skill they buy, so that the audit committee sees the cost of technology coverage as a line rather than a surprise.
Step 5: from plan lines to engagement scopes
A plan line says “ERP user access, 550 hours.” An engagement scope says which ITGC domains, which systems and layers, which period, which tests and which reliance. The translation happens in the planning memo for each engagement, and the IT layer of the plan makes it easier because the universe entry already holds the system’s processes, owner, hosting model and prior coverage. The table maps the common plan lines to the guides on this site that supply the engagement method, which is the fastest way to turn a line into a work program. Two scoping habits matter. Technology scope inside a process engagement should be written explicitly, “including change management and privileged access over the ERP modules used by the process,” so that it is budgeted and reported rather than assumed. And every technology engagement should state the layers it covers, application, database, operating system, network, and the ones it does not, because the layer decision is where most disagreements with the external auditor begin.
| Plan line | Typical scope | Method on this site |
|---|---|---|
| Identity and access management program | Joiner, mover, leaver; authentication; role design; access certification; across directory and key applications | IAM audit; user access review |
| Privileged access | Administrative accounts, vaulting, break-glass, service accounts, cloud admin roles | Privileged access audit |
| Segregation of duties in the ERP | Conflict matrix, effective access extraction, remediation and mitigation | ERP SoD analysis; SoD framework |
| Change management | Ticket to production for in-scope systems; pipelines; emergency and standard changes; data and configuration changes | IT change management audit |
| Automated controls and configuration | Key configured controls by financial cycle; interfaces and scheduled jobs | Testing automated controls; ITGC vs application controls |
| Backup and recovery | Inventory reconciliation, recovery objectives, restore testing, ransomware architecture | Backup and recovery audit; resilience |
| Cybersecurity program | Governance, identify, protect, detect, respond, recover; Topical Requirement content | Cybersecurity program audit |
| Cloud | Shared responsibility, configuration, identity, logging, provider assurance | Cloud audit |
| Third-party technology providers | SOC report review, CUECs, subservice organizations, contract and exit | SOC 1 review; Third-Party Topical Requirement |
| AI and models | Inventory, lifecycle controls, validation, governance | AI audit framework; model risk audit |
Step 6: reporting IT coverage to the audit committee
The audit committee does not need the universe or the scoring; it needs four things the plan can now give it. The proportion of tier 1 technology items that will be covered in the year by internal audit or by assurance the function has assessed, with the uncovered items named. The technology risks the function considers highest and whether the plan addresses them. The reliance placed on other assurance providers and the basis for it. And the cost of technology coverage, including co-sourcing, as a line the committee can compare with the risk. One slide in the annual plan presentation and one in each quarterly update carries this; the audit committee deck template has a place for it. The habit to build is naming the uncovered items out loud. A committee told that the acquired depot systems, the fleet telematics platform and the directory’s change control will not be assured this year, and why, has been given a decision; a committee shown a green coverage chart has been given a comfort it will remember when something breaks.
The IT universe and scoring worksheet
The worksheet below is the row structure for the universe and assessment, written so it can be built in a spreadsheet or in the function’s audit management system. One row per universe item; the scoring columns carry the 1 to 5 scores with the evidence reference; the coverage columns carry the map. The internal audit plan template is the document the ranked output feeds into, and the templates directory lists the companions.
IT universe and risk assessment worksheet. Version: ________ Prepared by: ________ Date: ________ Reviewed by: ________ Sources reconciled: ________
A. Identification. Item reference; name; layer (application / infrastructure / IT process / third party / data / project / program); description; business processes served; business owner; IT owner; hosting and support model (on-premises / cloud / SaaS / managed service); SOX relevance (yes / no); BIA tier.
B. Risk factors (score 1 to 5, each with an evidence reference). 1 Financial reporting impact; 2 Business criticality; 3 Data sensitivity and regulatory exposure; 4 External exposure; 5 Complexity and customization; 6 Change velocity; 7 Age and technical debt; 8 Third-party dependency; 9 Control history; 10 Time since last assurance.
C. Weighting and result. Weights per factor (recorded once for the whole universe with the reasoning); weighted score; tier; management’s own risk rating for the item and any difference explained.
D. Coverage map. For each domain (access and SoD; change; operations, backup and recovery; security and vulnerability; third-party assurance; project controls): source of last assurance, date, result summary, reliance assessment reference; gap flag.
E. Plan decision. Cycle rule applied; planned coverage year and form; engagement reference; estimated hours (in-house and co-sourced); deferral reason where the rule is not followed; audit committee disclosure flag for uncovered tier 1 items.
Worked example: MidState Beverage builds its IT universe and plan
MidState Beverage distributes drinks across three states from twelve depots and three hundred routes, on roughly 221 million dollars of revenue, with a 2013 ERP route-accounting module, depot spreadsheets, two recently acquired distributors still on their own systems and a six-person internal audit function led by a CAE who reports to the audit committee. Before 2026 the function’s plan carried a single line, “IT general controls review, 400 hours,” which had been performed twice in five years by a co-source firm and had never covered the acquired depots, the payroll provider or the backup regime. The FY27 planning cycle was the first to build the IT layer, and the analytics and IT auditor did it in about 120 hours over six weeks.
The universe came to 38 items from six sources: the ERP and its route-accounting module, warehouse and fleet systems, the payroll and benefits provider, the banking portal, the depot spreadsheet estate treated as a single item, the identity directory, the on-premises server estate and the backup platform, the network, two cloud subscriptions nobody in finance knew existed, the two acquired depots’ systems, seven SaaS tools found through the vendor master, the eleven ITGC process items, the planned ERP migration, and the cybersecurity and resilience programs. Reconciling the vendor master to the IT team’s list added nine items; reconciling the cloud consoles added the two subscriptions. Scoring used equal weights except for financial reporting impact and business criticality at 1.5, recorded with the reasoning that the company’s covenant reporting and daily settlement made those two dominant. The top of the ranking was unsurprising and useful: the ERP and route-accounting module at 4.6, the acquired depot systems at 4.4 (no assurance ever, end-of-support servers, key-person dependency), the identity directory at 4.2, the backup platform at 4.1, and the payroll provider at 3.9. The depot spreadsheet estate scored 3.7, higher than the IT team expected, on financial impact and control history.
| Universe item | Weighted score | Tier | FY27 plan decision | Hours |
|---|---|---|---|---|
| ERP and route-accounting module: access and SoD | 4.6 | 1 | Dedicated engagement (plan engagement three): user access, privileged access, SoD | 550 in-house plus 140 co-sourced ERP security specialist |
| ERP: change management and automated controls | 4.6 | 1 | Technology scope inside ICFR support (engagement six) | Approximately 220 of the 900 |
| Backup platform and ERP recovery | 4.1 | 1 | Restore test and backup review inside acquisition integration (engagement two) | Approximately 120 of the 750 |
| Acquired depot systems | 4.4 | 1 | Access, backup and migration controls inside acquisition integration | Approximately 200 of the 750 |
| Identity directory | 4.2 | 1 | Privileged access within engagement three; change control deferred to FY28 with disclosure | Within the 550 |
| Payroll provider | 3.9 | 2 | SOC 1 review and CUEC testing within ICFR support | Approximately 40 of the 900 |
| Cybersecurity program | 3.8 | 2 | Planned FY28; brought forward in-year at the audit committee chair’s request under Standard 9.4 | 540 added in-year |
| Depot spreadsheet estate | 3.7 | 2 | Covered through route cash engagement (engagement one) and backup review | Within existing engagements |
| Fleet telematics; seven SaaS tools; two cloud subscriptions | 2.1 to 2.9 | 3 | Reliance review of available vendor reports; cloud subscriptions inventoried and access reviewed in analytics hours | 60 of the 600 analytics hours |
The plan presented to the audit committee showed technology coverage of all five tier 1 items in FY27, with two disclosures: the identity directory’s change control and recovery would not be assured until FY28, and the acquired depot systems would be covered for access and backup but not for change management pending their migration. The committee accepted both and asked that the cybersecurity program, then a tier 2 item scheduled for FY28, be presented as a standing agenda item; when a peer distributor lost its route accounting to ransomware that spring, the chair’s request to bring the cyber audit forward was accommodated under Standard 9.4 by deferring the fleet advisory, and the plan amendment cited the universe entry and score in one sentence. The findings that the FY27 engagements then produced, the self-approved overrides, the unauthorized settlement data changes, the failed transaction-log backups, the terminated users on the payroll portal, each traced back to a universe item and a scored factor, which is the test of whether a plan was built on a risk assessment or on last year’s plan.
Common mistakes
- Carrying a single “IT general controls” line. One line cannot express which systems, domains and layers are covered, so nobody knows what is not.
- Building the universe from the IT team’s list alone. Reconcile to the vendor master, cloud consoles, SOX inventory and project portfolio; the missing items are the risky ones.
- Scoring without evidence. A score that cannot be traced to a BIA tier, a data classification or an incident record is an opinion the committee will eventually challenge.
- Ignoring management’s own IT risk register. Reconcile to it and record the differences; disagreement is information.
- Re-testing what the external auditor tested. The coverage map exists to prevent this. Assess the other assurance and rely on it where it holds.
- Relying on assurance nobody assessed. A SOC report filed unread or a penetration test nobody scoped is not coverage under Standard 9.5.
- Bending the cycle rules silently. Depart from a rule with a recorded reason and a committee disclosure, or the rules stop meaning anything.
- Under-budgeting co-sourcing. Specialist skills for defined engagements are cheaper than a shallow review by generalists, and far cheaper than the finding that follows.
- Leaving technology scope implicit in process engagements. Write it into the scope so it is budgeted, performed and reported.
- Presenting coverage as a green chart. Name the uncovered tier 1 items and let the committee decide.
Related guides
- How to build an internal audit plan
- The internal audit risk assessment
- The internal audit plan template
- IT general controls: the complete primer
- SOX ITGC scoping
- The IIA Topical Requirements
- The Global Internal Audit Standards
- Auditing cybersecurity programs
- How to audit IT change management
- How to audit backups and recovery
- How to review a SOC 1 report
- Co-sourcing vs. outsourcing
- The audit committee deck template
- IT & Cybersecurity Audit guides
Leave a Reply