There is a particular way SOX projects begin in organisations that are under time pressure. A date is set. Usually from outside: a group mandate, a regulatory obligation, a requirement arising from an audit. The date is non-negotiable. And yet the preparation begins too late.
What follows is a pattern I recognise. Not from textbooks. From mandates. The steering committee is appointed. An external consultancy is engaged. Controls are documented. Testing is planned. And at some point it emerges that the organisation is not in the state the SOX framework assumes.
What SOX Really Is and Why Most Implementations Misunderstand It
The difference between documented and lived controls is at the heart of what makes SOX projects fail. A documented control is a piece of paper describing what is supposed to be done. A lived control is a process that is actually performed, whose performance can be evidenced, and that works consistently over time.
The Six Mistakes CFOs Make Under SOX Time Pressure
Mistake 1: Treating SOX as a Compliance Project Rather Than a Leadership Project
SOX is not a documentation project. It is a fundamental change in the way a finance organisation works. A CFO who delegates SOX to a project manager and limits themselves to monthly status reports will end up with a SOX project that progresses formally but is not operationally embedded.
What the CFO must decide personally: the prioritisation of SOX work over day-to-day business. The escalation of decisions that cross departmental boundaries. The communication to the organisation of what SOX means and why it matters.
Mistake 2: Making the Scope Decision Too Late and Too Broadly
The scope decision is the single most important decision in a SOX project. It is a cascade of five sub-decisions.
Decision 1:
Which entities are in scope? Criteria: revenue contribution, balance sheet total, business complexity, risk exposure.
Decision 2:
Which accounts are material? Quantitatively and qualitatively. Non-material accounts must be explicitly documented.
Decision 3:
Which processes support the material accounts? A top-down approach: from material financial statement line items to the processes that affect them.
Decision 4:
Which controls are prioritised? Entity-level controls first, then financial close process controls, then IT general controls.
Decision 5:
Which approach for IT general controls? Access management is almost always the first priority.
These five decisions must be made in the first project week. Not as a preliminary assessment. As a documented decision.
Mistake 3: Underestimating Segregation of Duties
In SAP systems there are often authorisation combinations that enable SoD violations. No one deliberately set them up. Yet they have been there for years.
What must be done concretely: begin a complete SoD analysis in the first project week. Prioritise the critical conflicts. Remediate through authorisation adjustments in SAP. Document all unremediated conflicts as accepted risks with compensating controls. Set up ongoing SoD monitoring.
Mistake 4: Starting Testing Too Late
Testing must run in parallel with documentation. The definition of the testing approach for each control must be in place before testing begins. Findings must be communicated immediately. Distinguishing between design deficiencies and operating deficiencies is decisive for the right remediation strategy.
Mistake 5: Not Involving the Organisation Sufficiently
Every control owner must know: which control is expected of them, what the purpose of that control is, how it is performed, and how the evidence is to be produced and retained. Generic SOX training is not enough.
Mistake 6: Treating IT as Subordinate Rather Than a Partner
IT general controls are no less important than process controls. A weak IT control can undermine all process controls. IT must be a partner from week one: joint definition of the IT general controls, SOX-compliant change management, review and clean-up of user access management.
What I Experience in My Mandates
I am currently supporting a SOX implementation under considerable time pressure. The starting situation is typical: some processes are documented, but the documentation does not reflect lived practice. SoD violations exist in SAP that no one deliberately set up. And testing has not yet started because the documentation is not yet complete.
What I do in this situation: define the scope sharply straight away. Carry out the SoD analysis immediately. Start testing in parallel with documentation. Involve the organisation with clear, concrete requirements.
What I Bring
I am Nicole Vekonj, Interim Finance & Controlling Manager. I support SOX implementations operationally, not conceptually. I work in the system, in the processes, with the teams.
👉 Submit a project enquiry: zahlenkompetenz.de/en/contact
