The Enterprise Internal Financial Controls (IFC) Benchmark Report: Risk Control Matrix Trends in Indian Corporates

Three weeks before the audit committee meeting, someone on the finance team pulls up the risk control matrix to refresh it for the year. The document was last rebuilt in 2019. 

The ERP system it was written against has since been upgraded twice. Two of the process owners named against key controls left the company last year, and no one updated the matrix to reflect who owns those controls now.

This is not an unusual situation. It is close to the default state of risk control matrix preparation in India at mid-market and large enterprises, and it is the reason most RCM reviews show more gaps than the audit committee expects. 

This PKC report draws on patterns that show up consistently across PKC’s internal audit and IFC engagements with manufacturing, IT and ITES, and other multi-location enterprises. 

It looks at how risk control matrices are actually built and maintained inside these organisations, where the coverage gaps tend to concentrate and what a Chief Audit Executive or Head of Internal Audit can do about it before the next audit cycle surfaces the gap first.

TL;DRMost Indian enterprises with ₹100 crore+ turnover document between 150–350 risk-control pairs but coverage is often incomplete, especially for IT and ERP-related controls.IT general controls and application controls are the most commonly missed areas. Many RCMs document manual controls extensively but omit automated controls embedded in ERP systems.Most enterprises refresh their RCM annually, but the refresh is often superficial updating dates and job titles without reassessing risks or control effectiveness.Finance-led ownership is common but tends to miss operational controls. Cross-functional ownership produces more complete RCMs but requires more coordination.Weaknesses most often seen in organisations with 100+ employees: RCMs built from generic templates, controls selected without risk linkage, over-reliance on detective controls, and no defined risk criteria.

Why Risk Control Matrices Look Different Across Indian Enterprises

Risk Control Matrices (RCMs) can vary significantly across Indian companies, even within the same industry, depending on how they are prepared, the systems used, organisational structure, and update frequency.

Here are some factors that influences the structure of RCMs:

How It Was Originally Prepared: 

An RCM created during an IPO or major compliance exercise may focus heavily on financial reporting controls. A business that developed its RCM internally may have detailed coverage of procurement and payments but less attention to inventory, fixed assets or IT general controls. The consultant or audit firm involved can also influence how controls are classified, described and tested.

The ERP And Technology Environment: 

Companies using SAP, Oracle or Microsoft Dynamics may rely on automated approval workflows, access controls and three-way matching. Others may depend on spreadsheets, emails and manual approvals. These environments require different approaches to documenting and testing controls. An RCM should explain how each control operates in practice and how it addresses the related risk.

Industry And Business Model: 

A manufacturing company will have significant risks around inventory, production costs and fixed assets. A retail business may place greater emphasis on revenue, cash management, discounts and inventory movements. Using the same generic RCM template across different businesses can leave important risks poorly covered.

Group Structure And Ownership: 

Subsidiaries and multiple locations may use different ERPs, procedures and control frequencies. Who owns the RCM is also an important consideration. Finance, internal audit, risk or compliance teams may have different approaches to reviewing and maintaining the matrix.

Keeping the RCM Aligned With Your Business

RCMs can also become outdated simply because the business changes. Employees move on, processes are redesigned and ERP systems are upgraded. Without regular review, the matrix can end up documenting how the company operated several years ago rather than how it operates today.

A good RCM does not have to contain hundreds of rows. It should focus on significant risks, clearly define the controls addressing them, assign ownership and provide enough detail for effective testing.

Benchmark Finding 1: How Many Risk-Control Pairs Should an RCM Contain?

A common question CFOs and CAEs ask: How many risk-control pairs should our Risk Control Matrix contain?

There is no fixed number. 

The right size depends on the company’s processes, business complexity, number of entities, ERP environment and the materiality of its financial reporting risks. 

A simple business may need far fewer entries than a diversified group with multiple locations and complex systems.

A useful RCM is one that provides complete and consistent risk coverage. 

