Twenty entities, twenty RCMs
Group changes a control description. Three subsidiaries update their workbook, the rest don't. By year end nobody is sure which version was tested.
Your SOX programme across every entity, in one place
If your group has twenty subsidiaries, you probably have twenty versions of the same RCM. Global SOX keeps one. You write a control once, roll it out to the entities that perform it, and every project tests against that same library. The CAE approves the scope and each project before work starts. Evidence comes in against each request, staff test on a workpaper, and the final report only goes out once every control and every management response has been signed off.
Most teams know how to do this work. The trouble is that it lives in workbooks, mail threads and shared folders, and keeping them in sync becomes a job of its own.
Group changes a control description. Three subsidiaries update their workbook, the rest don't. By year end nobody is sure which version was tested.
Which entities are in scope this year? The answer is in someone's email from March. The external auditor asks for it in December.
Each control owner gets a mail asking for documents. Some reply, some forward it, some send the wrong file. Tracking who still owes what becomes a spreadsheet.
Testing was reviewed on a call, the response was agreed on mail, and the report was signed off in a meeting. Proving it later means digging.
Keep one risk and control library for the whole group. Decide each year which entities are in scope. Then run testing projects from the first evidence request to the final report.
Upload your existing RCM or build it on screen. Each control carries its type, frequency, COSO component, assertions, sampling criteria and testing steps. A master control can be rolled out to sub-entities, cloned to another entity, or edited once and applied everywhere.
Nothing is saved until the file is clean. You see every error in a preview grid, fix it right there, and then commit. If you'd rather fix it in Excel, download the error report.
When an Audit Manager edits, adds, deletes or links a risk or control, it goes to the CAE as a change request. The CAE sees exactly which fields changed and either approves it or sends it back with a note.
List every entity and sub-entity, mark each one Yes or No, and send it to the CAE. Once approved it's locked. If scope changes mid-year, you raise a new version, say SOXA-2026-000001 v2, and the old one is archived.
Pick control-wise or entity-wise, the audit period, and the processes and entities in scope. Drop any controls you're deferring, assign staff by entity, process or control with start and due dates, and send it to the CAE.
The data requirements on each control become its IDR. Staff send it to the Audit Manager, who approves it and releases it now or on a date you pick. Control owners then upload files against each line, or drop everything in one go and let the system match files to requests by name.
Staff record the population, sample, exceptions and test steps, rate design and operating effectiveness, and mark the control Pass or Fail. A failed control gets a gap analysis with root cause and recommendation. Review then goes to the Audit Manager and on to the CAE.
Responses open for all failed controls together, once the whole project is tested. The control owner fills in the response, action plan, owner and target date. The Process Owner or Business Head approves it first, then audit staff, the Audit Manager and the CAE.
Each project has a live view of testing progress, effectiveness rate, deficiencies by process and staff workload. The final report is issued once everything is approved, and downloads as a PDF, laid out by entity or by control.
Every control has its own chat thread with the client contacts, so questions about a document stay next to it. Your admin decides which reminders go out, on which days and to whom, so overdue items get chased without anyone doing it by hand.
The steps in the order your team will actually work through them.
Upload your risk and control matrix and roll out each control to the entities that perform it.
Mark which entities are in SOX scope for the period. The CAE approves it.
The Audit Manager picks the period, scope, controls and staff, and sends it to the CAE.
Staff prepare the document request for each control. The Audit Manager approves and releases it.
Control owners upload files. Staff accept them, return them, or ask for more.
Staff fill in the workpaper and mark each control Pass or Fail.
The Audit Manager and then the CAE approve each control, or send it back.
Control owners respond on failed controls. The business and then audit approve the responses.
The final report goes out to the audit team and the client contacts.
The records the module produces, and the regulations and frameworks they help you meet.
These references describe the context the module is designed to support. They are not a statement of certification, and do not replace professional judgement on your reporting obligations.
Everyone works on the same record. Each person sees the part they are responsible for.
Don't see your question here? Write to us and we'll answer it for your setup.
Because it's built for groups. You keep one set of risks and controls and roll it out to every entity, sub-entity and division that uses it. One project and one report can cover many entities.
Control Testing suits a single entity running a testing project. Global SOX adds what a group needs on top: a shared control library with approved changes, yearly scope approval, CAE approval of each project, scheduled IDR release, additional data requests, and a longer approval chain for management responses.
Yes. Download the template, paste your RCM in, and upload it. If something doesn't fit, such as a missing owner or an unknown entity, you'll see it in the preview and can fix it before anything is saved.
Yes. Your admin sets up who approves library changes, scope and testing, with up to four stages each. Out of the box it's the Audit Manager followed by the CAE.
So management sees the full picture. Responses open once every control in the project has been tested and approved, and then all failed controls are sent together.
Book an hour with our team. We will run the module on your own process and control matrix, so you can see how a full cycle would look for you.