Reading SOPs that have stopped working: a partner’s diagnostic.

Every CFO of a mid-cap or listed business has, in a drawer or a shared drive, a stack of Standard Operating Procedure manuals. Procure-to-pay. Order-to-cash. Inventory management. Fixed assets. Treasury. Each was prepared with care — often by a consulting firm during an ERP implementation, or by the internal audit function as part of an ICFR engagement, or by a department head trying to standardise practice. Each was approved, distributed, and filed. Each was supposed to be the canonical reference for how work gets done.

In most organisations, a significant fraction of those SOPs has stopped working. Not because they were badly written. Not because the people responsible are negligent. But because organisations change continuously while SOPs do not — and after a year or two of drift, the SOP and the actual practice are describing different work.

This is not, in itself, a crisis. SOPs that have drifted away from practice are normal. What matters is the diagnosis: which SOPs have stopped working, what they are now revealing about the organisation, and what the right response is. Rewriting the manual is rarely it. The COSO Internal Control framework treats this under Principle 12 (deploys control activities through policies and procedures) and Principle 13 (uses relevant information) — with the explicit recognition that policies must be enforced through actual operation, not through documentation alone.

What follows is a partner’s diagnostic framework, refined over two decades of audit and process work. Seven signals that an SOP has stopped working, what each signal reveals, and what the appropriate response is — which is often not what the natural reaction would suggest.

1 · Nobody on the team can find a copy

The simplest test, and the one most organisations fail.

The first diagnostic is the simplest. Ask a working-level member of the team responsible for the process to produce the current SOP. If they cannot — if they have to email a colleague, search a shared drive, or apologetically explain that the SOP is “somewhere” — the SOP is not operating. People do not consult documents they cannot find. They operate from memory, from custom, and from what the previous incumbent told them when they joined the role.

This signal reveals a documentation-governance problem more than a process problem. The SOP may be technically excellent; it is just not present in the working day of the people who need it. The remedy is straightforward: every SOP must have a known location, a known owner, a known last-review date, and must be referenced in the onboarding of anyone joining the relevant role.

The diagnostic implication for a CFO is broader. If working-level staff cannot find their SOPs, the CFO has very little assurance that the documented control environment exists in operation. The auditor’s test of operating effectiveness will surface this rapidly. The remediation is administrative, not operational — but it must happen before the rest of the SOP framework can do useful work.

2 · The SOP describes a system that is no longer in use

When the manual references screens, reports, and approvals that have not existed for two years.

A surprisingly common diagnostic. The SOP was written when the organisation was running a particular ERP version, a particular approval workflow, a particular reporting structure. Since then, the ERP was upgraded, the workflow redesigned, the structure changed — but the SOP was not updated. It now describes a system and a process that no longer exists.

The practical reality is that staff have figured out the new process on their own. They know how the current screens work. They know who the current approvers are. They know which reports are now available. The SOP, in their hands, is a historical document that they cannot reconcile with their working environment — so they ignore it.

The signal here is about change management. Every material change to systems, structures, or approval flows should trigger a review of the relevant SOPs. Most organisations do not have this trigger built into their change-management process. The remedy is to add it: the change-acceptance protocol for any system upgrade or organisational change must include the question “which SOPs does this affect, and how will they be updated?”

3 · Workarounds have become the norm

When “we don’t do it that way anymore” is the unofficial protocol.

The most informative diagnostic is the conversational one. Walk an internal auditor or a process consultant through the SOP step by step with the team that operates the process, and ask at each step: “is this what actually happens?” In organisations where the SOP is working, the answer is almost always yes. In organisations where it has stopped working, the answer becomes “well, what we actually do is…” and a workaround surfaces.

Workarounds are not, in themselves, evidence of failure. Sometimes they reflect a more efficient process that staff have discovered through experience and that should be adopted into a revised SOP. Sometimes they reflect a control bypass that staff have implemented because the documented control was operationally cumbersome — and they may not realise the control was there for a reason. The diagnostic skill is in telling the two apart.

The pattern that should always alarm an auditor or a CFO is the workaround that bypasses a segregation-of-duties control or an authorisation step — particularly when the bypass is justified as “saving time” or “handling exceptions.” The remedy is not to scold the team. The remedy is to redesign the SOP so that the underlying control is preserved through a more workable mechanism. If a control is being routinely bypassed, the control needs to be made workable; the bypass is a signal that the design has failed.

4 · The SOP refers to approvers who have left

Where individuals have been written into a procedure that should reference roles.

An SOP that names individuals — “approved by Mr. Sharma, the Finance Manager” — is an SOP that ages badly. People leave, change roles, get promoted. The SOP that referenced them either becomes stale or, worse, gets quietly amended by someone with no authority to amend it, with no documentation of the change.

A well-designed SOP references roles and authority levels, not individuals. The approval matrix lives in a separate, controlled document that maps roles to current incumbents and is refreshed as personnel change. The SOP itself remains stable through personnel transitions.

The diagnostic signal, when individuals are still referenced in active SOPs, is that the SOP framework was built without thinking about its operational lifecycle. The remedy is structural: every SOP should be rebuilt to reference roles, the role-to-incumbent mapping should be a separate document under HR or controllership ownership, and the change of an incumbent should not require any change to the underlying SOP.

