Visit Website →
← Back to blog

SOX Document Controls: Audit Ready Evidence for U.S. Public Companies

September 27, 2026
SOX Document Controls: Audit Ready Evidence for U.S. Public Companies

SOX requires management to document internal controls that address material misstatement risk, keep evidence of how those controls operated, and retain the resulting records so auditors and regulators can review them later. The governing rules come from the SEC, the PCAOB, and COSO's control framework. In practice, the minimum deliverable is a written control description, supporting evidence, and a retention policy that holds records for a period consistent with regulatory expectations.

TL;DR:

  • Management must clearly document controls, tying them to a specific risk and providing detailed descriptions, test plans, and supporting evidence for each key control.
  • Records must be retained for at least seven years, with strict version control, access restrictions, and a documented audit trail to prove authenticity and changes over time.
  • Risk-based classification determines whether controls are key or non-key, influencing documentation depth and testing rigor, especially when processes change or automation occurs.
  • Regular updates throughout the year are essential to maintain accurate documentation, requiring quarterly reviews, immediate revisions after control changes, and accountability for owners.
  • Using local, offline document tools ensures sensitive evidence remains protected, with capabilities to compare versions, merge files, and produce audit-ready packages without relying on cloud storage.
Lawtonpdf
lawtonpdf.com
Keep Audit Evidence Private
Compare and manage sensitive SOX documents locally, helping teams organize audit-ready evidence without relying on cloud storage.
Explore LawtonPDF

Table of Contents

What the law and standards require

Three sources define what counts as acceptable SOX documentation, and each plays a different role. The SEC's rule on audit retention requires accounting firms to keep workpapers, meaning the records showing audit procedures, evidence gathered, and conclusions reached, for seven years. That same expectation shapes how public companies build their own internal retention policies, since management's control documentation often becomes part of what auditors rely on and retain.

The PCAOB's AS 2201 standard governs how auditors test internal control over financial reporting. It directs a top-down approach: auditors start at the financial statement level, work down through entity-level controls, and then select process-level controls to test based on risk. Auditors lean on management's documentation to understand a control before testing it, so a thin or vague description slows the audit and invites follow-up requests.

COSO's Internal Control-Integrated Framework sits underneath both. It calls for a risk-based approach rather than a checklist mentality: management uses judgment to decide which controls matter and how thoroughly to document them. The framework organizes controls into five components and a set of principles, but it does not dictate a fixed template. That flexibility is useful, though it also means documentation quality varies widely between companies, which is exactly what auditors are trained to probe.

What to document for each control

Every control description needs five elements: who performs it, what they do, when they do it, how they do it, and what evidence proves it happened. Practitioner guidance frames this bluntly: an undocumented control is treated as if it does not exist, no matter how consistently someone actually performs it.

Five elements of a testable SOX control

Write descriptions the way you would explain a task to someone who has never seen it. "The controller reviews the monthly account reconciliation" is too thin. A testable version reads: "The assistant controller reviews all balance sheet reconciliations over $50,000 by the 10th business day after month-end, comparing supporting schedules to the general ledger, and signs off in the reconciliation tool with a dated electronic signature." That sentence answers who, what, when, and how in one pass, and it tells you exactly what evidence to expect: a signed, dated reconciliation with a defined review threshold.

Each control description should also tie back to a specific risk and a financial statement assertion, such as existence, completeness, or valuation. A control that exists without a clear link to a risk looks arbitrary to an auditor and raises the question of why it is there at all.

Core artifacts auditors expect to see

Four documents form the backbone of most SOX audit files, and each serves a distinct purpose.

The risk-and-control matrix, or RCM, maps identified risks to the controls designed to address them and the evidence that proves each control operated. It is the master index auditors use to navigate everything else, so gaps or inconsistencies here tend to surface first.

Process narratives and flowcharts explain how a transaction or activity moves through a system, from initiation to financial statement impact. They give context the RCM cannot: where handoffs happen, where automated steps take over from manual ones, and where a control fits into the broader process. A clear narrative answers questions before an auditor has to ask them.

Test plans and test results document how someone verified a control actually worked, not just that it exists on paper. A test plan should specify the sample size, the period tested, and the criteria for pass or fail. Test evidence, screenshots, signed forms, system logs, needs consistent file naming and a clear link back to the specific control and testing period it supports. Loose files with generic names like "test1.pdf" create exactly the kind of ambiguity auditors flag.

Version control, retention, and audit trails that hold up

Documentation only proves what it claims to prove if you can show what existed at a given point in time and who changed it. That means every control document needs a version history: a table showing the version number, the date, the author, and a short note on what changed. Guidance on maintaining version control recommends a controlled repository with automatic versioning rather than relying on saved copies scattered across shared drives. Our guide on document version control for compliance teams covers naming conventions and check-in workflows in more detail.

Version history and audit trail illustration

