Introduction: The RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices
On 7 November 2023 the Reserve Bank of India (RBI) issued the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (Reference DoS.CO.CSITEG/SEC.7/31.01.015/2023-24), which came into force with effect from 1 April 2024. This Master Direction consolidates, updates and supersedes a range of earlier circulars and the seminal recommendations of the Gopalakrishna Working Group (2011) on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds. It is the single, board-anchored rulebook that tells a Regulated Entity (RE) how to govern technology, manage IT and cyber risk, operate day-to-day IT controls, and independently assure that all of this actually works.
The Master Direction is principle-plus-prescription in style. It fixes accountability at the very top, the Board of Directors, and then cascades responsibility through an IT Strategy Committee (ITSC), an IT Steering Committee, a Head of IT (or CTO), a Chief Information Security Officer (CISO), and independent IT/IS audit. It deliberately covers the full technology lifecycle: strategy, sourcing, project delivery, change and patch management, capacity, cryptography, business continuity, data governance, third-party and outsourcing risk, information security operations, and the independent assurance that closes the loop. This guide is an auditor-grade, control-by-control deep-dive intended to help a compliance, IT-audit or CISO team read the Direction the way an assessor reads it, prepare evidence, and remediate gaps.
What is the RBI IT Governance MD
The RBI IT Governance Master Direction (referred to here as the RBI IT Governance MD) is a mandatory, enforceable direction issued under the powers conferred on the Reserve Bank by the Banking Regulation Act 1949, the Reserve Bank of India Act 1934, and the relevant NBFC and payment-system statutes. Unlike a guidance note or advisory, a Master Direction is binding; non-compliance can attract supervisory action, monetary penalty, and adverse comment in the RBI's risk-based supervision (SPARC / SREP-equivalent) assessment.
Structurally, the Direction is organised into chapters covering: (i) IT Governance, (ii) IT Infrastructure and Services Management, (iii) IT and Information Security Risk Management, (iv) Business Continuity and Disaster Recovery Management, and (v) Information Systems (IS) Audit. It requires a Board-approved IT governance framework, a documented IT and information security risk-management framework, defined roles for the ITSC, IT Steering Committee, CISO and Head of IT, and an annual, independent IS audit whose findings are placed before the Board or its Audit Committee (ACB).
A closely related instrument, the Master Direction on Outsourcing of Information Technology Services (dated 10 April 2023, effective 1 October 2023), governs how REs outsource IT and cloud services. Assessors routinely read the two together because outsourcing and cloud controls are explicitly cross-referenced. Where relevant, this guide flags those intersections.
- Nature: Mandatory Master Direction, not advisory guidance.
- Anchor: Board of Directors is ultimately accountable; cannot be fully delegated.
- Scope of control: Governance, infrastructure and service management, IT and IS risk, BCP/DR, and IS audit.
- Effective date: 1 April 2024 (issued 7 November 2023).
- Supersedes: Gopalakrishna Working Group guidelines and multiple legacy IT/IS circulars.
- Enforcement: Supervisory action, penalties, and adverse RBI supervisory rating on non-compliance.
Who must comply
The Direction applies to a defined universe of Regulated Entities (REs). Applicability is broad but proportionate; smaller and less complex entities are expected to implement controls commensurate with their size, nature and complexity, while larger banks face the full expectation set. The following table summarises applicability.
| Regulated Entity category | Applicability and notes |
|---|---|
| Scheduled Commercial Banks (excluding Regional Rural Banks) | Fully applicable. Highest expectation for governance committees, CISO independence and IS audit maturity. |
| Small Finance Banks and Payments Banks | Fully applicable, with proportionality for scale but no exemption from core governance and security controls. |
| Local Area Banks | Applicable; proportionate implementation permitted. |
| Primary (Urban) Co-operative Banks (UCBs) | Applicable in a graded manner based on the RBI four-tier UCB categorisation; smaller UCBs get proportionate timelines and reduced committee requirements. |
| Non-Banking Financial Companies (NBFCs) in Top / Upper / Middle Layers | Applicable under the Scale-Based Regulation framework; Base Layer NBFCs are broadly outside the full scope but should follow the spirit. |
| Credit Information Companies (CICs) | Applicable. |
| EXIM Bank, NABARD, NaBFID, NHB, SIDBI (All-India Financial Institutions) | Applicable. |
| Regional Rural Banks (RRBs) | Explicitly excluded from this Master Direction (governed separately). |
| Third parties and IT service providers | Not directly regulated, but bound through outsourcing contracts; the RE remains fully accountable for their compliance. |
Structure of the RBI IT Governance MD (domains, chapters and control families)
The Direction is organised into five substantive chapters plus a preliminary chapter. Each chapter contains control families that an assessor treats as discrete testable areas. The table below maps the chapter structure to the control families and the indicative paragraph clusters.
| Chapter / domain | Control families covered | Indicative focus |
|---|---|---|
| Ch. I — Preliminary | Short title, applicability, definitions, effective date | Scope-setting; who is an RE; key terms (RE, third party, ITSC). |
| Ch. II — IT Governance | Board oversight, ITSC, IT Steering Committee, Head of IT / CTO, IT governance framework, strategy and policy | Roles, committee charters, IT strategy alignment, MIS to Board. |
| Ch. III — IT Infrastructure and Services Management | IT services management, physical and environmental controls, capacity management, project management, change and patch management, cryptography, SDLC, network and endpoint, data centre and DR site, API and digital channels, audit trails and logging | Day-to-day build-and-run controls across the technology estate. |
| Ch. IV — IT and Information Security Risk Management | IT risk framework, information security policy and function, CISO mandate, identity and access management, cyber risk, vulnerability and threat management, cyber-crisis management, metrics | Risk identification, information security operations, and the CISO function. |
| Ch. V — Business Continuity and Disaster Recovery | BCP policy, BIA, RTO/RPO, DR strategy and drills, resilience testing | Availability, recoverability and operational resilience. |
| Ch. VI — Information Systems (IS) Audit | IS audit charter, competency, coverage, planning, reporting to ACB, follow-up | Independent assurance over all of the above. |
Master assessment checklist
This is the core of the guide. Each control family below carries a short scope note, a testing table (What to verify / Typical evidence), and where useful a callout. An assessor should be able to walk the entire estate using these tables without skipping any control area. Do not treat any single row as optional; proportionality changes depth, not existence.
IG-1: Board oversight and accountability
The Board of Directors owns the IT governance framework. The Board approves the IT strategy, the IT and information security risk appetite, and the annual IS audit plan, and reviews IT-risk MIS at defined intervals.
| What to verify | Typical evidence |
|---|---|
| The Board has approved an IT governance framework covering strategy, risk, controls and assurance. | Board resolution; approved IT governance framework document with version and date. |
| The Board (or a designated committee) reviews IT and cyber risk MIS at least quarterly. | Board / committee minutes; MIS dashboards tabled; attendance registers. |
| Board-approved IT strategy is aligned to business strategy and reviewed periodically. | IT strategy document; alignment mapping to business plan; review minutes. |
| IT and information security risk appetite / tolerance is Board-approved. | Risk appetite statement; approval trail. |
IG-2: IT Strategy Committee (ITSC) of the Board
The ITSC is a Board-level committee chaired by an independent director with substantial IT expertise, meeting at least quarterly. It advises the Board on IT strategy, oversees major IT investments and monitors IT risk.
| What to verify | Typical evidence |
|---|---|
| ITSC exists with a Board-approved charter and defined membership. | ITSC charter; constitution resolution; member list. |
| Chairperson is an independent director with substantial IT expertise; members have adequate IT/IS competence. | Director profiles; skills matrix; expertise declaration. |
| ITSC meets at least once per quarter with quorum. | Meeting calendar; minutes; attendance and quorum records. |
| ITSC reviews IT strategy, budgets, major projects and IT risk posture. | Minutes evidencing review of strategy, project portfolio and risk MIS. |
IG-3: IT Steering Committee (executive)
An executive-level IT Steering Committee assists the ITSC and management with prioritisation, project oversight, resource allocation and status reporting.
| What to verify | Typical evidence |
|---|---|
| IT Steering Committee is constituted with senior business, IT and risk representation. | Constitution note; membership including CIO, CISO, business heads. |
| Committee oversees project prioritisation, delivery status, budgets and issue escalation. | Minutes; project status packs; escalation logs. |
| Committee reports material matters upward to the ITSC. | Escalation records; ITSC minutes referencing steering committee input. |
IG-4: Head of IT / CTO and IT organisation
A sufficiently senior official (Head of IT or CTO) is responsible for IT operations, service delivery and implementation of the IT strategy, with adequate skilled resources.
| What to verify | Typical evidence |
|---|---|
| A designated Head of IT / CTO with defined role, seniority and mandate exists. | Appointment letter; role description; organisation chart. |
| IT function is adequately resourced with skilled personnel and succession planning. | Staffing plan; skills matrix; training records; succession plan. |
| Segregation of duties between IT operations, development and information security is maintained. | SoD matrix; role definitions; access reviews. |
ITSM-1: IT service management and operations
IT services are managed to defined SLAs with documented processes for incident, problem, service-request and configuration management.
| What to verify | Typical evidence |
|---|---|
| Documented IT service management processes (incident, problem, request, configuration) exist and are followed. | ITSM policy; process documents; ITSM tool records. |
| Service levels and availability targets are defined and monitored for critical services. | SLA/OLA documents; availability reports; SLA breach logs. |
| A configuration management database (CMDB) or asset inventory of IT assets is maintained and current. | CMDB extract; asset register; reconciliation reports. |
ITSM-2: Physical, environmental and data centre controls
Data centres and critical facilities have physical access controls, environmental protection (power, cooling, fire) and monitoring; DR site controls mirror the primary.
| What to verify | Typical evidence |
|---|---|
| Physical access to data centres is restricted, logged and periodically reviewed. | Access control logs; badge/biometric records; access review reports. |
| Environmental controls (UPS, generator, HVAC, fire suppression, water/smoke detection) are in place and tested. | Maintenance logs; test certificates; environmental monitoring dashboards. |
| DR / secondary site has controls commensurate with the primary data centre. | DR site audit; comparative control checklist. |
ITSM-3: Capacity management
Capacity of compute, storage, network and application resources is forecast and managed to meet current and projected demand, including transaction growth.
| What to verify | Typical evidence |
|---|---|
| Capacity is monitored and forecast against business growth and peak-load scenarios. | Capacity plans; utilisation trend reports; forecasting models. |
| Thresholds and alerts exist to trigger capacity augmentation ahead of exhaustion. | Monitoring configuration; alert logs; augmentation change records. |
| Historical capacity-related incidents are analysed and remediated. | Incident records; RCA; capacity uplift evidence. |
ITSM-4: Project management and SDLC
IT projects follow a defined project-management methodology and a secure software development lifecycle (SDLC) with security requirements, secure coding, testing and approvals at each gate.
| What to verify | Typical evidence |
|---|---|
| A project management framework governs IT project initiation, approval, delivery and closure. | PMO methodology; project charters; stage-gate approvals. |
| SDLC embeds security requirements, secure coding standards and independent testing (SAST/DAST). | SDLC policy; secure coding standard; SAST/DAST reports. |
| Segregation between development, test and production environments is enforced. | Environment architecture; access controls; promotion approvals. |
| User acceptance and security sign-off precede production deployment. | UAT sign-offs; security clearance; go-live approvals. |
ITSM-5: Change and patch management
Changes to production are authorised, tested, risk-assessed and recorded; security patches are applied within risk-based timelines with emergency-change controls.
| What to verify | Typical evidence |
|---|---|
| All production changes are raised, risk-assessed, approved and recorded through a change process. | Change management policy; change tickets; CAB minutes. |
| Emergency changes follow a defined expedited-but-controlled path with post-facto approval. | Emergency change records; post-implementation review. |
| Security patches are applied within risk-tiered SLAs; exceptions are tracked and approved. | Patch policy with SLAs; patch compliance reports; exception register. |
| Unauthorised or failed changes are detected and remediated. | Reconciliation of changes vs approvals; rollback records. |
ITSM-6: Cryptography and key management
Cryptographic controls protect data at rest and in transit; key generation, storage, rotation and destruction follow a documented key-management standard, ideally using HSMs.
| What to verify | Typical evidence |
|---|---|
| A cryptography policy defines approved algorithms, key lengths and protocols; weak/deprecated ciphers are prohibited. | Cryptography policy; approved algorithm list; TLS configuration scans. |
| Cryptographic keys are managed across their lifecycle (generation, distribution, rotation, revocation, destruction). | Key management standard; key inventory; rotation logs. |
| Hardware Security Modules (HSMs) protect high-value keys where required. | HSM inventory; FIPS/BIS certification; access controls. |
| Sensitive data is encrypted at rest and in transit as per data classification. | Encryption configuration; data-flow diagrams; scan evidence. |
ITSM-7: Network, endpoint and infrastructure security
Networks are segmented and defended; endpoints are hardened and protected; secure baseline configurations apply across the estate.
| What to verify | Typical evidence |
|---|---|
| Network is segmented (DMZ, internal, PCI/CDE zones) with firewalls and rule reviews. | Network diagrams; firewall rule base; periodic rule-review reports. |
| Endpoints are hardened to a baseline and protected with EDR/anti-malware. | Hardening standards; configuration compliance reports; EDR coverage. |
| Secure configuration baselines exist for OS, database, middleware and network devices. | CIS-style baselines; configuration compliance scans. |
| Intrusion detection/prevention and DDoS protection are deployed for internet-facing services. | IDS/IPS configuration; DDoS mitigation contracts; test evidence. |
ITSM-8: Audit trails, logging and monitoring
Systems generate tamper-resistant audit trails; logs are centralised, retained per policy and monitored for security events.
| What to verify | Typical evidence |
|---|---|
| Critical systems produce audit trails capturing user, action, timestamp and outcome. | Sample audit logs; logging configuration. |
| Logs are centralised (SIEM), integrity-protected and retained for the required period. | SIEM inventory; log retention policy; integrity controls. |
| Security events are correlated, alerted and triaged 24x7 (SOC). | SOC use-cases; alert and incident tickets; roster. |
| Privileged and administrative activity is logged and independently reviewed. | PAM logs; privileged-access review records. |
ITSM-9: Digital channels, APIs and payment systems
Internet/mobile banking, UPI, cards and open APIs carry additional controls for authentication, transaction integrity, fraud monitoring and secure integration.
| What to verify | Typical evidence |
|---|---|
| Digital channels enforce strong (multi-factor) authentication and secure session management. | Authentication design; MFA configuration; session controls. |
| APIs are secured (authentication, authorisation, throttling, input validation) and inventoried. | API gateway configuration; API inventory; security test reports. |
| Real-time fraud and transaction-monitoring controls are operational for payment channels. | Fraud rule engine configuration; alert and case records. |
| Alignment with applicable payment-system directions (UPI, cards) is maintained. | Compliance mapping; NPCI/PA-PG certifications where relevant. |
RM-1: IT and information security risk-management framework
A Board-approved framework identifies, assesses, treats and monitors IT and information-security risks, integrated with the enterprise risk-management (ERM) function.
| What to verify | Typical evidence |
|---|---|
| A documented IT/IS risk-management framework and methodology exists and is Board-approved. | Risk framework document; approval trail. |
| A current IT/IS risk register captures risks with owners, ratings and treatment plans. | Risk register; treatment plans; residual-risk ratings. |
| Risk assessments are performed for new systems, changes and third parties. | Assessment reports; change-linked risk assessments. |
| Key risk indicators (KRIs) are defined, monitored and escalated. | KRI dashboard; threshold breaches; escalation records. |
RM-2: Information security policy and function
A comprehensive, Board-approved information security policy and a dedicated information security function govern the security programme, reviewed at least annually.
| What to verify | Typical evidence |
|---|---|
| A Board-approved information security policy suite exists and is reviewed at least annually. | Policy set; approval and review records. |
| An independent information security function is established, separate from IT operations. | Organisation chart; reporting lines; function charter. |
| Security awareness training is delivered to staff and tracked. | Training calendar; completion reports; phishing-simulation results. |
RM-3: Chief Information Security Officer (CISO)
A senior-level CISO with a fixed minimum tenure heads the information security function, reports independently of the CIO/Head of IT, and places security reports before the Board/ITSC.
| What to verify | Typical evidence |
|---|---|
| A CISO of sufficient seniority is appointed with a defined, adequate tenure. | Appointment letter; role charter; tenure terms. |
| The CISO reports independently of IT operations (not under the CIO/Head of IT). | Reporting-line chart; independence declaration. |
| The CISO presents periodic security posture and incident reports to the Board/ITSC. | Board/ITSC minutes; CISO reports tabled. |
| The CISO has adequate budget, authority and resources. | Security budget; team structure; authority matrix. |
RM-4: Identity and access management (IAM)
Access follows least-privilege and need-to-know, with a full joiner-mover-leaver lifecycle, periodic recertification, and strong controls over privileged accounts.
| What to verify | Typical evidence |
|---|---|
| Access is provisioned on least-privilege via an approval workflow; role-based access is defined. | IAM policy; access-request tickets; RBAC matrix. |
| Joiner-mover-leaver processes revoke access promptly; leaver access is disabled within SLA. | JML records; terminated-user access checks. |
| Access rights are recertified periodically by data/system owners. | Recertification campaigns; sign-off records. |
| Privileged access is managed via PAM with vaulting, session recording and just-in-time elevation. | PAM inventory; session recordings; privileged-account list. |
| MFA is enforced for remote, administrative and privileged access. | MFA configuration; enforcement reports. |
RM-5: Vulnerability, threat and cyber-risk management
Vulnerabilities are identified through scanning and penetration testing and remediated on risk-based timelines; threat intelligence feeds the security programme.
| What to verify | Typical evidence |
|---|---|
| Regular vulnerability assessments and periodic penetration tests are conducted (including for internet-facing assets). | VA schedule; VA/PT reports; scope coverage. |
| Vulnerabilities are risk-rated and remediated within defined SLAs; exceptions tracked. | Remediation tracker; SLA compliance; exception register. |
| Threat intelligence and CERT-In advisories are consumed and actioned. | TI subscriptions; advisory-action logs. |
| Application security testing is performed before major releases. | AppSec test reports; release-gate evidence. |
RM-6: Cyber incident and crisis management
A documented incident-response and cyber-crisis-management plan defines detection, containment, eradication, recovery and mandatory regulatory reporting, including CERT-In and RBI timelines.
| What to verify | Typical evidence |
|---|---|
| An incident-response plan with severity classification, roles and playbooks exists and is tested. | IR plan; playbooks; tabletop/simulation records. |
| Cyber incidents are reported to RBI within the prescribed window and to CERT-In within 6 hours. | Incident register; RBI/CERT-In reporting evidence; timestamps. |
| A cyber-crisis-management plan (CCMP) addresses major incidents and communications. | CCMP document; crisis-drill records. |
| Post-incident reviews capture root cause and lessons learned. | PIR reports; corrective-action tracking. |
BCP-1: Business continuity policy and business impact analysis
A Board-approved business continuity policy and a current business impact analysis (BIA) identify critical processes, dependencies and recovery objectives.
| What to verify | Typical evidence |
|---|---|
| A Board-approved BCP policy and BCM programme exist and are reviewed periodically. | BCP policy; programme charter; review minutes. |
| A current BIA identifies critical business processes, dependencies and maximum tolerable downtime. | BIA report; process criticality ratings; dependency maps. |
| Recovery objectives (RTO and RPO) are defined for critical systems and approved. | RTO/RPO register; approval trail. |
BCP-2: Disaster recovery, drills and resilience testing
A DR strategy provides recoverability within defined RTO/RPO, tested through realistic drills, including near-live failover for critical systems.
| What to verify | Typical evidence |
|---|---|
| A DR site and strategy support recovery of critical systems within RTO/RPO. | DR architecture; replication configuration; RTO/RPO validation. |
| DR drills are conducted periodically, including unannounced or live failover for critical systems. | DR drill plans; drill reports; failover evidence. |
| Drill results are analysed; gaps are remediated and objectives re-validated. | Drill outcome analysis; remediation tracker. |
| Resilience of critical outsourced/cloud services is included in continuity testing. | Vendor DR test results; exit/portability testing. |
OS-1: Third-party and IT outsourcing / cloud risk
Where IT services are outsourced (including cloud), the RE remains fully accountable. Due diligence, contractual controls, concentration-risk management, right-to-audit, and exit strategies apply, aligned with the Master Direction on Outsourcing of IT Services.
| What to verify | Typical evidence |
|---|---|
| Due diligence and risk assessment precede onboarding of IT/cloud service providers. | Due-diligence reports; vendor risk assessments. |
| Contracts include security, data-localisation, audit rights, SLAs, breach notification and exit clauses. | Executed contracts; clause mapping. |
| Concentration risk from key providers/cloud is identified and managed. | Concentration analysis; contingency plans. |
| RBI/RE right-to-audit and access to service-provider records is preserved and exercised. | Audit-right clauses; vendor audit reports. |
| A documented exit and data-portability strategy exists for critical services. | Exit plan; portability testing; data-return evidence. |
DG-1: Data governance, classification and localisation
Data is classified, protected across its lifecycle, and stored in accordance with RBI data-localisation requirements (notably for payment-system data).
| What to verify | Typical evidence |
|---|---|
| A data classification scheme is defined and applied to sensitive/customer data. | Classification policy; data inventory; labelling evidence. |
| Data-protection controls (encryption, DLP, masking) align to classification. | DLP configuration; encryption evidence; masking in non-prod. |
| Payment-system and other regulated data is stored in India as required. | Data-residency architecture; localisation compliance report. |
| Data retention and secure disposal follow policy and legal requirements. | Retention schedule; secure-disposal records. |
AUD-1: Information Systems (IS) audit
An independent IS-audit function (or competent external auditors) audits the IT and information-security control environment at least annually, reporting to the Audit Committee of the Board (ACB).
| What to verify | Typical evidence |
|---|---|
| An IS-audit charter and risk-based annual IS-audit plan approved by the ACB exist. | IS-audit charter; approved annual plan. |
| IS auditors are independent and possess adequate IT/security competency (e.g., CISA/DISA). | Auditor profiles; certifications; independence declarations. |
| IS-audit coverage spans governance, infrastructure, security, BCP/DR and outsourcing. | Audit scope; coverage matrix; workpapers. |
| Findings are reported to the ACB with severity ratings and tracked to closure. | IS-audit reports; ACB minutes; remediation tracker. |
Scoping
Scoping determines which entities, systems and processes fall within an RBI IT Governance MD assessment. Because the Direction is enterprise-wide, scoping is less about carving out exclusions and more about ensuring nothing critical is missed and that proportionality is correctly applied.
- Entity scope: The RE itself, plus wholly-owned IT subsidiaries and captive service providers that operate critical systems.
- System scope: Core banking, payment systems, digital channels, treasury, risk/AML systems, supporting infrastructure, and DR environments.
- Third-party scope: Outsourced and cloud services in scope through the outsourcing framework; the RE remains accountable end-to-end.
- Data scope: Customer, transaction, payment and other regulated data, including data held by service providers.
- Proportionality: Depth of committee structure, testing frequency and documentation is calibrated to the RE's tier, size and complexity.
- Out of scope: Regional Rural Banks (governed separately) and Base Layer NBFCs for the full-scope obligations, though good practice is encouraged.
Implementation approach
A phased programme reduces risk and produces board-defensible evidence. The following four phases move from diagnosis to sustained assurance.
Phase 1 — Governance foundation and gap assessment (Weeks 1-6)
- Activities: Establish/refresh ITSC and IT Steering Committee charters; confirm CISO reporting independence; perform a control-by-control gap assessment against all six chapters; build a consolidated finding register.
- Deliverables: Committee charters and constitution resolutions; gap-assessment report with severity ratings; prioritised remediation roadmap approved by the ITSC.
Phase 2 — Policy and framework remediation (Weeks 6-16)
- Activities: Draft/refresh the IT governance framework, IT/IS risk-management framework, information security policy suite, BCP/DR policy and outsourcing policy; align to data-classification and cryptography standards.
- Deliverables: Board-approved policy and framework set; risk register with owners; updated SoD and RBAC matrices; approved risk appetite statement.
Phase 3 — Control build and operationalisation (Weeks 12-32)
- Activities: Implement or uplift technical controls (SIEM/SOC, PAM, MFA, patch SLAs, VA/PT cadence, DR drills, key management); operationalise change/patch and IAM lifecycle; run awareness training and phishing simulations.
- Deliverables: Operating controls with evidence trails; DR drill and VA/PT reports; SOC use-cases live; training completion metrics.
Phase 4 — Independent assurance and continuous monitoring (Ongoing / annual)
- Activities: Conduct the annual IS audit; report to the ACB; track findings to closure; embed KRI/KPI monitoring and periodic Board MIS; refresh the programme annually.
- Deliverables: IS-audit report and ACB minutes; closed-finding evidence; KPI dashboards; annual programme-refresh sign-off.
Maturity and capability model
The Direction does not mandate a formal maturity scale, but assessors and boards benefit from one to benchmark progress. The following five-level model maps typical states of the RBI IT Governance MD control environment.
| Level | Descriptor | Characteristics |
|---|---|---|
| Level 1 | Initial / Ad hoc | Controls exist informally; no ITSC or independent CISO; reactive security; minimal documentation. |
| Level 2 | Developing | Committees constituted and policies drafted, but inconsistent execution; partial risk register; sporadic testing. |
| Level 3 | Defined | Full committee structure operating; policies approved and applied; IAM, change and patch processes documented and followed; annual IS audit in place. |
| Level 4 | Managed | Controls measured via KRIs/KPIs; SOC operational; DR drills validated; findings tracked to closure; risk-based prioritisation embedded. |
| Level 5 | Optimised | Continuous improvement; automation of controls and evidence; threat-informed defence; board-level analytics; resilience regularly validated including for third parties. |
Assessment and audit approach
An RBI IT Governance MD assessment follows a disciplined sequence so that conclusions are evidence-based and defensible before the ACB and, ultimately, the RBI supervisory team.
- Define scope and objectives: Confirm entities, systems, third parties and applicable proportionality tier; agree the assessment charter with the ACB.
- Collect governance evidence: Obtain committee charters, minutes, policies, frameworks and appointment records.
- Walkthrough and control design review: Assess whether each control family is designed to meet the Direction's intent.
- Operating-effectiveness testing: Sample changes, access recertifications, patch compliance, incident records, DR drills and VA/PT reports.
- Technical validation: Review configurations, SIEM/PAM/MFA, encryption and network segmentation; corroborate with scans.
- Third-party and cloud review: Test outsourcing due diligence, contracts, audit rights and exit plans.
- Gap analysis and risk rating: Rate each finding by severity and residual risk; map to specific chapters/clauses.
- Reporting: Produce an assessment report and management summary; present to the ITSC and ACB.
- Remediation and follow-up: Agree owners and timelines; track findings to closure; re-test critical items.
- Continuous assurance: Feed results into KRIs/KPIs and the annual IS-audit cycle.
Evidence request list
The following categorised list is what an assessor typically requests up front. Providing complete, versioned and dated evidence accelerates the assessment materially.
- Governance: IT governance framework; ITSC and IT Steering Committee charters and minutes; Board/ACB minutes; IT strategy; organisation charts and reporting lines.
- Roles: CISO and Head of IT appointment letters and mandates; SoD and RBAC matrices; skills and training records.
- Risk and security: IT/IS risk framework and register; information security policy suite; KRI dashboards; risk appetite statement.
- Infrastructure and operations: ITSM process docs; CMDB/asset inventory; capacity plans; change and patch policies with compliance reports; configuration baselines and scan results.
- Access: IAM policy; access-request and recertification records; JML evidence; PAM inventory and session logs; MFA configuration.
- Security operations: SIEM/SOC use-cases and alerts; VA/PT reports; threat-intelligence action logs; incident register with RBI/CERT-In reporting evidence.
- Cryptography and data: Cryptography and key-management policy; HSM inventory; data classification and DLP evidence; data-localisation architecture; retention and disposal records.
- Continuity: BCP policy; BIA; RTO/RPO register; DR drill and failover reports.
- Outsourcing and cloud: Due-diligence reports; executed contracts with clause mapping; concentration analysis; vendor audit reports; exit and portability plans.
- Assurance: IS-audit charter and annual plan; IS-audit reports; ACB minutes; remediation trackers.
Roles and responsibilities
| Role | Primary responsibilities under the RBI IT Governance MD |
|---|---|
| Board of Directors | Ultimate accountability; approves IT governance framework, strategy, risk appetite and IS-audit plan; reviews IT/cyber risk MIS. |
| IT Strategy Committee (ITSC) | Board-level oversight of IT strategy, major investments and IT risk; chaired by an independent director with IT expertise; meets at least quarterly. |
| Audit Committee of the Board (ACB) | Approves the IS-audit charter and plan; receives IS-audit reports; oversees remediation. |
| IT Steering Committee | Executive prioritisation, project oversight, resource allocation and escalation to the ITSC. |
| Head of IT / CTO | Delivers IT strategy and operations; ensures service management, capacity, change and infrastructure controls. |
| Chief Information Security Officer (CISO) | Heads information security independently of IT operations; owns security policy, risk, incident response and Board security reporting. |
| Chief Risk Officer / ERM | Integrates IT and IS risk into enterprise risk management; monitors KRIs and risk appetite. |
| IS Audit / Internal Audit | Provides independent assurance over the IT and security control environment; reports to the ACB. |
| Business and data owners | Own data classification, access recertification and business-continuity requirements for their processes. |
| Third-party / service providers | Deliver contracted services under RE oversight; comply with security, audit-right and data obligations. |
KPIs to track
- Percentage of critical vulnerabilities remediated within SLA.
- Patch compliance rate for critical systems (target near 100 percent within tier SLAs).
- Mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.
- Percentage of privileged accounts under PAM with session recording.
- Access-recertification completion rate and count of orphaned/stale accounts.
- Number of overdue IS-audit findings and average days to closure.
- DR drill success rate against RTO/RPO for critical systems.
- Percentage of staff completing security awareness training and phishing-simulation failure rate.
- Change success rate and count of unauthorised or failed production changes.
- Percentage of critical third parties with completed due diligence, audit rights and exit plans.
- Number of incidents reported to RBI/CERT-In within mandated timelines versus total reportable.
- Board/ITSC MIS coverage: percentage of scheduled reviews completed on time.
Readiness checklist
- Board has approved the IT governance framework, IT strategy and IT/IS risk appetite.
- ITSC constituted, chaired by an independent director with IT expertise, meeting at least quarterly.
- IT Steering Committee operational with defined membership and escalation to the ITSC.
- CISO appointed with adequate tenure and reporting independent of IT operations.
- IT/IS risk-management framework and current risk register in place.
- Information security policy suite approved and reviewed within the last 12 months.
- IAM lifecycle (JML), periodic recertification, PAM and MFA operational.
- Change and patch management enforced with risk-based SLAs and exception tracking.
- Cryptography and key-management standard implemented with HSMs for high-value keys.
- SIEM/SOC operational with 24x7 monitoring and privileged-activity review.
- VA/PT programme running on a defined cadence with SLA-based remediation.
- Incident-response and cyber-crisis plans tested; RBI and CERT-In reporting paths proven.
- BCP/BIA current with defined RTO/RPO and validated DR drills including live failover for critical systems.
- Outsourcing/cloud due diligence, contracts, audit rights and exit plans in place.
- Data classification, protection and localisation controls implemented.
- Independent IS audit conducted annually with findings tracked to closure at the ACB.
Common gaps
- CISO reporting into the CIO/Head of IT, undermining the required independence.
- ITSC lacking an independent director with genuine IT expertise, or meeting less than quarterly.
- IT/IS risk register that is stale, incomplete, or disconnected from enterprise risk management.
- Patch SLAs defined on paper but not met in practice for legacy or high-availability systems.
- Privileged access not vaulted under PAM; shared admin accounts without session recording.
- Access recertification skipped or rubber-stamped; orphaned accounts of leavers left active.
- DR drills that are tabletop-only or planned, without near-live failover of critical systems.
- Incident reporting to RBI/CERT-In missing the mandated timelines or lacking timestamped evidence.
- Outsourcing contracts missing audit-right, data-localisation, breach-notification or exit clauses.
- Weak or deprecated TLS/cipher configurations despite an approved cryptography policy.
- IS-audit findings without a closed-loop remediation tracker at the ACB.
- Insufficient logging or log-integrity controls, hampering forensic investigation.
RBI IT Governance MD mapped to other frameworks
The Direction is deliberately consistent with international standards, which lets REs reuse existing control work. The mapping below is indicative and should be validated control-by-control before relying on it for certification.
| RBI IT Governance MD area | ISO/IEC 27001:2022 | NIST CSF 2.0 | PCI DSS v4.0 | COBIT 2019 |
|---|---|---|---|---|
| IT governance and Board oversight | Clauses 5, 9.3 (leadership, management review) | GOVERN (GV) | Requirement 12 (governance/policy) | EDM, APO01 |
| IT/IS risk management | Clause 6.1; A.5.7 | IDENTIFY (ID.RA) | Requirement 12.3 (risk analysis) | APO12 |
| Information security policy and CISO | A.5.1, A.5.2 | GV.RR, GV.PO | Requirement 12.1 | APO13 |
| Identity and access management | A.5.15-A.5.18, A.8.2-A.8.5 | PROTECT (PR.AA) | Requirements 7, 8 | DSS05 |
| Change and patch management | A.8.9, A.8.32; A.8.8 | PROTECT (PR.PS), ID.RA | Requirements 6.3, 11.3 | BAI06, BAI07 |
| Cryptography and key management | A.8.24 | PROTECT (PR.DS) | Requirements 3, 4 | DSS05, DSS06 |
| Logging, monitoring and SOC | A.8.15, A.8.16 | DETECT (DE.CM, DE.AE) | Requirement 10 | DSS01, DSS05 |
| Vulnerability and threat management | A.8.8 | ID.RA, PR.PS | Requirement 11 | DSS05 |
| Incident and crisis management | A.5.24-A.5.28 | RESPOND (RS), RECOVER (RC) | Requirement 12.10 | DSS02, DSS03 |
| Business continuity and DR | A.5.29, A.5.30 | RECOVER (RC.RP) | Requirement 12.10.1 | DSS04 |
| Outsourcing / cloud and third-party risk | A.5.19-A.5.23 | GV.SC (Supply Chain) | Requirement 12.8, 12.9 | APO09, APO10 |
| Data governance and classification | A.5.9-A.5.14 | PR.DS, GV.OC | Requirements 3, 9.4 | APO14, DSS06 |
| IS audit and independent assurance | Clause 9.2 (internal audit) | GV.OV (Oversight) | Requirement 11.4, 12.11 | MEA02, MEA03 |
Frequently asked questions
Need help with RBI IT Governance MD?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.