The RCM is a workbook nobody owns
Process changes are not reflected, control descriptions drift from what is actually performed, and two versions of the matrix circulate at once.
Control Testing
Project to report: the RCM, the requests, the testing, the responses and the sign-offs in one run
Control testing is a defined run, not a collection of files. A project is created for the entity and period, the RCM is uploaded to it, the IDR goes out to process owners for the information and documents required, the team tests against what comes back, the reviewer approves the results, management fills its response on what failed, that response is approved, and the report is generated from the approved record — so the file that supports the conclusion is built while the work happens rather than assembled after it.
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.
Requests and evidence run on email
Information and documents are chased over mail, so nobody can say what has been requested, what has arrived and what is still pending on the day it is asked.
Management response comes in late and loose
Responses are collected in a separate sheet after testing is done, and the link between the exception, the response and the person who accepted it is held together by hand.
The report is rebuilt from the file
Results, exceptions and responses are re-keyed into a report at the end, so the report and the working file can drift apart.
With Control Testing
- One project that carries the scope, the RCM, the testing and the report
- Every information and document request tracked with its status and due date
- Sample, evidence and conclusion held together on the control
- Testing approved by a reviewer before it reaches management
- Management response recorded against the exception and formally approved
- The report generated from the approved record, not re-keyed from it
What Control Testing does
Create a testing project, upload the RCM, release the information and document requests, test the controls, approve the results, collect the management response and generate the report — with the evidence attached at every step.
Project setup
Each round of testing runs as a project — entity, process scope, period, team and timeline defined up front, so the work has a boundary and a status of its own.
- Entity, process and period scope
- Team, reviewer and approver assignment
- Project timeline and status tracking
RCM upload and control library
Upload the risk and control matrix into the project — process, sub-process, risk, control and the attributes that drive testing — instead of maintaining it alongside in a workbook.
- Bulk upload of the existing RCM
- Preventive / detective, manual / automated, key / non-key
- Control frequency, owner and assertion held per control
IDR — information and document requests
Release the IDR from the project to the process owners, with what is required against which control and by when, so the request list is a tracked register rather than a mail thread.
- Requests raised control-wise with due dates
- Owner-wise pending and received status
- Reminders until the request is closed
Testing
Test design and operating effectiveness against the uploaded RCM, recording the sample, the attributes tested and the conclusion on each control.
- Design and operating effectiveness in one run
- Sample guidance by control frequency
- Attribute-level results with exceptions isolated
Evidence trail
What comes back against the IDR attaches to the control and the sample item it supports, so the conclusion and its evidence never travel separately.
- IDR response mapped to the control tested
- Evidence attached at sample level
- Complete trail retained with the project
Review and approval of testing
Testing is submitted for review, and the reviewer approves or returns it with comments before anything goes to management.
- Maker-checker on every test
- Return with comments and re-submission
- Approver identity and date recorded
Management response (MR)
Process owners fill the management response against each exception — the reason, the action committed and the date — inside the project rather than in a separate sheet.
- MR captured against the specific exception
- Action and target date recorded with the response
- Pending MR visible by owner and by process
MR approval and report generation
The management response is reviewed and approved, and the report is generated from the approved testing and responses.
- MR approved, or returned for revision
- Report generated from approved records
- Report retained with the project it came from
Control Testing on screen
Screenshots taken from the live product.
Inside a testing project
One project carries the RCM controls and the IDR fields raised against them, the report, and the analytics that read off both — controls in scope, testing progress, pass rate and open findings — with the project's own status line showing where it has reached in the approval and report release run.
How a cycle runs
The steps in the order your team will actually work through them.
- 1
Create the project
Set up the testing project for the entity, process scope and period, with the team, the reviewer and the timeline defined.
- 2
Upload the RCM
Load the risk and control matrix into the project, with each control's attributes, frequency and owner.
- 3
Release the IDR
Send the information and document requests to process owners against the controls to be tested, with due dates, and track what comes back.
- 4
Test
Test design and operating effectiveness on the samples selected, attach the evidence received and conclude on each control.
- 5
Approve the testing
The reviewer examines the testing and either approves it or returns it with comments for rework.
- 6
Fill the management response
Process owners record the MR against each exception — the explanation, the action committed and the date by which it will be done.
- 7
Approve the MR
The management response is reviewed and approved, or sent back for revision where it does not address the exception.
- 8
Generate the report
The report is produced from the approved testing and the approved responses, and stays attached to the project that produced it.
What you have at the end
The records the module produces, and the regulations and frameworks they help you meet.
Reports and records
- Project scope sheet with team and timeline
- Uploaded risk and control matrix for the project
- IDR register with request, owner and status
- Testing papers with samples, attributes and evidence
- Approved testing results with reviewer sign-off
- Exception list with management response against each
- Approved MR record with committed actions and dates
- Final control testing report generated from the project
Built around
- Companies Act 2013 — Sec 134(5)(e)
- Supports the directors' responsibility statement on internal financial controls.
- Companies Act 2013 — Sec 143(3)(i)
- Produces the file the statutory auditor examines when reporting on IFC adequacy and operating effectiveness.
- ICAI Guidance Note on Audit of Internal Financial Controls over Financial Reporting
- Design and operating effectiveness testing structured along the Guidance Note's approach.
- COSO Internal Control — Integrated Framework (2013)
- Component and principle mapping for entity-level and process controls.
- SEBI LODR — Reg 17(8)
- Supports the CEO and CFO certification on internal controls for financial reporting.
- SOX Section 404
- For groups with a US-listed parent running a 404 programme alongside IFC.
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.
- CFO and Controller
- Own the assertion, and track project status well before the reporting date.
- Testing team
- Runs the project — RCM, IDR, testing — and submits results for review.
- Process and control owners
- Respond to the IDR, and fill the management response where a control fails.
- Reviewer and approver
- Approves the testing and the management response before the report is generated.
Questions we usually get
Don't see your question here? Write to us and we'll answer it for your setup.
What exactly is the IDR step?
The information and document request is raised from the project to the process owners, control-wise, stating what is needed and by when. It becomes a tracked register — requested, pending, received — so the team is not chasing documents over email, and what arrives attaches to the control it was requested for.
Can we upload our existing RCM into a project?
Yes. The matrix is uploaded into the project with its processes, risks, controls and attributes, and becomes the control set that testing runs against. Later projects can start from it rather than from a blank sheet.
Why are there two approvals in the flow?
They cover different things. The first approval is the reviewer accepting the testing itself, before results are put to management. The second is the approval of the management response — whether what management has committed actually addresses the exception. Both are recorded with the approver and the date.
Is the report generated or drafted?
Generated. It is produced from the approved testing results and approved management responses held in the project, so the report reconciles to the file rather than being re-keyed from it.
Are these the same steps internal audit follows?
Yes. Internal audit starts earlier — audit universe, risk factor scoring, assurance mapping where required, plan approval and process-wise assignment — and from that point the steps are the same ones set out here: project, RCM, IDR, testing, approval, management response, approval and report.
See Control Testing 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.
Other RiskMan GRC modules
View the full product- Enterprise Risk ManagementA live risk register feeding heat maps and management reporting.
- Risk Based Internal AuditPlan by risk, approve the plan, assign it process-wise and execute it.
- Action Taken ReportTrack every observation through to closure, with owners and due dates.
- Policy and SOPOne library for policies and SOPs, with versions and approvals tracked.
- Global SOXFor groups testing the same SOX controls across many entities. One control library, one approved scope, and projects that end in a signed-off report.