Internal auditors ask process owners the same families of questions in every engagement, because every process has the same places to fail: where it starts and ends, who can do what, how approvals and access are controlled, how an error would be caught, what happens off the normal path, and whether anyone is watching. The 60 questions below are grouped into thirteen areas. Each table shows what the auditor is testing, what a strong answer contains, and the version of the answer that tends to become a finding. The pattern across all 60 is consistent: the answer that creates a finding is rarely the one that admits a flaw. It is the one that shows the owner does not know the facts, cannot produce the evidence, or describes the procedure instead of the practice.
This bank sits between two existing guides. The sixteen general questions almost every interviewee gets are in When internal audit interviews you; the “what could go wrong at this step” prompts auditors use while following one transaction are in the walkthrough question bank, and the auditee’s side of that session is in How to walk an auditor through your process. The questions here are the layer between: the area-specific probing that begins once the auditors understand the process and start testing where it could fail. The Being Audited? hub lays out the whole arc from notification to closure.
In this guide
- What auditors do with your answers
- Process understanding (1–5)
- Roles and segregation (6–10)
- Approvals and delegation (11–15)
- Access and systems (16–20)
- Reconciliations and reviews (21–25)
- Exceptions and overrides (26–30)
- Vendors and payments (31–34)
- HR and payroll (35–38)
- Change and projects (39–42)
- Data and reports (43–47)
- Monitoring and KPIs (48–51)
- Prior issues and self-identified problems (52–55)
- Culture and pressure (56–60)
- The meta-skills behind all 60
- Preparing without scripting
- Worked example: four questions, answered twice
- Questions readers ask
- Related guides
What auditors do with your answers
An interview answer is the weakest form of audit evidence, and auditors know it. Standard 14.1 of the Global Internal Audit Standards requires their analyses to rest on information that is sufficient, reliable and relevant, and a statement in a meeting is rarely sufficient or reliable on its own. So an answer almost never creates a finding by itself. It creates a test, and the test creates the finding. Read the fourth column of every table that way: it is the answer that points toward a test the process will fail, or that proves wrong when tested. What the auditors will accept in place of your word is set out in What counts as audit evidence.
| What you say | What the auditor does next | Where it ends up |
|---|---|---|
| A specific number (“about 1,200 a month, eight percent off the normal path”) | Reconciles it to a system count and sizes the sample from it | A population note and a sample size |
| An absolute (“never”, “always”, “everyone does”) | Looks for the counterexample. One is enough | A test exception, then a question about why you did not know |
| A described control (“I review it every month”) | Asks for last month’s and looks for what the review examined | A test of design, then of operating effectiveness |
| “I don’t know, but I will find out by Thursday” | Notes who owns the answer and waits for Thursday | A line on the request list; nothing adverse if it arrives |
| “The procedure says we…” | Asks what actually happens, then watches a real transaction | A documented-versus-actual gap if the two differ |
| A disclosure (“here is something we already know is wrong”) | Verifies it, checks the action plan, checks when it was logged | Management-identified; Standard 15.1 requires the final report to acknowledge actions already under way |
| A statement about another team | Treats it as a lead, not evidence, and asks that team | Nothing attributed to you unless corroborated |
Practitioner judgment: three answers lead to findings more reliably than any admission of weakness. They are the absolute (“we never have exceptions”), the delegated (“IT handles that”) and the unmeasured (“we don’t track that”). Each tells the auditor the owner is not looking, and an owner who is not looking has not found what the auditor is about to find. A wrong answer is recoverable. Standard 13.1 expects communication between the auditors and management to run throughout the engagement, not only at the end, and a prompt written correction is the tool; the rule in the what-not-to-say guide is to correct it as soon as you realize, in writing if it mattered.
Process understanding (1–5)
The auditors have had the “walk me through it” conversation by now. These five go after the edges: boundaries, volumes, variation and outputs, where a walkthrough narrative is thinnest and ownership tends to lapse.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 1. Where does your process start and end, and who owns the steps on either side? | Perimeter and handoff ownership | Upstream trigger, downstream recipient, the accountable person on each side, where the handoff is recorded | “It starts when I get the email.” Nobody owns the seam |
| 2. How many do you handle a month, and how many of those take the normal path? | Population and exception rate | A system count, an approximate split by type, and the report producing both | “We don’t track that,” or the exception path carries most of the volume |
| 3. Which steps are done the same way every time, and which depend on who does them? | Consistency of control performance | Candor about variation, the judgment steps named, and the thresholds or checklists bounding them | “It depends who picks it up,” said about a control step |
| 4. If someone new started Monday, what would the procedure give them and what would they have to be told? | Documentation and key-person dependency | Which steps are documented and current, which are tacit, and the cross-training planned | Everything is in one person’s head; the procedure is years out of date |
| 5. What does this process produce that others rely on, and how would they tell you if it were wrong? | Downstream dependency and feedback | The outputs and their consumers, the check at the receiving end, the last error returned | Errors surface months later at close, or when the auditors find them |
Roles and segregation (6–10)
Segregation questions are not about distrust. The auditor is mapping four functions (authorizing, recording, holding custody of the asset, and reconciling or reviewing the result) onto real people, including whoever steps in when the team is short, then checking the map against the system. The conflicts an ERP cannot see are covered in Segregation of duties beyond the ERP.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 6. For one transaction, who can approve it, who records it, who holds the money or asset, and who reconciles or reviews the result? Are any the same person? | Segregation across four incompatible functions | Four functions mapped to named roles, combinations identified, a compensating control over each | One person approves and releases; “small team, I do all of it” |
| 7. When you are short-staffed, which roles get combined, and is that reflected in the system or just agreed verbally? | Segregation under stress; temporary access | A documented fallback, temporary access with an end date, and a log of its use | Colleagues use each other’s logins; last year’s temporary access is still active |
| 8. Does anyone on your team hold a second role elsewhere: a project, a committee, another department’s approvals? | Conflicts no single system shows | Dual roles listed, conflicts declared, approval rights adjusted | Unaware. The payments approver also maintains a sister entity’s vendor master |
| 9. Where is the written record of who owns each control here, and when was it last confirmed? | Control ownership after turnover | A control matrix or RACI with named roles, confirmed within the year, including controls inherited from leavers | “The team owns it.” The named owner left eight months ago |
| 10. Which decisions here require two people, and how is the second person’s involvement proven? | Dual control and its evidence | Each dual-control point with its artifact: a second user ID’s approval, a second signature, dual bank authorization | The second person “just signs,” or one person logs in as both |
Approvals and delegation (11–15)
The auditors have already asked who else can approve. These test whether the limits are real: where they come from, whether the system agrees with them, and what an approval certifies. An approval that certifies nothing in particular is one of the most common weak controls we find in any process.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 11. Which document sets the approval limits, who approved it, and does the system match it? | Criteria, and configuration against policy | The authority document, its version and approver, and a periodic comparison of system limits against it | “I think it is 50,000.” Limits set by a departed administrator differ from policy |
| 12. When an approver is on leave, how is their authority delegated, for how long, and does it end automatically? | Delegation mechanics and revocation | Formal delegation in the system with start and end dates, a current list, periodic review of it | Open-ended delegations, delegation by forwarded email, or a shared password |
| 13. Could someone approve two items below their limit that together exceed it, and how would you detect that? | Split-transaction risk; detective control | The periodic query (cumulative approvals per requester or vendor), who runs it, when it last ran | “People would not do that.” No query, nobody has looked |
| 14. What must an approver check before approving, where is that written, and what happens when they get it wrong? | Approval as control or click | A written standard, examples of rejected items, and feedback to approvers who miss things | Nobody has ever rejected anything; at volume, a rubber stamp |
| 15. How are standing or recurring items approved, and when was the underlying authorization last renewed? | Stale authorizations | An inventory of standing items (recurring payments, standing entries), each re-approved on a cycle, with an owner | A years-old approval still generating payments; a terminated contract still paid |
Access and systems (16–20)
Access decides whether the auditors can rely on the system at all. If the wrong people can change anything, the controls inside it stop counting and the auditors fall back to substantive testing of your output. The method behind question 18 is in How to perform a user access review that actually works.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 16. Which systems and spreadsheets does this process depend on, and which does IT not know about? | The inventory, including end-user tools | A full list with owners, including macros and shared workbooks, and which sit under IT change control | A critical spreadsheet with no backup, no versions, one person who understands it |
| 17. Who can change a master record used here (vendor, employee, customer, price, account), and who reviews those changes? | Master data change control | Restricted roles, and a change log reviewed at a stated frequency by someone who cannot make changes | “Most of the team can.” The vendor payer can change bank details |
| 18. When you last reviewed access to this system, what did you compare the list against, and what did you remove? | Review or glance | A date, a system-generated user list compared to the HR roster and role matrix, removals with tickets | “Nobody has left, so nothing to remove.” Two leavers are still active |
| 19. Are any shared, generic or service accounts used here, and who knows their passwords? | Attribution of actions | An inventory of such accounts, credentials in a vault, restricted use, and monitoring of their activity | Transactions posted under a shared login; the password lives in a team chat |
| 20. Who on your team has administrator, superuser or developer rights, and what do they use them for? | Privileged access | Few named people, a business reason for each, monitoring, and no privileged user who also processes transactions | The owner has had admin rights “since the implementation” and can post entries |
Reconciliations and reviews (21–25)
The walkthrough covered what a reconciliation compares and who signs it. These test what a sign-off hides: what the reviewer would actually catch, and what is quietly not reconciled at all. The precision standard behind 23 and 24 is set out in Management review controls.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 21. Which reconciliations are performed here, by whom and how often, and which were late in the last six months? | Inventory and candor about timeliness | A list with owners and frequency, a tracker, and a plain account of the ones that slipped | No inventory; “all on time” contradicted by the tracker |
| 22. What is the oldest unexplained reconciling item right now, and what happens to items never explained? | Aging discipline and write-off authority | The oldest item and its age, the escalation rule, and who approves write-offs above what threshold | Items rolled forward for over a year; differences cleared with a plug by the preparer |
| 23. What would a preparer have to get wrong for you to notice it in your review, and how small could the error be? | Precision of the review | An explicit threshold, the specific checks (recalculation, tracing, trend comparison), and a recent error caught | “I would notice if something looked significantly off.” No threshold exists |
| 24. Where do you record what you looked at during a review, so someone else could see it was performed? | Evidence of review | Annotated workpapers, review notes or workflow comments, dated at the time of review | A signature on a cover sheet; “approved” by email; sign-offs added when asked |
| 25. Which balances or accounts in your area are not reconciled to anything independent, and why? | Coverage gaps | The gaps known, risk-assessed (low volume, immaterial, covered elsewhere), the reasoning written down | Suspense and clearing accounts nobody reconciles; “the system does it” |
Exceptions and overrides (26–30)
Every process has an off-ramp. Auditors ask about it because errors and fraud both travel by override, and because a process with “no exceptions” is either very small or not being described accurately. Strong owners treat the override log as their own early-warning system rather than something to explain away.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 26. Which controls here can be overridden, by whom, and where is each override recorded? | Override points known and logged | A list of override points, the roles authorized for each, the log, and who reviews it | The override is a flag anyone can set; no report of overrides exists |
| 27. How many overrides or exceptions were there last quarter, and who reviewed the list? | Monitoring of the exception population | A count, a trend, the main reasons, and an independent reviewer with evidence of the review | “A handful.” The log shows hundreds, mostly one user, reviewed only by that user |
| 28. What happens when an exception is urgent and the approver is unreachable at 5 p.m. on quarter-end day? | Emergency path and retrospective approval | A defined emergency procedure, approval after the fact within set days, a log, a low count | “We sort it out later.” At quarter-end the emergency path is the normal path |
| 29. Tell me about an exception that was approved and later turned out to be wrong. What changed because of it? | Whether the process learns | A specific case, its cause, and the change that followed (threshold, system check, training) | “That has never happened,” or a case after which nothing changed |
| 30. Are there workarounds or temporary fixes that have been in place for more than a year? | Normalized deviation | The workarounds named, their origin, and either a plan or a documented risk acceptance for each | A manual workaround from an old upgrade, never risk-assessed, mentioned only when found |
Vendors and payments (31–34)
Payment questions are the most direct in the bank because the loss is immediate and usually unrecoverable. The auditor is testing the moment money leaves and the master data that steers it; weak answers send them to the procurement and disbursements sections of the fraud red flags library to test for every flag listed there.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 31. How is a new vendor’s bank account verified before the first payment, and who does that independently of the requester? | Bank-detail verification and independence | A documented callback to an independently sourced number by someone outside the requesting team, applied to changes too | Checking the email signature; the clerk who sets up the vendor also verifies it |
| 32. Between invoice approval and money leaving the bank, what checks happen, and who performs the last one? | Payment release and segregation at release | Independent review of the payment run against approved invoices, dual bank authorization by two people, a paid-to-approved reconciliation | The file builder also releases it; both bank tokens sit in one drawer |
| 33. How do you detect duplicate payments, and when did that detection last find one? | Whether the duplicate check works | The system logic (vendor, invoice number, amount, date), periodic analytics on top, a recent catch with recovery | “The system blocks duplicates,” logic unknown; the only duplicates found were returned by vendors |
| 34. Which vendors were paid without a purchase order or contract last year, and who decided that was acceptable? | Off-contract spend; retrospective purchase orders | The categories and policy exceptions, a monitoring report, and the largest cases explained | “The PO is raised when the invoice arrives.” Approval follows the commitment |
HR and payroll (35–38)
Payroll is often the largest recurring payment an organization makes, and HR data drives access everywhere else. The auditor is testing the joins between HR, payroll and IT, where leavers slip through and where a payroll administrator can quietly hold every role at once.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 35. How does a leaver’s pay stop and access end, and what was the longest gap last year? | Data-triggered or memory-triggered leaver process | A trigger from the HR system, a service level, a tracker, and the known misses with causes | Depends on the manager emailing; a leaver paid for two months |
| 36. Who can change pay rates, bank details or allowances, and who reviews those changes before the pay run? | Payroll master data and pre-run review | Restricted roles; a change report reviewed each cycle against documents by someone who cannot make changes | The payroll administrator can change and run; the review checks only the total |
| 37. How is this period’s payroll agreed to last period’s, and what size of variance gets investigated? | Precision of the payroll reasonableness review | Variance analysis by cost center and headcount, a stated threshold, documented investigation above it | “We compare the totals and they are usually close.” The threshold is whatever feels large |
| 38. Who works in your area but is not on this entity’s payroll, and who approves their hours and rates? | Contingent-worker controls | Contractors, agency staff and secondees listed, contracts on file, hours approved by someone who sees the work, rates approved separately | The hiring manager approves their own contractors’ invoices; agency invoices paid without timesheets |
Change and projects (39–42)
In most audit functions’ experience, change breaks controls more often than people do. These test whether the business owns its changes or merely receives them, and whether anyone checked that the controls survived the last one.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 39. When a report, a spreadsheet formula or a system setting changes, who tests it before use, and where is that recorded? | User testing of business-owned tools | A tester other than the person who made the change, documented test evidence, sign-off, version history | The developer tests their own change; “we noticed it was wrong next month” |
| 40. Which projects currently touch this process, and who on your team signs off requirements and testing? | Business ownership of change | Named projects, a named business owner, a testing role, and a mapping of current controls to the future process | “IT is doing something.” Nobody from the business is testing |
| 41. After the last system change went live, how did you confirm the controls you rely on still worked? | Post-implementation verification | Key controls re-performed, reports confirmed to reconcile, a go-live checklist, an issues log with closure | Assumed. The approval workflow was off for three weeks, or an interface failed silently |
| 42. Who can change something directly in production in your area, and under what circumstances? | Emergency change; direct production access | Nobody in the business team; an IT emergency change procedure with approval after the fact and a log | The superuser changes configuration directly “because it is the only way,” with no record |
Data and reports (43–47)
Auditors test the reports they are shown before the controls that use them. These decide whether the data counts as evidence, the completeness-and-accuracy problem explained in IPE testing. An owner who can answer 43 and 46 has removed the most common reason a sound process fails a test anyway.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 43. For the report you rely on most, how do you know it is complete and that the figures are right? | Completeness and accuracy of system information | A standard report, saved parameters, a reconciliation to a control total, and knowledge of the logic | “It comes from the system, so it is right.” A filtered extract nobody can reproduce |
| 44. Which spreadsheets here would cause a wrong entry or decision if a formula broke, and what protects them? | Critical end-user computing | An inventory ranked by criticality; locked cells, version control, restricted access, an independent output check | No inventory; the auditors find a broken formula behind a journal entry |
| 45. What data arrives from other systems or third parties, and what tells you when a feed fails or is incomplete? | Interface monitoring | Record counts or control totals checked each run, failure alerts to a named person, a log of failures and fixes | “It loads overnight.” Failures are noticed when the numbers look odd |
| 46. If I asked for every transaction for twelve months, who would produce it, from where, and how would you prove it complete? | Population completeness | A standard extract, documented parameters, and a total that agrees to the ledger or a system count | A manually maintained spreadsheet in several versions whose totals do not tie |
| 47. Which numbers go to the board, a regulator or an external party, and what review do they get first? | Controls over external reporting | An inventory of external outputs, each reconciled to source and signed off above the preparer | Figures leave by email from an analyst, unreconciled, with a history of corrections |
Monitoring and KPIs (48–51)
Monitoring is one of the five components of internal control in the COSO framework, and the one owners can least often evidence. The auditor wants to know whether anyone would have noticed a failure before the audit did, and whether the people reporting the numbers are the people the numbers are about. Where the second line fits is in The Three Lines Model explained.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 48. What do you look at each month to know this process is working, and what would it show if it were not? | Whether monitoring would detect failure | Specific indicators (aging, error rates, exception counts, backlog), thresholds, and a case where one triggered action | Throughput measures only; nothing has ever triggered anything |
| 49. Which of your KPIs are produced by your own team, and who outside the team checks them? | Independence of performance data | System-generated where possible, with an outside party (finance, second line) checking the method and a sample | Self-reported figures, manually adjusted, with bonuses attached |
| 50. When did a metric last go red, who was told, and what happened? | Escalation and response | A specific instance, the escalation path used, the action taken, the date it returned to green | “They are always green.” Or a red metric redefined rather than fixed |
| 51. What does the second line (risk, compliance, quality) test in your area, how often, and what did they find last time? | Awareness of other assurance | The reviews known, their results and open actions, the correspondence available | Unaware of any second-line work; or their findings open for a year and disputed informally |
Prior issues and self-identified problems (52–55)
Past findings are the auditors’ cheapest test, because they already know the answer. Self-identified issues are the opposite: where an owner can change the tone of the whole report before fieldwork starts. The off-season habits that make these four answers easy (telling the auditors early and in writing, a one-line status on every open action each month, an annual self-check) are in Living with internal audit year-round; how to document a problem you found yourself so that it is rated as management-identified is in Self-identified issues; the right way to let an issue go is in Risk acceptance by management.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 52. What did the last audit of this area find, and which actions are open or were closed on paper only? | Remediation substance; repeat-finding risk | The findings, their status, the closure evidence, and which fixes were weaker than planned | Does not know; or an action closed by rewriting the procedure while practice continued |
| 53. What issues has your team logged itself in the last year, and where are they recorded? | The self-identification habit | A register with owners, dates and causes, and two or three examples the owner can describe without notes | Nothing logged in a complex area; issues known but kept off the register |
| 54. Which known weaknesses have you decided to live with, and who signed off on that decision? | Risk acceptance through the right process | A documented, time-limited acceptance by someone with authority for that risk, re-reviewed on a cycle | Accepted informally by the owner; if the acceptance exceeds the organization’s risk appetite, Standard 11.5 requires the chief audit executive to escalate it |
| 55. Who outside your team raised a concern about this process in the last year: a complaint, a dispute, a near miss? | External signals and their capture | The concerns known and logged, the trend visible, and what was done about each | “Nobody complains.” The complaints sit in another function’s log |
Culture and pressure (56–60)
These are the questions owners tend to prepare for least and experienced auditors weigh heavily. The auditor is not assessing your character but whether incentives and hierarchy push people toward the controls or away from them, the pressure and rationalization side of the fraud triangle. A manager who can describe the tension in their own targets is more credible than one who says there is none; why people stay silent is summarized in The Fearless Organization.
| Question | What it tests | A strong answer contains | The answer that creates a finding |
|---|---|---|---|
| 56. What are you and your team measured and rewarded on, and which targets could tempt someone to cut a control short? | Incentive design against control design | The targets named, the tension acknowledged, and the counterweight (quality metrics, independent checks) | Speed-only incentives for control performers, and an owner who denies any tension |
| 57. When did someone on your team last push back on a senior person’s request, and what happened to them? | Psychological safety; override by seniority | A specific example where the push-back was supported, and the route the person used | “That would not happen here.” Or the person was overruled |
| 58. If someone on your team saw something wrong, what would they do, and would you know? | Speak-up channels and their use | The channels named, confirmation the team knows them, and a concern that was raised and resolved | “They would tell me” as the only route; a concern raised that went nowhere |
| 59. Which control or policy here do people think is pointless, and what do they do about it? | The policy-practice gap | A candid list with reasons, and for each either a change request or evidence it is enforced anyway | “Everyone follows everything,” or a bypass everyone knows about and nobody has escalated |
| 60. Has anyone asked you to do, or not do, something in this process that you were uncomfortable with? | Management override; ethical pressure | A direct answer. If yes: what it was, how it was handled, and whom it was raised with | A long pause and “I would rather not say”; or a disclosure of pressure to backdate or suppress |
Two points on question 60. What you say is covered by the function’s confidentiality obligations (Standard 5.2 requires auditors to protect the information they gather), but it is not anonymous: it goes into the workpapers, and a possible override of controls will be followed up. If the answer is yes, say so plainly, in the room or through the organization’s speak-up channel. A hint is recorded as a hint, which is the worst of both outcomes.
The meta-skills behind all 60
The general technique is in the interview guide and the phrases that backfire are in What not to say to your internal auditor. This table is narrower: each skill applied to the bank above, how it usually fails, and what lands in the auditor’s notes, which are what survives the meeting.
| Skill | What it looks like against this bank | How it usually fails | What the auditor writes down |
|---|---|---|---|
| Answer only what was asked | Question 18: give the date, the comparison and the removals, not how access works in three other systems | Volunteering a weakness outside the scope, or answering a different question | Extra topics become requests; a non-answer becomes a note that the question was deflected |
| Say “I don’t know, I will find out,” then do | Name who knows and a date by which you will come back | Guessing. A guess is recorded as a management representation and tested | An open item with your name and date, closed when the answer arrives |
| Do not speculate about other teams | “The feed comes from Treasury. I can say what we check on arrival, and who to ask there” | Explaining why another team does what it does, or attributing motive | A lead to corroborate with that team, which comes back to you quoted if it was wrong |
| Quantify, do not absolutize | “About 140 last quarter, 92 by one person,” not “a handful” | “Never,” “always,” “everyone,” “rarely” | An absolute tested for a counterexample; one exception makes the statement wrong as well as the control |
| Practice first, then policy | “What happens is X. The procedure says Y. The difference is because Z” | Reciting the procedure, then being walked through a transaction that ignores it | A documented-versus-actual gap, logged against the process |
| Bring documents for the questions that have them | Access review evidence, delegation list, override log, reconciliation tracker, issue register, authority document. Offer them; do not read from them | Bringing nothing, or bringing everything, which drops a dozen new requests onto your own desk | Evidence shown closes a line of questioning; evidence promised opens a request |
| Separate knowing from believing | “I know the reconciliation was done. I believe the reviewer checked the aged items; I have not seen her notes” | Blending the two, so a belief is recorded as fact | A fact is tested; a labeled belief is followed up with whoever knows |
| Correct yourself the same day | “I said quarterly; it is semi-annual. The last two were March and September” | Hoping it goes unnoticed | A corrected representation, nothing adverse. An uncorrected error found later reads as a misstatement |
| Disclose before they find it | “Before you ask about overrides: the count rose last quarter, here is why, and here is what we are doing” | Waiting to see whether they find it | Management-identified, with the action acknowledged in the report under Standard 15.1 |
Preparing without scripting
A scripted answer is audible. It answers the question the team expected rather than the one asked, it arrives in the same words from three people, and it collapses at the second question; experienced auditors treat it as they treat an absolute, a reason to test harder. Preparation that works is preparation of facts, not phrasing. Pull the numbers, find the documents, decide what you will disclose, agree who answers what (the person who performs a step answers for it; the manager does not), and open the system beforehand so that “show me” takes seconds. Managers briefing a team should give rules and facts, not model answers. The briefing itself, including the three-minute talk and the one-page rules card, is in Briefing your team before an audit, and the manager’s table in the what-not-to-say guide shows which instructions help and which do damage.
| Fact to have ready | Where it comes from | Questions it answers |
|---|---|---|
| Monthly volumes for twelve months and the normal-versus-exception split | A system report, parameters saved | 2, 27, 46 |
| The approval limits document with date and approver, and the limits actually configured | The authority policy; the workflow configuration | 11, 12, 15 |
| Date and evidence of the last access review, current delegations, generic and privileged accounts | The access tool, the HR roster, the role matrix | 18, 19, 20 |
| The reconciliation inventory with six months of timeliness, and the oldest open item | The reconciliation tracker | 21, 22, 25 |
| The override and exception log with counts by user, and who reviewed it | The system log; the reviewer’s notes | 26, 27, 28 |
| Open and closed audit actions with closure evidence, the issue register, any risk acceptances | The issue tracking system; the second line | 52, 53, 54 |
| Changes and projects in the last twelve months, and the post-go-live checks | Change records; project documents | 39, 40, 41 |
| Team targets and the KPI pack as actually circulated | Performance documents; the monthly pack | 48, 49, 56 |
| External outputs and the sign-off on each | The reporting calendar | 47 |
| Leaver cases in the last year and the longest gap to pay stop and access removal | HR records; IT tickets | 35 |
Practitioner judgment: with one hour, spend it on questions 18, 21, 27 and 52. Each has a document answer, each document is often missing, and each missing document is a finding on its own however well the control operates. With a second hour, write down the three answers you would least like to give and decide whether each is to be disclosed, fixed or accepted formally, before the auditors arrive rather than during the closing meeting.
Worked example: four questions, answered twice
Northgate Logistics is a hypothetical regional freight company; its accounts payable supervisor is interviewed during a payables audit. The facts are identical in both versions, and so are the tests the auditors run afterward, because auditors test regardless of what they are told. What differs is what she knew, what she disclosed, and what she could show in the room.
| Question | Version A | Version B | What the test found (both versions) | Outcome A, then outcome B |
|---|---|---|---|---|
| Q31, vendor bank verification | “We always call the vendor back” | “Callback on an independently sourced number, form on file. In February’s vendor master migration, 38 vendors were loaded without callback forms; 29 are re-verified, here is the tracker” | Six of 25 sampled vendors had no callback form, all from the migration | A: a finding, with her statement quoted against it. B: management-identified, action acknowledged; the auditors tested her tracker instead |
| Q27, override count and review | “A handful. I keep an eye on it” | “140 tolerance overrides last quarter, 92 by one senior clerk who handles the three largest carriers. Here is my monthly review with notes. I have asked IT for a per-user cap” | 140 overrides; 92 by one user; monthly review notes existed | A: a finding on unmonitored overrides, because the review notes surfaced only after the exception. B: an observation on concentration, action already in train |
| Q18, last access review | “Quarterly. Nobody has left, so there was nothing to remove” | “March 14. System export against the HR roster and role matrix. Removed three, two of them leavers the ticket process had missed. I raised that with IT in March” | Two leavers had stayed active for seven weeks until the March review removed them; the leaver trigger was still broken | A: a finding against her access review (her statement was wrong) and a second on the leaver process. B: one finding on the leaver process, owned by IT and HR, with payables credited for detecting it |
| Q56, targets and pressure | “No, our targets are fine” | “Invoices processed per day. There is no quality measure, which I am not comfortable with. I have proposed adding duplicate rate and rework rate” | The KPI pack showed a throughput measure only; the auditors linked it to the override concentration | A: the override finding’s cause statement cites incentive design. B: the same cause, but the recommendation adopts her proposal and names her as owner |
Version A produces four findings and a supervisor the auditors no longer take at her word. Version B produces one finding, mostly owned by other functions, two management-identified items, and a supervisor whose later statements are tested lightly because the early ones held up. The process was the same in both. What changed was that in version B the tests confirmed what the auditors had been told, which is the only mechanism by which an interview answer ever helps you. How those outcomes then move through fact validation, rating, reporting and closure is traced in The life of a finding.
This guide is general and educational; it is not legal or employment advice.
Questions readers ask
What questions do internal auditors ask process owners?
They ask about the boundaries and volumes of the process; who can initiate, approve, record and hold custody; how approval limits and delegations work; who has access and who reviews it; what is reconciled and how precisely; how exceptions and overrides are handled; how vendor, payroll and master data changes are controlled; how changes are tested; whether reports are complete and accurate; what monitoring exists; which prior issues remain open; and what pressures the team works under. The 60 questions above cover each area; the sixteen general ones are in the interview guide.
What is the best way to answer internal audit questions?
Describe what actually happens rather than what the procedure says, use numbers instead of absolutes, show evidence rather than describing it, and say plainly when you do not know. Every answer is tested afterward, so the best answer is the one the test will confirm. If a question exposes a weakness, name it and say what is being done: a disclosed weakness is reported as management-identified, and one found after you denied it is reported with your denial next to it.
What if I don’t know the answer to an auditor’s question?
Say so, name the person who does know, and give a date by which you will come back. Not knowing is not a finding. Guessing often becomes one, because a guess is recorded as a statement by management and tested. The exception is a question about your own control, such as when you last reviewed access or what threshold you apply: not knowing that is itself evidence about the control.
Can internal auditors ask about my team’s bonus targets?
Yes, within the scope of the engagement. The Standards expect the board and senior management to support internal audit’s access to the people and records it needs (Standard 6.3), and incentive design is a recognized driver of control failure. The auditors are assessing whether targets create pressure to bypass controls, not what any individual earns, and rarely need individual compensation figures. If a question seems to exceed the scope, ask what it will be used for; the limits are described in What internal audit can and cannot do.
Should I give my team answers before an internal audit interview?
No. Give them the facts, the rules (answer what is asked, describe what actually happens, say “I don’t know” when true, do not speculate about other teams) and the schedule, and let them answer in their own words. Rehearsed answers are recognizable, they fail at the second question, and identical phrasing from several people makes auditors wonder what else was coordinated. If you know about a problem, decide before the interviews how you will disclose it. A twenty-minute briefing agenda that does this is in Briefing your team before an audit.
Does saying “we never have exceptions” cause an audit finding?
Not by itself. It causes a test, because an absolute is cheap to disprove and auditors are trained to look for the counterexample. If the test finds one exception, you have two problems: the exception, and a statement by management that was wrong. “We had 14 last quarter, mostly for these two reasons, and here is who reviewed them” takes the same thirty seconds and leaves nothing to disprove.
Are these the same questions a SOX tester asks?
They overlap where the control is a SOX key control: questions 17, 18, 23, 24, 36 and 43 are close to what a SOX tester establishes before testing. A SOX tester’s scope is narrower and more focused on evidence than on understanding: they need to see the control operate on specific samples, with evidence that is contemporaneous and attributable, and they care less about culture, monitoring or prior operational findings. The owner’s side of that process is in SOX for control owners.
Related guides
- Being Audited? Start here — the hub for everyone on the receiving end of an audit, stage by stage.
- When Internal Audit Interviews You — the sixteen general questions and how to prepare in an hour.
- What Not to Say to Your Internal Auditor, and What to Say Instead — the phrases that backfire at each stage, with replacements.
- Audit Interviewing: Question Design and Listening Craft — the auditor’s side: the funnel, the second question and what they listen for.
- Audit Walkthrough Guide: Question Bank, Script and Example — the step-by-step prompts used while following one transaction.
- How to Walk an Auditor Through Your Process — the walkthrough from the auditee’s chair, with the questions that feel like traps decoded.
- Briefing Your Team Before an Audit — what to tell the team, what not to script, and the three-minute talk.
- What Counts as Audit Evidence — what to send when an answer turns into a request, and what gets rejected.
- The PBC Survival Guide — handling the requests that interviews generate.
- Control Ownership: Making Someone Actually Accountable — the answer to question 9, in full.
- Segregation of Duties Beyond the ERP — the four-function map behind questions 6 to 10.
- How to Perform a User Access Review That Actually Works — what a defensible answer to question 18 rests on.
- SOX for Control Owners — what testers ask for when the control is a key control.
- Living With Internal Audit Year-Round — the heads-ups, action tracking and annual self-check that make questions 52 to 55 easy.
Leave a Reply