RBI Cyber Security Framework audit methodology: a practitioner reference for 2026 inspections

Indian banking IS auditor reference · 2026-05-19 · Reflects RBI Master Directions on IT Governance (April 2024) and Cyber Resilience (July 2024)

TL;DR

RBI's cyber security oversight has tightened materially over 2024–2026. Three regulatory instruments now define the audit landscape:

• The original Cyber Security Framework for Banks (RBI/2015-16/418 dated 2 June 2016) — still in force as the foundational document.
• Master Directions on Information Technology Governance, Risk, Controls and Assurance Practices, April 2024 — consolidating and updating earlier IT-related circulars. Applies to scheduled commercial banks (excluding RRBs), small finance banks, payments banks, top-tier NBFCs, all India financial institutions, and credit information companies.
• Master Directions on Cyber Resilience and Digital Payment Security Controls, July 2024 — applies to non-bank payment system operators including card payment networks, PA/PG, PPI issuers, white-label ATM operators.

Three themes have intensified in RBI inspections through 2025–26: third-party risk depth (cloud and core banking specifically), application security from scan-to-manual-pen-test, and end-to-end CIMS submission discipline for incident reporting.

This guide is an audit methodology — what to scope, what to test, what evidence to gather, and what RBI inspectors are currently focusing on. It is written for CERT-In empanelled IS auditors running RBI CSF / IT Audit engagements at banks, NBFCs, and payment system operators. The same content also serves internal audit teams, CISOs preparing for supervisory inspection, and Board IT Strategy Committees needing to scope assurance work.

A working note on CIMS reporting timelines that is non-negotiable: significant cyber incidents require initial report within 6 hours to RBI through the Centralised Information Management System (CIMS) at rbi.org.in, and a detailed root cause analysis report within 21 days. CERT-In Direction 70B runs in parallel with its own 6-hour reporting requirement. A single significant incident triggers both; the procedures must be pre-staged.

The audit landscape: what governs whom

Different regulated entity types fall under different stacks. Scope at the start of every engagement:

The CSF 2016 controls in scope. The framework specifies 22 baseline cyber security controls in Annex 1 (organised into core areas covering inventory, configuration, access, vulnerability, anti-malware, vendor risk, network security, application security, customer education, customer information, secure mail and messaging, removable media, BCM, training, awareness, periodic reviews, audit logs, security operations centre, vulnerability assessment, anti-phishing, web filtering). Additional controls scale by Level 1–4 categorisation based on the bank's technology adoption maturity.

The 2024 Master Directions on IT Governance apply at a higher altitude — Board-level governance, IT Strategy Committee, IT Steering Committee, three-lines-of-defence structure, audit independence, cyber resilience oversight. This is structural; expect the inspector to ask for the Board minutes and committee composition before getting into control detail.

The 2024 Master Directions on Cyber Resilience for non-bank payment system operators are the operational analogue for PA/PG and card-network entities. They mandate the same control families adapted to payment system context.

Pre-audit preparation

Before opening engagement, the audit team should pin down:

1. Scope letter. Which CSF Annex 1 controls, which ITGRCA chapters, which entities (subsidiaries, branches, joint ventures), which time period. RBI inspections are typically risk-based and may carve out specific control families; an internal IS audit should be comprehensive.

2. CERT-In empanelment. RBI inspectors prefer (and supervisory exams effectively require) the lead auditor for VAPT and pen-testing to be CERT-In empanelled. Empanelment is checkable at the CERT-In website. Without it, the audit findings may be challenged on credentialing grounds.

3. Entity categorisation. Verify the bank's CSF Level (1–4) and matching control set. UCBs follow a graded approach by asset size. NBFCs follow the asset-value thresholds in the IT Framework Master Directions. Mismatched scoping leads to either over-audit (cost) or under-audit (gap discovered at inspection).

4. Document request list. Pre-stage:

• Cyber Security Policy (current version + history of amendments + Board approval dates).
• Cyber Crisis Management Plan (CCMP).
• BCP/DR Policy and last DR test results.
• IT Outsourcing Policy and live vendor register.
• VAPT reports for past 12–24 months (internet-facing + critical internal).
• Penetration testing reports with manual-test evidence (not just scan dumps).
• CIMS incident submissions for past 12 months and DBOD-DPSS responses.
• Logs and SIEM coverage matrix.
• KRI/KPI dashboards reviewed at Board IT Strategy Committee.
• Patch compliance metrics.
• Vendor risk assessments for cloud, core banking, AML, KYC, payment-rail providers.
• Annual IS audit reports (internal + external).
• DPB-style data privacy alignment (overlapping with DPDPA from May 2027).