For example, in the procure-to-pay cycle, the matrix may need to address risks such as unauthorized vendor creation, duplicate payments, purchases without approval, price overrides and mismatches between purchase orders, goods receipts and invoices.

Each significant risk should have a corresponding control that is clearly defined and can be tested. Simply having a large number of rows does not mean the RCM is comprehensive.

Several gaps appear repeatedly:

• Incomplete Process Coverage: RCMs may cover procure-to-pay, order-to-cash and record-to-report but give limited attention to treasury, payroll, fixed assets, tax, inventory or other relevant processes.
• Inconsistent Level of Detail: One section may document controls in detail, while another may contain broad statements such as “management reviews transactions.” This makes control testing difficult and creates uncertainty about what evidence should be retained.
• Missing IT Controls: Manual controls are often documented more thoroughly than IT general controls (ITGC) and application controls. This can leave important system-based risks around user access, automated approvals, system changes and data integrity outside the RCM.

How to assess whether your RCM is complete

Instead of comparing your RCM with an arbitrary target number, test its coverage process by process. Take procure-to-pay, for example, and map the key sub-processes and risks from vendor onboarding through payment. Then check whether each significant risk has a defined, testable control.

An RCM with 200 well-designed risk-control pairs can provide better coverage than one with 500 generic or duplicated entries.

Your RCM should be complete enough to capture significant risks, precise enough to support control testing and practical enough for the business to maintain.

Benchmark Finding 2: Coverage Gaps in IT and ERP-Related Controls

IT and ERP-related controls are often less thoroughly documented than manual financial controls in Indian enterprise RCMs. Finance teams may have detailed controls around reconciliations, approvals and month-end reviews, while controls operating within the ERP receive much less attention.

This is particularly relevant as technology plays a growing role in financial reporting. Under the Companies Act, 2013, IFC requirements extend to the systems and processes that support financial reporting. 

An RCM that overlooks these controls may therefore provide an incomplete picture of the organisation’s control environment.

The gaps usually appear in

• IT general controls are too broad: Entries such as “user access is controlled” or “IT systems are secure” do not provide enough detail for effective testing. A useful control should identify what is reviewed, who performs the review, how often it happens and what evidence is retained.
• Application controls are overlooked: ERP systems can automatically enforce approval limits, validation rules, segregation of duties and three-way matching. These controls should be identified in the RCM rather than relying only on the related business process or policy.
• ERP changes are not reflected in the RCM: Approval limits, user roles, workflows and system configurations change as the business evolves. If these changes are not considered during RCM reviews, the matrix can quickly become different from the control environment that actually operates.
• Interfaces and legacy systems are missed: Companies often operate multiple ERP modules, standalone applications and spreadsheets. Controls over data transfers, system interfaces and migrations can become important where financial information moves between systems.

Instead of writing “IT systems are secure”, an RCM could specify:

“User access to the SAP FICO module is reviewed quarterly by the IT Manager and Finance Controller. Exceptions are investigated and resolved. Evidence: quarterly access review report.”

This makes the control identifiable, testable and accountable.

ITGCs and application controls should form part of the RCM wherever technology supports significant financial reporting processes. Internal audit does not necessarily need to perform every technical test itself.

Where specialist skills are required, targeted IT audit support can help test access logs, segregation of duties, configuration changes and system interfaces.

The RCM must reflect both manually performed controls and controls performed by the organisation’s systems.

Benchmark Finding 3: How Often Enterprises Should Refresh Their RCM

As the business changes, the risks and controls documented in the RCM can change with it.

Many enterprises follow an annual RCM review cycle, often before the statutory audit. 

The problem is that in many organisations, an annual review becomes an administrative exercise. Names and dates may be updated while the underlying risks, control activities and testing approach remain unchanged.

What you need to find is “What has changed in the business since the last RCM review?”

An ERP upgrade, new plant or location, change in approval limits, restructuring of responsibilities, new product line or move from manual to automated controls can all require a targeted review of the affected controls.

A meaningful RCM review should consider:

