RBI NBFC Cybersecurity Directions 2026: A Practical Audit Checklist for Maker-Checker Controls

Most NBFC audit files have a delegation of authority (DoA) matrix in them, and most have a line confirming that "maker-checker controls are in place". Both are usually true on paper. The harder question, and the one the RBI's new IT and cybersecurity directions now push towards, is whether those controls actually run inside the systems, and whether anyone can prove it.

The RBI issued the Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions on 31 July 2026, effective the same day. They replace the earlier IT framework instructions for NBFCs, and they apply in tiers. This article looks at one narrow slice that matters to internal auditors, IS auditors and concurrent auditors: approvals, authority and the audit trail behind them.

First, check which tier applies

The directions split NBFCs three ways:

• base layer NBFCs below ₹500 crore and Core Investment Companies (Chapter III);
• base layer NBFCs of ₹500 crore and above (Chapter IV);
• middle, upper and top layer NBFCs, excluding CICs (Chapter V).

Several requirements below are stated in only one chapter. Before testing anything, record which chapter applies to the entity and why, so each test is matched to the right requirement.

1. Maker-checker inside the systems

For smaller base layer NBFCs and CICs, the Board-approved IT/IS policy must provide for systems with a "maker-checker concept to reduce the risk of error and misuse" (paragraph 8(3)). For base layer NBFCs of ₹500 crore and above, the information security policy must require maker-checker for authorisation in information systems, so that transactions are completed only after independent verification and approval by at least two individuals (paragraph 21(6)).

What to test:

• Pick a sample of high-risk transactions (disbursements, changes to borrower or vendor bank details, manual journals, write-offs). Was the checker a different person from the maker, every time?
• Can a user approve an item they created? Ask for a demonstration in the system, not a policy extract.
• Where approvals happen by email and are keyed in later by one person, treat the system record as single-person evidence. The email is not part of the system's maker-checker.

2. Documented delegation for permissions and key parameters

Paragraph 21(3) (base layer ₹500 crore and above) requires role-based access and avoiding dependence on one or a few people, and says there "shall be clear delegation of authority for right to upgrade / change user profiles and permissions, and changes to key business parameters (e.g., interest rates)", and that this must be documented.

This is the part most DoA matrices miss. They are detailed on credit limits and silent on who can change a rate card, a product parameter or a user's access in the loan system.

What to test:

• Does the DoA matrix name an approver for user-permission changes and for changes to key parameters such as interest rates, fees and limits?
• Take the change log for rate cards and user roles for a quarter. Was every change approved by the person the matrix names? Is there an approval record, not just a system change?
• Look for dormant or generic administrator accounts that make such changes.

3. Audit trails that are good enough to rely on

For base layer NBFCs of ₹500 crore and above, audit trails must exist for IT assets, meet business, regulatory and legal requirements, facilitate audit, serve as forensic evidence and assist in dispute resolution, and record any unauthorised user activity (paragraph 21(8)). For the middle layer and above, every application or system that can access or affect critical or sensitive information needs audit logging (paragraph 109), the trails must be detailed enough for audits, forensics and dispute resolution including non-repudiation (paragraph 110), and the NBFC must regularly monitor audit trails and system logs (paragraph 111).

What to test:

• For a sample approval, can the system show who approved, when, on what version of the record, and under which authority, without someone rebuilding it from emails?
• Can an administrator edit or delete log entries? If yes, how would that be detected?
• For the middle layer and above: who reviews the logs, how often, and where is the evidence of review?

4. Data migrations and outsourced systems

Two areas are easy to overlook.

• Data migrations (middle layer and above, paragraph 99): the policy must provide for audit trails of migration activity and sign-offs from business users and application owners at each stage. If the NBFC moved from spreadsheets or an old LOS to a new system this year, ask for the stage-wise sign-offs.
• Outsourced technology (base layer ₹500 crore and above, paragraph 62(2)(i)): contracts must let the NBFC access records, and the service provider must retain audit trails and logs of administrative activity, accessible to the NBFC on approved requests. Check that the contract actually says so, and that the NBFC has ever asked.

A short testing checklist

1. Record the applicable chapter (III, IV or V) and why.
2. Sample high-risk transactions and confirm maker and checker were different people, in the system.
3. Confirm the DoA matrix covers user permissions and key parameters, not only credit.
4. Trace a quarter of rate-card and role changes to approvals by the named authority.
5. Walk one approval end to end in the audit trail: who, when, version, authority.
6. Check whether log entries can be altered and how alteration would be detected.
7. For middle layer and above, obtain evidence of regular log review.
8. For migrations and outsourced systems, check sign-offs and contractual access to logs.

None of this needs a new framework. It needs the existing DoA matrix and maker-checker rules to live where the work actually happens, with a record that holds up when someone asks for it.

This article is general information for audit and finance professionals, not legal or regulatory advice. Readers should refer to the directions on rbi.org.in for the full text.

Source: Reserve Bank of India (Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, RBI/DoS/2026-27/461 dated 31 July 2026, available on rbi.org.in.

The author is Sales Director at Averoic Digital Group, which builds a no-code platform for governed approvals, maker-checker controls and audit trails used by lenders and funds in India.