5. Inspector intensification themes to read against the documentation: - Third-party risk: evidence of independent assessments of cloud, core banking, AML/KYC vendors. Self-attestation from vendors is no longer sufficient. - Application security: moved from "did you scan" to "did you perform manual penetration testing, were findings remediated within agreed SLA, and was re-test performed." - CIMS submission discipline: initial report within 6 hours, detailed report within 21 days, no missing submissions for the period.

Audit methodology by domain

The 12 domain areas below follow the CSF 2016 Annex 1 organisation, augmented with ITGRCA 2024 governance and Cyber Resilience 2024 considerations for payment system operators.

Domain 1: Cyber Security Policy & Governance (CSF Para 3 + ITGRCA Chapter 2)

What the audit checks. - Board-approved Cyber Security Policy that is separate from the broader IT Policy (CSF Para 3 explicitly requires this separation). - Annual review and update of the policy by the Board (or delegated to Board IT Strategy Committee with ratification). - Policy covers: cyber security strategy, risk management approach, baseline cyber resilience requirements, roles and responsibilities, CCMP integration, vendor cyber controls, incident management, customer education, training. - CISO role: independent of IT operations, reporting line to MD/CEO or Board IT Strategy Committee (not embedded in IT Service Delivery). - IT Strategy Committee meets at least quarterly; IT Steering Committee operates at executive level. - Chief Compliance Officer (CCO): reports directly to MD/CEO and/or Board/Audit Committee. Quarterly meeting between CCO and Audit Committee without senior management present (ITGRCA requirement post-2024).

Evidence sources. Board approval minutes; Cyber Security Policy versions with date trail; CISO appointment letter and organogram; IT Strategy / Steering Committee minutes; CCO Audit Committee meeting minutes (closed-door).

Common findings. - Cyber Security Policy folded into IT Policy, not separate. - Annual review attendance is BAU committee; no Board ratification trail. - CISO reports to CTO (conflict of interest with operations). - CCO–Audit Committee closed-door meeting not happening or not minuted.

Domain 2: Cyber Security Operating Center (CSOC / SOC) (CSF Para 5)

What the audit checks. - SOC operational 24×7 for scheduled commercial banks. For UCBs and smaller NBFCs, MSSP-based SOC is acceptable with appropriate oversight. - Coverage: critical systems (core banking, payment switches, internet banking, mobile banking, ATM, treasury, AML/KYC, customer-facing apps). - Use cases tuned to current threat landscape (ransomware, BEC, account takeover, SWIFT-related fraud, UPI fraud, internal threats). - Log retention period: minimum 12 months active, longer per RBI specific guidance (some regulators expect 24 months for critical logs). - SOC effectiveness metrics: alert volume, true-positive rate, mean time to detect, mean time to respond. - Independent assessment of SOC effectiveness — typically annually.

Evidence sources. SOC runbook; SIEM coverage matrix; use-case library; sample alerts traced through to incident-response actions; KPI dashboard reviewed at IT Strategy Committee; MSSP contract (if outsourced) with security obligations.

Common findings. - SOC active only during business hours. - SIEM coverage incomplete — payment switches and ATM channels logged but not feeding the SIEM in real time. - Log retention 90 days, missing the 12-month minimum. - SOC effectiveness assessed by the same provider running the SOC (independence absent).

Domain 3: Vulnerability Assessment and Penetration Testing (CSF Annex 1 control + ITGRCA)

What the audit checks. - Annual VAPT for all internet-facing applications; after any significant change (new release, new infrastructure, new feature). - Manual penetration testing — not just automated scanning. The inspector specifically asks for manual test evidence (logical flaws, business logic issues, authentication/authorisation flaws that scanners miss). - CERT-In empanelled lead auditor for the engagement. - Findings remediation within agreed SLA (typically 30 days for critical, 90 for high, 180 for medium). - Re-test of remediated findings — not just closure note, but actual re-test evidence. - Coverage of: web, API, mobile (Android + iOS), internal network, infrastructure, cloud configuration. - Frequency for non-internet-facing critical systems: at least every 18 months.

