Know your controls hold before someone checks

The finding usually arrives in the same shape. A controller has the ability to create a vendor and also to approve a payment to that vendor. Nobody has ever done it. The access has been sitting there since a system upgrade in a year nobody remembers. On paper it is a control deficiency; in practice it is an open door, and the people who look for open doors are patient.

Operational governance is the layer between your systems and your financial statements. It covers who can do what inside the enterprise resource planning system, how changes get into production, how access is granted and taken away, and what proof exists that any of it was followed. Get this right and your close is faster, your fraud exposure narrows, and your auditors stop billing you to reconstruct history.

Building or extending the enterprise resource planning system itself is different work and lives under Application & Systems Development. This page is about the controls around it — the rules, the approvals, the evidence.

What you get:

• A current inventory of who can do what in the financial systems, with the combinations that shouldn’t exist flagged by name
• Segregation-of-duties rules written for your actual roles, not a vendor’s generic matrix
• Working change management: what gets tested, who approves, what evidence gets kept
• Control owners named — a person, not a department — with a schedule for what they review and when
• A defensible evidence file, so the next audit is a retrieval exercise rather than a scramble

The assessment stage inventories what is actually configured, which is regularly not what the documentation says. Transform is the remediation: cleaning up access, rewriting the duties matrix against your real job roles, standing up a change process people will actually follow rather than route around. Optimize is the part most firms skip. Controls decay. People change jobs, systems get upgraded, and a matrix nobody re-tests is worth roughly nothing by year three, so we set the review cadence and hand it over with the owners named.

The documentation that comes out of this work is built to be tested, because the people directing it have spent careers testing other people’s. The moment that matters is when an auditor with the authority to reject your evidence sits down with it. That is what this documentation is built for, and the credentials shown alongside this page are the short version of why.

[PROOF: ERP controls remediation engagement — sector, region, scope, what changed — supply]

The IT Risk & Readiness Assessment is the sensible first move here: a defined engagement, measured against a recognized control framework, that tells you which of these controls exist, which are documented but not operating, and which are simply absent. You will know where you stand before you decide what to spend.