What SOX record retention requirements apply to IT and audit evidence?
Sarbanes-Oxley sets no single retention period for logs, tickets or change records. It sets three things that matter here: criminal provisions under Section 802 for altering or destroying records to impede a federal investigation, a seven-year rule for the external auditor's workpapers under Regulation S-X Rule 2-06, and a duty for management to keep the evidence that supports its assessment of internal control over financial reporting. The retention period for ITGC evidence is therefore a decision the company makes and must be able to defend, not a number the statute hands you. Section 802 added 18 U.S.C. 1519, which makes knowingly altering, destroying, concealing or falsifying records with intent to impede a federal investigation punishable by up to 20 years in prison. That provision applies regardless of whether a record was ever formally requested, so deleting access logs or closed tickets during a dispute carries exposure well beyond the audit itself.
The period that fits depends on the controls, the risk they address and the evidence the assessment relies on. SEC Release 33-8810 says the nature of supporting evidence may vary with the assessed risk of the underlying controls, and that management's assessment must be supported by evidential matter that gives reasonable support. A control that auditors test by sampling change tickets for a financially significant application needs those tickets, approvals and test results kept for the full period the auditor may examine, including prior years if the company relies on them. Ask your external auditor which periods they expect to inspect, then map each ITGC to the system of record that holds its evidence, including any retention limits set by a SaaS provider or log platform. Write the chosen periods into a retention standard approved by the control owner and reviewed each year before the assessment begins.
Who must keep which records: management, the auditor and the provider
SOX record retention is split across three parties with different duties and different clocks. Management must keep evidence that supports its ICFR assessment, the external auditor keeps workpapers under its own rules, and a cloud or SaaS provider keeps records that the company may need but does not automatically own.
Management's ICFR evidence
Management owns the evidence behind its annual ICFR assessment. Instruction 2 to Item 308 requires the registrant to maintain evidential matter, including documentation, that reasonably supports that assessment, and Rule 13a-15 ties the evaluation to each fiscal year end. The nature of the evidence can vary with the assessed risk of each control, so keep test results, screenshots, reports and sign-offs for every ITGC relied on in the year. Confirm the retention period with your auditor and counsel, since the supplied sources do not set a fixed period for management's files.
Auditor workpapers under Rule 2-06
Regulation S-X Rule 2-06 requires an issuer's auditor to retain workpapers and other records relevant to an audit or review for seven years after concluding it. The rule covers electronic records, so the auditor's copies of extracted reports, system exports and logs they examined fall under the same clock. Management does not own those workpapers, but it should expect requests for them and confirm how the auditor stores data it received from your systems.
The 5-year floor under 18 U.S.C. 1520
Section 802 added 18 U.S.C. 1520, which requires accountants who audit issuers to keep audit or review workpapers for five years from the end of the fiscal period in which the audit concluded. This is a statutory floor that sits beside the seven-year rule in Rule 2-06, so the longer period is the one to plan around. Ask your auditor which period their firm applies and whether it matches the seven years in the SEC rule.
Cloud and SaaS provider records
A cloud or SaaS provider keeps its own system logs, change records and access records, and its SOC report may describe them, but those records are not automatically in your hands. Before go-live, write into the contract what evidence you can obtain, how long the provider keeps it and in what form. Confirm that you can export audit logs and change tickets in a readable format before the provider's retention window closes, since the company remains responsible for proving its controls operated.
Internal audit files
When internal audit tests ITGCs, its planning memos, walkthrough notes, sample selections and test results form evidence that management and the external auditor may rely on. Keep these files in a controlled repository with version history and restricted edit rights, so that a reviewer can see who tested what and when. Agree in advance with the external auditor how long internal audit keeps its working papers and whether it will share them, because those files are separate from the auditor's own workpapers.
Log and ticket source systems
The operational systems that generate access logs, change tickets and job records are where most ITGC evidence starts. Their default retention settings often expire earlier than the periods described above, so review them against the assessment and audit calendar. Export or archive evidence for each fiscal year before routine deletion runs, and record the hash or source of each export so an auditor can confirm it was not altered. Changing or deleting records to impede an investigation can carry criminal penalties under 18 U.S.C. 1519.
How long to keep ICFR evidence for IT controls
Sarbanes-Oxley does not give management a fixed number of days to keep ICFR evidence for IT controls. SEC Release 33-8810 instead requires that management's assessment rest on evidential matter that gives reasonable support for the conclusion, and it says the nature of that evidence may vary with the assessed risk of the underlying controls. The same guidance says ICFR documentation can take many forms, such as policy manuals, process models, flowcharts, job descriptions and memoranda, and needs to cover only the controls management concludes adequately address financial reporting risks, not every step in a process. So the retention question starts with a scoping question: which IT general controls and automated controls did management rely on, and what proves each one operated? Item 308 of Regulation S-K, through Instruction 2, requires the registrant to maintain that evidential matter, which is why the written policy should list evidence by control rather than by system.
Because the statute sets no day count for management evidence, the company should write its own retention policy and confirm it with its auditor and counsel. The period should cover everything the external auditor may test in the year under audit, including the prior-year roll-forward, any interim testing windows, and evidence of remediation for any IT general control deficiency that was found and fixed. Access reviews, change approvals, job schedules, backup restore tests and incident tickets are the usual records, and a log retention setting that deletes data before the audit window closes will leave a gap that is hard to fill later. Ask the auditor which periods it expects to sample and whether it accepts system-generated reports or needs the underlying data.
Retention should also account for records that outlast the company's own review cycle. Section 802 added 18 U.S.C. 1519, which carries up to 20 years in prison for knowingly destroying or falsifying records with intent to impede a federal investigation, so a deletion schedule should be approved by counsel and paired with a legal hold process that suspends deletion when an inquiry, audit dispute or litigation is anticipated. For the external auditor's own workpapers, Regulation S-X Rule 2-06 requires seven years after the audit or review concludes, which is a rule for the auditor, not a substitute for the company's policy. Document the policy version, the owner of each evidence set, and the date each deletion job ran, so the company can show what it kept and why.
What log and ticket retention means for access, change and operations controls
Access controls are tested by looking at who had access, when that access was granted, changed or removed, and whether someone independent reviewed it. The evidence is usually a set of periodic access review sign-offs, provisioning and deprovisioning tickets, and the system logs that show what the reviewer saw. A review sign-off without the population it covered is weak evidence, so the retention window has to keep the user lists and role assignments as they stood on each review date, along with the logs that support later sampling of terminations and privileged activity.
- Periodic access review sign-offs: Keep the signed review, the user population it covered and the reviewer's identity for every review cycle in the period under audit.
- Provisioning and termination tickets: Keep requests, approvals and completion records so an auditor can trace a sampled new hire or leaver from request to system change.
- Privileged activity logs: Keep administrator and elevated-role logs retrievable for the full sample window, since auditors often select privileged changes for inspection.
- Role and entitlement snapshots: Keep exports of role definitions and user-to-role mappings at review dates, because live systems overwrite them.
Before year end, confirm with your auditor the exact sample period and whether they will accept system-generated reports, and make sure those reports can be regenerated unaltered from retained logs.
Program change controls are tested by picking changes from the population and checking that each one was requested, approved, tested and moved to production by the right people. The evidence is the change ticket with its approval record, the test results attached to it, and the deployment record from the production environment. Auditors also check that the people who deployed a change were not the same people who approved it, so the logs that show who did what in the pipeline and in production need to survive as long as the tickets they support.
- Change tickets with approvals: Keep the request, risk rating, approver identity and approval timestamp for every change in the period.
- Test evidence: Keep test scripts, results and sign-offs that are linked to the specific change, not stored in a separate folder with no reference.
- Deployment and pipeline logs: Keep records showing who moved the change into production and when, including any emergency changes and their after-the-fact review.
- Configuration baselines: Keep versioned configuration exports so the production state can be compared against the approved change.
Ask your auditor how they plan to select changes, and confirm that your ticketing and pipeline tools keep history after tickets are closed or archived.
Computer operations controls keep financially significant processing complete and accurate. Auditors commonly test job scheduling and monitoring, backup and restore procedures, and incident handling. The evidence is a job schedule with run results, backup logs and restore test records, and incident tickets showing how failures were detected, escalated and resolved. Restore tests matter because a backup that has never been restored does not show that recovery works, so the records of those tests must be kept with the same care as the backups themselves.
- Job schedules and run logs: Keep schedule definitions and the outcome of each financially significant job, including failures and reruns.
- Backup logs: Keep backup job records showing completion, retention settings and any failed or skipped jobs.
- Restore test results: Keep the test plan, the date, the scope restored and the outcome, including any issues found and fixed.
- Incident tickets: Keep the detection source, severity, escalation path, resolution and review for incidents that touched financial processing.
Confirm with your auditor which operations populations they will sample, and check that backup and log retention settings in your platform cover that window and are not shortened by default policies.
How to set a retention policy the auditor will accept
This sequence turns scattered logs, tickets and approvals into a retention policy that matches the periods management and the external auditor actually test, can be preserved when an investigation or lawsuit starts, and can be produced on request. Each step ends with a record an assessor can inspect.
Inventory ITGC-relevant evidence by control
The control owner for each in-scope IT general control lists the evidence that shows the control operated: access review sign-offs, change tickets with approvals, job scheduler logs, backup restore records, and privileged activity logs. The GRC or SOX program lead merges these into one inventory, with the system that holds each item and its owner. Done means every control in the ITGC scope has at least one named evidence source and a named custodian, and gaps are logged as open items rather than left blank.
Map each evidence type to its retention period
For each evidence type, management and counsel set a retention period that covers the fiscal years the ICFR assessment and the external audit reference, plus any period the company's legal team requires. The auditor's own workpaper rules under 18 U.S.C. 1520 and Regulation S-X Rule 2-06 apply to the auditor's records, not to management's, so the policy should be written to cover management's own evidence. Done means a table lists each evidence type, its system, its retention period and the rule or decision behind that period.
Set legal hold and preservation triggers
Define who can place a legal hold, what starts one (for example, a regulator inquiry, subpoena, internal investigation, or litigation notice), and how affected evidence is frozen so routine deletion jobs skip it. Section 802 makes knowingly altering, destroying or concealing records to impede a federal investigation a crime, so the trigger process should be documented and quick. Done means a written hold procedure exists, the systems that can purge logs or tickets have hold exclusions configured, and a test hold has been confirmed by counsel.
Enforce immutability for logs and tickets
Configure write-once or append-only storage for audit logs, change records and approval history so entries cannot be edited or deleted by the administrators whose actions they record. Confirm with each platform vendor which controls, such as object lock or retention modes, the product supports in your version, and document any gap with a compensating procedure. Done means a configuration record shows the storage setting, who can change it, and a test showing that an attempted edit or early deletion is blocked or logged.
Test retrieval with a sample request
Ask someone outside the control owner's team to request a sample of evidence for a past period, such as a set of access reviews and change approvals from a prior fiscal year. Measure whether the evidence can be located, exported with its timestamps and approver identity, and read without help from the original administrator. Done means the test is written up with the request, the items returned, any missing items, and the fixes assigned, so the team knows the policy works before an auditor asks.
Record decisions and secure sign-off
Assemble the inventory, retention table, hold procedure, storage configuration records and test results into one retention policy document with a version history. Management approves it, counsel reviews the legal hold and retention periods, and the external auditor reviews whether the evidence set supports the ICFR assessment. Auditors give their view within their own process, and the company keeps the sign-off record. Done means a dated, approved policy is filed with the SOX documentation, and every later change goes through the same review.
How certification liability ties back to evidence
Section 906 makes the CEO and CFO personally answerable for every periodic report that contains financial statements. Each officer must certify that the report fairly presents the company's financial condition and results. The Act attaches fines of up to $1,000,000 and up to 10 years' imprisonment for knowing false certification, and fines of up to $5,000,000 and up to 20 years for willful false certification. Those penalties apply to the certifying officer, which is why the officers who sign have a direct stake in whether the records behind the report can be produced on request.
The certification itself is a statement about the numbers, but officers only have a reasonable basis for it if the controls behind those numbers are evidenced. For the IT side, that means the access reviews, change approvals, job monitoring and incident records that support management's ICFR assessment under Item 308 must still exist, be complete and be retrievable for the period under review. If a ticket was closed without the approval it should show, or logs covering a quarter were rotated away before the review, the officer's basis for certifying weakens even if the financial figures are right. Confirm with your auditor which IT evidence they will request for each period and how far back they expect it to go.
Officers should take legal advice on their own exposure under Section 906 and related provisions, since individual circumstances, prior certifications and any ongoing investigation change the analysis. What the finance and IT teams can do is agree on a retention schedule for ICFR evidence, confirm that log and ticket systems hold records for at least that period, and run a periodic test that pulls evidence for a sample control from the archive. Those steps give the certifying officers a documented basis that does not rely on memory or on someone's recollection of what was reviewed.
What to check before the next audit cycle
Retention problems rarely appear in the year they start. They surface when an auditor asks for last year's evidence and the answer depends on a person who has left, a log that rolled off or a provider contract that never mentioned records. The six checks below test whether your retention position holds before the auditor asks.
Written retention policy matches the audit period
Confirm a written retention policy exists, names the record types it covers (ITGC logs, change tickets, access reviews, backup job reports, and management's ICFR documentation) and sets periods that cover the audit window plus the time the auditor needs to test prior periods. Compare the policy against your fiscal year and the retention periods in Regulation S-X Rule 2-06, which apply to the auditor's workpapers rather than to your records. Ask whether anyone has ever checked the policy against what the systems actually keep.
Legal hold procedure tested end to end
A legal hold stops deletion of records that may be relevant to a federal investigation. Under 18 U.S.C. 1519, altering or destroying records with intent to impede an investigation is a crime, so the hold must work in practice. Run a tabletop or a sample hold: freeze the relevant log sources, ticket queues and backup sets, confirm that automated purges are suspended, and record who approved the hold and when it was released. Document the result.
Logs and tickets exportable in original form
Auditors need records they can inspect in the form they were created, with timestamps, user identifiers and approval fields intact. Export a sample of change tickets, access review sign-offs and privileged-user logs from each in-scope system and check that the export keeps metadata, that the source system clock was synchronized, and that the export can be reproduced later. A screenshot or a spreadsheet retyped from a ticket will not hold up when the auditor asks how it was generated.
Provider evidence obtained contractually
When a SaaS vendor, managed service provider or hosting partner runs a financially significant system, the records that prove your controls may sit with them. Check that each contract gives you the right to obtain logs, change records and access reports within a stated time, and that the retention period at the provider meets or exceeds yours. Confirm whether a provider report such as a SOC 1 report covers the period you need. Ask the provider to confirm, in writing, how long it keeps each evidence set.
Access to archived evidence for former staff and systems
Evidence often outlives the people and systems that produced it. Test whether you can retrieve a sample of archived records after an administrator has left, after a system has been retired or after a backup tape has been rotated out. Confirm that archives remain readable with current tools, that decryption keys are retained under a named custodian, and that at least two people can run the retrieval. A record that exists but cannot be opened is a retention gap.
Named owner for each evidence set
Each evidence set, such as access review records, change approvals, backup restore tests and incident tickets, needs one accountable owner who decides retention, performs the export and answers auditor questions. Management must keep evidence supporting its ICFR assessment under Item 308, so unowned evidence is a control gap in its own right. Record the owner, the system of record, the retention period and the backup location in a single register, and confirm each owner still works in the role.
Who owns retention, who prepares evidence and who issues the opinion
This table compares five parties on three questions: who decides how long SOX records are kept, who prepares the evidence, and who tests or attests to it. Read each row as a division of responsibility, not a menu of services. The main takeaway is that management owns the retention decision and the evidence, while only the independent auditor issues the opinion, and DeployOpen's role stops at preparing systems, settings and exports.
| Party | Retention decision | Evidence preparation | Testing or attestation |
|---|---|---|---|
| Management | Sets the retention schedule for ICFR documentation, IT logs and tickets, and confirms it covers the assessment period and auditor requests | Maintains documentation, change tickets, access reviews and reports that support its Item 308 assessment | Performs and documents its annual ICFR evaluation; does not receive an auditor opinion on its own assessment |
| Internal audit | Advises management on retention gaps and confirms policies are followed | Samples evidence, checks completeness and tracks exceptions before the external auditor arrives | Tests controls for management where it is used; its work may be relied on but does not replace the external audit |
| External auditor | Applies its own seven-year workpaper retention under Rule 2-06 for audit records it creates | Requests and reviews client evidence; keeps copies it relies on in its own workpapers | Issues the independent attestation on ICFR under AS 2201 where Section 404(b) applies |
| Implementation partner (DeployOpen) | Does not set the company's retention period; configures systems to the schedule management approves | Prepares log forwarding, retention settings, access reports and evidence exports from self-hosted systems | Does not test controls for attestation and does not issue audit reports, opinions or certifications |
| Cloud or SaaS provider | Sets platform default retention and offers configurable options under its contract | Supplies logs, audit trails and attestation reports the customer can request or export, within contract terms | Its own third-party reports may be provided to the customer; the customer's auditor decides what to rely on |
Common questions about SOX record retention
Does SOX set one retention period for all IT logs?
No. Sarbanes-Oxley does not publish a single retention period for IT logs, tickets or change records. The Act sets specific rules for specific parties: Section 802 added 18 U.S.C. 1519, which makes knowingly altering, destroying, concealing or falsifying records to impede a federal investigation punishable by up to 20 years in prison, and 18 U.S.C. 1520 covers audit workpapers. What a company must keep for its own ICFR assessment depends on which controls it relies on and the evidence needed to support them. Ask your auditor and counsel to confirm the period for each record type in your environment.
Does the seven-year rule apply to my company's records?
Usually not directly. The seven-year period in SEC Rule 2-06 of Regulation S-X applies to the issuer's auditor, who must retain workpapers and other audit or review records, including electronic records, for seven years after concluding the audit or review. Management has a separate duty under Item 308 and Instruction 2 to keep evidential matter that reasonably supports its ICFR assessment, and that duty does not state a fixed number of years. Many companies align internal retention with the auditor's period for simplicity, but that choice should be documented and confirmed with the external auditor.
Can I delete logs after a set number of days?
Only if the deletion does not remove evidence you still need for the ICFR assessment, the audit or a foreseeable investigation. A short log window can be defensible for high-volume operational logs, but access logs, change approvals and job records that show a financially significant control operated usually need to remain available for the period the auditor tests. Write the retention schedule down, tie each log type to the control it supports, and confirm the schedule with your auditor before you automate deletion. Confirm your log platform's retention and immutability settings directly with its documentation.
What if an investigation is foreseeable?
Once an investigation is reasonably foreseeable, routine deletion becomes a serious risk. Section 802's 18 U.S.C. 1519 makes it a crime to knowingly destroy or conceal records with intent to impede a federal investigation, and the penalty can reach 20 years in prison. Suspend automated purges for relevant systems, preserve logs and tickets in their current state, and involve legal counsel early. Document when the hold started, who approved it and what it covers. Treat a litigation or regulatory hold as a control in its own right.
How do cloud provider logs count?
Cloud provider logs count when they are evidence for a control that management relies on, and management still owns that evidence even when the provider runs the platform. Common examples include identity and administrative activity logs, configuration history and storage access logs. Check what the provider keeps by default, for how long, whether logs can be altered by administrators, and whether you can export them to storage you control. Many providers let you configure longer retention. Confirm the settings in your own account and the provider's documentation, and agree on the export process with your auditor.
How much effort does retention setup take and what drives it?
The effort depends on the number of in-scope systems, how many log sources feed each control, whether logs are already centralized, and how much history the auditor will sample. Setup usually includes mapping record types to controls, configuring retention and immutable storage, building export and hold procedures, and testing that evidence can be retrieved for the full period. Costs are mostly internal labor and storage. Ask any provider for a written scope that lists systems, log sources, retention periods and deliverables, because those items determine the quote. No general figure is applied here.
Do I need outside help?
Not always, but many teams benefit from it. Management owns its controls, its retention schedule and its evidence. An implementation partner such as DeployOpen can configure self-hosted logging and ticketing platforms, centralize evidence, and document retention and hold procedures inside your own infrastructure, under a written, fixed scope. Only an independent auditor issues the audit opinion. Before you engage anyone, confirm with your external auditor which records they expect, how long they expect them, and in what format.
How DeployOpen scopes retention and evidence work
DeployOpen works under a fixed scope agreed in writing before work starts, and that scope is where retention decisions become concrete. Within the client's own cloud accounts, data centers or air-gapped networks, DeployOpen can configure log storage and ticket retention in the platforms in scope, set up export jobs that copy records out of operational systems, and build evidence folders with consistent naming and access controls. The output is a documented retention schedule that lists each record type, its source system, where it is stored, how long it is kept and who may change those settings. Management reviews that schedule and approves it.
The approval step is where the client's own roles matter most. DeployOpen does not set the company's legal retention position. Counsel, the CFO, the chief accounting officer and the audit committee decide how long ICFR evidence, change tickets and access reviews must be preserved, and whether any legal hold applies. The retention schedule should cite the internal decision that sets each period so an auditor can trace it back. Before scoping, confirm with counsel which records relate to the ICFR assessment and which relate to a possible federal inquiry, because the two may call for different periods.
DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. What the client receives is a configured environment, a retention schedule, and runbooks that show how exports were produced and verified. Ask any implementation partner to state in the quote which systems are in scope, which settings they will change, who will hold administrative credentials after handover, and what the client must still do itself, such as approving the schedule and testing restores on a set cadence.
How DeployOpen prepares evidence and retention for SOX audits
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so logs, tickets and approvals that support ICFR are kept where the company controls them. The company owns its retention decisions and its controls, while DeployOpen prepares the systems and evidence an independent auditor will review.
How we scope
- Agree in writing which systems, log sources and ticket queues hold evidence for the financially significant controls in scope.
- Record the retention period management sets for each evidence type, with the reasons it was chosen and who approved it.
- Confirm with the client's legal and audit teams which retention rules their own counsel and auditor expect to apply.
How we build
- Configure log collection and storage so audit trails for access and change events are kept under immutable or write-protected settings where the platform supports them.
- Set up ticketing and approval workflows so change requests, access reviews and their sign-offs are stored with timestamps and cannot be silently edited.
- Test that retention settings actually apply by checking that older records remain retrievable after the configured period is reached.
How we hand over
- Deliver a retention schedule that maps each evidence type to its owner, storage location, retention setting and retrieval procedure.
- Document how evidence is pulled for a sample request, including the query steps and the export format an auditor can read.
- Provide runbooks for holds, so records tied to an investigation or audit can be preserved without manual deletion risk.
How we support
- Offer ongoing support and upgrades as a retainer, so retention settings stay correct as platforms change version.
- Re-test evidence retrieval on a schedule the client agrees, and update the schedule when scope or systems change.
- Confirm with the client's auditor which evidence formats and retention periods they will accept before the fiscal year closes.