Retention policy should follow the seven-year expectation set out in SEC rulemaking, and it should say explicitly that records are never destroyed while an investigation or dispute is open, regardless of the scheduled retention date. Archive rather than delete once a document rolls off active use, and keep the archive searchable rather than boxed away.

Access controls matter as much as retention. Limit who can edit a finalized control document, log every change, and where possible attach a digital timestamp or signature to reviewer sign-offs. Auditors increasingly ask for an exportable change log rather than taking your word that a document has not been altered since review. A plain, undated PDF invites more questions than it answers.

How privacy-first, local document tools support audit-ready controls

SOX evidence is sensitive by nature: reconciliations, access logs, financial schedules. Processing that material entirely on local hardware, rather than uploading it to a cloud service, keeps control over who can see it without adding a separate layer of vendor risk to track.

The practical requirements are the same regardless of where files live: encryption on sensitive files, a record of who accessed or changed a document, and an exportable history showing what a document looked like at each point in time. A local comparison tool that can show exactly what changed between two versions of a control narrative, without either version ever leaving your machine, satisfies both the version-control expectation and the confidentiality expectation at once. That kind of point-in-time comparison maps directly onto the "how" and "evidence" elements auditors ask about, and it works well alongside the offline workflow practices described in keeping documents offline for audit-ready controls.

How auditors evaluate your documentation

Auditors follow the same top-down, risk-based logic COSO and PCAOB both describe. They start with entity-level controls, the tone-set-at-the-top items like a code of conduct or a management review process, before moving to process-level controls tied to specific transaction cycles. Weak entity-level controls tend to widen the scope of testing everywhere else.

Inside a workpaper, auditors look for traceability: can you follow a single transaction from the RCM to the narrative to the test evidence without a gap. They expect dated reviewer signatures, a defined sample for any test of operating effectiveness, and original evidence that has not been recreated or backdated to look tidier than the actual process was.

The failures that show up most often are predictable. Vague control descriptions that skip the "how" or the evidence element. Missing or incomplete test evidence for the sample period under review. Process narratives that describe how something used to work rather than how it works now. And IT general controls documentation that treats access reviews or change management as an afterthought, when auditors treat ITGCs as foundational to whether they can rely on any system-generated report at all.

Pre-audit document controls checklist

In the 30 to 90 days before fieldwork, run through a focused readiness pass rather than waiting for the auditor's first request list.

  • Confirm every control in the RCM has a linked narrative, a test plan, and dated test evidence for the current period.
  • Check version histories on key documents to make sure the most recent approved version is the one in the shared repository.
  • Verify retention settings match the seven-year policy and that nothing scheduled for review is close to an unintended deletion date.
  • Re-test or spot-check ITGC documentation, particularly around user access reviews and change management logs.
  • Index all test evidence files with a naming convention that ties each file to its control number and testing period.

Assemble the final package by control, not by document type, so an auditor can open one folder and see the narrative, RCM entry, and evidence together. Where you find a gap, assign an owner immediately, capture the missing evidence if the control period is still open, snapshot the current state of the document, and write a short note explaining the remediation so the fix itself is documented.

Classifying key controls versus non-key controls

Not every control that exists needs the same documentation depth. A key control is one that, on its own, prevents or detects a material misstatement; if it fails, there is no other control positioned to catch the error. Non-key controls support the process but are not the last line of defense against a material error.

The classification decision should follow the same risk-based logic COSO recommends: start from the financial statement assertion at risk, then ask which control, if it failed silently, would let a material error through. That control gets full documentation treatment: the five-element description, a test plan, and evidence retained on the same schedule as any other key control. A backup or secondary control covering the same risk may still warrant a lighter-touch narrative, but it does not need the same testing rigor.

Getting this classification wrong in either direction creates problems. Treating too many controls as key inflates the testing workload without reducing risk, since auditors and internal teams end up spending time on items that were never going to catch a material error on their own. Treating a genuinely critical control as non-key is the more serious mistake: it means the one control standing between a process and a misstatement gets the least documentation and the least scrutiny. Revisit the classification whenever a process changes, a system is replaced, or a prior key control is automated, since automation sometimes shifts where the real risk point sits.

Keeping documentation current all year, not just before the audit

The biggest challenge most compliance teams face is not writing the documentation once, it is keeping it accurate as processes, systems, and staff change throughout the year. A control narrative written in January can be stale by August if a system upgrade changed how a reconciliation is performed, and nobody remembers to update the file until the auditor asks why the documentation does not match what actually happens.

Staff turnover compounds this. When a control owner leaves and a new person takes over the task, the documentation frequently does not get updated to reflect the new owner's name, let alone any small changes in how they perform the task. Multiply that across dozens of controls and a handful of departures in a year, and the documentation set drifts steadily out of sync with reality.

The most reliable mitigation is a quarterly review cycle rather than a single annual push. Practitioner playbooks recommend a controlled repository with point-in-time snapshots taken at each fiscal quarter close and again at year-end, so there is never a dispute about what the documentation said on a given date. Pair that with a simple rule: any process change, system migration, or control owner change triggers an immediate documentation update rather than waiting for the next scheduled review. Assigning a single accountable owner per control, rather than leaving updates to whoever notices first, closes most of the remaining gap.

