That distinction matters more than most teams realize. A questionnaire can look complete on paper and still miss the manual workaround that makes an entire control ineffective. The quality of your results depends on scope, who answers, how questions are worded, and whether anyone validates the answers against real system data.
This guide walks through a practical method: defining scope, mapping processes activity by activity, writing questions that surface incompatible duties, documenting exceptions, and turning all of it into a usable SoD ruleset.
TL;DR
- Cover processes, applications, roles, permissions, approvals, custody, recordkeeping, and review—not only approvals.
- Start with highest-risk processes; route questions to process owners, app owners, IT, finance, security, and audit.
- Write plain-language questions with conditional follow-ups that catch manual workarounds.
- Validate answers against access data, workflow configs, and policy before building the SoD matrix.
- Document conflicts, compensating controls, owners, and evidence as a living artifact.
How to Create Your Own Segregation of Duties Questionnaire
Step 1: Define the Questionnaire's Scope and Objectives
Start by naming exactly what's in scope: which business processes, legal entities, departments, applications, and user populations you're examining. Prioritize processes where unauthorized access or fraud would do the most damage.
That usually means starting with:
- Procure-to-pay and vendor management
- Payroll and journal entries
- User provisioning and privileged administration
- Production change management
Next, state the questionnaire's purpose out loud. Is this for an initial SoD assessment? An ERP or IGA implementation? A control redesign ahead of an audit? Respondents give different levels of detail depending on what you tell them the answers are for.
Finally, record which frameworks apply: SOX-related financial controls, HIPAA access safeguards, PCI DSS, or internal policy.
Note that smaller organizations often have fewer opportunities to fully segregate duties, and PCAOB guidance recognizes this directly. PCAOB Auditing Standard 2201 states that smaller, less complex companies may rely on alternative controls, with auditors evaluating whether those alternatives are actually effective. Don't assume every gap is a finding. Some are compensated risks.
Step 2: Identify Respondents and Establish Common Terminology
Don't send one generic form to everyone. Process owners know what should happen. Application owners and IAM teams know what users can actually do. Those are different answers, and you need both.
Assign respondents by knowledge area:
- Process owners describe business activities and approval steps
- Application owners describe system workflows and configuration
- IT/IAM teams describe permissions, roles, and access assignment
- Compliance and audit teams describe control and evidence expectations
Before distributing anything, agree on terminology. Define requester, approver, executor, administrator, recordkeeper, reconciler, reviewer, privileged user, emergency access, and mitigating control. Without shared definitions, you'll get answers that can't be compared side by side.
Ask respondents to answer for roles, not names, and capture the system, department, and legal entity tied to each role.
Step 3: Map Each Process From Initiation Through Review
This is where most questionnaires fall short. Asking "who owns this process?" tells you almost nothing about where duties actually overlap.
Break each in-scope process into discrete activities: request or initiation, authorization, execution, recording, reconciliation, monitoring, and closure. For every activity, ask:
- Which role performs it?
- Which application or manual tool is used?
- What data or asset does it affect?
- What approval is required?
- What evidence proves it happened?
Use paired examples to keep respondents grounded: vendor creation versus invoice processing, purchase approval versus payment release, user provisioning versus access certification, production deployment versus code approval. These pairs force respondents to think in terms of specific activities rather than vague job descriptions.
Step 4: Write Questions That Reveal Incompatible Duties and Access Combinations
This is the core diagnostic step. Ask directly whether one role can create, approve, execute, record, and review the same transaction or access change. If the answer is yes, that's your conditional follow-up trigger.
This traces back to a fairly old principle in the field: authorization, custody, and recordkeeping shouldn't sit with the same person, because authorization combined with custody creates embezzlement risk that neither duty alone would create. A fourth category, verification or review, can be incompatible with any of the other three.
Also cover technical access questions:
- Role memberships and privileged permissions
- Shared accounts, service accounts, and emergency access
- Direct database access
- Ability to modify workflow or audit log settings
Then ask the concealment question directly: what combination would let one person initiate and hide an unauthorized action? Creating a vendor and paying that vendor. Granting access and approving that same access. Changing a control setting and reviewing the logs that would catch it.
This is where genuine conflicts surface, not in the polite "who approves this" version of the question.
Finally, ask how access gets assigned: roles, groups, profiles, direct entitlements, manual tickets, or exceptions. The assignment method changes how conflicts get detected and fixed later.
Step 5: Add Validation, Exception, and Evidence Questions
A conflict you can't eliminate still needs to be governed. For every unavoidable conflict, ask:
- Why is separation impractical here?
- What compensating control is in place?
- Who approved the exception, and when does it expire?
- What evidence shows the control actually operated?
Then close with a confirmation question: do these answers reflect current practice, including manual workarounds, temporary access, recent reorganizations, contractors, and third-party users? This catches the gap between what respondents think is true and what's actually running.
Once responses are validated, convert them into an SoD matrix. Include fields for:
- Process, activity, and role
- Application and entitlement
- Conflicting activity and risk rationale
- Control owner and remediation path
- Exception status and evidence source
Identity CoAnalyst's SoD question set uses conditional logic to walk respondents through conflicting role combinations, business justification, and risk level automatically. A Purchase Requestor/Purchase Approver pairing gets flagged as a hard block, while a Developer/Production Administrator pairing routes to a soft block requiring CTO approval and a defined expiration.
When Should You Use an SoD Questionnaire and What Do You Need First?
Use an SoD questionnaire when:
- Processes cross multiple departments or applications
- You're redesigning access roles
- Audit prep is coming up
- Existing SoD documentation is stale
Keep the first version tight. Focus on the processes where conflicts do the most damage:
- Procure-to-pay and order-to-cash
- Payroll and journal entries
- Vendor management and user provisioning
- Privileged administration and production change management
Before distributing anything, gather:
- Current process maps and role catalogs
- Application inventories and access reports
- Approval workflows and org charts
- Prior audit findings and known exception records
Manually pulling this together typically takes over 12 weeks for certification requirements alone. Audit prep adds another 4-6 weeks on top. That lag is one reason incomplete SoD documentation shows up as an audit finding instead of getting caught earlier.
Confirm sponsorship before you collect a single response. Get an executive or control owner to back the effort, set respondent availability expectations, and agree on how disagreements between answers will get resolved. Skipping this step is how questionnaires stall halfway through.
Key Parameters That Affect Questionnaire Quality
Question count isn't the variable that matters. Scope, respondent expertise, question design, and validation are what separate a questionnaire that reflects reality from one that just looks thorough.
Scope and Risk Prioritization
Too broad, and you get generic answers nobody can act on. Too narrow, and you miss conflicts that span applications. Risk-based scoping is the balance: document why each process, application, and role population is in or out of scope, so the decision is defensible later.
Respondent Expertise and Accountability
Process owners know intended behavior. IAM and application owners know actual access. Build accountability into collection from the start:
- Require cross-functional review of any material answer
- Assign an owner and due date to each response set
- Define escalation for unanswered or contradictory responses before fieldwork begins
Question Design and Branching Logic
Strong SoD questions follow a few non-negotiable rules:
- One concept per question
- Give examples without leading the respondent toward a particular answer
- Distinguish "policy says" from "people actually do" (often different answers from the same person)
- Use conditional follow-ups for approvals, privileged access, and exceptions
Support your answer types with structure:
| Response Type | Use Case |
|---|---|
| Role/application names | Mapping who does what, where |
| Yes/no with explanation | Surfacing conflicts without losing context |
| Evidence location | Supporting audit validation |
| Risk rating | Prioritizing remediation |
| Free-text context | Capturing workarounds and exceptions |
Validation and Evidence Requirements
Compare answers against access extracts, workflow configurations, ticket records, and audit logs wherever they exist. Every important answer needs the following attached, or it cannot support an audit-ready control record:
- Owner
- Control frequency
- Evidence source
- Remediation or exception path
Common Mistakes, Troubleshooting, and Alternatives
Skipping Process Discovery
Asking only "who approves this?" misses initiation, execution, recording, reconciliation, and review duties entirely. If a respondent answers "finance handles it" or "IT manages access," push for specifics:
- Role and permission
- Application
- Approval step
- Evidence source
Vague answers are a sign the process wasn't actually mapped.
Treating Policy as Proof of Operating Effectiveness
Documented policy and actual behavior diverge more often than teams expect. Informal approvals, shared accounts, spreadsheet workarounds, and emergency access all live outside the policy document.
When answers conflict, route the discrepancy to process and application owners and validate it against system data. Don't just pick the more convenient answer.
Ignoring Small-Team Limitations and Exceptions
Not every organization can assign every duty to a different person. When that's true, the questionnaire needs to capture compensating controls:
- Secondary review
- Dual release
- Independent sampling
- Periodic access analysis
For every conflict that stays in place, require:
- Exception owner
- Approval date
- Expiration date
- Review frequency
Choosing Between a Manual Questionnaire and a Guided Platform
A spreadsheet works fine for a narrowly scoped, stable process. It gets painful fast once you're versioning questions, branching logic, and reconciling answers across a complex IGA, IAM, or PAM discovery effort involving a dozen stakeholders.
That's the gap Identity CoAnalyst was built to close. Instead of stakeholder interviews and spreadsheet chaos, it provides:
- More than 500 practitioner-written questions across 11 identity domains
- A dedicated SoD library with conditional logic for conflicting role combinations, exceptions, and risk levels
- Cross-stakeholder analytics that flag contradictory answers as they come in
For teams gathering requirements from multiple stakeholders, it's a practical alternative to another spreadsheet tab.
Conclusion
A strong SoD questionnaire does more than collect names. It documents how critical processes actually run, where duties overlap, what access enables each activity, and how conflicts get controlled once they're found.
The reliable results come from risk-based scoping, cross-functional respondents, plain-language questions, technical validation, and documented exceptions: in that order, not as an afterthought bolted onto a survey.
Treat the finished questionnaire as a maintained control artifact, not a one-time exercise. Update it when processes change, applications change, roles get restructured, or regulations shift. Keep it current between audit cycles so the next review starts from how work actually runs today, not last year's snapshot.
Frequently Asked Questions
What duties need to be segregated?
The core duties are initiation, authorization, execution or custody, recordkeeping, reconciliation, and review. Common examples include vendor creation versus payment, access provisioning versus approval, and transaction entry versus reconciliation.
What does GAAP say about segregation of duties?
GAAP governs financial reporting standards, not internal control design. It doesn't function as an SoD checklist. Segregation of duties falls under internal control frameworks and SOX-related requirements, which are separate from GAAP itself.
How many questions should an SoD questionnaire have?
There's no fixed number. Length should track process complexity and risk. Aim for enough questions to cover roles, systems, duties, conflicts, controls, exceptions, and evidence without creating redundant responses.
Who should complete a segregation of duties questionnaire?
Process owners, application owners, IAM or IT administrators, finance, security, compliance, and internal audit each answer for their area of knowledge. No single respondent should be asked to answer for the whole scope.
What should you do after completing an SoD questionnaire?
Validate responses against access and workflow data, then build the SoD matrix or ruleset. From there, remediate conflicts, document compensating controls, assign owners, and set a recurring review cadence.
