If your process lives in people’s heads and the audit is four weeks out, you do not need a procedure manual. You need three documents: a one-page narrative of what actually happens, a control list naming each point where an error would be caught, and an evidence map saying where the proof of each control lives and who can pull it. An owner and one performer can usually produce all three in twelve to sixteen working hours spread across the month, and the kit answers most of what the audit team asks in planning, in the walkthrough and on the first request list.
The month-before plan covers the whole preparation month. This guide is the documentation kit inside it: why an undocumented process produces findings however well it runs, how to write each document so an auditor can use it, how to find the controls you did not know you had, the mistakes that turn documentation into findings, how to keep it alive, and a week-by-week schedule. It is written from the owner’s chair; the auditor’s version of the same ground is the walkthrough documentation template. One rule runs through all of it: write the process as it runs today, date everything, and change nothing about the past.
In this guide
- Why an undocumented process generates findings
- The three-document kit
- Writing the one-page narrative
- Example: Northgate Logistics freight claims
- Identifying your controls
- The control list, with six filled rows
- The evidence map
- Versioning and approval
- Mistakes and fixes
- Keeping it alive
- The four-week plan
- Questions readers ask
- Related guides
Why an undocumented process generates findings even when it runs well
Auditors do not write findings because paperwork is missing. They write them because a missing document breaks three things the audit depends on, and each break has its own finding wording.
The criteria problem. A finding is the gap between criteria and condition, what should happen against what does. The IIA’s Global Internal Audit Standards build findings on that comparison (Standard 14.2 Analyses and Potential Engagement Findings), and Standard 13.4 Evaluation Criteria has the auditor assess whether the board and senior management have established adequate criteria, use them if they have, and otherwise identify criteria through discussion with them. When you have no documented criterion the auditor borrows a yardstick: the group policy two levels up, a framework such as COSO, a regulator’s expectation, the way another region does it. Every one of those is more demanding than a procedure you wrote yourself, because none of them knows your constraints. In most functions, “the process is not documented” is also a reportable condition on its own, usually rated low or medium, and one of the few findings an auditor can support without testing a transaction. That is practitioner observation rather than a rule, but it is close to universal.
The evidence problem. Standard 14.1 requires auditors to base their analyses on sufficient, reliable and relevant information. A control that leaves no trace cannot be shown to have operated, however faithfully it was performed. If the supervisor looks at every claim over the threshold but never records that she looked, the test result is “no evidence of review” and the finding reads as if the review never happened. The auditors’ own work is held to a documentation standard by their reviewers (Standard 14.6 Engagement Documentation), and “the supervisor told us she checks” does not meet it. Test of design vs operating effectiveness explains the consequence: an undocumented control can pass the walkthrough and still fail testing.
The key-person problem. If the process exists only in one person’s memory, the auditor sees continuity risk: an absence, a resignation or a misremembered rule changes how the process runs and nobody would know. That is a risk to the organization, not a preference for tidiness, which is why “key-person dependency” appears as a cause in findings about processes that have never produced an error. The control ownership guide describes how such controls become orphans when the person leaves.
There is a fourth cost that never reaches the report. When the auditor cannot find the edges of the process on paper, they ask more questions, request more documents and sample more widely. Documentation is one of the few things an auditee controls that shortens how long the audit takes.
The three documents that cover most of the audit
Three documents do most of the work. Together they fit on three or four pages, and each answers a question the audit team must settle before it can test anything. As a practitioner estimate, a kit like this answers roughly four of every five questions a planning auditor puts to a process owner; the remaining fifth is about what went wrong last year and what you already know is broken.
| Document | The auditor’s question it answers | Length | Who writes it | Where the audit uses it |
|---|---|---|---|---|
| One-page narrative | What happens, in what order, by whom, in which system, and what comes out the end? | One page: header block, 8 to 15 numbered steps, exceptions path, known gaps | The person who does the work drafts; the owner edits | Planning memo, engagement risk assessment, walkthrough script |
| Control list | Where would an error be caught or stopped, by whom, how often, and what trace is left? | Half a page to a page; five to twelve rows is a typical range | The owner, with the performers in the room | Key-control selection, test plan, the risk and control matrix if in SOX scope |
| Evidence map | If I ask for proof that control X operated in March, who pulls it, from where, and how fast? | One page, one row per control | The audit coordinator with each performer | Request list, sample selection, fieldwork |
The kit leaves out the full SOP (a manual is for training; auditors read a map faster), the flowchart (welcome if someone draws well, but the auditors will draw their own), the risk assessment (the engagement-level risk assessment is the auditors’ job, and your knowledge of what could go wrong belongs in the control list) and the policy (it states intent; the narrative states practice). If your organization needs a formal SOP for quality or regulatory reasons, write the narrative first and let the SOP grow from it; the reverse order buries the controls on page 23.
The audit team uses the kit in a predictable sequence. The planning auditor reads the narrative before kickoff and arrives with “what happens if” questions. The walkthrough, which has its own guide from the auditee’s chair, follows one real transaction against your steps; in a SOX context, PCAOB AS 2201 paragraph .37 describes a walkthrough as following a transaction from origination through the company’s processes until it reaches the financial records, using the same documents and information technology that company personnel use, and paragraph .38 has the auditor questioning personnel at the important processing points about what the prescribed procedures require. Internal auditors outside SOX do the same with less ceremony. The first request list then asks for the evidence your map points to, for a sample of dates.
How to write a narrative auditors can use
A narrative is the story of one transaction from the event that starts it to the record it leaves behind. The auditor reads it with four questions in mind: where does the process begin and end, who touches it, which systems hold it, and where does it change hands. Seven elements answer them: the trigger (the event that opens a transaction, which also defines the population the auditor will sample from), the steps, the systems (every application, spreadsheet, mailbox and folder the transaction passes through), the roles, the handoffs (each change of hands and its mechanism), the exceptions path, and the outputs the process leaves behind.
- Present tense, active voice. “The analyst opens the claim in TMS,” not “Claims are to be opened.” Passive sentences hide the performer, which is the first thing the auditor needs.
- Roles in the steps, names in the header. Steps outlive people. A narrative that says “Maria” in step 4 is wrong the week Maria moves teams.
- One observable action per step, numbered. Eight to fifteen steps fill a page; more than twenty usually means two processes are sharing a name.
- Name the system and the object in it. “The claim record in TMS,” not “the system.” Auditors will ask to see the object and who administers access to it.
- Write what happens, not what should happen, and label workarounds. The walkthrough will surface them within the hour anyway, and a narrative that matches reality buys credibility that lasts the engagement. What not to say to your auditor covers the spoken version of the same rule.
- Put volumes, peaks and cycle time in the header. They let the auditor size samples sensibly; where the sample sizes come from explains why they will ask.
- Tag the control points (C1, C2) to match the control list, so the two documents read as one.
- Write the exceptions path as its own block. Five or six lines answer most “what happens if” questions before they are asked.
- End with known gaps, each dated, with what you intend to do. It is the most credibility-building section in the kit.
| Section of the narrative | What to write | Length |
|---|---|---|
| Process name and boundary | One sentence each for where it starts and where it ends | Two sentences |
| Owner, performers, backups | Roles with current holders and a backup for each | Three or four lines |
| Trigger | The event that opens a transaction | One sentence |
| Volume and timing | Monthly volume, peaks, cycle-time target | One sentence |
| Systems | Each system and what it holds, spreadsheets and mailboxes included | One line per system |
| Steps 1 to n | Who, does what, in which system, producing what, handed to whom, with control tags | 8 to 15 numbered steps, one or two sentences each |
| Exceptions path | What happens when the normal path fails: incomplete input, failed check, threshold, outage, dispute, absent approver | Five or six lines |
| Known gaps and workarounds | Each with the date found and an intention | One line per gap |
| Version block | Document name, version, effective date, author, approver and approval date, next review date, change log, storage location | Two lines |
Most of the editing is translation from procedure language, which describes intentions, to narrative language, which describes events. Each row below gets longer and more useful, because it now names a performer, an action, a threshold or a system that can be checked.
| Procedure language (do not write) | Narrative language (write instead) | Why the second helps you |
|---|---|---|
| “Claims must be processed promptly.” | “The analyst opens a claim record in TMS within two business days of the email arriving; the mailbox is checked twice a day.” | “Promptly” cannot be tested, so the auditor substitutes a standard of their own. Two business days can be tested, and you chose it. |
| “Claims are reviewed for accuracy.” | “The supervisor compares the proposed amount to the commercial invoice and the BOL weight for every claim above $2,500 before approving it in TMS.” | Names the performer, the comparison, the threshold and the system, which is what a test is designed from. |
| “Appropriate approvals are obtained.” | “TMS routes claims above $2,500 to the supervisor and above $25,000 to the claims manager and the VP Operations; IT maintains the thresholds on a ticket from the claims manager.” | Says who approves, what enforces it, and who can change it, which pre-empts the override question. |
| “The system ensures data integrity.” | “TMS will not save a new claim unless the PRO number exists and shows delivered status; a message blocks the save.” | Describes the rule the system enforces rather than a virtue. A rule can be shown live in the walkthrough. |
A complete one-page narrative: Northgate Logistics freight claims
Northgate Logistics is an invented regional carrier, and everything below is hypothetical. Its freight-claims process is the kind that lives in people’s heads: two analysts and a supervisor who have run it for years, a procedure memo older than the current transportation management system, and a claims manager who inherited the team eighteen months ago. Internal audit has scheduled a review of claims handling for December. This is what the claims manager and the senior analyst produced in week one, in about three hours of drafting and one hour walking a real October claim against the draft. It is in table form because tables are easier to maintain; a prose narrative with the same content is equally acceptable.
- Process and boundary. Customer freight claims, from receipt of a claim to settlement in the ERP and closure of any carrier recovery. Starts when a claim arrives in the claims mailbox or the customer portal; ends when the credit memo or payment posts in the ERP and any recovery claim against a partner carrier is closed. The monthly claims summary and Finance’s accrual sit outside the boundary.
- Owner and performers. Owner: claims manager (D. Reyes). Claims analysts: J. Okafor (customers A–L) and P. Lindqvist (M–Z), covering for each other. Claims supervisor: M. Chen, with the claims manager as backup. Finance: AR specialist (R. Patel), backup AR supervisor.
- Trigger. A customer claim for shortage or damage on a delivered shipment.
- Volume and timing. About 180 claims a month, of which roughly 30 exceed $2,500 and two or three exceed $25,000. Peaks in December and January. Target cycle time 30 days from receipt to settlement.
- Systems. TMS (claims module, approval workflow, settlement register); document imaging (proofs of delivery and bills of lading); ERP (AR credit memos, AP payments); the claims shared mailbox; the pricing team’s contract-limits spreadsheet on the shared drive.
| Step | Who | What actually happens | System | Output and handoff | Control |
|---|---|---|---|---|---|
| 1 | Customer | Emails the claim form, photos and commercial invoice to the claims mailbox, or submits through the portal, which forwards to the same mailbox. | Mailbox, portal | Claim email. H1: mailbox to analyst by customer initial. | None |
| 2 | Claims analyst | Opens a claim record in TMS within two business days: PRO number, claim type (shortage, visible or concealed damage), claimed amount, customer. TMS assigns the claim number and acknowledges the customer by email. | TMS | Claim record, status Open. | C1: TMS blocks the save unless the PRO exists and shows delivered status. |
| 3 | Claims analyst | Retrieves the POD and BOL from imaging and answers the five liability questions on the claim record (exception noted at delivery; filed within nine months; concealed damage reported within five business days; invoice attached; BOL weight recorded). Status cannot move to Under review until all five are answered. | Imaging, TMS | Status Under review. | C2: checklist completion enforced by TMS; the answers are the analyst’s judgment. |
| 4 | Claims analyst | Determines liability and the payable amount: invoice cost (not retail) times quantity, capped at the released-value limit in the customer’s contract, looked up in the pricing team’s spreadsheet because TMS does not hold it. Enters the proposed amount and a reason code for any reduction. | TMS, spreadsheet | Proposed amount. Workaround W1: contract limits live outside TMS. | None |
| 5 | Analyst, supervisor, manager | Approves by amount: the analyst to $2,500; the supervisor from $2,500 to $25,000, after comparing the proposed amount to the invoice and BOL weight; the claims manager and the VP Operations above $25,000. TMS routes by role and records approver and timestamp. | TMS workflow | Status Approved or Denied, with reason code. | C3: approval routing by threshold, enforced by TMS roles. |
| 6 | Claims analyst | Selects the settlement type: credit memo against open receivables (the default) or payment where the customer has no open balance. TMS writes the settlement to the register the nightly interface sends to the ERP. | TMS | Settlement request. H2: TMS to ERP by nightly interface. | None |
| 7 | AR specialist (Finance) | Each morning compares the previous day’s TMS settlement register to the credit memos and payment requests posted in the ERP, item by item, logs differences in the interface exception log and re-sends failed records; anything open after one business day goes to the AR supervisor. | TMS, ERP | Interface exception log, initialed and dated. | C4: daily interface reconciliation. |
| 8 | Claims analyst | Where a partner carrier handled the shipment, files a recovery claim with that carrier inside its filing window and records it on the TMS recovery tab. | TMS, carrier portals | Recovery claim open. | None |
| 9 | Claims manager | Monthly, reviews the open-recovery aging from TMS, questions every item over 60 days with the responsible analyst, records the outcome against each item, signs and dates the file. | TMS report, shared drive | Reviewed aging with notes. | C5: monthly recovery aging review. |
| 10 | Claims manager | Quarterly, reviews IT’s list of users holding TMS claims-approval roles and their thresholds, confirms or removes each, signs the list and returns it to IT, which confirms removals by ticket. | IT access report, ticketing | Signed access review. | C6: quarterly access review of approval roles. |
- Exceptions path. Disputed denial: the analyst reopens the claim with reason code Dispute and the claims manager decides within ten business days; TMS records the decision. Duplicate claim on the same PRO: TMS warns but allows a second claim; no reason is captured when the warning is bypassed. TMS unavailable: claims are logged on a shared-drive sheet and back-entered when the system returns; the sheet is retained. Approver absent: IT sets a delegation on a ticket from the claims manager, with an end date.
- Known gaps, found 3 November 2026. G1: contract limits sit in a spreadsheet outside TMS, an accuracy risk and a question about the report’s reliability; pricing has agreed to load them into TMS in Q1. G2: the duplicate warning can be bypassed without a reason; IT has been asked to make the reason mandatory. G3: a July delegation of the supervisor’s approval role to an analyst was not removed until September; raised with IT and listed on the disclosure note for the auditors.
Notice what the narrative does not do. It does not describe TMS screens, reproduce the tariff, or claim anything the team cannot show. It names three gaps the auditors would have found within a day of fieldwork, and names them first, with dates and intentions. That moves a finding from “identified by internal audit” toward a self-identified issue with remediation under way, which is a different conversation at the closing meeting and a different line in the report.
How to identify your controls
Most owners underestimate how many controls they have and overestimate how many are documented. A control is any point where a wrong, missing or unauthorized item would be stopped or caught: an approval before something moves on, a comparison of two records, a review by someone who was not the preparer, a rule the system enforces. The long-form definition of a control has forty examples; for the kit you need a method. Walk the narrative one step at a time and ask the same question at each: if this step were done wrong, what would catch it, and when.
Four families account for most answers: approvals, reconciliations, reviews and system checks. Two labels then matter. A preventive control acts before the event and a detective control acts after it, and auditors want at least one of each around the risks that matter, partly because they test them differently: an automated block is tested once, together with the general controls over who can change it, while a monthly review is tested on a sample of periods, which is why its evidence matters so much. The corrective loop, what happens after detection, is the part owners most often omit and auditors most often ask about.
Describe each control at the precision it actually operates. If the supervisor compares amounts only above $2,500, that is the control, and a $2,400 claim is covered by the analyst’s checklist and nothing else. Overstating precision (“all claims are reviewed”) is the most common way owners talk themselves into a finding, because the auditor will pick a transaction below the real threshold and ask to see the review. The control description guide treats precision and exception handling as the two attributes that make a description testable. Ask one design question as well: could one person run a transaction from start to finish. At Northgate an analyst can open, assess and approve a claim under $2,500 alone, and neither the monthly summary nor the daily interface reconciliation would catch a modest fictitious claim against a cooperative customer. That is a segregation of duties exposure; know it, size it and have a position on it before the auditor asks.
| Prompt to ask at each step | What it surfaces | Usually | Northgate example |
|---|---|---|---|
| What stops a wrong or unauthorized item from entering here, and what does the system refuse to let you do? | Input validation, required fields, access restrictions, automated blocks | Preventive, often automated | C1: TMS blocks a claim without a delivered PRO; the checklist gate in C2 |
| Who has to say yes before this moves on, and above what amount? | Approvals and delegated authority | Preventive | C3: threshold routing to supervisor, manager, VP |
| What two records get compared, by whom, how often? | Reconciliations | Detective | C4: TMS settlement register to ERP postings, daily |
| Who looks at this afterward, for what, and what do they do when they find something? | Management reviews and their precision | Detective | C5: recovery aging, items over 60 days questioned |
| Who can change the rules (thresholds, master data, roles), and who checks that list? | Change and access controls | Detective | C6: quarterly review of approval roles |
| How would you know if a step were skipped entirely? | Completeness controls: sequence, aging, open-item reports | Detective | C5 for recoveries; nothing yet for unopened claims in the mailbox (a gap) |
| Could one person do this from start to finish? | Segregation of duties | A design feature, not an activity | Claims under $2,500 can be handled end to end by one analyst |
| What happens when the check finds something? | Exception handling, the corrective loop | Corrective | Interface differences re-sent and logged; aging items questioned |
| Which of these would you miss first if it stopped tomorrow? | Your key controls | Key vs non-key | C1, C3 and C4 marked key |
Some things look like controls and are not, and listing them costs credibility: a policy statement, training, a report produced but compared with nothing, a meeting without recorded decisions, a KPI with no action threshold, “experienced staff,” and a system “having” a workflow, which is a control only when someone can say which rule it enforces and who checks its configuration. The control design principles guide goes deeper on what separates a control from an activity.
The control list: columns and six filled rows
The control list is a stripped-down risk and control matrix. Five columns carry most of its value: the control, its owner and performer, its frequency, the evidence it leaves and the system it runs in; add an identifier, a type and a key marker. Keep owner and performer distinct even when they are the same person today; the ownership guide treats a performer who is also the only named owner as a warning sign. Write each description with the formula the control description guide uses: who, an observable verb, what, when, how, at what precision, leaving what evidence, and what happens on an exception. That guide suggests forty to eighty words; under twenty is usually missing a part.
| ID and type | Control (who does what, when, how, at what precision) | Owner / performer | Frequency | Evidence it leaves | System |
|---|---|---|---|---|---|
| C1. Automated, preventive, key | TMS rejects a new claim unless the PRO number exists and the shipment status is Delivered; the analyst cannot save the record and sees a blocking message. Changes to the rule require an IT change ticket approved by the claims manager. | Owner: claims manager. Performer: TMS; configuration held by IT applications | Every claim | Blocking message; TMS configuration setting; change tickets | TMS |
| C2. IT-dependent manual, preventive | The claims analyst answers the five liability questions on the claim record from the POD, BOL and claim form before TMS allows the status to move to Under review. A No on any question routes the claim to the supervisor for a liability decision. | Owner: claims manager. Performers: claims analysts | Every claim | Checklist fields with user and timestamp; POD and BOL images attached | TMS, imaging |
| C3. Automated routing, manual approval, preventive, key | TMS routes each claim for approval by amount: analyst to $2,500; supervisor from $2,500 to $25,000, who compares the proposed amount to the invoice and BOL weight and records the comparison in the approval comment; claims manager and VP Operations above $25,000. IT maintains thresholds and role membership on tickets from the claims manager. | Owner: claims manager. Performers: supervisor, claims manager, VP Operations | Every claim above $2,500 | Approval history on the claim (approver, role, timestamp); supervisor’s comparison comment | TMS workflow |
| C4. Manual, detective, key | Each business day the AR specialist compares the previous day’s TMS settlement register to the credit memos and payment requests posted in the ERP, item by item, records every difference in the interface exception log, re-sends failed records and clears differences within one business day; items still open go to the AR supervisor by email. | Owner: AR supervisor (Finance). Performer: AR specialist | Daily | Interface exception log with date and initials; the two reports used; escalation emails | TMS, ERP |
| C5. Manual, detective | Monthly the claims manager reviews the TMS open-recovery aging, questions every item over 60 days with the responsible analyst, records the outcome against each item, and signs and dates the aging file. | Owner and performer: claims manager. Backup: claims supervisor | Monthly | Signed, dated aging file with a note per item over 60 days | TMS report, shared drive |
| C6. Manual, detective | Quarterly the claims manager reviews IT’s list of users holding TMS claims-approval roles and their thresholds, confirms or removes each user, signs the list and returns it to IT within five business days; IT confirms each removal by ticket. | Owner: claims manager. Performer: claims manager with IT applications | Quarterly | Signed access list; IT removal tickets | TMS, IT ticketing |
Writing the list exposed what the narrative had hinted at. Nothing prevents or detects a duplicate claim (G2). The contract limit used in steps 4 and 5 comes from a spreadsheet nobody reconciles (G1). The supervisor’s comparison in C3 leaves a trace only when she writes the comment, which she did in about half the claims the team looked back at. Do not invent a control, and do not write the comment into the description as if it had always been mandatory. Record the gap with today’s date, decide whether to fix it or disclose it, and start the fix before the audit if you can; the management action plan guide shows how to word one that will close. Standard 15.1 Final Engagement Communication requires the auditors to acknowledge actions management has already started or completed, so a dated fix that began before fieldwork changes how the finding reads, and sometimes whether it is written at all.
If the process is in SOX scope, the list is mapped into the formal matrix and held to the testers’ standard; SOX for control owners explains what that standard is. For an operational audit the list stays yours, and the auditors use it to choose which controls to test and which to accept on the walkthrough alone.
The evidence map: where the proof lives and who can pull it
The evidence map answers the request list before it arrives. For each control it says what the evidence is, where it lives, who can pull it, who can pull it when that person is out, how long it takes, and what is known to be missing. The PBC survival guide covers running the list once fieldwork starts; the map turns it into a file transfer instead of a scavenger hunt.
Four things matter before you build it. Evidence of review: a signature or tick without a trace of what was checked is a manually produced internal record, fifth of the six rungs in the hierarchy of audit evidence, and it shows that someone signed, not what they checked; a reviewer should leave behind the comparison made, the exceptions found and the date. What counts as audit evidence, written for the person sending it, covers what gets sent back and why. Reports: every report you hand over is information produced by the entity, and the auditor will ask how it was produced, with what parameters, and how you know it is complete, the questions IPE testing explains, so record the report name, parameters and row count each time you run one. Screenshots need the system name, user and date visible or they will be requested again. Retention: a mailbox that purges after 90 days does not evidence a control for the last twelve months. Then pull a sample pack: one complete instance of each control’s evidence from a recent month, pulled by the backup rather than the primary person, from the location the map states. If the backup cannot find it, the map is wrong, and week three is a better time to learn that than fieldwork.
| Control | Evidence item | Where it lives | Who can pull it (primary / backup) | Time to produce | Known gap or note |
|---|---|---|---|---|---|
| C1 | Blocking message on an invalid PRO; TMS configuration setting; change tickets since the TMS upgrade | Message shown live in TMS; configuration report from IT applications; IT ticketing | Claims manager / IT applications lead | Message same day; configuration report about three days | Auditors will also ask who can change the setting, which ties to C6 |
| C2 | Checklist fields with user and timestamp; attached POD and BOL | Claim record in TMS; images in imaging, linked by PRO | Either analyst / claims supervisor | Same day per claim; a population needs the TMS “claims by period” report (date range, all statuses, all customers) | The population report is IPE: record parameters and row count when run |
| C3 | Approval history per claim; supervisor’s comparison comment | Claim record, Approvals tab; TMS workflow log | Claims supervisor / claims manager | Same day per claim; population is the claims report filtered above $2,500 | Comment present in about half of past approvals; mandatory from 10 November 2026 (dated change, disclosed) |
| C4 | Daily interface exception log; the two source reports; escalation emails | Finance shared drive, Interface recs folder, by month; reports saved with the log | AR specialist / AR supervisor | Same day; logs retained from go-live | Before August, reports for days with no differences were not always saved; a “no differences” line now records that the comparison was made |
| C5 | Signed, dated aging file with notes | Claims shared drive, Recovery aging folder, by month | Claims manager / claims supervisor | Same day | Two months in the past year have no file (manager on leave, no backup performed the review); disclosed |
| C6 | Signed access list; IT removal tickets | IT ticketing system (quarterly ticket); copy on claims shared drive | Claims manager / IT applications lead | Two days for tickets | Q3 review performed in October against a September due date; July delegation not removed on time (G3) |
The right-hand column is where the map earns its keep. Each entry is a finding the auditors would otherwise have discovered and written in their own words; written in yours, with a date and an action, it becomes a disclosed item the audit confirms rather than a surprise it reports. The month-before plan’s rule applies here too: do not create the missing evidence. A “no differences” line added from August forward is a control improvement; one added for March is a fabrication.
Versioning and approval without faking the age of a document
The three documents are working documents, but to serve as criteria they need to be official: versioned, dated and approved by someone with authority over the process. The reason sits in the framework most audit functions use as their reference for internal control. COSO’s 2013 Internal Control–Integrated Framework states, as Principle 12, that the organization deploys control activities through policies that establish what is expected and procedures that put policies into action. An approved procedure is management’s own statement of what is expected, which is why an auditor can hold the process to it and an unapproved draft on someone’s desktop cannot do the same work.
Auditors check four things about a procedure’s status: that the version you handed them was the one in force during the period tested; that the approver had authority, where one level above the owner is the normal minimum in most functions and the SOX program’s change process governs in-scope control descriptions; that the people doing the work have seen it, which they test by asking them rather than you; and that the effective date is truthful, which they test against file metadata, email trails and what staff say about when things changed.
The version block needs eight fields: document name, version, effective date, author, approver with the date and the approval email filed alongside, next review date, change log, and storage location. If there was no procedure before this month, say so in the change log: “v1.0, effective 15 November 2026. No documented procedure existed before this date; the 2019 claims handling memo is superseded.” The auditors may still note that the earlier period was undocumented, but “management documented the process before fieldwork and the documentation reflects practice” is a different finding from “no procedure exists,” and in many functions it is not written at all once the action is complete. Keep the kit in one location with read access for everyone who performs a step, put dates in the file names, and archive superseded versions rather than deleting them; the auditors may legitimately ask for the version in force in March.
Common mistakes and their fixes
Every one of these turns up in real walkthroughs, and most share a cause: the document was written for a reader other than the auditor, or for a process other than the one that runs.
| Mistake | How the auditor spots it | What it costs you | Fix |
|---|---|---|---|
| The aspirational procedure: the process you wish you had | The walkthrough transaction contradicts the document within three steps | “Procedure not followed,” which usually rates worse than “no procedure,” plus a credibility deficit for the rest of the audit | Write what happens. Put the improvements in a dated action plan |
| Copying a template or another unit’s SOP | References to systems, roles or thresholds you do not have | The auditor stops trusting the document and tests everything | Borrow structure, never content; start from a real transaction |
| The 40-page SOP | Staff cannot say where the controls are in it; nobody has read it since onboarding | “Procedures not communicated”; the auditor builds their own map and may get it wrong | One page plus appendices. The Checklist Manifesto is the case for short over complete |
| Controls written as objectives (“ensure accuracy”) | Cannot be tested, so the auditor defines the test | You are held to a standard you did not choose | Observable verb, threshold, evidence, exception handling |
| Writing it the week before and dating it earlier | File metadata, email trails, staff who say “that is new” | An integrity issue that escalates beyond the audit and outlives it | Date it truthfully; say the earlier period was undocumented |
| Documenting the system, not the control (“TMS has a workflow”) | “How do you know it is configured correctly, and who can change it?” | An automated control with no owner becomes a finding about access | Name the rule the system enforces, who owns the configuration, who reviews access |
| Marking every check as a key control | Twelve key controls in an eleven-step process | Larger samples; a failure on a trivial control counts like any other | Mark three to six as key: the ones whose failure you would notice first |
| Never telling the team | Staff describe a different process from the document | Either the document or the staff look wrong; both cost you | Walk the team through the kit before kickoff; briefing your team covers the talk itself, and what auditors ask in interviews tells them what is coming |
Keeping it alive: the quarterly review and the change triggers
Process documentation goes out of date because nothing forces an update. Two mechanisms prevent that, for an hour or two a quarter. The first is a quarterly review: the owner and one performer walk a recent real transaction against the narrative, tick that each control operated and left its evidence where the map says, confirm the names and backups in the header, record any change, and increment the version if anything moved. Thirty minutes covers a one-page process; put it on the owner’s calendar and on the ownership register the control ownership guide describes. The second is a short list of triggers that force an update out of cycle, so that a system upgrade in May does not wait for the September review to reach the document.
| Change trigger | What to update | When | Who |
|---|---|---|---|
| System change or upgrade: new workflow, field, report or interface | Systems list, affected steps, automated controls (C1 and C3 at Northgate), evidence locations | Before go-live; confirm after | Owner with IT applications |
| A person leaves, joins or changes role | Header names and backups, owner and performer column, evidence pullers; trigger the access review | Within the week; before a leaver’s last day for handover | Owner |
| Reorganization or outsourcing | Owner, approver, boundaries, handoffs | On the effective date | Outgoing and incoming owners together |
| New customer type, product, contract or threshold | Steps, precision in control descriptions, exceptions path | Before the first transaction of the new type | Owner |
| Incident, error or near miss | Exceptions path; whether a control is missing or misdescribed; known gaps | Within the month, with the cause | Owner with performers |
| Audit finding, regulatory or policy change | Criteria references, affected steps and controls, action plan dates | By the action plan date | Owner; auditors confirm at follow-up |
| Nothing has happened | Quarterly review: walk one transaction, confirm names, sign and date | Every quarter | Owner and one performer |
When a trigger fires, increment the version, date the change, and if the process is on the audit plan, tell the auditors at the next touchpoint. Living with internal audit year-round covers that relationship in the off-season; the kit is what keeps those conversations short.
The four-week plan
The sequence matters more than the hours. The narrative comes first because the controls are found in it; the control list second because the evidence map is indexed to it; the evidence map third because it is the only one of the three that can be tested before the auditors arrive. The hours are a practitioner estimate for a process of eight to fifteen steps with two to four performers; a process twice that size takes about twice as long, not four times.
| Week | Sessions | Output | Check before moving on |
|---|---|---|---|
| Four weeks out | Owner and the performer who does most of the work: two drafting sessions of 90 minutes; owner edit, one hour; walk one recent real transaction against the draft, one hour | Narrative v0.9: header, steps, handoffs, exceptions path, first list of workarounds | Could a competent new hire follow it? Where the walked transaction differed from a step, which was wrong: the step or the practice? |
| Three weeks out | Control workshop with all performers using the prompts table, 90 minutes; owner drafts the list, two hours; one performer checks each description against what they do, one hour | Control list v0.9 with five to twelve rows, key controls marked; dated gap list | Could someone who has never met you test each control from its description? Does every control name its evidence? |
| Two weeks out | Coordinator with each performer: pull one complete evidence instance per control for a recent month, two to three hours in total, with the backup pulling as well; fix evidence habits going forward, dated | Evidence map v1.0; sample pack; disclosure note listing gaps and what has started | Did every pull succeed from the stated location, by the backup? Are report parameters and row counts recorded? |
| One week out | Owner: approval by the owner’s manager; version block completed; team briefing, 45 minutes; send the kit and disclosure note to the audit lead before kickoff; prepare the walkthrough around the sample pack | Approved kit v1.0, dated; a briefed team; the kickoff pack | Does every team member describe the process the way the narrative does? Has the audit lead confirmed receipt? |
With one week instead of four, write the narrative in two days with the performer, build the control list on day three, and let the evidence map grow as requests arrive; send the first two before kickoff and say the third is in progress. Most auditors would rather have an accurate one-page narrative on day one than a complete kit on day ten, and the rest of the audit runs more smoothly for it. The Being Audited? hub collects the guides for every later stage.
This guide is general and educational; it is not legal or employment advice.
Questions readers ask
What is a process narrative for an audit?
A short written description of how one transaction moves from the event that starts it to the record it leaves behind: who does each step, in which system, what is produced, where it changes hands, and what happens when the normal path fails. Auditors use it to plan the engagement, script the walkthrough and choose which controls to test. One page of numbered steps in the present tense is the right length for most processes.
Do internal auditors require written procedures?
The Standards do not require you to have them; they require auditors to evaluate your process against criteria, starting with the criteria management has established. Without a written procedure the auditors borrow criteria from policy, frameworks or practice elsewhere, and most functions also report the absence of documentation as a finding in its own right. SOX programs and regulated industries usually do require documented controls for in-scope processes.
What is the difference between a process narrative and an SOP?
An SOP tells a performer how to do the work in enough detail to do it consistently: screens, fields, rules, templates. A narrative tells a reader how the work flows: steps, roles, systems, handoffs, controls and exceptions, on one page. Auditors need the narrative; new staff need the SOP. Writing the narrative first produces a better SOP, because the controls are visible before the detail is added.
How do I identify the controls in my process?
Walk the narrative one step at a time and ask: if this step were done wrong, what would catch it, and when. The answers fall into four families: approvals, reconciliations, reviews by someone other than the preparer, and rules the system enforces. Label each as preventive or detective, describe it at the precision it actually operates, and note what happens when it finds something.
What if we have no documentation at all and the audit is in two weeks?
Write the one-page narrative first, with the person who does the work, in two sessions; it is the document the auditors use most and the one the other two depend on. Build the control list from it in a single workshop. Date both truthfully, send them to the audit lead before kickoff, and say the evidence map is in progress. Do not attempt a full SOP, and do not date anything earlier than the day it was written.
Should I send my process documentation to the auditors before the audit starts?
Yes, with the version block completed and the known gaps listed. Sending it before kickoff lets the planning auditor arrive with specific questions rather than general ones, shortens the walkthrough, and puts your account of the process on the record first. Keep a copy of exactly what you sent, and do not change it during fieldwork without telling the auditors what changed and why.
Will auditors write a finding if the procedure is new?
Sometimes, depending on how the period before the procedure looked. If the process ran consistently and left evidence, a new procedure that reflects practice is usually recorded as a completed management action rather than a finding; Standard 15.1 requires the final communication to acknowledge actions management has already started or completed. If practice varied or evidence is missing for the earlier period, expect a finding about that period, with your new procedure cited as the action already taken.
Related guides
- Being Audited? The hub for people on the receiving end — every stage of the auditee’s journey, with quick answers.
- How to Prepare for an Internal Audit: A Month-Before Plan in 10 Steps — the whole preparation month, of which this kit is one part.
- How to Walk an Auditor Through Your Process — preparing and running the walkthrough your narrative will be tested against.
- The Walkthrough Documentation Template — what the auditor is filling in while you walk them through the process.
- How to Write a Control Description — the five parts and two attributes that make a description testable, with ten rewrites.
- Control Ownership: Making Someone Actually Accountable — owner vs performer, the ownership register and how controls become orphans.
- Preventive, Detective and Corrective Controls — the taxonomy with fifty examples, for classifying what you find.
- What Counts as Audit Evidence — what to send for each kind of request, what gets rejected, and the evidence-of-review standard.
- Audit Evidence: Sufficiency, Appropriateness and the Hierarchy — the six-rung reliability hierarchy, and why a controlled system record outranks a spreadsheet.
- The PBC Survival Guide — running the request list once fieldwork starts.
- Self-Identified Issues — why the gaps you list first are treated differently, and how to document one.
- Briefing Your Team Before an Audit — the talk to give once the kit exists and before the auditors arrive.
- SOX for Control Owners — what changes when your control list becomes part of the risk and control matrix.
- Living With Internal Audit Year-Round — keeping the relationship and the documentation current between audits.
Leave a Reply