Internal Control Documentation Best Practices That Survive Testing

The core of internal control documentation best practices is that a stranger can reperform the control from what you wrote. Each control description names who performs it, what they do, how often, how precise it is and what evidence it leaves. The narrative or flowchart shows where the transaction starts and how it reaches the ledger. The risk control matrix ties each control to the risk it answers. The evidence shows what the reviewer actually looked at, and the reports behind each control are proven complete and accurate.

Most documentation fails on the last two points: review controls that can't show their precision, and reports nobody checked. This guide covers both, along with the basics, from management's side of the table. It is general information, not accounting or legal advice. Talk with your auditor or a qualified professional about your own facts.

Three documents, three jobs

Narratives, flowcharts and risk control matrices (RCMs) are often treated as interchangeable. They aren't.

Process narratives explain the flow in sentences. A narrative covers how a transaction starts, which systems it passes through, who touches it, where it is recorded and where the controls sit. In an ICFR audit, auditors usually perform walkthroughs, following a transaction from origination through the company's processes and systems until it is reflected in the financial records. This is often how they confirm their understanding of where misstatements could happen and where the controls sit. Your narrative should follow the same path, so the walkthrough confirms it instead of rewriting it.

Flowcharts show handoffs, system boundaries and decision points that prose hides. They work best for processes with several systems or interfaces. They are poor at holding control detail, so keep that in the narrative and the RCM.

The RCM is the index. Each row is one control. The row records:

• the risk, or "what could go wrong"
• the assertion
• the control description
• type and frequency
• whether it is a key control
• the owner
• the systems and reports it relies on
• the evidence it leaves

If you are searching for a risk control matrix template, those columns matter more than the layout. The test of a good RCM is that every key control maps to a risk, every significant risk has a key control, and nothing sits in the matrix only because it was there last year.

SEC guidance for management doesn't require you to document every control or every process. It supports a top-down, risk-based focus on the controls that address the risk of material misstatement. Document deeply where the risk is, and document lightly or not at all where it isn't.

Writing a control description someone can test

A tester reads a control description as a set of instructions. Write it so it answers five questions.

1. Who. Give the role, and the person if you like. The role shows authority and competence, which SEC guidance treats as part of whether a control operates effectively. "Accounting" is not a who. "The assistant controller" is.
2. What. Use the verb and the object: reviews, reconciles, approves, compares, investigates. Say what is compared to what.
3. When. Give the frequency and the timing relative to close, such as "monthly, by business day five." Frequency sets the sample size, so it has to be true.
4. Precision. Give the threshold that triggers follow-up and the level of detail reviewed. This is where most descriptions go vague (see the review control section below).
5. Evidence. Name what is retained and where: the signed reconciliation, the ticket, the system approval log, the variance analysis with explanations.

If any of the five is missing, the tester fills the gap with an assumption. Testers tend to assume the strict version.

Preventive or detective, manual or automated

Preventive controls stop an error before it is recorded. Examples include a three way match that blocks payment, or a system that refuses a journal entry over a limit without a second approver. Detective controls find the error afterward. Examples include reconciliations and management reviews. Most programs need both. Leaning only on detective controls puts the full weight on the precision of a few reviews.

Automated controls run in the system. Manual controls are performed by people. A third category causes the most trouble: IT dependent manual controls. These are a person acting on a system report, such as an aging report or a variance listing. The manual part is only as good as the report.

Automated controls are attractive because, when IT general controls are effective, auditors can often test them with very few instances and a check that the configuration hasn't changed. The exact approach depends on the auditor's judgment and methodology. That reliance holds only while access and program change controls hold. This is why testing should start with the ITGCs.

Segregation of duties and the preparer-reviewer line

Segregation of duties separates authorizing, recording, custody and reconciling, so that no single person can both make an error or commit a fraud and hide it. In practice, check for these combinations:

• the person who sets up vendors can also release payments
• the person who posts journal entries also approves their own
• the person with system administrator access also performs financial transactions
• the preparer of a reconciliation is also its only reviewer

Map conflicts from actual system access, not from the org chart. Users accumulate roles over time, and the access listing is what an auditor will pull.

When the team is too small to separate

A finance team of four cannot fully segregate. Hiring your way out isn't the only answer. Document the conflict openly and then answer it with a compensating control: a control performed by someone outside the conflict, precise enough to catch what the conflict could hide. PCAOB staff guidance for auditors of smaller companies recognizes that alternative controls, such as review by someone outside the conflict, can address limited segregation of duties if they are precise enough and tested. Its example is a manager who spot checks and reconciles inventory held by a custodian who also has access to the records.