5 · The SOP is longer than the process

When fifty pages describe what takes five minutes to do.

A pathology that recurs in organisations where SOPs have been written by consultants paid by the page is the over-documented procedure — the fifty-page SOP for a process that takes five minutes to execute, hedged with every conceivable scenario and exception. Length feels like rigour. It is, in practice, the opposite. No working-level staff reads a fifty-page SOP. They read the first page, scan the diagram, and operate from intuition.

The signal here is misalignment between the SOP’s form and its use. An SOP that is meant to be consulted in operation should be short, visual where possible, and structured for rapid reference. A separate, longer document can capture the rationale, the control objectives, the exceptions — but it is not the operating document.

The discipline of good SOP design is closer to writing a checklist than to writing a textbook. A one-page SOP, properly designed, captures the essential sequence of steps, the named control points, the approval thresholds, and the deviation protocol. If that one page is not enough, the process has design problems that more documentation will not fix.

6 · The exception-handling section has more text than the standard process

When exceptions are the rule, the rule needs to be re-examined.

Many SOPs describe a clean standard process, followed by a section on exceptions that is two or three times longer. The exception section accumulates over time — every time a non-standard scenario arises, someone adds a clause to address it. After a few years, the exception section dominates the SOP, and staff in operations are referring to it more often than the standard process.

This is a structural signal that the standard process has been incorrectly defined. If exceptions are the dominant flow, then the “exceptions” are actually a significant operational pattern that the standard process should have captured. The SOP is fighting the business, not supporting it.

The remedy is to re-examine the standard process from the bottom up. What does the operation actually do most of the time? That is the standard. What is genuinely exceptional — rare, ad-hoc, requiring senior judgment? That is the exception. An SOP rebuilt around the actual modal flow, with a small exception section reserved for genuinely rare scenarios, becomes operationally useful where the older version had become operationally ignored.

7 · The SOP has no defined review cadence

An undated SOP is on its way to becoming a historical document.

The final and most telling diagnostic is metadata. Every SOP should have a defined review cadence — annually or biennially for stable processes, more frequently for processes undergoing change. The review should be documented, the reviewer should be named, and the next review date should be visible on the document. SOPs that lack any of this are not being maintained; they are slowly decaying.

The signal is institutional rather than procedural. An organisation that maintains its SOPs on cycle, with active ownership and clear review discipline, treats them as live instruments. An organisation that has SOPs without review metadata treats them as compliance artefacts — documents produced once, filed, and forgotten until the next audit forces an update.

The remedy is governance. The SOP library should sit under a named owner — typically the financial controller or the head of internal audit — with annual review cycles built into the calendar. Each SOP should display its review status visibly. Where review is overdue, the document should carry a clear marker indicating that. This is not bureaucratic overhead; it is the discipline that converts an SOP framework from a stack of paper into a functioning element of the control environment.

How a CFO or COO should approach this.

A CFO or COO who reads this and recognises several of the seven signals in their organisation’s SOPs is not facing an unusual situation. The same pattern appears in most mid-cap and many large businesses. What separates the well-controlled from the rest is the response.

The natural response is to commission a rewrite of the entire SOP library. This is, almost always, the wrong response. A rewrite reproduces the same drift cycle: the new manuals will look better than the old ones, but in two years they will exhibit the same seven signals. The drift was not caused by the writing; it was caused by the absence of an ownership and review framework around the writing.

The right response is a diagnostic first, a governance redesign second, and a selective rewrite third. The diagnostic identifies which SOPs are still operationally relevant, which have drifted into uselessness, and which need to be retired or merged. The governance redesign establishes ownership, review cadence, and the change-management trigger that will keep the framework alive. Only then, against that governance, are selected SOPs rewritten — starting with the ones that govern the highest-risk processes (procurement, payments, journal entries, payroll, and the procure-to-pay cycle as a whole).

A diagnostic of this kind for a mid-cap business typically takes six to eight weeks. The remediation programme that follows runs over six to nine months, and the resulting framework, properly governed, should remain stable for two to three years before the next significant refresh. The discipline is real; the work is finite; the operational value is substantial.

The honest summary.

SOPs are diagnostic instruments. They reveal more about an organisation than they prescribe to it. An organisation that maintains its SOPs is an organisation that takes its control environment seriously. An organisation whose SOPs exhibit the seven signals above is not, in most cases, a poorly-run business — it is a normal business that has not invested in the governance layer around documentation.

The path to remediation is not glamorous. It involves an honest audit of the current SOP library, a redesign of how SOPs are owned and reviewed, and a disciplined refresh of the highest-priority documents. None of this is intellectually difficult. All of it is operationally demanding. The organisations that do it well derive material benefit in audit defensibility, in onboarding speed for new staff, in control consistency across geographies, and in the simple operational reality that the SOPs become useful again.

For listed companies under ICFR, this is also a defensible-control-environment question. An auditor who tests operating effectiveness under Section 143(3)(i) and the COSO framework will probe the relationship between documented controls and operating practice. Where the SOPs match the practice, the controls test cleanly. Where they do not, the testing surfaces issues that may not be resolvable within the audit window.

That, in a sentence, is the work the firm does.