RBI IT Framework Compliance for NBFCs: Step-by-Step Audit Checklist 2026

What the RBI IT Examination Will Actually Ask You

The Reserve Bank of India's IT Examination Framework is one of the most rigorous regulatory audits an Indian financial institution will face. Unlike a checklist audit, RBI examiners conduct evidence-based reviews — they ask for logs, reports, screenshots, and interview your IT and security staff. A policy document without implementation evidence is scored as a gap.

This guide is written for NBFCs, co-operative banks, payment aggregators, and account aggregators preparing for their next RBI IT examination or internal audit cycle.

Who Is Covered

Domain 1: IT Governance and Policy Framework

The examiner's first question is always: "Show me your IS Policy." If it was last updated more than 12 months ago or signed off by anyone below Board level, it is a finding.

Self-Assessment Checklist — Domain 1

1. [ ] IS Policy approved by the Board of Directors (not just the IT committee), reviewed annually, version-controlled with change log
2. [ ] IT Strategy Committee constituted with Board-level representation — meeting minutes available for last 4 quarters
3. [ ] Chief Information Security Officer (CISO) appointed with a defined role description and direct reporting line — not a dual-hat arrangement where the CTO is also the CISO
4. [ ] IT risk appetite statement documented, with quantified thresholds (e.g., "maximum acceptable downtime per year: 4 hours")
5. [ ] Technology risk register maintained and reviewed quarterly — each risk has an owner, rating, and mitigation status
6. [ ] IT budget as % of total opex tracked and reported to the Board — examiners look for evidence that IT investment is commensurate with the institution's technology risk profile
7. [ ] Vendor and outsourcing policy in place — covering due diligence requirements, SLA standards, exit clauses, and right-to-audit provisions

Domain 2: IT Infrastructure and Operations

RBI examiners conduct hands-on walkthroughs of data centres and cloud environments. They look for documented processes, not just implemented controls.

1. [ ] Data Centre and DR site documentation: physical security, access logs (badge swipes), environmental controls (temperature, humidity, fire suppression), and a current asset inventory
2. [ ] Network architecture diagram current, signed off by CTO/CISO, includes all third-party connectivity (banking correspondents, payment rails, credit bureau links)
3. [ ] Segregation of duties (SoD) enforced at the infrastructure level — development team cannot push to production, DBA cannot modify audit logs
4. [ ] Change management process documented and followed — every infrastructure change has: request → impact assessment → approval → implementation → post-change review. Emergency changes have a post-facto approval trail
5. [ ] Configuration management database (CMDB) or equivalent — all production assets catalogued with owner, OS version, patch level, and criticality
6. [ ] Capacity management — utilisation trending for CPU, storage, and network; alerts before thresholds are breached
7. [ ] CBS (Core Banking System) version — supported by vendor, on current release or with a documented upgrade plan with timeline

Domain 3: Business Continuity Planning (BCP) and Disaster Recovery (DR)

This is the domain most often cited in RBI findings. A written BCP that has never been tested is not a compliant BCP.

1. [ ] Business Impact Analysis (BIA) completed and current — for each critical system: RTO (Recovery Time Objective) and RPO (Recovery Point Objective) defined
2. [ ] DR site is geographically separated from primary data centre — same building or same city is not acceptable for critical systems
3. [ ] DR drills conducted at minimum once per year, with a full drill (actual failover, not a paper exercise) at minimum every two years — drill reports with outcomes and gaps documented
4. [ ] RTO targets achieved in last drill — if the drill showed RTO was missed, there is a remediation plan with a deadline
5. [ ] Customer-facing channels (mobile app, internet banking, payment gateway) have documented continuity plans separate from core banking
6. [ ] Communication plan for a major outage — who notifies RBI, when, and what information is provided
7. [ ] Pandemic / physical access denial scenario covered in BCP — remote access for critical staff, access to core systems from home network

graph LR
    A[Primary DC
Mumbai] -->|Replication| B[DR Site
Hyderabad]
    A --> C[CBS Live]
    B --> D[CBS Standby]
    C -->|Failover trigger| D
    D -->|RTO: 4 hrs| E[Operations Resume]
    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e5f3a,stroke:#10B981,color:#e2e8f0
    style E fill:#1e5f3a,stroke:#10B981,color:#e2e8f0