Write the compensating control the same way as any other: who, what, when, precision, evidence. Then say in the RCM which conflict it compensates for. "CFO reviews" with no threshold does not compensate for anything.

Management override

At smaller companies, senior management often prepares, approves and posts period end entries. That raises the risk of management override, which auditors expect controls to address. Useful documentation here includes:

• a journal entry review by someone other than the poster, covering manual and top side entries above a stated threshold
• system enforced approvals where the ERP supports them
• an audit committee that sees a defined report of unusual entries and related party activity

Write down what the committee actually receives and how often.

Management review controls: where precision lives

Review controls draw the most inspection attention because their precision is easy to claim and hard to show. PCAOB guidance lists what makes a review precise:

• whether it relates directly to the assertion
• the level of detail reviewed (by location or product line, not only the company total)
• the threshold for investigating differences, measured against materiality

A review that only chases items near financial statement materiality is less likely to catch a material misstatement than one with a lower threshold. If the review compares results to expectations, the expectations have to be precise enough to flag a potentially material misstatement.

The same control, written twice

Written badly: "The controller reviews the monthly income statement for reasonableness."

That sentence gives no threshold, no level of detail, no expectation, no follow-up and no evidence. A tester cannot tell what a failure would look like. That means the tester cannot conclude the control works.

Written to be tested: "Monthly, by business day seven, the controller compares revenue and cost of sales by product line to the approved forecast and to the prior month. Any line that varies by more than [amount] and [percent] is investigated. The threshold is set and documented annually against planning materiality. The controller obtains an explanation from the line's owner and corroborates it to source documents or operational data such as shipment volumes. The controller records the explanation and any proposed adjustment on the variance analysis, then signs and dates it. Unresolved items are escalated to the CFO before the close is finalized. The signed analysis, supporting corroboration and any resulting entries are retained in the close folder."

The second version states its own precision, and that is the difference. It also tells the reviewer what to keep. Evidence of review should show what the reviewer looked at and what they did about it. A signature on a clean report shows neither. Explanations should be corroborated, not just restated. "Timing" is not an explanation.

Information produced by the entity: proving the report

Every control that runs on a report inherits the report's flaws. Auditors refer to these reports, queries and extracts as information produced by the entity (IPE) and expect their completeness and accuracy to be addressed. Inspection findings in this area come up often.

A practical checklist for each key report:

• Inventory it. Record the report name, the system, the controls that use it, and whether it is standard, customized or a user written query.
• Capture the parameters. Record the date range, entity, filters and sort, as run, with a screenshot or saved settings. A correct report run for the wrong period is still wrong.
• Document the logic. For custom reports and queries, keep the code or field mapping and who can change it.
• Test completeness. Reconcile the report total to the general ledger or another independent source. Or trace a sample from source records into the report.
• Test accuracy. Trace a sample of report lines back to source documents, and recalculate any computed fields.
• Tie it to the ITGCs. For standard reports, show that change control covers the report and access to modify it is restricted. Then the test from one year can support later years. For user run queries and exports, the ITGCs cover less, so test each time the report is used.
• Keep it reperformable. Retain enough detail that someone else could rerun the test and get the same answer. Auditors define reperformance as exactly that.

Spreadsheets, estimates and assumptions

Spreadsheets are applications with no change control unless you add one. For each key spreadsheet, document:

• its purpose
• its inputs and where they come from
• its formulas and logic
• who can edit it
• how version changes are tracked
• how the output ties to the ledger

Lock formula cells. Keep a version history. Have the reviewer check inputs to source and recalculate a sample, not just read the bottom line.

Estimates need more. Allowances, reserves, impairment analyses and fair value inputs depend on judgment. The control documentation should therefore show:

• how the method was chosen
• what data feeds it, and that the data is complete and accurate (treat it as IPE)
• which assumptions drive the result
• how the reviewer challenged them
• how prior estimates compared to actual outcomes

A review that accepts management's assumptions without testing them against data or prior year outcomes is not precise enough. Whether a specific estimate method is appropriate is an accounting question for your team and your auditor. Documentation records how the judgment was made and checked; it doesn't make the judgment for you.

When the design is the problem

When a control fails testing, first decide whether it was a design gap or an operating failure.