Evidence sources. VAPT reports with manual test methodology and findings; CERT-In empanelment certificate of the lead firm; findings register with remediation dates; re-test reports; SLA dashboard.

Common findings. - VAPT scan reports without manual testing evidence. - Lead firm not CERT-In empanelled. - Findings closed by self-attestation without re-test. - Mobile app testing skipped; only web tested. - API authorisation testing absent or shallow.

Domain 4: Network Security and Segmentation (CSF Para 8 controls)

What the audit checks. - Network architecture documented and current; segmentation between corporate, production, payment, and external-facing zones. - Defence in depth: perimeter firewalls + IDS/IPS + internal segmentation + endpoint detection. - DDoS mitigation in place for internet-facing applications. - Secure remote access: MFA mandatory for all administrative access from outside the corporate network. - Wireless network segregation: corporate WiFi separate from guest separate from production access. - Network change management with documented approval.

Evidence sources. Network architecture diagram (current); firewall rule audit; segmentation evidence (VLAN, subnet, ACL); IDS/IPS deployment evidence; sample remote access events showing MFA enforcement; change management records.

Common findings. - Network diagram outdated by 12+ months. - Flat networks behind the perimeter — east-west traffic uncontrolled. - MFA for remote admin access bypassable via legacy accounts. - Firewall rule sprawl with "any-any-tcp" rules never cleaned up.

Domain 5: Identity, Access, and Privilege Management (CSF Annex 1 + ITGRCA Chapter 5)

What the audit checks. - Centralised identity management (AD/Azure AD/Okta/etc.) covering all critical systems. - Joiner-Mover-Leaver process working: time-to-disable on departure within 24 hours (preferably automated). - Privileged access management (PAM) for system administrators, DBAs, root access — with session recording for high-privilege roles. - MFA mandatory for: administrative access, internet-banking customer access, employee access to core banking, vendor access. - Quarterly access reviews with sign-off by line manager and system owner. - Service accounts inventoried and rotated; no shared logins for production systems. - Customer-facing MFA: at least two-factor for internet banking; risk-based authentication for transaction-level controls.

Evidence sources. IAM tool screenshots; sample joiner/leaver/mover events traced end-to-end; PAM deployment and session recordings; access review records; service account register; MFA enforcement evidence.

Common findings. - Leaver access disabled in primary system but retained in legacy systems. - PAM deployed but admins bypass it via direct SSH/RDP. - Quarterly access reviews performed but the same accounts repeatedly approved as "still needed" without justification. - Service accounts with passwords unchanged for years.

Domain 6: Application Security and Secure Development (CSF Annex 1)

What the audit checks. - Secure coding standards published and trained. - SAST/DAST integrated into the CI/CD pipeline; results reviewed before release. - Threat modelling for high-risk applications (customer-facing, payment, treasury). - API security: authentication, authorisation, rate limiting, input validation, output encoding. - Third-party library / open-source dependency scanning (SCA) for known vulnerabilities. - Application change control: separation of dev/test/prod environments; release sign-off. - Pre-production security testing (carrying forward Domain 3 VAPT into per-release testing).

Evidence sources. Secure SDLC policy; sample SAST/DAST reports for recent releases; threat models for high-risk apps; SCA scan results; release approval records.

Common findings. - SAST run but findings never reviewed; pipeline gates not configured to fail on critical findings. - API authorisation gaps — IDOR-style flaws. - SCA not deployed; dependency vulnerabilities unknown. - Threat models exist for hero applications but not for the long tail.

Domain 7: Endpoint and Anti-malware (CSF Annex 1)

What the audit checks. - EDR/anti-malware deployed on all endpoints and servers; central management console. - Detection capability beyond signature: behavioural / heuristic / cloud-reputation. - Coverage check: no endpoints unprotected; protection actively running; signatures current. - Endpoint hardening: USB controls, full-disk encryption, host firewall, application allow-listing where feasible (especially for high-risk roles like treasury and SWIFT operators). - Patch management for endpoints with measurable SLAs (typically 30 days for critical, longer for lower severity).

Evidence sources. EDR/AV console screenshots; coverage matrix; patch compliance dashboard; sample 3 endpoints checked for deployment, signatures, and patching.

