Segregation of duties between preparer and reviewer: why your workflow tool should enforce it

Internal auditors spend their working lives testing other people's segregation of duties. Can the person who creates a vendor also approve its payment? Can the analyst who posts a journal entry approve it too? Where the answer is yes, we write it up, because we know the principle cold: a control performed and approved by the same person is not a control.

Then we go back to our own audit file — a spreadsheet tracker where the "Reviewed by" column is free text, filled in by whoever is updating the tracker, which is sometimes the tester — and we apply to our own work a standard we would fail any client for.

This isn't hypocrisy so much as tooling. Nobody decides that review integrity doesn't apply to the audit file; the file simply has no mechanism to enforce it, and unenforced rules erode under deadline pressure the same way they do everywhere else we've ever audited.

Why review segregation exists — a two-minute refresher

The preparer of a piece of testing is structurally the worst-placed person to catch its problems. Not because testers are careless, but because:

• They can't see their own blind spots. Whatever the preparer misunderstood about the control, they will also misunderstand while checking their work. Self-review catches typos; it cannot catch wrong assumptions.
• They're invested. The preparer has concluded. Reviewing your own conclusion is confirmation-seeking with extra steps.
• Fresh eyes are the actual test. If the workpaper doesn't convince an independent reader that the work supports the conclusion, it isn't finished — and the only way to know is for an independent reader to try.
• It's what your external auditor is relying on. When external audit reduces its own testing by relying on management's SOX program, the quality of internal review is a large part of what they're relying on. Evidence that review is independent and real is evidence your program deserves the reliance.

None of this is controversial. The controversial part — apparently — is applying it with the same rigor we demand of the first line.

How honor-system review fails in practice

The failure is never announced. It accumulates:

Initials are data entry, not events. In a tracker, "reviewed by: KM" is a cell someone typed. It might mean KM performed a review. It might mean the tester filled in the expected reviewer while updating statuses. It might mean KM said "looks fine" in a hallway. The cell is identical in all three cases, and months later, so is the evidence.

Nothing stops self-review. In a small team where everyone tests and everyone reviews, the person who prepared W-14 can absolutely be the person who marks it reviewed — especially at 7 p.m. on a due date, especially when the designated reviewer is on vacation and the item is "basically fine." Every team believes it doesn't do this. No spreadsheet can tell you whether yours actually does.

Review happens after the conclusion is already used. With no workflow gate, testing flows into the deficiency evaluation and the status report before review. The review, when it comes, is retroactive — and reversing an already-reported conclusion has a social cost that quietly pressures reviewers toward agreement.

Post-review edits are invisible. The reviewer signs off Tuesday. Wednesday, the tester "just fixes a date" — or pastes in a different sample item. The sign-off now covers work the reviewer never saw, and nothing in the file distinguishes it from work they did.

Review depth is unrecorded. Points the reviewer raised, how they were resolved, what changed as a result — in a tracker, this exists in email if it exists at all. When an external auditor asks "show me evidence of review beyond the initials," email archaeology is the answer, and it's a weak one.

What enforcement actually means

The fix is the same one we recommend to every process owner we audit: move the rule from policy into the system. For audit workflow specifically, enforcement means the tool — at the server, not as a UI suggestion — guarantees:

1. Distinct identities. The reviewer on a test cannot be its preparer. Not discouraged: rejected. This single constraint eliminates the failure mode no spreadsheet can even detect.
2. A real state machine. Work moves not started → in progress → ready for review → complete, and only the assigned reviewer can move it past review. A conclusion cannot reach "complete" without independent review having happened, because there is no other path to "complete."
3. Sign-off freezes the work. After sign-off, content is locked. Corrections happen through an explicit, logged reopen that clears the sign-offs — so a sign-off always means this reviewer approved exactly this content, with no silent divergence. The same rule should cover evidence: swap an attachment on a signed-off workpaper and the sign-off must fall away.
4. Review points are first-class records. A reviewer can return work with notes; notes follow a raise → address → clear lifecycle; and — critically — sign-off is blocked while notes remain open. Review depth stops being a matter of memory and becomes part of the file.
5. Everything lands in an audit trail. Who submitted, who returned, who signed, who reopened and why, timestamped, unerasable from within the app. The audit file gets what we require of every system we test: accountability by design.

The word server matters in that list. A rule enforced only in the interface is a rule enforced only for people using the interface as intended. If the tool's own API will happily let a preparer approve their own work, the control is cosmetic — precisely the distinction we draw when testing everyone else's application controls. Ask your vendor how the rule is enforced. Then ask how it's tested.

For transparency: this is the design brief SoxDesk was built to, by people who'd felt each failure above personally. Preparer-reviewer separation, the workflow gate, sign-off freezing with logged reopens, note-blocked approvals, and checkout locking are all server-side rules, exercised by an automated enforcement suite on every release — because an audit tool's controls deserve the same testing discipline as an auditee's.

"We're too small for this"

The objection writes itself: we're four people, we all know each other, the ceremony is overhead. Three answers:

• Small teams have the least slack for enforcement. In a forty-person function, an independent reviewer is always available. In a four-person team under deadline, the temptation to self-sign is structural — which is exactly when a hard rule is worth most. Controls exist for the pressured case, not the comfortable one. We know this; we say it to auditees weekly.
• The ceremony is minutes. Submitting for review, returning with a note, signing off — each is a click that replaces a status-cell edit and an email. The overhead argument is really an argument against evidence, and evidence is the product.
• The audience is external. Your external auditor's reliance decision, and any future inspection of it, turns partly on whether management's review is demonstrably independent. A small team that can prove review integrity punches above its weight in that conversation; a large team with initials in a tracker punches below.

The first line would never accept "we're small and trust each other" as a segregation answer from a process owner. The audit file shouldn't accept it either.

The uncomfortable test

Here's the self-assessment, and it takes one minute: in your current audit file, could a preparer mark their own work reviewed — and if they did, would anything in the file show it?

If both answers are the wrong ones, that's not a people problem to manage harder. It's a missing application control, in the one application your team runs on. Fix it the way you'd tell anyone else to: put the rule in the system.

SoxDesk is an on-premise audit workflow app for SOX and internal audit teams: server-enforced preparer-reviewer segregation, sign-offs that freeze work, review notes that block approval — with every byte of audit data on your own network. The 60-day free trial is the full product, sample audit included: soxdesk.com.