• Changes in Risk: Have new financial, operational, regulatory or technology risks emerged? Have existing risks become more significant?
• Changes in Controls: Are controls still designed appropriately, or have processes and responsibilities changed?
• Control Performance: Have there been control failures, audit observations, recurring exceptions or changes in testing results?
• Changes in Systems and Processes: Have ERP configurations, workflows, interfaces or manual procedures changed?
• Changes in People and Ownership: Have key control owners or approval responsibilities changed?

For most mid-sized enterprises, a full review at least once a year, supported by targeted reviews when significant business or system changes occur, is a good approach. Higher-risk processes may require more frequent monitoring based on the organisation’s risk assessment and control testing results.

Keeping the RCM aligned with business changes makes it a working document rather than an annual compliance exercise. It also reduces the risk of gaps between documented and actual controls being identified during statutory audit fieldwork.

Ultimately, the right refresh frequency depends on the pace of change and the risk profile of the business. The calendar should trigger a review, but significant changes in the business should trigger one too.

Benchmark Finding 4: Ownership Models – Finance-Led vs Cross-Functional

Who owns the RCM? The answer varies widely across Indian enterprises, and the ownership model has a significant impact on RCM quality and usefulness.

Finance-led ownership: 

In many enterprises, the finance team owns the RCM. Finance prepares the document, maintains it, and presents it to auditors. 

This model has the advantage of clear accountability if someone is explicitly responsible. However, it has a significant drawback: finance cannot own controls that operate outside the finance function.

Cross-Functional Ownership: 

In more mature IFC frameworks, the RCM is owned by a cross-functional team that includes representatives from finance, internal audit, IT, and business operations. Each function contributes its expertise, and the RCM reflects the full control environment, not just the finance portion.

In most cases, we see:

• Finance-led RCMs Often Miss Operational Controls: Controls over inventory, production, logistics, and sales are often documented superficially because the finance team does not have deep visibility into these processes.
• Cross-functional RCMs are Harder To Maintain But More Complete: Getting multiple functions to agree on risks, controls, and ownership takes time. However, the resulting RCM is more accurate, more complete, and more useful for audit purposes.
• Ownership Often Determines Refresh Frequency: Finance-led RCMs tend to be refreshed annually, around the audit cycle. Cross-functional RCMs are more likely to be reviewed quarterly, because multiple stakeholders have a vested interest in keeping the document current.

The RCM should be owned by a cross-functional team, with clear accountability assigned to a single individual ( the Head of Internal Audit or the CFO) for overall coordination and quality. Each control should have a named owner who is responsible for its operation and evidence.

Where Organizations With 100+ Employees Fall Short Most Often

Having an RCM does not necessarily mean that the control environment is well documented. 

As organisations grow beyond 100 employees, add locations or introduce more complex systems, several weaknesses tend to appear repeatedly.

1. Generic RCM Templates

Many RCMs start with a standard template and are never sufficiently adapted to the business. Generic risks and controls may make the matrix look comprehensive, while important risks specific to the organisation remain undocumented.

This becomes particularly relevant when companies add new plants, offices, subsidiaries or business lines without updating the original RCM.

2. Weak Linkage Between Risks And Controls

Controls are sometimes listed without clearly explaining which risk they address. Without this linkage, management cannot easily determine whether significant risks are actually covered or whether controls are simply being documented for the sake of compliance.

The RCM should make the connection between risk, control, control owner and evidence clear.

3. Risk Criteria Are Not Clearly Defined

Risk assessments can become subjective when likelihood and impact criteria are not properly defined. What one person considers a high-risk area may be considered moderate by another.

Clear risk-rating criteria help ensure that significant risks receive appropriate attention and control coverage.

4. Too Much Reliance On Detective Controls

Reconciliations, management reviews and exception reports are important, but they identify problems after they occur. 

RCMs should also capture preventive controls such as system validations, approval workflows and segregation of duties that can stop errors or unauthorised transactions before they happen.

5. Controls Lack Clear Evidence Requirements