Common findings. - Servers excluded from EDR (legacy AIX, mainframes, OT-style systems). - Coverage at 95% with the missing 5% being the highest-risk endpoints. - Patch SLAs missed without root-cause analysis.

Domain 8: Vendor / Third-Party Risk Management (CSF Para 8 + ITO 2023 + Cyber Resilience 2024 for payment SOs)

What the audit checks. This is one of the intensified themes in recent RBI inspections.

• IT Outsourcing Policy approved by Board; live vendor register classified by criticality.
• Pre-engagement due diligence for critical vendors: independent security assessment, financial soundness, BCP capability, references, regulatory compliance posture.
• Contractual coverage: right to audit, security obligations, incident notification timelines flowing back to the bank, exit assistance, data return/destruction, sub-contractor approval.
• Ongoing oversight: at least annual review of critical vendor risk; independent assessment of cloud providers and core banking providers (not vendor self-attestation).
• Cloud assurance specifically: SOC 2 Type 2 or ISO 27001 reports + bank-specific cloud configuration review.
• Vendor incident response integration: vendor incidents that affect the bank flow into the bank's CCMP and CIMS reporting.

Evidence sources. IT Outsourcing Policy; vendor register with criticality classification; due diligence reports for critical vendors; sample 3 critical vendor contracts; ongoing review records; cloud configuration review reports.

Common findings. - Vendor register exists but is missing fields (no criticality, no last-review date). - Cloud assessment limited to AWS/Azure SOC 2 report from the provider; no bank-specific configuration review (S3 buckets, IAM policies, network rules). - Contractual right to audit exists but never exercised. - Sub-contractor approval clause present but no inventory of sub-contractors. - Vendor incidents discussed at vendor governance meetings but not flowing into bank CCMP.

Domain 9: Incident Response and CIMS Reporting (CSF + Master Directions Cyber Resilience 2024)

What the audit checks.

• CIMS portal (rbi.org.in) registration and live access for incident submissions.
• Initial report within 6 hours for significant incidents.
• Detailed root cause analysis report within 21 days.
• Incident response procedure documented; tested via tabletop exercise at least annually; covers detection, triage, containment, eradication, recovery, post-incident review.
• CCMP integrated into the broader BCP framework; tested annually.
• Forensic capability either in-house or via retainer.
• CIMS submission discipline: no missing submissions for the audit period; submissions complete and timely.
• Parallel CERT-In Direction 70B reporting within 6 hours; reconciliation with RBI submission.

Evidence sources. CIMS submission history (12-month period minimum); incident response procedure with last review date; tabletop exercise records; CCMP document and last test report; forensic retainer agreement if applicable; CERT-In submission records.

Common findings. - CIMS submission missed because the awareness clock was not tracked precisely. - Detailed root cause report submitted past 21 days without seeking extension. - Tabletop exercises annual but recycled with the same scenario every year. - CCMP exists but not BCP-integrated; double recovery paths uncoordinated. - CERT-In submission delegated to MSSP without bank oversight of the timing.

Domain 10: Customer Information Protection and Customer Education (CSF Annex 1)

What the audit checks. - Customer data classification and handling procedures. - Data leakage prevention (DLP) deployed for customer data: at email gateway, on endpoints, at web gateway. - Customer-facing security: device binding for mobile banking, transaction OTP, beneficiary cooling-off period, anomaly detection on transactions. - Customer education programme: phishing awareness, OTP-fraud awareness, social engineering, account-takeover patterns, safe banking habits. Multiple channels (SMS, email, app, branch). - Annual customer awareness campaign with metrics on reach and effectiveness.

Evidence sources. Data classification policy; DLP deployment evidence; customer-facing security feature inventory; education campaign materials; reach metrics.

Common findings. - DLP deployed at email but not endpoint or web. - Customer education limited to legal disclaimers; no proactive awareness campaign. - Anomaly detection on transactions exists but tuned too loosely; high false positives reduce customer trust.

Domain 11: Cryptographic Controls and Data Protection (CSF + ITGRCA)

