They should prioritise SoD whenever a single role can create, approve, and record the same financial transaction or control state. Convenience-based access design is risky once auditability matters, because IPO readiness depends on proving that no one identity can silently dominate a critical process.
Why segregation of duties becomes the safer default before an IPO
Pre-IPO teams should treat broad access as a temporary convenience, not a stable operating model, once the same person can both initiate and finalise a control state. At that point, the issue is not only fraud prevention, but also whether the company can demonstrate credible control over financial reporting, approvals, and changes to sensitive records.
SoD matters because IPO readiness raises the cost of ambiguous ownership. If one role can create, approve, and record the same event, audit evidence becomes weaker and remediation becomes harder to prove, especially when the business is still changing rapidly.
That is why access design must shift from “who can get work done fastest?” to “who can change a control state without independent challenge?” In practice, this means separating request, approval, execution, and recording where those steps affect financial, compliance, or other attested processes.
Where convenience-based access breaks down
Broad access often looks efficient in a startup or scale-up because headcount is small and teams need to move quickly. The problem appears when those shortcuts are embedded into core systems, because convenience tends to collapse maker-checker discipline, hide conflicts of interest, and leave too much authority concentrated in a single identity or role.
This is especially risky in finance-adjacent workflows, close processes, payment flows, procurement, journal entries, and access administration. If the same operator can create a transaction, approve it, and then alter the record, the organisation loses the ability to trust the control trail even when no abuse has yet been detected.
SoD should therefore be applied to the points where a process can materially affect reported numbers, asset movement, or approval state, while keeping low-risk operational tasks simple enough to support delivery. The practical goal is not zero access, but bounded access with independent review at the steps that matter most.
What pre-IPO teams should separate first
The first separations should be the ones that create the largest audit and fraud exposure if combined. Typical examples include transaction creation versus approval, system administration versus control review, and entitlement assignment versus entitlement certification. That is the smallest set that usually changes both the risk profile and the audit narrative.
When the business cannot fully separate a role, it should define a compensating control that is explicit, repeatable, and reviewable. A vague “manager oversight” note is not enough if the underlying process still allows one identity to override the control state without independent evidence.
For teams that are still maturing their identity and access design, IAM and IGA Basics is a useful way to frame provisioning, access reviews, and entitlement governance before access sprawl hardens into process debt.
Risk and Threat Considerations
SoD gaps create both control failure risk and abuse risk. The immediate exposure is that one user can conceal an error or manipulate a transaction end to end, while the longer-term risk is that the organisation builds an evidence trail that looks complete but is not independently trustworthy.
Failure mechanism: A single role or account combines incompatible permissions, allowing creation, approval, and recording to occur without independent review, which removes the control break that auditors and investigators rely on.
Impact: That concentration of authority can enable undetected misstatement, unauthorized spend, fraudulent changes, and weakened IPO readiness because the company cannot show effective control operation.
Teams should treat the problem as a design issue, not just a review issue. If conflicting permissions already exist, the control should be separated in the system where possible, not merely monitored after the fact.
For a direct playbook on control conflicts, compensating controls, and extension of SoD principles to service identities and automation, Segregation of Duties (SoD) Guide provides the most direct navigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD is the core control issue in pre-IPO access design. |
| AC-6 — Least Privilege | Broad access convenience conflicts with minimizing authority in sensitive workflows. | |
| Recommendation — Define incompatible duties and enforce independent approval paths for critical transactions. Restrict each role to the minimum permissions needed for its assigned task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IPO readiness depends on controlled access and auditable enforcement over critical records. |
| A.5.18 — Access rights | Pre-IPO teams must review and govern who can create, approve, and record sensitive actions. | |
| Recommendation — Implement access-control rules that separate critical duties and preserve traceable approvals. Review and recertify access rights for conflicting permissions and excessive privilege. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about controlling who can perform sensitive actions and preventing broad access drift. |
| Recommendation — Limit administrative and business access paths that let one user complete conflicting duties. | ||
Practitioner Guidance
What to prioritise: Start with any workflow where the same role can request, approve, and post a material financial or control event. Those are the combinations that most directly undermine auditability and should be broken before the IPO timetable compresses remediation options.
What to verify: Test real user paths, not just role definitions. Confirm that approvals are enforced independently, that emergency access is time-bound and reviewed, and that evidence exists for who changed what, when, and under whose authority.
Common mistake: Teams often preserve convenience for too long by keeping broad admin roles and promising to “clean it up later.” That approach usually pushes the hardest separation work into the period when finance, legal, and audit pressure are highest.
Practitioner takeaway: If a single identity can both cause and legitimise the same critical change, convenience has already become a control weakness, and SoD should move ahead of usability until the control can withstand audit scrutiny.
Related resources from NHI Mgmt Group
- When should teams prioritise zero standing privilege over broader access convenience?
- When should organisations prioritise data classification and zero trust over broad cloud access convenience?
- How should organisations prioritise segregation of duties remediation when ERP access is already over-assigned?
- When should teams prioritise risk based due diligence over broad network access in crypto platforms?