Domain 4: Vulnerability Management and VAPT

This is where an external VAPT report becomes a direct RBI examination deliverable.

1. [ ] VAPT policy defines scope (which systems are in scope), frequency (minimum annual), methodology (black/grey/white box), and who conducts it (CERT-In empanelled vendor)
2. [ ] Last VAPT report is less than 12 months old — if the examination falls in month 13, you are technically out of cycle
3. [ ] Scope includes internet-facing applications, internal network, and CBS interfaces — an application-only scan without network perimeter testing is considered partial scope
4. [ ] Critical and High findings from the last VAPT are remediated and re-tested — a finding that remains open from the prior cycle is a significant examination risk
5. [ ] Vulnerability tracking register maintained — each finding has: CVE reference (if applicable), severity, owner, target fix date, and current status
6. [ ] Patch management SLA defined by severity: Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days, Low ≤ 180 days — and evidence that SLAs are being met
7. [ ] Penetration test (manual) is distinguished from automated vulnerability scanning — RBI examiners ask specifically about manual PT coverage

Domain 5: Information Security Management

1. [ ] SIEM or log aggregation in place — events from CBS, firewalls, applications, and endpoints centralised with alert rules for known attack patterns
2. [ ] Security incident response team (SIRT) or equivalent — defined roles, escalation matrix, and a call tree that is tested
3. [ ] User access review conducted quarterly — a formal process where each system owner certifies that all current users still require their access levels
4. [ ] Privileged access management (PAM) — super-user accounts are time-boxed, logged, and reviewed; shared root/admin passwords are not in use
5. [ ] Anti-malware deployed on all endpoints — centrally managed, signature updates automated, scan schedules documented
6. [ ] Data Loss Prevention (DLP) controls on channels that could exfiltrate customer data — email, USB, cloud file sharing
7. [ ] Security awareness training — annual training for all staff, phishing simulation results tracked, high-risk departments (operations, treasury, customer service) receive enhanced training

Domain 6: Incident Response

1. [ ] Incident response policy — categories of incidents, severity levels, response timelines per severity, and reporting obligations (RBI, CERT-In, DPDP Board)
2. [ ] CERT-In reporting integrated into IR process — the 6-hour clock starts at detection, not at declaration; your runbook must account for this
3. [ ] RBI notification SLA — significant IT incidents must be reported to RBI within 2 hours of declaration; "significant" is defined as incidents affecting customer transactions or data confidentiality
4. [ ] Post-incident review (PIR) conducted within 30 days of resolution — root cause analysis, control gap identification, and remediation actions tracked
5. [ ] Cyber insurance policy reviewed by legal and IT risk team — ensure exclusions don't defeat the policy (many policies exclude "known vulnerabilities")

Domain 7: Third-Party and Outsourcing Risk

NBFCs that use third-party loan management systems, KYC vendors, or cloud providers face specific examination scrutiny on outsourcing risk.

1. [ ] Outsourcing policy covers: risk assessment before engagement, contractual protections (right-to-audit, data return, SLA), concentration risk management
2. [ ] Cloud usage disclosed to RBI if it covers regulated data or critical operations — RBI's cloud guidelines require notification for certain arrangements
3. [ ] KYC/AML vendor holds its own regulatory compliance — CERT-In empanelled for security audits, UIDAI authorised for Aadhaar-based eKYC
4. [ ] Business correspondent (BC) network security controls — each BC endpoint is in scope for the institution's overall security framework
5. [ ] SLA performance reports from critical vendors reviewed quarterly and reported to the IT Strategy Committee

RBI Examination Readiness: Summary Dashboard

Book your RBI IT Framework readiness assessment at bachao.ai/rbi-it-examination-readiness. We conduct CERT-In aligned VAPT, help structure your policy documentation, and produce examination-ready reports that examiners can accept directly.

Written by Shouvik Mukherjee, Founder, Bachao.AI. 15+ years in software engineering, now building AI-powered security products. Fourth-time founder. DPIIT Recognised Startup. Serving NBFCs, co-operative banks, and fintech companies across India.