Global SOX

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.

Where it usually goes wrong

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.

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.

Scope agreed on a call

Which entities are in scope this year? The answer is in someone's email from March. The external auditor asks for it in December.

The same request, sent fifty times

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.

Who approved this?

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.

With Global SOX

  • A control is written once and used by every entity that performs it
  • Scope for the year is approved by the CAE and kept on record
  • You can see, per control, which documents are still pending
  • The person who tested a control can't approve it
  • Management responds once testing is complete, not control by control

What Global SOX does

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.

One risk and control library

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.

  • Automated, manual or semi-manual; preventive, detective or corrective
  • Classified as Operational, Financial, ITGC, ELC or Stat Compliance

Excel upload that checks your file first

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.

  • Templates for RCM, Risk Master and Control Master
  • Full history of every upload and who did it

Changes to the library need approval

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.

  • Deleted records can be restored
  • Every change is logged with the old and new value

SOX applicability for the year

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.

Projects the CAE approves before work starts

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 CAE can defer or bring back controls while approving
  • Can be limited to the entities marked Yes in the applicability
  • Close or reopen a project when you need to

Evidence requests and uploads

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.

  • Process Owner and Business Head are copied as escalation contacts
  • Need more? Raise an Additional Data Request
  • Return a file with a reason if it isn't what you asked for

Workpapers and review

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.

  • Nobody can approve a control they tested
  • Approve or send back several controls at once

Management response

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.

Reports and analytics

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.

Chat and reminders

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.

How a cycle runs

The steps in the order your team will actually work through them.

  1. 1

    Load the RCM

    Upload your risk and control matrix and roll out each control to the entities that perform it.

  2. 2

    Agree the scope

    Mark which entities are in SOX scope for the period. The CAE approves it.

  3. 3

    Set up the project

    The Audit Manager picks the period, scope, controls and staff, and sends it to the CAE.

  4. 4

    Send the IDR

    Staff prepare the document request for each control. The Audit Manager approves and releases it.

  5. 5

    Collect evidence

    Control owners upload files. Staff accept them, return them, or ask for more.

  6. 6

    Test

    Staff fill in the workpaper and mark each control Pass or Fail.

  7. 7

    Review

    The Audit Manager and then the CAE approve each control, or send it back.

  8. 8

    Get management's response

    Control owners respond on failed controls. The business and then audit approve the responses.

  9. 9

    Issue the report

    The final report goes out to the audit team and the client contacts.

What you have at the end

The records the module produces, and the regulations and frameworks they help you meet.

Reports and records

  • Risk and control library, with the entities each control applies to
  • Approved SOX applicability for each period
  • Approved project scope and staff assignment
  • IDR list with the evidence received against each line
  • Workpapers with samples, exceptions and conclusions
  • Gap analysis for every failed control
  • Management responses with action plans and target dates
  • Final SOX testing report (PDF)
  • Log of every change made to the library

Built around

SOX Section 404
Testing of internal control over financial reporting across the entities in scope.
SOX Section 302
A current view of control status to back the officer certifications.
PCAOB AS 2201
Workpapers and evidence in the form the external auditor reviews.
COSO Internal Control (2013)
Each control is tagged to its COSO component, and each risk to its financial assertions.
Companies Act 2013, Sec 134(5)(e) and 143(3)(i)
For Indian groups running IFC on the same control library.

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.

Who works in it

Everyone works on the same record. Each person sees the part they are responsible for.

Chief Audit Executive
Approves the scope, each project and changes to the library, and gives the final sign-off on testing and responses.
Audit Manager
Sets up projects, approves IDRs before they go out, and reviews testing.
Staff Auditor
Prepares IDRs, checks evidence, tests controls and reviews responses.
Control owners
Upload evidence and write the management response on failed controls.
Process Owners and Business Heads
Escalation contacts on each control, and first approvers of the response.

Questions we usually get

Don't see your question here? Write to us and we'll answer it for your setup.

Why is it called Global SOX?

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.

How is this different from Control Testing?

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.

Can we bring in our current RCM?

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.

Can the approval steps be changed?

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.

Why don't management responses open straight away?

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.

See Global SOX on your own data

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.