Which SOX ITGCs for SaaS financial applications stay with your company
When an ERP, billing or payroll application moves to SaaS, your auditor will still ask for IT general control evidence over that system. Your company still owns user access, configuration, interface and change controls for the application, and it must obtain, review and rely on the provider's report. The provider runs the infrastructure and much of the platform, but it does not run your user provisioning, your role design, your parameter settings or the feeds that move transactions in and out of the ledger. Management owns these controls. DeployOpen prepares systems, documents controls and assembles evidence for the assessment, but DeployOpen does not test controls or issue opinions on them. The external auditor tests the controls under PCAOB AS 2201 and decides whether they work. Under AS 2201, when a service organization's services are part of your information system, the auditor includes them in the evidence it needs. Under the same standard, if the provider's report assumes controls applied by your company (complementary user entity controls), the auditor checks that you actually operate them. Management also keeps responsibility for the flow of information to and from the provider, even when it relies on a service auditor's report. The exact split depends on three things: the application, the scope of the provider's report, and how your company has configured the system. A report that covers only the hosting environment will leave application access and configuration with you. A report that covers the application's logical access and change management may shift more of the testing burden, but only for the controls it actually tested. Confirm with the provider which controls and subservice organizations the report includes, then map each remaining control to a named owner before the auditor's walkthroughs begin.
Which ITGC areas the company still runs for a SaaS ERP, billing or payroll system
When a financial application runs as SaaS, the provider's SOC 1 report covers its own data center and platform operations, not the configuration, users and interfaces your company controls. The four cards below cover the areas that stay with the company and the reasons the provider's report cannot close them.
User access and privileged roles
Your company still approves who gets accounts, which roles they hold and when access is removed. Provisioning, the privileged and administrator roles that can change configuration or payment settings, and segregation of duties between entry, approval and release all live in the tenant you administer. Auditors will ask for the access request, approval and termination records, plus a periodic review that shows each user's role is still appropriate. A provider's report describing its own staff access does not show who in your organization holds these roles.
Configuration and parameter changes
Many automated calculations depend on tables and parameters rather than code. A tax rate table, a billing rule or a payroll deduction setting can change a reported figure without any software release. PCAOB AS 2201 paragraph B30 notes that automated application controls may depend on related files, tables, data and parameters, so these settings fall within your ITGC scope. Keep a log of who changed each parameter, why, and who approved it, and compare parameter values against the approved source at period end.
Interfaces and data flows
Data moves between the SaaS application and your general ledger, banks, HR records and other systems through files, APIs or integration middleware that you configure. Under AS 2201 paragraph B18, a service organization's services that form part of your information system are part of your ICFR, so the feeds into and out of the provider are yours to evidence. Confirm who owns each interface, how transmissions are authorized, and how failed or rejected records are detected and resolved.
Vendor oversight and report review
Management stays responsible for controls over outsourced operations even when it relies on a service auditor's report. Your team must obtain the SOC 1 report each year, check its period against your fiscal year end, read the scope and exceptions, and document the complementary user entity controls the report assumes you perform. If the report is a bridge letter or covers a different period, you need a record of how the gap was assessed. Auditors will test that this review happened and that its conclusions were acted upon.
What provider report you must obtain and how auditors evaluate it
The usual starting evidence for a SaaS financial application is a SOC 1 Type 2 report from the provider, prepared by an independent service auditor. The company does not get to skip the assessment because the provider has a report. SEC staff FAQ Question 8 says management still has to assess the controls over outsourced operations even when it relies on a service auditor's report. In practice, that means the company must obtain the report, read it against its own financial reporting risks, and document what it concluded and why. Before you request the report, confirm with the provider which systems, modules, hosting locations and services the report covers, since a report for the platform may not cover the billing or payroll module you actually use.
When the external auditor reviews your reliance on the report, under PCAOB AS 2201 paragraph B21, they look at four things: the period the report covers relative to your as-of date, the scope and controls tested, the test results, and the opinion. Check each one. A Type 2 report covering a period that ends months before your year end leaves a gap you must cover with your own evidence, and a bridge letter from the provider is one common way to address it. Read the exceptions section closely, because an exception on a user access or change management control touches the same risks you own. Confirm the service auditor's opinion is unqualified, and note any subservice organizations carved out of the scope.
Two obligations stay with you regardless of how clean the report is. First, under AS 2201 paragraph B22, the report often assumes that the user company performs certain complementary user entity controls, such as reviewing user access lists, approving configuration changes, or reconciling interface files. The auditor evaluates whether you actually apply each one, so build a list from the report and map each item to an owner, a frequency and evidence. Second, under the SEC staff FAQ, you remain responsible for controls over the flow of information to and from the provider, including the data feeds, interface files and file transfers that carry transactions in and results out. If the report period or scope does not fit, the usual next step is a gap assessment with the provider, not an assumption that the report covers it. Pointers on SOC 2 reports and bridge letters are covered elsewhere in this pillar.
How the SaaS ITGC scope gets set and tested each year
The annual sequence starts with confirming the SaaS application is financially significant and ends with the company's own controls tested and handed to the external auditor, with each step producing a documented output. The provider's SOC 1 report supplies part of the evidence, but the company still owns the controls around its users, configuration and interfaces.
Confirm the application is financially significant
Finance, IT and internal audit confirm which SaaS applications process, store or report transactions that feed the financial statements, such as the ERP, billing platform or payroll system. The team records the reasoning, the relevant financial reporting risks and the modules, reports and interfaces in scope. The output is a signed scoping memo that lists each in-scope application and the business process it supports. Anything excluded needs a documented reason so the external auditor can follow the decision.
Obtain and read the provider SOC 1 report
The company requests the provider's SOC 1 Type 2 report, which is prepared by the provider's service auditor under the AICPA's SOC 1 framework, and reviews the period it covers, the systems described, the controls tested and the opinion. Compare the coverage period with the company's fiscal year end and confirm the report covers the specific services used, not only the provider's general platform. The output is a short review note recording any gap in period, scope or exceptions, which feeds the bridge work in a later step.
Map complementary user entity controls to owned controls
The SOC 1 report lists complementary user entity controls, which are controls the service auditor assumed the customer performs, such as reviewing user access lists or approving configuration changes. The team maps each one to a named control the company owns, with an owner, frequency and evidence source. Any complementary control without a matching owned control is flagged as a gap. The output is a mapping table that the external auditor can trace from the provider report to the company's own testing.
Design and document the company's own controls
The company designs and documents its own access, configuration, interface and change controls for the application. Access controls cover provisioning, periodic user access reviews and privileged role management in the SaaS tenant. Configuration controls cover settings that affect financial calculations, such as rate tables and approval thresholds, and the process for changing them. Interface controls cover the feeds in and out of the application, and change controls cover releases the provider makes that the company must review. The output is a control narrative and risk-control matrix for each area.
Test design and operating effectiveness with samples
Internal testing first confirms the design of each control through a walkthrough, then tests operation over the period using samples. For example, a tester might select user access review records for several quarters and check that the reviewer compared the listed users against current job duties and that exceptions were removed. Testers also check the completeness of system-generated reports used in the controls. The output is a test workpaper for each control showing the population, sample, evidence examined and any exceptions with their root causes.
Bridge any gap between report and year end
Where the SOC 1 report period does not reach the company's assessment date, the company gathers evidence covering the remaining period. This usually includes a bridge letter from the provider confirming that no significant changes occurred and that known exceptions are unchanged, along with the company's own testing of the controls it owns over that gap. The SEC staff FAQ notes that management may rely on a provider's report as of a different year end but remains responsible for controls over the flow of information to and from the provider. The output is a documented bridge conclusion linked to the provider report review.
Hand the results to the external auditor
The company gives the external auditor the scoping memo, the provider report review, the complementary control mapping, the control narratives and the test workpapers. The auditor uses these to assess the provider report under its standards, including the period covered, scope, controls tested and results, and to check that the company applies the complementary controls the report assumes. Any exceptions are discussed with management and the auditor before the assessment is finalized. The output is an agreed evidence package and a documented list of open exceptions and their owners.
Complementary user entity controls: what each common provider report assumes you do
An ERP provider's SOC 1 report usually describes the controls the provider runs over its hosted environment, such as data center access, infrastructure change management and backups. It also lists complementary user entity controls, which are controls the report assumes the customer operates for the report to hold together. For a SaaS ERP, these commonly concern who can administer the tenant, how customer-side configuration is approved, and how the customer checks that the provider's output matches what it records in the ledger. Confirm the exact list in the report's complementary user entity controls section, since wording and numbering differ by provider.
- Tenant administrator access: Review the list of users with administrative roles in the customer tenant on a set schedule and remove access that no longer matches a current duty.
- Customer-side configuration approval: Approve changes to workflows, approval limits, chart of accounts and posting rules before they go live, and keep the approval record.
- Interface and batch monitoring: Check that scheduled interfaces and batch postings completed, and investigate rejected or partial loads.
- Output reconciliation: Reconcile key ledger balances and subledger totals produced by the system to source reports.
For each complementary control in the report, write down the matching control in your own program, its owner and its evidence, and confirm that the auditor will see the same list in your documentation.
Billing and subscription platforms often drive revenue recognition, so their provider reports tend to assume the customer controls the rate and product setup and checks the output that flows to the general ledger. The provider may run the application and its infrastructure, but the customer still decides which prices, discounts and tax rules apply, and who may change them. Where the billing system is a source for revenue entries, the auditor will look for evidence that the customer reviewed the output rather than relying on the provider alone. Confirm which of these assumptions appear in your provider's report.
- Rate and product table changes: Require review and approval for changes to prices, plans, discount rules and tax settings, and keep a log of who approved each change.
- Invoice-to-ledger reconciliation: Reconcile billed amounts, credits and adjustments from the billing system to revenue entries posted in the ledger for each period.
- Credit and manual adjustment review: Review manual invoice changes and credit memos above a defined threshold, with evidence of independent approval.
- Interface monitoring: Confirm that usage or order data feeds reached the billing system completely and that failed records were resolved.
Illustrative example: a company might reconcile its billed totals to ledger postings each month and file the signed reconciliation with the period close package, which gives the auditor evidence the report's assumption was operated.
Payroll providers commonly report on controls over calculation, tax filing and the security of their platform, while assuming the customer controls the employee master data, pay rates and the approval of payroll runs before funds move. Because payroll amounts flow directly into expense and liability balances, auditors give these assumptions close attention. Customers should not treat a clean provider report as covering their own approval of a payroll run or their review of payroll totals. Confirm the specific list in the provider's report, including any reliance on the customer for bank file transmission or funding.
- Employee master data changes: Approve new hires, terminations, pay rate changes and bank account changes, with segregation between the person who enters and the person who approves.
- Payroll run approval: Review the register and summary totals against approved headcount and expected changes before each run is released.
- Payroll-to-ledger reconciliation: Reconcile gross pay, employer taxes and withholdings in the provider's reports to the amounts posted in the general ledger.
- Provider access to bank files: Confirm who can authorize funding and bank transmissions, and review access to the payroll portal by people with payment authority.
Some payroll reports cover only part of the process, so confirm whether the user entity controls extend to funding and bank file release, which are often where the highest-risk misstatements arise.
Gaps that leave the ITGC evidence incomplete
A SaaS financial application can look fully covered on paper and still leave gaps in the evidence auditors need. The six gaps below share one root cause: the company assumes the provider's report or the provider's controls answer a question that only the company's own records can answer.
Report period misses the assessment date
A SOC 1 Type 2 report covers an observation window, and that window may end months before your fiscal year end. Compare the period covered with the as-of date you are assessing. If a gap exists, check whether the provider issued a bridge letter and whether your own controls cover the uncovered months. Ask the provider for the report's exact period and the date of its next report before the assessment starts. Management remains responsible for controls over the flow of information to and from the provider, even when a report is used.
Report excludes a module or interface
Providers often scope their report to the core application and leave out add-on modules, reporting tools, data exports or integration services that your team uses for financial reporting. Map every module, integration and report that feeds the ledger against the report's system description. Anything outside that description needs its own evidence, such as your own access reviews and change records. Raise the gap with the provider early, because a missing scope item cannot be fixed by a later reading of the report.
Complementary controls assumed, not operated
A provider report often lists complementary user entity controls, which are controls the report assumes you run. Typical examples include reviewing user access, approving configuration changes and checking the completeness of uploaded data. If you do not operate these controls, the provider's clean opinion does not cover your side of the process. Build a list of every assumed control, assign an owner, define the evidence each one produces and test it on its own schedule. Keep the evidence in a location the auditor can reach.
Exceptions in the report never reviewed
A report with an unqualified opinion can still list test exceptions, deviations where a provider control did not operate as described. Read the test results section for each control relevant to your financial data, not only the opinion paragraph. For each exception, record the impact on your reliance, ask the provider for remediation evidence and decide whether a compensating control of your own is needed. Document that review as part of the provider assessment, because the auditor will ask for it.
Interfaces without reconciliation
Payroll, billing and ERP systems often exchange files or API transactions that move balances between systems. A provider's controls over its side of an interface do not show that the data arrived complete and accurate in your general ledger. Run reconciliations that compare record counts, control totals and key balances between the source and the target, and retain the signed results. Confirm who investigates unmatched items and how quickly they are cleared. Without this check, an interface failure can silently misstate reported figures.
Privileged provider access not visible
Provider support engineers and administrators may hold elevated access to your tenant, data or configuration, and that access may not appear in your own user listings. Ask the provider to describe its privileged access process, how it is approved, how it is logged and whether customers can see those logs. Request access logs or a periodic listing of provider administrator activity in your tenant, and review them against support tickets. Confirm with the provider which of these capabilities it offers, since the options vary by product.
What to request from a SaaS provider before the audit
Before the audit starts, ask the SaaS provider for a current SOC 1 Type 2 report that covers the financial application you run, and check its period first. The report should state the period it covers and the scope of the system it describes. Read the system description to confirm that your ERP, billing or payroll modules, the hosting environment and the interfaces you use are inside that scope. If a module you rely on is missing, the report does not support your controls over it. Also ask for the list of complementary user entity controls, which are the controls the provider assumes you operate, such as reviewing user access, approving configuration changes you request and reconciling interface output. Each one becomes a control you must design, run and evidence.
Next, request the exceptions and management's responses, and the names of the subservice organizations such as hosting, data center or backup providers that the report carves out. Exceptions show where the provider's controls did not operate as described, and the response shows whether the provider has fixed them. Ask whether any subservice organization is excluded from testing and whether it issues its own SOC 1 report. If the report period ends before your fiscal year end, request a bridge letter that states whether the provider is aware of material changes or failures since the period end. Confirm with the provider how it will deliver these documents and how often it updates them, because your auditor will expect a current copy at the time of testing.
If the provider cannot supply a SOC 1 Type 2 report, or the report covers only part of the system or a short period, your approach changes. You will need to test more of the controls yourself, and the gap must be documented before fieldwork. The separate topic on vendors without a SOC 1 report covers the options, so start that review as soon as you see a gap, not during year-end close. Keep a dated record of every document requested, received and reviewed, along with the name of the person who confirmed each answer. That record shows the auditor how management assessed the provider's evidence and where it still holds responsibility.
Questions finance and IT teams ask about SaaS ITGCs
Is a SOC 1 report alone enough for SaaS financial applications?
No. A SOC 1 report from the provider covers the controls that provider operates, but it does not cover the controls the company runs for its own users, roles, configuration and interfaces. The PCAOB standard expects the auditor to evaluate the service auditor's report by its period, scope, controls tested and results, and it also expects the company to apply any complementary user entity controls the report assumes. Management also keeps responsibility for controls over outsourced operations even when it relies on that report. Treat the SOC 1 as one input to the assessment, and map each control the report depends on to a control you run and can evidence.
Who tests the company's access controls in a SaaS ERP?
The company's own team performs and documents the access controls it owns, and the external auditor tests them. Typical company-owned access controls include user provisioning and removal, role design, segregation of duties conflicts, privileged administrator accounts and periodic access reviews. The provider's SOC 1 usually does not test whether your administrators approve the accounts they create. Internal audit or a co-sourced reviewer may test these controls before the auditor does, but the external auditor makes its own selection and evaluation. Ask the auditor early which population and sample it expects for user access testing.
What drives the effort of SaaS ITGC work?
Effort tracks how many controls the company must own and evidence, which is shaped mainly by three factors:
- Number of users and roles: more accounts and role changes mean larger access review populations and more provisioning tickets to sample.
- Number of interfaces: each feed into or out of the SaaS application, such as payroll files, bank loads or billing exports, may need its own completeness and accuracy controls.
- Scope of the provider report: a report that covers the financial application and its hosting, and lists clear complementary user entity controls, leaves less to build. A narrow or outdated report leaves more gaps to close.
Ask any consultant or provider to price the work against these inputs in writing, and separate one-time setup from recurring quarterly or annual testing.
Can our internal team run SaaS ITGCs without outside help?
Often yes, if the team has someone who understands both the financial application and the control objectives, and enough capacity to perform reviews on schedule. Internal teams usually handle access reviews, change approvals and interface reconciliations well once the design is documented. Outside help tends to be useful for mapping the provider's SOC 1 complementary controls, writing control descriptions that match the auditor's expectations, building repeatable evidence packs and running a dry-run test before fieldwork. Management must keep ownership of the controls and the conclusions either way. Confirm with your external auditor what documentation and testing it will accept.
How does the external auditor use the provider's report?
The auditor reads the provider's service auditor report and decides how much reliance it can place on it. Under the PCAOB standard, the auditor considers the period covered relative to the as-of date, the scope of services and controls tested, the test results and the opinion. If the report assumes controls the company applies, the auditor checks whether the company actually operates them. Where the provider's services are part of the company's information system, the auditor includes them when deciding what evidence is needed. The auditor still performs its own procedures on company-owned controls, so the report reduces work but does not replace it.
What happens when the provider report period does not match our year-end?
A gap between the report period and your fiscal year end does not automatically fail the assessment, but it must be addressed. The SEC staff FAQ says management may rely on a provider report covering a different year-end, while remaining responsible for controls over the flow of information to and from the provider. In practice, companies often gather a bridge letter from the provider covering the gap, test the company's complementary controls across the uncovered period, and document why the coverage is sufficient. Ask your provider how it issues bridge letters and what it confirms in them, and agree the approach with your auditor before the year end.
Does DeployOpen issue a SOX audit report or attestation?
No. DeployOpen does not issue audit reports, attestations or certifications. Its role is to prepare systems, controls and evidence for the assessment, for example by mapping provider complementary controls to company-run procedures, configuring access review and change records, and documenting interfaces. Management owns the controls and its ICFR conclusion, and the external auditor performs the attestation under the applicable PCAOB standard. Engagements are fixed-scope and agreed in writing before work starts, so you can check the scope against your auditor's expectations before committing.
Where SaaS ITGC programs usually break down
The most common failure in a SaaS ITGC program is not a missing control but a control that exists only on paper: the complementary user entity controls (CUECs) named in the provider's SOC 1 report that nobody at the company has mapped to an owner. Auditors read the report's section on controls the provider assumes you run, then ask for evidence that you run them. Typical examples include reviewing the provider's user access listing each quarter, approving the vendor's changes to rates or tax tables, and confirming that the scope of the report covers the modules you actually use. Before the period starts, build a register that lists each CUEC, the named owner, the frequency and the file or ticket that will prove the review happened. Confirm with the provider which of its carve-outs or subservice organizations the report excludes, because those gaps also need your own coverage.
Interface reconciliations are the second frequent gap. A SaaS billing or payroll system usually sends journal entries, bank files or tax data into the general ledger through an integration that someone built and nobody formally owns. When the integration fails, the totals stop agreeing and the error is found months later during close. Under PCAOB AS 2201, the company must still control the flow of information to and from the service organization. Assign an owner to every interface, define the control total (record count, batch value, hash total), and retain the signed reconciliation for each period along with the exception log. Ask whether the vendor's API or file export logs are retained long enough to support a full-year test.
Configuration changes made directly by administrators without a ticket are the third failure point. SaaS platforms let a small group of administrators change approval limits, posting rules, workflow routing, tolerance thresholds or user role definitions from the admin console, and those settings often feed automated controls the auditor will test. Under AS 2110, unauthorized changes to data and processing are an IT risk the auditor expects you to address. Pull the provider's audit or configuration change log for the period, compare every entry against a change ticket and approver, and investigate any gap. Restrict the admin role to named individuals, review its membership each quarter, and make sure the log cannot be edited by the people whose changes it records. Confirm with the vendor whether that log is available in an exportable form and how far back it goes.
Who does what: the company, the SaaS provider, the implementation partner and the auditor
The company owns its internal control over financial reporting, including every IT general control that its SaaS financial applications depend on. Management cannot hand this responsibility to the provider. SEC staff guidance says management still assesses controls over outsourced operations even when it relies on a service auditor's report, and PCAOB AS 2201 treats a service organization's services that are part of the company's information system as part of the company's ICFR. Management also makes the annual assessment under Section 404 and documents its conclusion.
- Access and configuration: Granting, reviewing and removing user access in the application, and owning role design, approval workflows and configuration settings the company controls.
- Complementary user entity controls: Performing any controls the provider's SOC 1 report assumes the customer applies, such as reviewing user access lists or approving configuration requests, and keeping evidence that they operate.
- Interfaces and data flow: Reconciling data sent to and received from the provider, and controlling the flow of information in and out of the service.
- Management assessment: Scoping the systems, testing or reviewing the controls, evaluating deficiencies and concluding on ICFR at fiscal year end.
Before relying on any provider, confirm which complementary controls the report lists and who inside the company performs each one.
The SaaS provider operates the platform and its own internal controls, such as data center security, provider-side change management, logical access to the hosting environment and backup operations. A service auditor may examine those controls and issue a SOC 1 report, which is the document the company uses as evidence about the provider's part of the process. The report describes what was tested, over what period and with what results. It does not test the company's own access reviews, configuration choices or interface reconciliations.
- Provider controls: Operating and monitoring the controls inside the service, including hosting infrastructure, provider staff access and production change control.
- SOC 1 report: Engaging an independent service auditor to examine those controls and issue a report to user entities, where the provider chooses to have one.
- Complementary subservice organizations: Disclosing which subservice organizations, such as hosting providers, carry part of the control environment and how those are covered.
- Report currency: Issuing a bridge letter or equivalent when the report period does not reach the company's year end, if the provider offers one.
- Notifications: Informing customers of exceptions, control changes or incidents that affect the service.
Confirm whether the provider issues a SOC 1 Type 2 report, its period, and whether it lists complementary user entity controls that you must perform.
An implementation partner such as DeployOpen can help a company prepare the evidence and documentation its own team needs for the ITGCs it owns. Typical work includes preparing access review packages, documenting configuration baselines, building evidence for interfaces and data conversions, and writing control descriptions and procedures. The partner works under a written, fixed scope and does not own the controls, decide scope, sign off on the company's conclusions or issue audit reports or attestations.
- Access review preparation: Producing user and role extracts, mapping them to job duties and organizing the evidence the company's reviewers need to sign off.
- Configuration baselines: Documenting approved settings, change history and approval records for the application configuration the company controls.
- Interface evidence: Setting up reconciliation or logging evidence for feeds between the SaaS application and the general ledger or other systems.
- Documentation: Drafting control narratives and procedures that the company reviews, adopts and maintains.
- Independence boundary: The partner does not issue SOC 1 reports, test the company's controls as the auditor does, or certify ICFR.
Ask for the written scope to name each deliverable, the company owner who accepts it, and the evidence the partner will not produce.
The external auditor tests ICFR under PCAOB AS 2201 when the company is subject to the auditor attestation requirement, and assesses IT risks under AS 2110, including the ITGCs important to automated controls. For a SaaS application, the auditor reads the provider's SOC 1 report and evaluates whether it covers the relevant period, scope, controls and results. It also checks whether the company performs the complementary controls the report assumes. The auditor issues the attestation where applicable. It does not design the company's controls or perform management's assessment on the company's behalf.
- Report evaluation: Reviewing the service auditor's report for the period covered relative to the as-of date, the scope and controls tested, and the test results and opinion.
- Complementary control testing: Confirming that the company applies the user controls the provider report assumes.
- Direct testing: Testing the company's own access, change and interface controls, and the automated controls that depend on configuration and data.
- Attestation: Issuing the auditor's attestation on ICFR where Section 404(b) applies to the company.
- Gap handling: Identifying where provider evidence is missing or stale and requiring the company to close the gap with its own testing.
Agree the auditor's testing approach and the evidence list early, before the period under review begins.
How DeployOpen prepares SaaS ITGC evidence for the audit
DeployOpen prepares the company's side of the SaaS ITGC evidence under a fixed scope agreed in writing before work starts. The starting point is the provider's SOC 1 report, read against the complementary user entity controls it assumes. Each of those assumptions is mapped to a control the company owns, with a named owner, a frequency and the evidence that will show it operated. Where the report assumes a control that the company does not run, the gap is recorded so it can be assigned before the audit rather than discovered during it. The mapping is a working document that the company's management and its external auditor can review, and it is the basis for deciding which owned controls need design and operating evidence.
The owned controls are then set up so they produce evidence on a routine basis. For user access, that means periodic review of privileged and financially relevant roles in the SaaS application, with the reviewer's sign-off, the population used and the removals traced to tickets. For configuration change, it means a record of tenant settings, approval matrices and posting or tax parameters, captured before and after each change and linked to an approved request. For interfaces, it means reconciliation reports that compare record counts and control totals between the SaaS system and the company's general ledger or data warehouse, with exceptions investigated and closed. Each report is saved in a form that can be re-performed, which matters more to an assessor than a summary.
DeployOpen then hands over the documentation the company needs to run these controls without outside help: control descriptions, evidence checklists, reconciliation procedures and the mapping of provider assumptions to owned controls. Ownership remains with the company, and the handover is the point at which management decides whether each control is ready for walkthrough. Hiring DeployOpen does not guarantee an audit result. DeployOpen prepares systems, controls and evidence; it does not issue audit reports, attestations or certifications, and those are issued only by the independent external auditor. Before engaging, confirm with the auditor which evidence formats and sample sizes it expects, because those details shape the work.