Who should own SOX documentation and what training they need

Responsibility for SOX documentation usually spans three groups: control owners, who perform the control and are best positioned to describe it accurately; an internal SOX or compliance team, who maintain the RCM, coordinate testing, and enforce version control standards; and IT, who own documentation for ITGCs like access provisioning, change management, and system configuration controls.

Control owners need enough training to write a testable description, not a compliance certification. The most useful training is a short session on the five-element format, using real examples from the company's own control set, plus a walkthrough of what an auditor will actually ask to see. Compliance teams handling the RCM and version control need deeper training on retention rules, the SEC's seven-year expectation, and how to run a version history that will hold up under audit scrutiny.

A recurring failure point is treating training as a once-a-year event tied to the audit calendar. New hires who inherit control ownership mid-year, and any IT staff added to a system that touches financial reporting, need the same grounding before they take on documentation responsibility, not after the fact when a gap is discovered.

Fitting document controls into existing compliance frameworks and ERPs

Most companies already run SOX documentation alongside other compliance work, SOC 2, internal audit, or a broader enterprise risk program, and alongside an ERP system that generates a lot of the underlying financial data. The most effective integration point is the RCM itself: map SOX controls against other framework requirements where they genuinely overlap, such as access management controls that satisfy both SOX ITGC requirements and a SOC 2 security criterion, rather than maintaining duplicate documentation for the same underlying control. Our overview of layered document security for SOC 2 covers how those overlapping controls get evidenced in practice.

Where an ERP generates system reports used as control evidence, document the report's configuration and any manual adjustments made before it reaches the reconciliation, since auditors will ask how you know the report itself is reliable. Building documentation workflows around the ERP's own audit trail, rather than exporting data into a separate tracking spreadsheet, cuts down on the version-control problems that come from maintaining two records of the same activity. The goal is one authoritative source per control, not parallel systems that eventually disagree with each other.

Where documentation rigor actually pays off

Most compliance teams overinvest in document volume and underinvest in whether each control description would survive a stranger reading it cold. A shorter, precise control write-up that names the reviewer, the threshold, and the evidence beats a three-page narrative that never quite says what happens.

Automate what is mechanical, versioning, timestamps, change logs, so nobody has to remember to do it by hand. But keep a human signature on anything that involves judgment, since that signature is often the actual evidence an auditor is testing for. Build a quarterly review into the calendar and take a full snapshot before year-end, so nobody is reconstructing what a document said back in March.

— Lawton

Making local, audit-ready documentation practical

Public companies handling SOX evidence face a real tension: the documentation has to be thorough, traceable, and easy to hand over, but it also contains exactly the kind of sensitive financial detail nobody wants sitting on a third-party server. LawtonPDF runs every document tool locally on your own hardware, so comparing two versions of a control narrative, merging test evidence into a single audit package, or redacting a sensitive figure before sharing a file never means uploading it anywhere.

That matters most in the version-control and evidence-collection work described above. LawtonPDF's document comparison tools can show exactly what changed between two versions of a control document, line by line, and its folder comparison feature can check an entire evidence folder against a prior snapshot in one pass, which is useful when confirming that a repository matches what was in place at quarter-end. Merging, extracting, and organizing pages with the PDF organization tools helps assemble a clean auditor delivery package without leaving files scattered across a shared drive.

LawtonPDF offers Plus, Business, and Free plans, with pricing available on request through the pricing page. If your documentation process still relies on emailing files back and forth or storing evidence in a cloud drive you don't fully control, start by checking the full tools overview to see what a local-first workflow looks like for your next audit cycle.

Sources

FAQ

What are the controls required for SOX compliance?

SOX does not name a fixed list of required controls; instead it requires management to design and document controls that address the risk of material misstatement in financial reporting, following a risk-based approach like the one described in COSO's framework. In practice, this means entity-level controls, process-level controls over key transaction cycles, and IT general controls supporting the systems that produce financial data.

What are some examples of SOX controls?

Common examples include a manager reviewing and approving journal entries above a set dollar threshold, a segregation of duties between who initiates a payment and who approves it, and an access review confirming only authorized staff can change financial system settings. Each of these needs a written description covering who performs it, when, how, and what evidence proves it happened.

What are the 5 main internal controls?

COSO's framework organizes internal control into five components: control environment, risk assessment, control activities, information and communication, and monitoring activities. These are broader categories for organizing a control system, not five specific controls a company implements.

Are SOX and SOC2 the same?

No. SOX is a U.S. federal law governing financial reporting controls at public companies, while SOC 2 is an attestation standard focused on data security and privacy controls, often used by service organizations to reassure customers. They can overlap in practice, particularly around access controls and change management, but they serve different audiences and different legal purposes.