Skip to content
1961 Digital TransformX

Service

Every number needs a name against it

Systems rarely fail because of software. They fail because nobody owns the definition of a figure, nobody reviews who can change it, and the approval that mattered was given verbally. We name the owner, the control and the evidence.

You will recognise this

  • Two departments quote a different revenue figure for the same month, and both can defend theirs from the same system.

  • People who left last year still have active accounts, and nobody can say which of them are being used.

  • The same person raises the purchase order, receives the goods and releases the payment, because the team is small.

  • A credit limit gets overridden regularly, and the only record of who authorised it is a message on somebody's phone.

  • Your external IT supplier holds full database access, and no one internally can list what they have changed.

How the work runs

  1. Establish the perimeter

    We inventory every system that holds a number the business acts on, including the ones IT does not consider systems: the shared drive, the workshop tablet, the file that carries project costing. Shadow systems are where control actually leaks, and they never appear on the architecture diagram.

  2. Trace the critical figures

    We take the figures the board reads and follow each one backwards to the transaction that creates it. That walk exposes where a definition changes hands, where a manual adjustment enters, and which department has been quietly correcting another department's data for years.

  3. Test access and duties

    We pull actual permissions rather than the intended ones and test them against real people, including leavers, contractors and shared logins. Segregation of duties is checked as executed, not as designed, because the conflict that matters is the one somebody actually exercised last quarter.

  4. Write the findings

    Every finding names the system, the control that is missing, the exposure in operational terms and the person who has to own the fix. Findings are ranked by what could go wrong and how easily, not by how they would look in a slide deck. Nothing is softened for comfort.

  5. Sequence the remediation

    The plan orders the work by risk and by dependency, so the controls that stop the worst outcome come first and the ones that need a system change wait for it. Each item carries an owner, a date and the evidence that will prove it was closed.

What you are handed

  • Systems and data inventory including shadow systems
  • Definition sheet naming the owner of each critical figure
  • Access review showing effective permissions per person
  • Segregation of duties conflict register with evidence
  • Approval matrix covering value bands and delegations
  • Remediation plan sequenced by risk, with owners and dates

Ownership is a person, not a department

Ask who owns the gross margin figure and you are usually told finance. Ask who decides whether a rebate is netted off revenue or booked as a cost, and the room goes quiet. That is the gap. A number without a named owner is defended by everybody and maintained by nobody, so each department computes a version that suits its own report and all of them are defensible. We write a definition sheet: one figure per line, its exact calculation, the system of record, and a named individual who is accountable when it is wrong. It is a short document and it settles arguments that have run for years.

Segregation of duties in a small team

Textbook segregation assumes headcount most firms in this region do not have. Telling a forty-person company to split a role three ways is advice nobody will follow, so the finding is closed on paper and the exposure stays. The workable answer is compensating controls: if one person must both receive and pay, then someone else reviews the exception report weekly and signs it, and the system makes the exception visible without being asked. We design controls against the staffing you actually have. A control that requires hiring is a control that will be quietly ignored.

A report that survives the room

Most governance reports are written to be accepted rather than acted on. The findings are hedged, the risks are described in language that commits to nothing, and the plan has no dates. Six months later the same issues reappear in the next review. Ours states what is exposed in operational terms, what it would take for that exposure to become a loss, and who has agreed to close it by when. It is written to be read by a board member and by an auditor without a second version for each. We are independent of whoever built the systems, which is what makes the findings worth reading.

Questions we get asked

Is this an audit that gets our people in trouble?
It is not an investigation and we do not write findings against individuals. Almost everything we find is structural: a permission granted years ago for a legitimate reason and never reviewed, or a duty combined because the team was small. We report the exposure and the control, not the person. Where genuine misuse appears, that goes privately to the sponsor first, because it stops being our decision at that point.
How is this different from our external auditor?
A statutory auditor forms an opinion on the financial statements and looks at controls to the extent they affect that opinion. We look at the operational systems that produce the numbers before they reach the ledger: who can change a price, how a stock adjustment is approved, whether a delivery can be posted without a receipt. Our work often makes the audit cheaper, but it is not a substitute for it.
Will you tell us we need to buy new software?
Sometimes, and we earn nothing either way because we do not resell licences. Most findings are closed by configuration, by a permission change or by writing down a definition, none of which cost anything in software. Where a control genuinely cannot be enforced by the current system we say so and state what it would take. If we hold any commercial interest in that recommendation, it is disclosed in the report itself.
How long does a review take, and what do we need to give you?
For a single-entity company with two or three core systems, a few weeks of fieldwork and a similar period to write. What we need is read access to the systems, a list of current staff and leavers, and time with the people who actually do the work rather than only with their managers. The interviews are the part clients underestimate, and they are where most findings come from.
What if the report finds something we cannot afford to fix?
Then it is recorded as an accepted risk, in writing, signed by the person accepting it, with the exposure stated plainly. That is a legitimate outcome and it is very different from an issue nobody named. Accepted risks go into the plan with a review date, so the acceptance is revisited when circumstances change rather than becoming a permanent silence.

Tell us what is not working

Send one line about what is going wrong. On the first call we will tell you whether it is a system problem, a process problem or a governance problem — and which one to fix first. That call is free and it is not a sales meeting.

Book a consultation