A control may be documented correctly but still be difficult to test if the RCM does not specify what evidence should exist.

For example, instead of simply stating “user access is reviewed periodically,” the RCM should identify the review frequency, responsible owner and evidence, such as an approved access review report.

6. Risk Register And RCM Operate Separately

The enterprise risk register and RCM are often maintained by different teams with little connection between them. 

This can result in significant risks being identified at the enterprise level without a corresponding control being documented or tested.

These gaps become harder to manage as the organisation expands across locations and systems. 

A company operating from several plants or subsidiaries may have controls that work differently at each location, even though the RCM describes them as one standard control.

At that stage, an RCM review should check whether the documented controls still reflect actual business practices across locations, functions, and systems.

For many organisations, identifying these gaps means a structured review of the existing matrix, followed by targeted updates to risks, controls, ownership and evidence requirements, can often bring the document back in line with the current business.

A Practical Checklist for Building or Refreshing Your RCM

Before deciding that a complete RCM rebuild is necessary, use the following checklist to assess where the existing matrix stands.

1. Scope and Process Coverage

• Does the RCM cover all relevant financial reporting processes (procure-to-pay, order-to-cash, record-to-report)?
• Are inventory, fixed assets, treasury, payroll, and tax processes included where relevant?
• Are significant operational processes that affect financial reporting covered?
• Does the RCM cover all material subsidiaries, branches, plants, and business units?
• Are newly introduced or significantly changed processes reflected?
• Does the RCM account for process variations between locations?
• Critical check: Is every key business process represented in the process map?

2. Risk Identification

• Are risks identified at process and sub-process levels (not just entity level)?
• Are risks based on actual business operations, not generic templates?
• Does each significant process have clearly defined risks?
• Are likelihood and impact assessed using defined criteria?
• Are significant risks distinguished from routine ones?
• Where relevant, are risks linked to financial statement assertions?
• Are emerging risks considered when processes, systems, or regulations change?
• Critical check: Can you clearly state what could go wrong and what it would mean?

3. Risk and Control Linkage

• Is every significant risk linked to one or more controls?
• Can you explain how each control reduces its linked risk?
• Are there identified risks without corresponding controls?
• Are multiple controls documenting the same activity?
• Does the RCM distinguish between key and supporting controls?
• Critical check: Does each control directly address the specific risk, not just describe a general activity?

4. Control Documentation

• Does each control describe a specific action, not a broad policy?
• Is the control owner clearly identified?
• Is frequency stated (daily, weekly, monthly, quarterly)?
• Is the control identified as preventive, detective, or both?
• Does the description explain triggers, what is reviewed/approved, how exceptions are handled, and what evidence is generated?
• Is evidence retained in an auditable form?
• Critical check: Can an independent person understand and test the control from its description alone?

5. IT and ERP Controls

• Are IT general controls (ITGCs) documented?
• Are user access, joiner/mover/leaver processes, and privileged accounts covered?
• Is segregation of duties considered within the ERP?
• Are application approvals, system validations, and automated checks documented?
• Are ERP configuration changes subject to approval and review?
• Are controls over system interfaces, data transfers, and migrations documented?
• Critical check: Does the RCM reflect actual ERP configuration, not policy intentions?

6. Ownership and Accountability

• Does every control have a named owner who understands their responsibility?
• Is there a process owner for each process?
• Are all relevant functions (finance, operations, IT, etc.) involved?
• Is one person responsible for coordinating the overall RCM?
• Is there an escalation process for non-compliance?
• Are responsibilities transferred when employees change roles?
• Is there a deputy for critical controls?

7. Evidence and Testing

• Does each key control have defined evidence generated as part of normal operations?
• Can evidence be retrieved and does it show who performed the control and when?
• Does evidence demonstrate what was reviewed or approved?
• Are exceptions documented and followed up?
• Have controls been assessed for design and operating effectiveness?
• Are recurring failures captured in the risk assessment?
• Critical check: Can you demonstrate the control operated as intended?

8. Risk Register Linkage