What the audit checks. - Cryptography policy: approved algorithms, key lengths, deprecated algorithms forbidden (DES, RC4, MD5, SHA-1 in security-sensitive uses). - TLS 1.2 minimum; TLS 1.3 preferred; SSL versions disabled. - Data at rest encryption for customer data and critical systems. - Key management: hardware security module (HSM) for high-value keys (payments, signing); key rotation procedures; key custody segregation. - Application-layer encryption for sensitive fields (card numbers, account numbers, biometric data) — additional to transport encryption.

Evidence sources. Cryptography policy; TLS configuration evidence on internet-facing endpoints (e.g., SSL Labs reports); HSM deployment evidence; key management procedures; sample encryption-at-rest verification.

Common findings. - TLS 1.0/1.1 still enabled on legacy systems. - Application-layer encryption claimed but actually transport-only. - HSM deployed but key rotation procedures never exercised.

Domain 12: BCP/DR and Cyber Resilience (CSF + ITGRCA)

What the audit checks. - BCP and DR plans for critical systems with RTO and RPO defined per system. - Annual DR test for critical systems (full failover, not desktop walk-through). - Cyber-specific recovery scenarios in CCMP: ransomware recovery, destructive-attack recovery, supply-chain compromise recovery. - Backup strategy: 3-2-1 minimum; immutable / air-gapped backups for ransomware-resilience. - Periodic backup restoration testing. - Tabletop and live testing of cyber crisis response.

Evidence sources. BCP/DR plans; DR test reports; CCMP document; backup architecture document; restoration test logs; tabletop and live test records.

Common findings. - DR test annual but limited to non-cyber scenarios (data centre power, network outage). - Backup restoration tested at file level but not at full-application level. - Immutable / air-gapped backups claimed but actually mounted writable on the same storage system.

Three views: external IS auditor / internal audit / CISO

External IS auditor view. Independence is the differentiator. RBI inspectors weight findings from auditors who can demonstrate independence from the engagement subject. CERT-In empanelment is necessary but not sufficient; documented separation between the audit firm and any active managed-service relationship with the bank is the operational test. Findings should be ranked by RBI's intensification themes (third-party, app security, CIMS) to align with inspector focus.

Internal audit team view. Internal audit's role is continuous assurance; the external audit is a point-in-time check. Build the internal audit programme to surface findings before they reach external audit: monthly KRI review, quarterly targeted re-tests of specific control families, continuous monitoring through the SOC, quarterly Board IT Strategy Committee briefings. Internal audit reports to Board Audit Committee independently of the CISO/CTO.

CISO view. The audit is a forcing function; the CISO's responsibility is to make the audit boring. Pre-stage the documentation library, run quarterly self-assessments against the CSF Annex 1 controls, fix the recurring findings between audits. The CISO's KPI is not zero findings (impossible) but zero recurring findings and timely remediation of all open findings.

Common findings — the recurring pattern across 2025–26 inspections

Five findings recur:

1. Cloud assurance gap. Cloud-provider SOC 2 Type 2 accepted in lieu of bank-specific cloud configuration review. The inspector now asks for evidence that the bank itself reviewed the IAM policies, network rules, encryption configuration, and logging coverage of its cloud tenancy — not just what AWS or Azure provides.
2. VAPT depth. Findings show "VAPT performed" but the evidence is automated scan output. RBI inspectors specifically ask: "Where is the manual penetration testing? Where is the business logic testing? Where are the auth/AuthZ findings?"
3. CIMS submission discipline. Late submissions, missing submissions, or submissions that omit material details. The 6-hour clock is from internal awareness; banks often interpret this loosely.
4. Third-party risk depth for critical vendors. Core banking providers, AML/KYC providers, payment-rail providers — these are mission-critical, and self-attestation evidence is no longer accepted by RBI.
5. Patch management discipline. Patch compliance dashboards exist but exceptions never close out. SLAs are missed, root causes not analysed, and the same gaps recur quarter over quarter.

Penalty exposure

RBI's enforcement toolkit is broader than monetary penalties — but the monetary side has expanded materially:

• Monetary penalties under Section 47A of the Banking Regulation Act, 1949 (banks), Section 30 of the Payment and Settlement Systems Act, 2007 (payment system operators), Section 58G of the RBI Act (NBFCs). Recent fines in 2024–25 have ranged from ₹50 lakh to ₹5 crore per violation depending on entity size and breach severity.
• Supervisory action, including restrictions on new customer onboarding, restrictions on opening new branches, restrictions on issuing certain products. These are operationally severe and have been used recently against banks and NBFCs with cyber/IT governance failings.
• Compounding restrictions — RBI may direct the entity to pause specific business activities until remediation.
• Public disclosure — RBI publishes enforcement actions; reputational impact is significant.
• Cancellation of operating licence — for severe and persistent failures (rare but real).

