What segregation of duties in IT systems requires under SOX
Segregation of duties in IT systems asks that no single person can both initiate and approve a financially significant transaction, or both change a financial system and move that change into production, without an independent check. Under Section 404, management owns this design, and the external auditor tests whether the access model actually prevents the conflict. If you are preparing for a 404 audit and have found one user who can create and approve journal entries, the question is not only whether that person misused access but whether the system allowed the combination at all. PCAOB AS 2110 lists IT personnel holding privileges beyond their duties among the IT risks to internal control over financial reporting, and that is the risk auditors will look for first.
The risk is concrete. A user who can create a journal entry in the general ledger and also approve it can post an entry that no second person reviewed. A developer who can build a change and deploy it to production bypasses the testing and approval that the change control process is meant to provide. Management should identify the conflicting combinations for each in-scope application, database and operating system, then decide whether each one is prevented by role design or detected by a monitoring control. SEC Release 33-8810 says management needs to evaluate only the IT general controls that support other controls addressing financial reporting risks, so the conflict review should start from the financial processes and work down to the systems that enforce them.
The work is hard for three reasons. Roles accumulate: people change jobs, keep old roles, and pick up temporary access that is never removed. Role definitions in packaged applications often bundle functions that were never meant to be granted together, so a role that looks harmless can carry a conflict. Privileged IT staff, such as administrators and database owners, can often change data or configuration directly, which can defeat application-level separation entirely. Confirm with your application owners which roles exist, what transactions each role can perform, and whether any combination is blocked by the system or only by policy. Then ask whether a periodic certification review will catch what drifts between cycles.
Which systems, roles and third parties fall inside SOD scope
Segregation of duties scope starts with the financial reporting risks, then works outward to the systems, roles and provider accounts that could let one person complete a conflicting transaction. Management only needs the IT general controls that keep other financial reporting controls operating properly, so the scope decisions below determine how much work follows.
Financially significant applications and databases
Start from the reports and balances that feed the financial statements, then trace which applications create, store or modify that data. The general ledger, subledgers, procurement, payroll and billing platforms usually qualify, and so do the databases behind them. Check whether users can reach the database tables directly, because a role that looks clean in the application can still allow conflicting changes through the database layer. Confirm this list with the control owners rather than relying on the application inventory alone.
Conflicting transaction pairs
Document the combinations of actions that one person must not hold together. Typical pairs include creating and approving journal entries, maintaining vendor master data and releasing payments, and developing code and deploying it to production. For each pair, record which application functions or roles grant each side, so reviewers can check the rule against actual role assignments. Keep the conflict matrix short enough that owners can maintain it after system changes.
IT staff with privileges beyond their duties
Administrators, database owners and support engineers often hold broad rights that let them perform business transactions as well as technical maintenance. PCAOB AS 2110 lists IT personnel with privileges beyond their duties among the IT risks to internal control over financial reporting, so these accounts belong in scope. Compare administrator rights against job descriptions and ask whether any engineer can both change a financial configuration and approve the result.
Service and integration accounts
Batch jobs, interfaces and integration accounts often run with broad database or application rights and no named owner. Treat each one as an identity that can perform transactions. Record who owns the account, what it can do, whether anyone logs in interactively, and whether its activity is logged. A service account that posts journal entries and is also reachable by a developer creates a conflict that a user-level review will miss.
Third-party and cloud administrators
Managed service providers, SaaS vendors and cloud administrators can hold access to financial data or to the platforms that run it. Identify which provider staff can change configurations, reset accounts or act inside client tenants, and whether your own administrators can override provider actions. Confirm with each provider how it restricts its own staff and what evidence it can supply, because the external auditor will ask how you know those rights are controlled.
Only the controls that affect reporting
Management evaluates only the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. Access rules that only affect operational efficiency, such as who can edit a non-financial dashboard, can be left out of the SOD evaluation. Record the reasoning for each exclusion so the external auditor can follow the scoping decision, and revisit it when a system starts feeding reported numbers.
How an assessor tests segregation of duties
Design testing asks whether the control, as written, could prevent conflicting access if it operated as described. An assessor starts with the conflict matrix: a documented list of which application functions, roles and duties must not be held by the same person, such as creating and approving journal entries, maintaining vendor master data and paying vendors, or developing code and deploying it to production. The assessor then checks whether the role design in each in-scope system reflects that matrix, and whether the rules are enforced at the point of assignment rather than only reviewed afterward.
- Conflict matrix: A current, approved list of incompatible functions, tied to the financial reporting risks it addresses, and owned by a named person.
- Role content: Roles and permission sets are mapped to the matrix, so the assessor can see which combinations are blocked and which are allowed with compensating controls.
- Enforcement point: Systems that block a conflicting assignment (for example, through a provisioning workflow that checks the matrix) are stronger evidence than a spreadsheet check performed after the fact.
- Compensating controls: Where a conflict cannot be removed in a small team, the design should name the detective review, who performs it, and how often.
- Design gaps: A missing matrix entry, an unassigned owner or a role that combines incompatible functions is a design deficiency even if no one has yet used that access.
Confirm the matrix date and approver before the walkthrough, and check that every role in the system export is traceable to it.
Operating effectiveness testing asks whether the control worked throughout the period under audit. The assessor selects users who hold, or during the period held, conflicting access and inspects what happened: who approved the grant, whether the conflict was identified before or after it took effect, whether the periodic review caught it, and what was done to remove it. Sample selection is usually based on the population of conflicts found in the access listing, not on a sample of users chosen for convenience.
- Sampled conflicts: For each sampled user, the request, approval and grant records, with the conflict rule that applied at the time.
- Review evidence: Dated reviewer sign-off showing that conflicts were identified, the reviewer had the authority to decide, and each decision was either a documented exception or a removal.
- Remediation: Evidence that revoked access was actually removed from the system, not just from the ticket, with the removal date.
- Exceptions: Approved exceptions with a business reason, an owner, an expiry date and a compensating review.
- Operator competence: The reviewer must hold enough system knowledge and authority to judge the conflict. A manager who signs without reviewing the access listing produces an operating deficiency.
Confirm that the review population was generated from the system at the time of review, and that the sample covers the full period.
Auditors test conflicts from a user access listing, so the listing itself must be complete and accurate before any conclusion can be drawn. If a user with conflicting roles is missing from the export, the control appears to work when it does not. Assessors therefore test the population: they confirm that the listing includes all users, all roles and all assignment paths, including indirect access through groups, nested roles, shared accounts and service accounts that can perform financial functions.
- Completeness check: Record counts from the source system compared with the export, with the method and date stated.
- Accuracy check: Role-to-permission mappings verified against the system, since a role name alone does not show what it allows.
- Indirect access: Group membership, inherited roles and database-level grants that let a user perform a conflicting function outside the application.
- Non-human accounts: Batch, integration and service accounts that can post or approve transactions, and who owns them.
- Change control over the query: Whether the report logic used to produce the listing was itself controlled and unchanged.
Confirm who generated the listing, when, and whether the same population was used for both the design and operating tests.
Auditors classify what they find, and the classification drives how serious the matter is. Under PCAOB AS 2201 (paragraph A3), a design deficiency exists when a control is missing or is not designed to meet its objective. An operating deficiency exists when a control that is properly designed does not operate as designed, or when it is performed by someone without the necessary authority or competence. Conflicting access can fall into either category, and the same finding can be written up differently depending on whether the matrix or the execution failed.
- Design deficiency: No conflict matrix for a financially significant application, or a role design that allows a journal entry creator to approve their own entries.
- Operating deficiency: A correct matrix that was not applied, or a conflict identified but left in place past the review date.
- Authority or competence gap: A reviewer without the authority to revoke access, or without the knowledge to judge the conflict.
- Compensating control failure: A detective review that was designed but not performed, or performed without evidence.
- Aggregation: Multiple operating deficiencies may indicate a design issue, which the auditor will consider when evaluating severity.
Illustratively, an approver who signs every access review without opening the listing is an operating deficiency, while a missing matrix is a design deficiency that affects every period.
Implementing SOD controls in IT systems, step by step
The sequence turns a general segregation of duties policy into role designs, preventive checks, detective monitoring and documented exceptions that an auditor can test. Each step produces an artifact that the next step depends on.
Inventory roles, transactions and systems in scope
Start by listing the financially significant applications, databases and infrastructure in SOX scope, then record every role and the transactions each role can perform in them. Include administrator, database owner and service accounts, because they often hold conflicting rights that standard role lists miss. The output is a role and transaction inventory signed off by the system owners, which becomes the baseline for every later step. Confirm the scope against your current ICFR scoping decisions so that no in-scope system is left out.
Build the conflict matrix with business owners
Working with process owners from finance, IT and security, define which combinations of transactions must never sit with one person. Typical pairs include creating and approving journal entries, requesting and approving access, and developing and deploying code to production. The matrix should name each conflict, the reason it matters for financial reporting and the owner who accepts it. The output is a version-controlled conflict matrix approved by the business owners and the control owner.
Redesign roles to remove conflicts
Map the matrix against the current role catalog and split or retire any role that combines conflicting transactions. Where a role must stay broad, such as for a small team, document why and move to the exception path in a later step. Check that the redesigned roles still let people do their jobs, since overly narrow roles drive users toward shared accounts. The output is a revised role catalog with a change record for each role that was split, merged or retired.
Configure preventive checks at provisioning
Enforce the conflict rules at the point where access is requested and granted, so a conflicting assignment is blocked or routed for review before it takes effect. Identity governance tools can hold the conflict rules and flag a request that would create a conflict, while the access approval workflow records who approved it. Test the rules with known conflicting requests and confirm that they are blocked or escalated. The output is test evidence showing that each conflict rule fires for a sample of conflicting requests.
Set detective monitoring and periodic conflict reports
Preventive checks miss conflicts that exist before the rules were written and access that changes outside the workflow, so run a detective control on a defined schedule. Pull current role assignments from each in-scope system, compare them with the conflict matrix and list every user who holds a conflicting combination. Review certification campaigns can help here, because designated reviewers decide whether to keep, change or revoke each item. The output is a dated conflict report, reviewed and signed by a reviewer who is independent of the people listed.
Assign an approver for exceptions with compensating controls
Where a conflict cannot be removed, for example in a small finance team, assign a named approver with the authority to accept the risk. Require a written justification, an expiry or review date, and a compensating control such as independent review of the transactions the user performs. Track each exception in a register so that it can be reported and tested. The output is an exception register with the approver, justification, compensating control and review evidence for each entry.
Document each step with its output
Bring the matrix, role catalog changes, rule tests, conflict reports and exception register into one control narrative that names the owner, frequency, population and evidence for each activity. Auditors test the design first and then operating effectiveness, so the narrative should show how each output flows into the next step. Confirm the population used for each report is complete, since an incomplete list of role assignments undermines every test that depends on it. The output is a control description and evidence index that an auditor can walk through from start to finish.
Why access accumulates and how role design prevents it
Access accumulates when people change roles and keep the permissions they earned in earlier jobs. A finance analyst moves to a systems team, a developer picks up a release duty, and nobody removes the old entitlements because the request to do so never comes. Over time one person can hold both the ability to create a journal entry and the ability to approve it, and that conflict is invisible in a list of individual grants. This is the core SOX risk in segregation of duties: PCAOB AS 2110 names IT personnel with privileges beyond their duties among the IT risks to internal control over financial reporting, and the defect usually comes from drift rather than from a single bad grant.
Role design is the main preventive control. Define roles by business function, then write conflict rules that state which combinations are never allowed, such as journal entry creation with approval, vendor master maintenance with payment release, or code development with production deployment. Each rule needs an owner, a documented exception path with compensating controls, and a check that runs when a role is assigned. Ask whether your identity platform can reject a conflicting assignment at request time, and confirm how the platform handles roles granted directly rather than through a group. Direct grants are where conflicts tend to hide.
A one-time cleanup does not hold, so pair role design with a recurring access certification campaign. In a campaign, designated reviewers decide within a set timeframe whether to keep, change or revoke each role assignment. midPoint, an EUPL-1.2+ identity governance project, documents this approach in its access certification reference, and its campaigns can be scoped to conflict-bearing roles so reviewers see the combinations that matter. Confirm the campaign cadence, the escalation path for unanswered items and the evidence retained for each decision before you rely on it. This page covers conflicts. General recertification of who holds access to in-scope systems is covered in the periodic user access review topic.
Evidence that satisfies a segregation of duties test
Auditors testing segregation of duties usually ask for a small set of records that show the conflict rules existed, were applied when access was granted, and were reviewed afterward. The cards below cover each artifact, what a reviewer should check in it, and how to keep it current between audits.
Approved SOD conflict matrix
The conflict matrix lists which combinations of access are incompatible, such as creating and approving the same journal entry type, or developing and deploying the same application. It should carry an owner, an approval date, and a version history showing who signed off on each change. Auditors use it as the baseline, so every later test is measured against it. Confirm that the matrix covers in-scope applications, databases and infrastructure, not only the main ERP.
Role definitions with transaction mapping
Each role should list the specific transactions, menus, tables or administrative functions it grants, mapped back to the conflict matrix. A role named accounts payable clerk that quietly includes vendor master changes is a common finding. Review the mapping whenever a transaction code or permission is added to a product release, because vendors often extend existing roles during upgrades.
Provisioning tickets with conflict checks
For every grant, the ticket should show the requested role, the approver, and a documented conflict check against the matrix and the user's existing access. Tickets that show approval without a conflict check suggest the control operated only as a formality. Ask whether the check was manual or system-enforced, and keep the record of which conflicts were found and resolved.
Conflict reports with dated review sign-off
A periodic report listing users who hold combinations the matrix prohibits gives management a detective view that catches what preventive checks missed. Each report needs a run date, the parameters used, and a reviewer's dated sign-off with the action taken on every hit. Auditors often test whether the report was complete, so keep the query or extract logic alongside the output.
Access certification records
Certification campaigns record a reviewer's decision to keep, change or revoke each access item within a set timeframe. The midPoint access certification model is one open-source example of this workflow. Retain the campaign scope, the reviewer assignments, each decision, and proof that revocations reached the target systems. A campaign that revokes nothing across several cycles can draw questions about whether reviewers examined access at all.
Exception logs and compensating controls
Some conflicts cannot be removed, for example in a small finance team. Each exception needs a named business justification, an approver with authority over both functions, the compensating control such as independent review of the affected journal entries, and an expiry date. Auditors test whether the compensating control operated, so keep its evidence with the exception entry. Unlogged exceptions are a frequent source of deficiencies.
Change records for role edits
Changes to roles, permission sets and matrix rules are program changes in their own right. Each edit should show the request, the business owner's approval, the testing performed, and the date it reached production. Compare these records against the access that actually changed in the systems, because an unrecorded role edit can silently widen conflicts. Confirm that role changes follow the same change process as application code.
Keeping evidence current between audits
Evidence goes stale when the matrix is not updated after system changes, reviews slip past their deadlines, and exceptions outlive their justification. Set a recurring calendar for matrix review, report sign-off and certification campaigns, and record each run as it happens rather than reconstructing it before fieldwork. Ask your auditor which periods and sample sizes they will select so the retained records line up with that window.
What segregation of duties in IT systems costs to meet
This table breaks down the cost components of segregation of duties controls in IT systems, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to shape your quote request and to see which costs open-source tooling can reduce. The main takeaway is that role design and certification effort usually recur every year, so the scope you set early drives most of the long-term cost.
| Cost component | One-time or recurring | Who is paid or who spends time | What drives it up or down |
|---|---|---|---|
| Role and conflict matrix design | One-time, with periodic updates | Internal process owners, IT security, and any consultant facilitating design | Number of financially significant applications, number of distinct job functions, and how many conflicting duties are in scope |
| Conflict-check tooling or licenses | Recurring | Software vendor or open-source project maintainers, plus internal administrators | Commercial licenses scale with users or modules; open-source options can remove license spend but still need hosting and admin time |
| Engineering to configure provisioning and conflict reports | One-time build, then ongoing upkeep | Internal platform or IAM engineers, or an implementation partner under a written scope | Number of target systems, depth of integration with approval workflows, and frequency of role changes |
| Periodic access certification by business reviewers | Recurring, per review cycle | Business owners and managers who approve or revoke role assignments | Number of reviewers, number of role assignments per reviewer, and whether reviews are scheduled and time-boxed |
| External review or consultant fees | One-time or retainer | Independent consultants or co-sourced internal audit, if engaged | Scope agreed in writing, number of systems assessed, and whether support covers only readiness or continuous monitoring |
| Auditor testing of conflicts and sampling | Recurring, per audit period | External auditor, paid under the engagement letter | Number of conflicting role pairs tested, population sizes for samples, and quality of system-generated conflict reports |
| Remediation of conflicts found | Variable, event-driven | Internal IT and business owners, sometimes compensating control design | Number of conflicts discovered, whether roles can be split in the application, and whether compensating controls are accepted |
Who owns segregation of duties, who can help, and where the auditor stops
Management owns segregation of duties. Under the SEC's guidance on management's ICFR report (Release 33-8810), management evaluates the IT general controls needed for other controls over financial reporting to operate properly and consistently, and that evaluation rests with the company, not with any outside party. Your team decides which conflicting duties matter for each financially significant application, approves exceptions, and signs off on access reviews. Typical responsibilities include:
- Owning the conflict matrix: Defining which combinations of duties are incompatible, such as creating and approving journal entries, or developing and deploying code to production.
- Making role decisions: Deciding which roles exist, what each one grants, and who may hold them.
- Approving exceptions: Documenting any conflicting access that is required, the compensating control, the approver and the review date.
- Running periodic reviews: Having named reviewers confirm or revoke access, and following up on removals.
- Keeping the evidence: Retaining the matrix, approvals and review records in a form the auditor can inspect.
Confirm that each of these tasks has a named owner in your own documentation before the auditor's walkthrough begins.
An implementation partner can help prepare the systems that enforce segregation of duties and the evidence that shows they work. DeployOpen plans, configures and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares evidence for compliance assessments. It does not design the company's controls on the company's behalf, own the conflict matrix, or issue any audit report. Work of this kind commonly includes:
- Role configuration: Building role and group structures in the identity platform so that conflicting entitlements are separated as management has defined them.
- Provisioning checks: Setting up automated provisioning and deprovisioning so that changes made in source systems reach target applications, and testing those flows.
- Review tooling: Configuring access certification campaigns, with designated reviewers and set deadlines, for the periodic reviews management runs.
- Evidence packages: Exporting role listings, change logs and review results in a consistent format for management and the auditor.
- Documentation: Recording how each platform enforces the rules, so the configuration matches the matrix.
The contract should state which of these tasks the partner performs and which remain with management, and it should be fixed in writing before work begins.
The external auditor tests the controls and reaches a conclusion. Under PCAOB AS 2201, the auditor evaluates whether controls are designed effectively and operate as designed, and under AS 2110 the auditor must understand the IT general controls that support automated controls, including the risk that IT personnel hold privileges beyond their duties. Because the auditor must stay independent, it cannot design, implement or own the controls it tests. Auditors typically:
- Walk through the process: Trace a sample of access requests, approvals and role assignments from start to finish.
- Test design: Assess whether the conflict rules and roles would prevent the conflicts they target.
- Test operation: Select samples of access records and reviews and check them against approvals and policy.
- Evaluate exceptions: Judge whether approved exceptions had adequate compensating controls and whether deficiencies are significant.
- Report: Communicate deficiencies to management and the audit committee, and issue the attestation, where it applies, in its own name.
Ask the auditor early which evidence it will accept and in what format, and confirm that any help you receive from a partner is documented so the auditor can see who did what.
Common gaps in SOD programs and how to close them
Most segregation of duties failures in IT come from a small set of recurring gaps rather than from missing policy. The cards below cover where those gaps usually sit and the closing action for each, so that the conflict rules you write can be tested against the access that actually exists.
No conflict matrix for IT roles
Many programs define conflicts for business users but never write them down for IT roles such as developer, database administrator, system administrator and release manager. Without a matrix that lists which combinations are prohibited, which need compensating controls and who approves exceptions, reviewers have no baseline to test against. Close it by building the matrix from the in-scope systems, covering both application roles and infrastructure roles, and getting the owner of each financial process to sign it off.
Developers holding production deploy rights
When the same person can write code and push it to production, changes can reach financial applications without independent review. Auditors typically look for this in deployment pipeline roles and in direct server access granted during an incident. Close it by separating development and production access, routing deployments through an approved pipeline, and logging any emergency access so it can be reviewed afterward.
Privileged IT staff with business approval rights
An IT administrator who can also approve business transactions, such as vendor master changes or user access requests for finance, can both perform and authorize the same activity. PCAOB AS 2110 lists IT personnel with privileges beyond their duties among the IT risks to internal control over financial reporting. Close it by removing business approval rights from administrator accounts and checking role assignments against job descriptions at each review.
Unreviewed service accounts
Service and integration accounts often hold broad database or application rights, have shared or non-expiring passwords, and sit outside normal recertification. Because no individual owns them, nobody notices when their rights drift. Close it by inventorying every service account against in-scope systems, assigning a named owner to each, and including them in the periodic access review with the same conflict rules that apply to people.
Exceptions without compensating controls
Teams often grant a conflicting combination for a short period, such as during a staffing gap, and the exception stays open. An exception with no end date, no named approver and no monitoring is effectively a control failure. Close it by requiring each exception to name the compensating control, such as independent review of logged activity, an expiry date and an approver outside the conflicting role, and by reporting open exceptions to the control owner.
Reports that omit cloud and SaaS administrators
Conflict reports built only from on-premises directories or the core ERP miss administrators of cloud platforms, SaaS finance tools and data warehouses that feed reported figures. An admin role in a SaaS system can change journal logic or reporting without touching the ERP. Close it by listing every system that stores or processes financially significant data, including administrator roles in each cloud or SaaS tenant, and confirming the conflict report pulls from all of them.
Segregation of duties in IT systems: questions buyers ask
How much effort does segregation of duties testing take in-house?
The effort depends mainly on how many financially significant applications you run, how many roles those applications use, and whether conflicts are documented today. Most of the work is one-time design: mapping transactions to duties, writing a conflict matrix, and clearing existing conflicts. The recurring part is reviewing role assignments and new conflicts each cycle and keeping evidence of both. Ask your team to size the role catalog for each in-scope system before estimating, since role count usually drives the work more than headcount does.
Do we need an outside partner for SOD work?
Not always. A team with identity, application and finance knowledge can design conflict rules and run reviews internally. A partner is useful when the team lacks experience with role design in a specific ERP or when the conflict matrix must be built quickly across several systems. A partner prepares systems, role models and evidence. Only your independent auditor tests the controls and reaches a conclusion on them, so the decision to bring in help should rest on internal capacity, not on any expectation of an audit outcome.
What does the work require from business owners?
Business owners decide what a role should be able to do and which combinations are acceptable. They approve exceptions, state why a conflicting duty is needed, and confirm that compensating controls, such as independent review of journal entries, actually operate. Without their input, IT can only tell which technical permissions overlap, not whether the overlap creates a financial risk. Plan for owners to review the conflict matrix, sign off on each accepted exception, and attend the periodic certification where access is kept, changed or revoked.
How long does it take to prepare SOD evidence before an audit?
No fixed duration applies, because it depends on system count, the state of existing role design, and how much remediation the review uncovers. Confirm the timeline with your implementation partner and your external auditor before committing to a date. The main variables are how quickly conflicts can be removed without breaking business processes and whether exceptions have documented approvals. Starting well before the fiscal year end gives room to remediate and to collect evidence for the period under test, which auditors generally expect to cover the full period.
Can open-source tools replace commercial SOD software?
Open-source tools can cover parts of the work, but they rarely replace every feature of commercial SOD products out of the box. Identity governance platforms such as midPoint support access certification campaigns, where designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments. Directory and provisioning tools such as FreeIPA and authentik handle centralized access and deprovisioning. Whether they meet your needs depends on connectors to your ERP and the conflict logic you require. Confirm those capabilities with the vendor and test them in your environment before relying on them.
How does SOD differ from user access reviews?
User access reviews check whether each person's current access is still appropriate. Segregation of duties checks whether the combined access a person holds creates a conflict, regardless of whether each individual entitlement looks reasonable. A reviewer can approve every item in a periodic recertification and still miss that one account can both create and approve payments. SOD therefore needs a conflict matrix and rules that flag combinations. In practice the two controls share evidence, and the access review often becomes the place where SOD conflicts are detected and resolved.
Which IT risk does poor segregation of duties create for ICFR?
Poor segregation of duties lets one person complete a financial transaction from start to finish without a second check. PCAOB AS 2110 cites IT personnel with privileges beyond their duties as an IT risk to internal control over financial reporting, because such privileges break down segregation of duties. Whether the gap is a design or operating deficiency under AS 2201 depends on whether the control was missing or not operating as designed. Your auditor will assess that classification, so document the conflict, the compensating control and the approval for any accepted exception.
What DeployOpen prepares and what it does not issue
DeployOpen plans, implements and documents segregation of duties controls inside your own cloud accounts, data centers or air-gapped networks. The work covers role design for financial applications and databases, conflict rules that block incompatible combinations such as journal entry creation and approval, and the monitoring that catches access accumulating over time. DeployOpen then assembles the evidence an auditor will ask for: role definitions, conflict matrices, approval records, review certifications and configuration exports. The organization keeps ownership of the controls themselves, including who is authorized to approve a conflicting exception and how it is recorded.
DeployOpen does not issue any audit opinion, attestation or certification. Under Section 404, management assesses internal control over financial reporting and the external auditor tests it under PCAOB AS 2201. Only that independent auditor forms the conclusion on whether segregation of duties operates effectively. Before the engagement starts, confirm in writing which artifacts DeployOpen will hand over, who inside your organization signs off on the design, and which evidence the external auditor has already accepted for the same system. Ask your auditor which population and sampling approach they plan to use so the prepared evidence matches what they will test.
Confirm the scope boundary early. The SEC guidance on management's report on internal control limits evaluation to the IT general controls needed for other financial reporting controls to operate consistently, so the segregation of duties design should be tied to the specific in-scope applications and reports your auditor has agreed. Any work outside that boundary is a fixed-scope decision made in writing before work begins, and the scope document should name the owner of each control, the review frequency and the person accountable for remediation.
How DeployOpen scopes and implements segregation of duties
DeployOpen works on segregation of duties as an implementation partner. We help the organization map conflicting access in its self-hosted financial platforms, build role design and monitoring that keep those conflicts apart, and hand over documentation the organization and its external auditor can test. Management keeps ownership of the controls, and only the independent auditor forms the opinion on them.
How we scope
- Agree in writing which financial applications, databases and directories fall inside the segregation of duties scope
- List the incompatible duty pairs management defines, such as journal entry creation with approval
- Confirm the systems of record and identity sources that feed role assignments and access reviews
How we build
- Design role models and conflict rules in the identity platform so incompatible roles cannot be granted together
- Configure access certification campaigns with named reviewers, decision deadlines and recorded revocations
- Test conflict detection with sample users, including attempts to combine roles that should be blocked
How we hand over
- Deliver the conflict matrix, role design documentation and configuration records for management's review
- Provide evidence packs showing certification decisions, provisioning logs and blocked conflict attempts
- Walk the control owners through the procedures so they can run reviews and explain them to auditors
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing of conflict rules are available as a retainer
- Ask the auditor early which evidence they expect, since DeployOpen prepares evidence but does not issue opinions
