What a SOX ITGC checklist covers and who owns each item
A public company or newly scoped issuer that needs its IT general controls mapped and evidenced for SOX 404 should start with a clear understanding that no SEC rule or PCAOB standard publishes an official ITGC catalog. The checklist used here is a working set drawn from the four areas named in SEC Release 33-8810: access to programs and data, program changes, program development, and computer operations. Those areas are examples management might consider, not a required list, and the SEC notes that the relevant aspects vary with each company's facts and circumstances. Management only needs the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks, so the first task is deciding which items on any checklist apply to your systems.
Ownership is the part of the checklist that most often goes wrong. Management owns every control, its design and its operation, and management is the party that must assess them and retain evidence supporting that assessment. An implementation partner such as DeployOpen can prepare systems, configure access and change workflows, set up logging and ticket trails, and assemble the evidence packs that management reviews. Only the external auditor tests the controls under PCAOB AS 2201 and issues the attestation report. Internal audit, consultants and vendors can support any of these roles, but none of them can take over management's ownership. Confirm this split in writing before work starts, so that each checklist line has a named internal owner and a named evidence source.
For each item on the checklist, record three things: the control owner, the system or population it covers, and the evidence that will show the control operated during the period under audit. Access items, such as periodic user access reviews and privileged access restrictions, need an owner who can approve or reject access and a report that lists who had access. Change items need an owner who approves releases and a ticket trail that links requests to approvals and testing. Operations items, such as job monitoring and backup restores, need an owner who reviews exceptions. Ask your external auditor early which items they expect to test for your environment, and ask your implementation partner to show how each item maps to a system and a retained artifact. Items with no owner or no evidence are the first gaps to close.
Access to programs and data: what auditors check
Access controls are where SOX ITGC testing most often starts, because they decide who can change financially significant data and programs. Auditors look at how access is granted, limited, reviewed and removed, and they ask for evidence that each step happened as designed.
User provisioning and termination
Auditors test whether each new or changed user account in a financially significant application has an approval that matches the person's job, and whether leavers lose access in a timely way. The risk they name is unauthorized access to data, which can lead to improper changes or unauthorized transactions. Management keeps approval tickets, provisioning logs and termination records, and should reconcile active accounts against the HR leaver list. Confirm which applications the team can export logs from before scoping.
Privileged access
Administrator, superuser and firefighter accounts can bypass the controls built into business applications, so auditors test them separately. The concern is IT personnel holding privileges beyond what their duties require, which breaks segregation of duties. Evidence includes the list of privileged accounts, approvals for elevated rights, and logs showing when those accounts were used and by whom. Ask whether break-glass accounts are logged and reviewed after each use.
Segregation of duties
Segregation of duties checks whether one person can both create and approve a financial transaction, or can build and deploy a change to production. Auditors compare role assignments against a conflict matrix that management defines for each system. Management keeps the role matrix, the conflict rules it applied, and records of any exception with its approval. Expect auditors to ask how new roles are checked against the matrix before they are granted.
Periodic access reviews
A periodic access review asks a manager or data owner to confirm that each person on a system still needs the access they hold. Auditors test whether the review covers the right population, whether the reviewer had enough information to decide, and whether removals were actioned. Evidence is the population report used for the review, the reviewer's sign-off and the follow-up tickets. The review should be documented with its date and reviewer so the auditor can rely on it.
Database and infrastructure access
Access to the database, operating system and cloud console beneath a financial application can change data without passing through the application's controls. Auditors check that direct access to these layers is limited to named administrators, is approved, and is logged. Management keeps the account lists for each layer, database audit logs for direct changes, and the review of those logs. Confirm which layers are in scope with the auditor early, since each one needs its own evidence.
Access continuity and data availability
The second risk named in the standard is loss of data or inability to access data when it is required. For access controls, this means that account lockout, expired credentials or a lost administrator key should not stop the business from reaching its records. Auditors may ask how backup access and recovery accounts are governed and tested. Management keeps the recovery account register, periodic test results and documented procedures for restoring access.
Program development controls for new financially significant systems
This sequence shows how a new or replacement financially significant system moves from the acquisition decision to production, with each step leaving evidence that an auditor can trace. It supports the program development area that SEC guidance names as one IT general control area management may consider, and it reflects AS 2201 paragraph B33, which places controls over application and system software acquisition and maintenance within the IT control environment relevant to automated controls.
Document the acquisition or build decision
Management decides whether to buy a package, adopt an open-source platform, or build in-house, and records the reason, the financial reporting risks the system will touch, and who approved the choice. For self-hosted open-source platforms, the record should also name the people who will own patching, configuration and support after go-live. The output is a signed decision memo or steering committee minute stored with the project file. Confirm with your auditor how much approval detail they expect for systems that only affect operational efficiency, since SEC guidance limits the scope of ITGC evaluation to controls that affect financial reporting.
Approve requirements and design
Finance, IT and the system owner agree on the financial reporting requirements, the automated controls the system must perform, the interfaces to other financially significant applications, and the access model. Approval should come from people who are accountable for the reporting outcome, not only the project team. The output is an approved requirements and design document that maps each key automated control and its data inputs to the risks in the risk assessment. Keep the version history, because auditors often compare the approved design with the configuration that reaches production.
Build and configure under change control
The development or configuration team builds the system or sets up the platform inside the client's own environment, and every code change, configuration setting and infrastructure definition goes through the same ticketing and version control used for production changes. Segregation between developers and production access should be defined before build begins. The output is a traceable build record that links each deliverable to an approved requirement and a named developer. Where the platform is self-hosted, keep the hardening baseline and the configuration files that define it as part of this record.
Test controls against approved requirements
Testers run scripts that exercise each key automated control, including calculations, approval workflows, interface reconciliations and error handling, and compare results with the expected outcomes in the approved design. Defects are logged, fixed and retested, and the final test run is signed off by someone independent of the build team. The output is a test plan, executed test scripts with results, a defect log showing resolution, and a sign-off record. Testing evidence is the item auditors most often request when they examine whether a new system works as designed.
Validate data conversion and migration
When data moves from a legacy system, the team reconciles record counts, balances and key fields between source and target, and documents any mapping decisions or excluded records. Finance reviews the reconciled results and confirms that opening balances agree with the legacy ledger. The output is a conversion plan, reconciliation reports with differences explained, and a signed confirmation from the finance owner. Retain the reconciliation files with the project evidence so the conversion can be traced if a balance is questioned later.
Obtain user acceptance
Business users execute scenarios drawn from their actual processes, such as month-end close, approval routing and report generation, and confirm that the system produces the expected results with the expected access. Users should test the access roles that will go live, so that privileged or conflicting access is caught before production. The output is a user acceptance test record with scenario results, issues raised and their resolution, and a written acceptance by the business owner. Auditors use this record to confirm the people who will rely on the system agreed it works.
Approve go-live and migrate to production
A go-live decision is made by an authorized approver after reviewing test results, conversion reconciliations, user acceptance, open defects and the rollback plan. The production migration is performed by people who did not build the change, and the deployment is logged with the approval reference. The output is a go-live approval record, a deployment log, and a post-implementation review that confirms production settings match the approved design and that the system is added to the access review and monitoring processes. Confirm with your external auditor which evidence they will sample, as the list of required items varies by company.
Computer operations: scheduling, backups, incidents and service providers
Scheduling controls make sure that batch jobs that produce financially significant output, such as interface feeds, month-end postings, interest accruals and report generation, run as designed, complete, and are reviewed when they fail. The control question is whether a job that feeds the general ledger or a financial report runs completely and accurately. A job that only supports an operational dashboard usually falls outside scope, because SEC guidance says management need not evaluate IT general controls that only affect operational efficiency. Scope starts from the financial reports and the automated controls that depend on the job.
- Job inventory: A current list of batch jobs that touch financially significant data, with owner, schedule and dependencies.
- Failure handling: Alerts for failed or late jobs, and a record of who reviewed each exception and how it was resolved.
- Reconciliation of outputs: Control totals or record counts that confirm the job output matches its input.
- Change control over schedules: Changes to job definitions or timing go through the program change process.
- Evidence: Scheduler configuration exports, job run logs for the test period, exception tickets and reviewer sign-off.
Confirm with your auditor which jobs they treat as in scope before you build the evidence set.
Backup controls address the PCAOB risk of potential loss of data or an inability to access data as required. For SOX purposes, the question is whether financially significant data and applications can be restored completely and accurately if a failure occurs, and whether management tests that capability rather than assuming it. Backup jobs that succeed on a log do not prove recovery works, so auditors usually look for a restore test with documented results.
- Backup scope: Documented coverage of financially significant applications, databases and configuration files, mapped to the systems in ITGC scope.
- Monitoring: Alerts for failed backups and records of how each failure was cleared.
- Restore testing: Periodic restores into a non-production environment, with results compared against source data.
- Retention and protection: Backup copies protected from unauthorized access and kept for the period management sets.
- Evidence: Backup policy, schedule configuration, job logs, restore test records with sign-off, and the ticket trail for failed restores.
Confirm the restore test frequency and sample size with your auditor, since these are set by your risk assessment and the auditor's testing approach.
Incident controls make sure that operational failures affecting financially significant processing are logged, prioritized, resolved and escalated when they could affect financial reporting. The question is not whether every help desk ticket is in scope, but whether the incident process would detect and correct a failure that could cause a misstatement, such as a failed interface, a corrupted data load or a processing outage during a close window. Where an incident touches a security matter, the process also connects to the cybersecurity controls in your ITGC program.
- Logging and classification: Incidents recorded with timestamp, system, severity and affected process.
- Escalation: Defined routes for incidents that reach financially significant systems or the close calendar.
- Root cause and follow-up: Analysis of significant incidents and tracking of corrective actions to closure.
- Link to other controls: Incidents that reveal a control failure are assessed for their effect on related automated controls.
- Evidence: Incident tickets with timestamps, severity and resolution, escalation records, post-incident reviews and the closure approvals.
Ask how your organization records incidents on financial systems so that the population an auditor samples is complete.
When a service provider runs part of a financial process, such as a hosted ledger, a payroll platform or a managed data center, management still owns the ICFR assessment. Oversight controls require management to obtain assurance about the provider's controls, understand which of those controls the company relies on, and cover any gaps with its own controls. A SOC 1 report is a common source of that assurance, but it describes the provider's controls at a point in time or over a period, and it does not replace the company's own review of user entity controls.
- Provider inventory: A list of providers that process or host financially significant data, with the services and processes they perform.
- Report review: Annual review of each SOC 1 report, the test period, exceptions, complementary user entity controls and bridge letters where the period gap is open.
- Complementary controls: Documented company controls that address each complementary user entity control the report assigns.
- Contract and access terms: Agreements that give audit rights, define responsibilities and limit provider access to your data.
- Evidence: Reviewed SOC 1 reports with reviewer notes, mapping of complementary controls, exception assessments and vendor review sign-offs.
Confirm with the provider which report type and period cover your processes, and with your auditor how they plan to rely on that report.
Where manual intervention and spreadsheets break the checklist
Inappropriate manual intervention is an IT risk that PCAOB AS 2110 names directly, and it is the risk that most often breaks an otherwise clean ITGC checklist. An automated control, such as a three-way match or a calculated reserve, is only as reliable as the program logic and data it depends on. If someone can override a result, edit a table directly or re-run a job by hand, the automated control still appears to operate while its output can no longer be trusted. Auditors therefore test the ITGCs that protect those dependencies (access, program changes and computer operations) and then look for the manual paths that bypass them. Each manual path should be a line item on the checklist with an owner, a trigger and a named evidence source, not a footnote.
Three paths need separate rows. Manual overrides of system results, such as a changed approval status or a forced posting, should require a documented business reason, a second approver who is independent of the requester, and a system record that captures the before and after values. Direct database edits should be restricted to a narrow, named set of privileged accounts, routed through a break-glass or change process, and logged at the database level with the user, timestamp, statement and ticket reference. End-user spreadsheets that feed financial figures should be inventoried, assigned an owner, version-controlled, and checked for the formulas and inputs that matter, with evidence of review. The reader should confirm with the external auditor which spreadsheets and override types it will treat as in scope, because that determination depends on each company's facts and circumstances.
Before year end, run one exercise: pick a financially significant report, trace every manual step that touched its inputs over a sample period, and ask whether the approval, log or review that proves each step can be retrieved without asking the person who performed it. Gaps found this way are usually retention gaps, such as database audit logs rolled off after a short window, or approval evidence held in chat rather than a ticket. Confirm the retention period for those logs with IT operations and the finance team now, since the answer determines whether the evidence exists when the auditor asks for it. Self-hosted platforms can help by keeping database audit logs, ticket records and change approvals inside the company's own environment, where retention and access controls are set by the organization rather than by a vendor.
Which evidence management keeps for each control area
This table compares the four IT general control areas against the IT risk each addresses under AS 2110, the evidence an auditor typically asks for, and who produces it. Read each row as a question to answer with a ticket, log or approval record, then confirm the owner with your own control matrix.
| Control area | IT risk under AS 2110 | Typical evidence | Who produces it |
|---|---|---|---|
| Access to programs and data | Unauthorized access to data, and IT personnel holding privileges beyond their duties, which breaks segregation of duties | Access request and approval records, quarterly user access reviews with sign-off, privileged account lists, terminated user removal tickets | Management reviews and approves; system owner runs the reports and removes access |
| Program changes | Unauthorized changes to systems or programs | Change tickets with approvals, test results, segregation evidence between developer and deployer, production change logs | Change owner and system owner; IT change board approves; service provider supplies its own change records where it runs the system |
| Program development | Inappropriate manual intervention and unauthorized changes during build or conversion of new financial systems | Project approvals, test plans and sign-offs, data conversion reconciliations, go-live approval memo | Project sponsor and management approve; system owner and testers execute and retain records |
| Computer operations | Potential loss of data or inability to access data as required, and inappropriate manual intervention in processing | Job schedule and monitoring logs, backup completion and restore test records, incident tickets, service provider review memos | System owner runs operations and backups; management reviews incidents and service provider reports |
How much documentation the checklist needs
SEC guidance does not require a particular documentation format for ICFR. Management can use policy manuals, process models, flowcharts, job descriptions and memoranda, and the documentation only has to cover the controls management concludes adequately address financial reporting risks, not every step in a process. For this checklist, that means the documentation scope follows the ITGCs your automated controls depend on. Start from the list of financially significant applications and the automated controls that rely on them, then record the access, change, development and operations controls that keep those controls reliable. Anything you check here that does not support a financial reporting risk can be documented lightly or left out of the ICFR file.
Instruction 2 to Item 308 of Regulation S-K requires the registrant to maintain evidential matter, including documentation, that gives reasonable support for management's assessment of ICFR. In practice, each checklist line should point to a named artifact: a policy, a configured report, a ticket, an approval record or a review sign-off, with an owner and a date. Before the auditor arrives, confirm with your external auditor which forms of evidence they will accept for each control area, such as system-generated reports versus screenshots, and whether they expect a walkthrough document for each in-scope system.
Retention is where many teams assume too much. The checklist will tell you which logs, tickets and approvals to keep, but it does not set how long to keep them. Ask your securities counsel and your external auditor to confirm the retention periods that apply to your company, including the requirements that relate to audit workpapers and records supporting management's assessment, and make sure your log and ticket retention settings match that answer. Record the confirmed periods in your evidence inventory so the decision is documented, not inherited from a default in a tool.
How the checklist moves from scoping to auditor testing
The sequence turns a list of IT general controls into a documented, evidenced package that management can stand behind and the external auditor can test. Each phase closes with a named output so gaps surface before the auditor arrives.
Scope applications and infrastructure top-down
Start from the financial statements and work down to the systems that produce, store or process the figures in them. Management, with finance and IT, identifies the financially significant applications, databases, operating systems, network components and the IT service providers behind them, using a risk-based approach. SEC guidance says management only needs the IT general controls that support controls addressing financial reporting risks, so operational-only systems are excluded with a recorded reason. The output is a signed scope list that names each in-scope system, its role in financial reporting and the rationale for leaving out anything close to the line.
Map each in-scope risk to a control area
For each in-scope system, identify the IT risks that could affect internal control over financial reporting. The risks PCAOB AS 2110 names include unauthorized access to data, IT personnel holding privileges beyond their duties, unauthorized changes to systems or programs, loss of data or inability to access it, and inappropriate manual intervention. Assign each risk to access to programs and data, program changes, program development or computer operations, and note which automated or IT-dependent controls depend on it. The output is a risk-to-control matrix that shows every in-scope system is covered in at least one area and every control has a stated purpose.
Document the design of each control
Write down how each ITGC is designed to work: who performs it, how often, which system or tool it runs in, what triggers it and what it produces. SEC guidance accepts many documentation forms, including policy manuals, process models, flowcharts, job descriptions and memoranda, so teams can use the format they already maintain. Documentation only needs to cover controls management relies on, not every activity in the process. The output is a control narrative or matrix entry for each in-scope control that a reviewer can read without asking the control owner what it means.
Perform walkthroughs for each control area
Trace one transaction or change through each control from start to finish with the person who performs the control. The walkthrough confirms that the documented design matches what happens in practice, including approvals, system settings and the points where evidence is created. Walkthroughs are usually run across access, change, development and operations for each in-scope system. The output is a dated walkthrough record for each control that states whether the design is effective or where it differs from the documentation, along with any gaps that need remediation before testing.
Collect operating evidence for the period
Gather the records that show each control operated throughout the period under review. Typical evidence includes access review sign-offs, user provisioning and removal tickets, change tickets with testing and approval, release records, job schedule logs, backup and restore results, incident records and reviews of service provider reports. Owners should confirm that reports used as evidence are complete and accurate, such as system-generated user lists, so the evidence reflects the population tested. The output is an evidence binder indexed to each control, with a named owner and retrieval path for every item.
Assess exceptions and document the conclusion
Review the collected evidence for any control that failed to operate as designed, missed a review or lacked approval. Management decides whether each exception is isolated, whether a compensating control or manual check covers the gap, and how it affects IT-dependent controls over financial reporting. Each conclusion is written down with the reasoning behind it. The output is an exception log with a disposition for every item and a management conclusion for each control area that the team can defend in discussion with the auditor.
Hand the package to the external auditor
Assemble the scope list, risk matrix, control documentation, walkthrough records, evidence binder and exception log into one package, and confirm the index matches the scope agreed at the start. The external auditor, not the implementation partner or internal team, tests the controls and forms its own conclusion under PCAOB AS 2201 and AS 2110. Confirm with the auditor in advance how they want evidence delivered and which samples or populations they will request. The output is a delivered, indexed package and a recorded list of follow-up requests from the auditor.
What must be in place before the auditor tests
Before an auditor samples anything, management needs agreed scope, named owners, complete populations, retained evidence and documented walkthroughs. These five items connect so that each test can be traced from a control, to the people responsible for it, to the records that prove it ran.
Scope agreed with the auditor
Confirm in writing which applications, databases, infrastructure and locations sit inside ITGC scope before testing starts. SEC guidance says the relevant ITGCs vary with each company's facts and circumstances, so the scope should trace back to the financial reporting risks it supports. Check that the external auditor has reviewed the scope and that any system added after the scope was set is tracked to a documented decision.
A named owner for each control
Every ITGC needs one accountable person who can explain how the control operates, who performs it and what evidence it produces. Shared ownership, such as an access review split between IT and finance with no lead, makes it hard to answer auditor questions. Check that each owner appears in the control matrix, has a backup for absences, and has signed off on the control description.
A population report for each control
Auditors select samples from a complete population, so management must produce a full list for each control, such as every user change, every production release or every job failure in the period. An incomplete or unverified population can invalidate the sample. Check that the report comes from the system of record, carries a date and parameters, and reconciles to a count the owner can explain.
Retention of logs and tickets
Access approvals, change tickets, job logs and incident records must still exist when the auditor asks for them. PCAOB AS 2110 treats unauthorized access and unauthorized program changes as IT risks, and the evidence for those controls depends on logs that have not been overwritten. Check the retention period configured in each source system, confirm that exports are stored outside the system, and test that you can retrieve a record from the start of the period.
A walkthrough file per control
A walkthrough shows one transaction moving through a control from start to finish, which lets the auditor confirm the control exists as designed. Keep a file for each control with the process description, the flow of the sample transaction, the screenshots or exports used, and the names of people interviewed. Check that the file matches the current configuration, because a walkthrough from a previous system version does not support the control today.
Questions buyers ask about the SOX ITGC checklist
Is there an official list of SOX IT general controls?
No. Neither the SEC nor the PCAOB publishes a catalog of IT general controls. SEC Release 33-8810 says the IT controls relevant to an ICFR evaluation vary with each company's facts and circumstances. It names program development, program changes, computer operations and access to programs and data as areas management might consider, while noting they do not apply to every company. A checklist is therefore a working tool your team builds from your own systems, financial reporting risks and auditor expectations, not a published standard you can simply adopt.
How many ITGCs does a typical SOX checklist contain?
It depends on scope. The number of controls follows from which financially significant applications, databases, infrastructure and locations fall inside the ICFR evaluation, and from how many automated or IT-dependent controls rely on them. A company with one ERP and a single general ledger will need a much shorter list than a group with several ERPs, a consolidation tool and multiple cloud platforms. Management only needs to evaluate the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. Ask for the scoping memo before you ask for a control count.
Can our own team build the ITGC checklist in-house?
Often yes, if you have staff who understand both the financial systems and the control objectives. The checklist should map each control area to the IT risks that PCAOB AS 2110 names, such as unauthorized access to data, IT personnel holding access beyond their duties, unauthorized changes to systems or programs, loss of data or inability to access it, and inappropriate manual intervention. The work is mostly judgment about what matters for your environment. An outside partner can help prepare systems, configurations and evidence collection, but the organization owns its controls and the external auditor does the attestation.
What does the work require from IT and finance staff?
It requires named owners on both sides. IT must confirm how access is granted and removed, how changes move to production, how new systems are approved and how jobs, backups and incidents are handled. Finance must confirm which reports and automated calculations feed the financial statements and who reviews them. Expect walkthroughs, sample requests and screenshots or exports that show each control operated during the period. Ask your partner to list each evidence item, its owner and its retention location before work begins, because missing evidence is the most common reason a control cannot be relied on.
What drives the cost of building and maintaining the checklist?
The main drivers are the number of in-scope systems, the number of locations and third-party providers, how much evidence is generated automatically versus collected by hand, and how many remediation cycles are needed. Cost components include internal labor, which is usually the largest, plus outside advisory fees and the external audit. The SEC's 2020 estimate for issuers newly exempt from the Section 404(b) auditor attestation put average savings at about $210,000 per year, roughly $110,000 in audit fees and $100,000 in other costs (Release 34-88365). That figure is a regulatory estimate for a specific exemption, not a benchmark for your engagement. Request a fixed-scope written quote that lists systems, deliverables and timing.
Can an implementation partner issue or sign a SOX ITGC report?
No. Only an independent external auditor can issue the ICFR attestation under Section 404(b) when it applies, and management signs its own assessment. A partner such as DeployOpen can plan, implement, configure, document and support the open-source systems that produce ITGC evidence, and can prepare controls and evidence for the audit. It does not issue audit reports, attestations or certifications. Confirm with your auditor which evidence formats and sampling approach they will accept before the partner builds the collection process.
Which tests will the auditor run on the checklist?
Auditors typically test whether each control is designed effectively and whether it operated during the period. Design testing usually uses walkthroughs, and operating testing uses samples drawn from logs, tickets and approvals. Your checklist should name the evidence each sample will need, such as access review sign-offs, change tickets with testing and approval records, or backup restoration logs. Ask your auditor which population and sample sizes they expect, because those choices determine how much evidence you must keep.
How DeployOpen prepares systems and evidence for the ITGC checklist
DeployOpen works on the SOX ITGC checklist by control area as an implementation partner. We prepare the self-hosted open-source platforms, access settings, change records and operating evidence that management reviews and the external auditor tests, while management keeps ownership of every control and the auditor issues the conclusion.
How we scope
- Agree in writing which financially significant applications, databases and infrastructure fall inside the ITGC checklist before work starts.
- Map each in-scope system to the access, program change, program development and computer operations areas it touches.
- Confirm with management which controls it relies on, so that no control is built without a named owner and evidence source.
How we build
- Configure role-based access, privileged account handling and periodic access review on the self-hosted platforms within your infrastructure.
- Set up change workflows with approval, testing and production promotion records that tie each change to a ticket.
- Enable logging, job monitoring and backup and recovery procedures, with retention settings your management team has agreed to.
How we hand over
- Deliver control descriptions, flowcharts and procedures in a form your management and auditors can review and sign off.
- Provide an evidence index that lists each control, its owner, the system of record and the sample population an auditor would select.
- Document configuration baselines and known limitations so your team can run and explain the controls after handover.
How we support
- Ongoing support, upgrades and continuous testing are available under a retainer, agreed separately from the fixed-scope project.
- Re-check access, change and operations evidence before each assessment period so gaps surface before the auditor's fieldwork.
- Confirm with your auditor which evidence formats and sample periods they expect, and adjust the evidence index to match.
