SoD enforced byorganizational hierarchyis not SoD.It is a policy that can be bypassed.
Segregation of Duties and the Control Environment
"SoD enforced by system architecture cannot be overridden by any organizational instruction. The DCAA adequacy standard requires architectural enforcement — not a policy that prohibits self-approval in a system that allows it."
Paper 9 covers SoD requirements across three transaction cycles, why organizational hierarchy SoD fails DCAA examination, audit trail structure and immutability requirements, policy and procedure documentation standards, FAR 4.703 evidence retention, and the four-question control environment self-assessment.
Adequate timekeeping, job costing, billing, procurement, ICS, and FICS are all dependent on an audit trail that allows DCAA to independently reconstruct the history of any transaction without relying on the memory or cooperation of the people who performed it. A compliance architecture with adequate controls in every other domain but an inadequate audit trail cannot satisfy the adequacy standard — because DCAA cannot verify the controls it cannot see the record of.
What This Paper Defines
- Policy says supervisors cannot approve their own timesheets
- Pressure can override the control
- SoD gaps during vacancies and turnover
- Emergency overrides documented but not prevented
Download the Executive Paper
Complete the form to receive the full research, frameworks, and architectural blueprints.
The Argument
Why the Audit Trail Is the Infrastructure of Every Other Compliance Domain
Adequate timekeeping, job costing, billing, procurement, ICS, and FICS are all dependent on an audit trail that allows DCAA to independently reconstruct the history of any transaction without relying on the memory or cooperation of the people who performed it. A compliance architecture with adequate controls in every other domain but an inadequate audit trail cannot satisfy the adequacy standard — because DCAA cannot verify the controls it cannot see the record of. ""The adequacy test for SoD is not whether the firm has a policy. It is whether the system would have prevented the transaction if the employee had tried to approve their own timesheet. A system that would have allowed it has inadequate SoD regardless of what the policy says.""
Why Immutability Is an Architectural Property, Not a Policy
Many firms have policies that prohibit modifying audit trail records. The adequacy standard requires something stronger: an audit trail that cannot be modified regardless of what any policy says, because modification is architecturally impossible. Append-only storage with cryptographic verification ensures that any modification would be detectable as a modification — the original record remains, and the modification creates a new record that references it. An audit trail that can be modified by system administrators — even if policy prohibits it — does not satisfy the immutability standard.
One question determines audit trail adequacy: can DCAA independently trace any cost in any ICS or billing submission back to the originating transaction event — including the user identity, the exact timestamp, any modifications and their justifications, and all approval events — without any assistance from the contractor? If the answer requires contractor explanation, manual assembly from multiple systems, or reconstruction from memory, the audit trail is inadequate.
The Architecture of Choice
Side-by-side comparison of structural assumptions and operational outcomes.
Organizational SoD (Policy-Based)
Policy says supervisors cannot approve their own timesheets
System accepts self-approval if no one checks. A supervisor who is also listed as their own alternate approver can approve their own timesheet when their designated primary approver is out.
Pressure can override the control
Payroll deadline pressure, personnel absence, and management directives can all cause organizational SoD to be bypassed in specific circumstances — even when the bypass is unintentional.
SoD gaps during vacancies and turnover
When a designated alternate approver role is vacant, no system control prevents transactions from completing without proper SoD. The gap exists until the role is filled.
Emergency overrides documented but not prevented
Emergency override documentation proves the control was bypassed — not that SoD was maintained. DCAA finds the documentation and the bypass, not just the documentation.
Architectural SoD (System-Enforced)
System rejects self-approval before it can occur
The system checks user identity at every approval event. A user whose identity matches the initiator identity is rejected — not warned, rejected. No organizational instruction can change this.
No bypass mechanism exists
Architectural SoD cannot be bypassed by pressure, absence, or management directive. The system behavior is a property of the access control model, not a rule that people follow.
Vacancies trigger workflow escalation, not SoD gaps
When a designated approver is unavailable, the system routes to the next qualified approver in the escalation chain — all of whom have been verified to not be the initiator identity.
Emergency overrides are system events with audit trails
If an override is genuinely required, it requires a specific override permission granted by a defined authority, generates an immutable audit record, and is visible in every subsequent compliance review.
Strategic Insight
""The adequacy test for SoD is not whether the firm has a policy. It is whether the system would have prevented the transaction if the employee had tried to approve their own timesheet. A system that would have allowed it has inadequate SoD regardless of what the policy says.""
Frequently Asked Questions
What does DCAA actually look for when testing SoD?
What makes an audit trail "immutable" for DCAA purposes?
How does Paper 9 connect to Paper 10 (the Compliance Command Center)?
Want to model your own ROI?
Use our interactive calculator to see how a contract-native architecture can transform your margin.