For non-bank payment system operators specifically, the Cyber Resilience Master Directions 2024 increase the penalty surface; payment system licences themselves are conditional on continuing compliance.

Cross-references to adjacent frameworks

• RBI ITGRCA 2024 — covers IT governance, risk, controls, and assurance practices. CSF sits under it; ITGRCA establishes the Board-level structural requirements.
• RBI IT Outsourcing 2023 — operationally extends CSF Para 8 vendor controls and provides specific obligations for IT outsourcing arrangements.
• RBI DLG / PA-PG Directions — for digital lending and payment aggregators specifically.
• CERT-In Direction 70B — 6-hour incident reporting parallel to CIMS; KYC and log retention requirements.
• DPDPA 2023 + Rules 2025 — privacy overlay from May 13, 2027. Personal-data breach notification under DPDPA is parallel to CIMS reporting; the procedures must be coordinated.
• SEBI CSCRF 2024 — for capital markets entities; concept-equivalent to RBI CSF for SEBI-regulated entities.
• IRDAI Information and Cyber Security Guidelines 2026 — concept-equivalent for insurance entities.
• ISO/IEC 27001:2022 — establishes the security-management baseline; many CSF and ITGRCA requirements align with ISO 27001 Annex A controls. ISO 27001 certification does NOT substitute for CSF compliance but reduces audit friction.
• NIST CSF 2.0 — useful as a structural reference; RBI's framework is more prescriptive but the categories align.
• PCI DSS v4.0.1 — for entities handling payment card data; layered on top of RBI requirements.

What to do this quarter — for CISOs preparing for inspection

If RBI inspection is on the calendar within the next 6 months:

Month 1. Documentation library refresh. Cyber Security Policy version + Board approval trail + IT Strategy Committee minutes + CCMP + CCMP test report + BCP/DR test reports + VAPT reports + CIMS submissions. Gap-flag missing items.

Month 2. Internal control re-test on the five intensification themes: cloud configuration review, manual VAPT, CIMS submission discipline check, third-party assessment depth on top-5 critical vendors, patch compliance.

Month 3. Tabletop exercise covering a ransomware scenario through CCMP → CIMS submission → CERT-In submission → recovery. Document gaps and fix.

Month 4. Remediation sprint on identified gaps. Re-test critical findings.

Month 5. External pre-inspection review by independent CERT-In empanelled firm. Findings list.

Month 6. Final remediation; inspection-ready documentation; CISO–Audit Committee closed-door review of readiness.

A note on what this guide does not cover

Three areas worth separate treatment:

1. AI in banking — RBI has not yet issued AI-specific cybersecurity directions, but inspectors are starting to ask about AI use in fraud detection, customer-facing chatbots, and credit decisioning. India MeitY's IT Amendment Rules 2026 and India AI Governance Guidelines 2025 increasingly intersect.
2. Cyber insurance — RBI does not mandate it, but more banks are purchasing cyber insurance and the underwriting questionnaires (which mirror RBI controls) are useful pre-audit indicators.
3. Open Banking and Account Aggregator framework — separate set of obligations under RBI's Account Aggregator regime; intersects CSF when AA-related data flows touch the bank.

This guide is a practitioner reference for IS auditors, internal audit teams, and CISOs preparing for RBI inspection or conducting internal RBI CSF audits. It is not legal advice. Reflects RBI Master Directions on IT Governance (April 2024) and on Cyber Resilience and Digital Payment Security Controls (July 2024), and publicly available RBI guidance as of 19 May 2026. Compliance teams should validate specific obligations against current RBI circulars and counsel review.

ControlForge curates RBI CSF, ITGRCA, IT Outsourcing 2023, DLG/PA, SEBI CSCRF, IRDAI 2026, CERT-In 70B, and DPDPA as a cross-mapped framework set. The synthesis engine surfaces strictest-clause patterns across these regimes for organisations operating under multiple Indian regulators. Available at controlforge.[domain-tbd].