• Are significant risks in the risk register mapped to relevant processes?
• Do material risks have corresponding controls in the RCM?
• Are gaps identified where significant risks lack adequate controls?
• Are risk register changes considered during RCM reviews?
• Is there clear distinction between enterprise-level and process-level risks?

9. Refresh and Change Management

• Is there a defined periodic RCM review process?
• Does the review go beyond updating names and dates?
• Do system changes, new locations, approval limit changes, or process redesigns trigger RCM updates?
• Are regulatory changes, audit findings, and control failures incorporated?
• Are new products, acquisitions, or business models assessed?
• Critical check: Are significant changes addressed promptly, not just annually?

10. Audit Readiness

• Can an independent reviewer understand the control without speaking to its designer?
• Can each key control be tested directly from the RCM?
• Is evidence available and do documented controls match actual practices?
• Can control owners explain how the control operates in practice?
• Are location differences captured and known deficiencies incorporated?

How to Use This Checklist

You do not need to rebuild the entire RCM because some boxes remain unchecked. Here’s what you need to do:

1. Start with one high-risk process, such as procure-to-pay or order-to-cash, and work through the checklist from beginning to end.
2. This often reveals whether the problem is limited to a few outdated controls (fix those directly)  or whether there is a broader issue with risk coverage, ownership, IT controls or control testing. The latter means that a systematic refresh needed 
3. For larger organisations, use the same approach across different plants, subsidiaries, or business units, especially where processes appear standardised but operate differently in practice.
4. Use your risk register as a companion. It provides the broader business risk view that feeds into process-level risk identification, ensuring nothing falls between responsibilities.
5. If a control description does not allow testing or a risk lacks a clear control link, that is your priority for remediation.

Remember: A good RCM answers clearly –  What could go wrong, what controls prevent or detect it, who is responsible, and how do we prove it worked?

If your risk control matrix has not been tested against how your business actually runs this year, the most useful next step is a focused review of one function, not a full rebuild. Schedule an appointment with PKC to walk through where your current RCM stands.

FAQs

What is a Risk Control Matrix (RCM) and why is it needed for IFC? 

A risk control matrix maps the risks in a business process against the specific controls designed to address them, along with who owns each control and how it is tested. It is the working document that internal financial controls (IFC) reporting is built on, because auditors and management use it to show that risks are actively managed.

How often should an enterprise refresh its risk control matrix? 

A full walkthrough once a year is a reasonable baseline, but the more important discipline is refreshing specific sections whenever the underlying process changes: an ERP upgrade, a new location, a leadership change in a control-owning role, or a process redesign should each trigger a targeted update rather than waiting for the annual cycle.

Who should own the RCM: finance, internal audit, or a cross-functional team? 

There is no single correct model, but ownership needs to be explicit. A joint model, where finance and internal audit own the overall framework and testing calendar while individual process owners are accountable for the accuracy of their own sections, tends to produce broader and more current coverage than a purely finance-led build.

What are the most commonly missed control areas in Indian enterprises? 

IT and ERP-related controls are the most consistent gap: user access reviews that are documented but not tested, segregation of duties that is not mapped to actual system roles, and change management controls around ERP configuration changes. Newer locations or entities added after the original RCM was built are also frequently under-covered.

How does RCM quality affect the statutory audit process? 

A well-maintained RCM gives the statutory auditor a clear, current basis for testing controls, which means fewer surprises, fewer last-minute requests for evidence, and a shorter path to closing observations. A stale or generic RCM forces the auditor to test more from scratch, which extends timelines and increases the number of findings raised during fieldwork.

How does PKC help enterprises build or refresh a risk control matrix? 

PKC’s internal audit and IFC advisory teams map the business process as it actually runs, test the existing controls (including ERP-level controls) against real evidence, and rebuild or refresh the RCM to reflect current ownership and process reality. Engagements start with a single plant, business unit, or high-risk process before extending to the full enterprise, so findings and recommendations can be reviewed before scaling the approach further.