• Design gap: the control, run perfectly, would not catch the risk. Rewriting the description won't fix it. Redesign the control so it does. Common fixes are a lower threshold, a more detailed review, a report proven complete, or a different person performing it.
• Operating failure: a sound control wasn't performed or evidenced. The fix is usually training, scheduling and better evidence capture.

Either way, a remediated control has to run long enough to be tested. Because ICFR is assessed as of year end, management can conclude it is effective if material weaknesses have been remediated by then and the new controls have operated long enough to show they work. A new control running for only the final weeks may not give an auditor enough instances to test. While the fix runs in, operate a compensating control and document it. The remediation memo should say what failed, why, what replaced it, and when it will have run long enough to retest.

Scaling for private and pre-IPO companies

Private companies don't need public company volume on day one. They need the right controls documented in the right order.

The general rules shape the staging:

Newly public companies generally don't file a management report on ICFR until their second annual report. Companies that were already filing annual reports before going public don't get this delay.

• Emerging growth companies, and smaller reporting companies with under one hundred million dollars of annual revenue, are generally exempt from auditor attestation. Management must still assess ICFR.
• In 2026 the SEC proposed further changes to filer thresholds and attestation. That is a proposal, not a final rule. Check its status before you plan around it.

Some banks face attestation requirements under banking rules regardless of SEC filer status.

A sensible order:

1. Entity level controls and the financial close.
2. ITGCs over the systems that matter.
3. Revenue and the largest estimates.
4. The remaining cycles.

Document key reports as you go rather than at the end. A material weakness found before an offering is a project. Found after, it is a disclosure. The readiness timeline should be built backward from that.

Keeping it current year over year

Documentation decays quietly. Update the narratives and RCM whenever one of these happens:

• a new system, module or major upgrade
• a reorganization or a change in control owner
• a new revenue stream, acquisition or estimate
• a change in materiality or thresholds
• a deficiency, which changes the control it touches

Put the documents under version control: a date, an author and a change note on each revision, with prior versions kept. Before the auditor's planning meeting, roll forward:

• confirm each narrative still matches how the process runs
• confirm each control owner is still in the role
• refresh the key report inventory
• update remediation status with evidence

A short walkthrough with each owner each year catches more drift than a long rewrite every few years.

Where we come in

We document and test controls to the standard an inspector applies to the auditor. The approach comes from years spent defending that work through PCAOB inspections, described on our experience page. The work covers:

• narratives and RCMs
• review control precision
• key report testing
• remediation and retest

We work as management's advisor, not as your auditor. The full list is on our services page, and the engagement model is on the home page. We can't tell you how your auditor will conclude. We can tell you what we would expect an inspector to question, before your auditor tests it.

Start with a free two hour scoping call. Send the date on your calendar and a sentence on what is coming up.

Frequently asked questions

What should a risk control matrix include?

Each row should hold:

• the risk
• the assertion
• the control description (who, what, when, precision, evidence)
• type and frequency
• key or non key status
• the owner
• the reports and systems relied on
• where the evidence is kept

Every key control should map to a risk, and every significant risk to a key control.

How do I document a management review control?

State who reviews it and at what level of detail. State the investigation threshold and how it was set against materiality. Say how explanations are corroborated and what is retained. Keep evidence that shows what the reviewer examined and what they did about it, not just a sign off.

What does completeness and accuracy of a report mean?

Completeness means the report contains all the records it should. Accuracy means the data in it matches the source and is calculated correctly. You prove both with the parameters as run, a reconciliation or trace to source, and a link to the IT general controls that protect the report's logic.

Can a small finance team meet segregation of duties expectations?

Often, yes. Document each conflict openly. Then answer it with a compensating control performed by someone outside the conflict, written with a real threshold and evidence. Whether your auditor accepts a specific compensating control is their decision.

Does a private company need SOX level documentation?

Not on day one. Start with entity level controls, the close, ITGCs and the highest risk cycles. Then expand toward the standard you will need before your first required assessment. Lenders, sponsors and acquirers often ask for evidence of controls well before any rule requires it.

Can you guarantee our controls will pass the audit?

No one can promise an auditor's conclusion. What we put in writing: if your auditor, an examiner or a regulator writes up a deficiency on a control we documented and tested, we remediate it at no charge. Twenty percent of each fixed fee is held back until testing of the controls in scope is complete with no deficiency attributable to our documentation or testing.