Introduction: The RBI Co-operative Bank Cyber Security Framework
Urban Co-operative Banks (UCBs) sit at the heart of India's community and small-business banking, yet for years they operated with materially weaker cyber controls than their commercial-bank peers. Recognising this asymmetry, and following a series of cyber incidents affecting smaller banks, the Reserve Bank of India (RBI) issued a graded, proportionate cyber security framework specifically for Primary (Urban) Co-operative Banks. This guide is written for boards, CISOs, IT heads, internal auditors and CERT-In empanelled assessors who must implement, operate and independently certify a UCB against that framework.
The anchor circular is DoS.CO/CSITE/BC.4083/31.01.052/2019-20 dated 31 December 2019, titled 'Comprehensive Cyber Security Framework for Primary (Urban) Co-operative Banks (UCBs) - A Graded Approach'. It is reinforced by the earlier RBI Advisory on Basic Cyber Security Controls for Primary (Urban) Co-operative Banks issued in October 2018, and by the technology-vision and outsourcing guidance RBI has published for the co-operative sector. Together these define a four-level graded model in which a UCB's control obligations scale with the digital products it offers and its transaction footprint.
This deep-dive translates the framework into an auditor-grade assessment methodology and an implementer's remediation blueprint. It enumerates every control area across all four levels, states exactly what an assessor should verify, the typical evidence a UCB must produce, a phased implementation approach, a maturity model, evidence-request lists, roles, KPIs, common gaps and mappings to allied frameworks (RBI SAR/Master Direction on IT Governance, CERT-In directions, NPCI/UPI mandates, UIDAI AUA/KUA obligations and ISO 27001).
Source and copyright note
This is an original CyberSigma interpretation. The RBI framework text, circulars and Annexes are the copyright of the Reserve Bank of India and are reproduced here only as short paraphrased references and control identifiers for assessment purposes. Always work from the current circular DoS.CO/CSITE/BC.4083/31.01.052/2019-20 and its Annexes I-IV, plus subsequent RBI Master Directions, as the authoritative source. Control counts and level thresholds are indicative and must be confirmed against the live circular at the time of assessment.
What is the UCB Cyber Framework
The UCB Cyber Security Framework is a graded, risk-proportionate set of cyber security baseline controls that RBI mandates for every Primary (Urban) Co-operative Bank in India. Unlike the single, uniform framework RBI issued for scheduled commercial banks in June 2016 (DBS.CO/CSITE/BC.11/33.01.001/2015-16), the UCB framework recognises that co-operative banks vary enormously in size, digital sophistication and risk. It therefore places each UCB into one of four levels and prescribes a progressively deeper control set as the level rises.
Level I is a mandatory baseline that applies to ALL UCBs regardless of size. Levels II, III and IV add successively more demanding controls (network security, application security, secure configuration, anti-phishing, digital signatures, incident response, Security Operations Centre integration, forensics readiness, cyber crisis management, and independent assurance) for banks that offer digital delivery channels, participate in payment systems or sub-member arrangements, or provide internet/mobile banking with fund-transfer capability.
- Graded, not one-size-fits-all: obligations scale with digital footprint and product risk.
- Board-owned: the framework requires board and top-management ownership of cyber risk, not delegation solely to IT.
- Baseline-plus-incremental: Level I controls are non-negotiable for every UCB; higher levels are additive.
- Incident-reporting mandate: unusual cyber security incidents must be reported to RBI (and CERT-In) within a defined window.
- Assurance-driven: higher levels require independent vulnerability assessment, penetration testing and IS audit.
Who must comply
Every Primary (Urban) Co-operative Bank licensed by RBI is in scope for at least Level I. The specific level is determined by the bank's digital depth. The table below summarises the graded applicability. Note that a UCB may be placed at a higher level than its asset size alone would suggest if it offers higher-risk digital products; the level is driven by product/channel risk, not merely balance-sheet size.
| Level | Illustrative applicability | Nature of obligation |
|---|---|---|
| Level I | All UCBs, including the smallest, offering only basic services (branch banking, RTGS/NEFT sub-membership through a sponsor, ATM cards) | Mandatory baseline cyber security controls (Annex I) |
| Level II | UCBs offering additional digital channels such as own ATM networks, SMS/basic mobile alerts, or acting as sub-members in payment systems | Level I plus incremental controls (Annex II) |
| Level III | UCBs providing internet banking (view/limited), mobile banking, and participating more actively in payment/settlement systems | Level I + II plus further controls (Annex III) |
| Level IV | UCBs offering the full suite - internet/mobile banking with fund transfer, own payment aggregation, hosted/critical applications, direct RTGS/NEFT membership | All controls including advanced assurance and SOC/forensics readiness (Annex IV) |
- In-scope entities: all Primary (Urban) Co-operative Banks, single-state and multi-state, scheduled and non-scheduled.
- Determination of level: self-assessment by the bank, validated by RBI supervision, based on the digital products, delivery channels and payment-system participation offered.
- Third parties: managed service providers, data centres, cloud/hosting vendors, ATM switch operators, mobile/internet banking application vendors and UPI/BBPS technology service providers inherit applicable controls via outsourcing governance.
- Boards and top management are explicitly accountable; the framework is not satisfiable by IT alone.
Structure of the UCB Cyber Framework
The framework is organised as a graded set of control families delivered through Annexes I to IV. Level I (Annex I) defines the mandatory baseline of roughly 20-25 basic cyber security controls. Each higher level adds control families. The following table maps the principal control domains that recur across the Annexes and shows the level at which each becomes mandatory. Use it as the domain skeleton for the master assessment checklist that follows.
| Domain / control family | Introduced at | Focus |
|---|---|---|
| Cyber security policy and board oversight | Level I | Board-approved policy distinct from the IT policy; ownership and reporting |
| Inventory of business IT assets | Level I | Hardware, software, network and information asset register with criticality |
| Preventing execution of unauthorised software | Level I | Application whitelisting / control over installed software |
| Environmental and physical controls | Level I | Secure server room, power, access control to IT infrastructure |
| Network management and security | Level I / II | Firewalls, network segmentation, secure configuration, wireless controls |
| Secure configuration / baseline hardening | Level II | Documented baseline configurations for OS, DB, network devices |
| Anti-virus and patch/vulnerability management | Level I / II | Endpoint protection, timely patching, VA cadence |
| User access control and authentication | Level I | Least privilege, unique IDs, strong authentication, privileged access |
| Secure mail and messaging | Level II | Email security, anti-phishing, DMARC/SPF where applicable |
| Removable media and data leakage controls | Level II | USB/media policy, DLP for higher levels |
| Application security lifecycle | Level III | Secure SDLC, application VA/PT, source-code assurance for critical apps |
| Vendor / outsourcing risk management | Level II / III | Due diligence, contracts, right-to-audit, service-provider controls |
| Incident response and reporting to RBI/CERT-In | Level I | IR plan, escalation, reporting unusual incidents to RBI within timeline |
| Business continuity and disaster recovery | Level II / III | BCP/DR plan, DR drills, recovery objectives |
| Digital signatures / non-repudiation | Level III | Digital signatures for critical transactions (e.g., RTGS/NEFT files) |
| Security Operations / monitoring and log management | Level III / IV | Centralised logging, monitoring, SOC integration |
| Forensic readiness and advanced assurance | Level IV | Forensic capability, cyber crisis management, red-team / advanced PT |
| User / staff awareness and training | Level I | Cyber hygiene awareness for staff, management and board |
| Customer education and protection | Level I / II | Awareness on phishing, safe banking, grievance handling |
Master assessment checklist
This is the core of the guide. It enumerates every control family across all four levels with, for each, what an assessor must verify and the typical evidence a UCB must present. Assess Level I for all banks, then apply the higher-level tables according to the bank's determined level. Each control should be rated Compliant / Partially Compliant / Non-Compliant / Not Applicable with a documented rationale and a remediation owner and target date.
1. Board oversight and cyber security policy (Level I)
| What to verify | Typical evidence |
|---|---|
| A board-approved cyber security policy exists, separate and distinct from the IT/IS policy | Board resolution, dated cyber security policy document with version control |
| The policy is reviewed at least annually and after major changes | Review minutes, revision history, sign-off |
| Cyber risk is a standing agenda item for the board / IT sub-committee | Board / committee meeting minutes showing cyber discussion |
| Roles for CISO/IT-security officer and reporting lines are defined | Organisation chart, appointment/designation letter, JD |
| Budget and resources for cyber security are sanctioned | Approved budget, procurement records |
2. Inventory of business IT assets (Level I)
| What to verify | Typical evidence |
|---|---|
| A complete, up-to-date inventory of hardware, software, network devices and information assets exists | Asset register with owner, location, criticality and end-of-life status |
| Each asset has an assigned owner and criticality classification | Register fields for owner and business criticality |
| Unauthorised / rogue devices are detected and removed | Network scan reports, reconciliation logs |
| Licensed and supported software only; end-of-support software is tracked and remediated | Licence records, EoL/EoS tracker, remediation plan |
| Inventory is reconciled periodically | Reconciliation reports with dates and sign-off |
3. Preventing execution of unauthorised software (Level I/II)
| What to verify | Typical evidence |
|---|---|
| Controls prevent installation/execution of unauthorised software on critical systems | Application whitelisting config, admin-rights policy |
| Users lack local administrator rights on standard workstations | Group policy / endpoint config, privileged-account list |
| A documented list of approved software is maintained | Approved software baseline |
| Deviations are detected and alerted | Endpoint management / EDR reports |
4. Environmental and physical security (Level I)
| What to verify | Typical evidence |
|---|---|
| Server room / data centre has restricted physical access | Access control system logs, biometric/card records |
| Environmental controls (UPS, fire suppression, cooling, water/smoke detection) are present and tested | AMC records, test logs, maintenance certificates |
| Physical access to network and IT infrastructure is logged and reviewed | Visitor register, access review minutes |
| CCTV coverage of critical areas is retained per policy | CCTV retention policy, footage availability check |
5. Network management and security (Level I/II)
| What to verify | Typical evidence |
|---|---|
| Perimeter firewalls exist with a documented, reviewed rule base | Firewall configuration, rule-review reports |
| Network is segmented (e.g., branch, DC, DMZ, payment zones separated) | Network architecture diagram, VLAN/segmentation config |
| Wireless networks are secured or disabled on the corporate/payment network | WLAN config, WPA2/enterprise auth evidence |
| Remote access is via secure VPN with MFA | VPN config, MFA logs |
| Intrusion detection/prevention deployed at higher levels | IDS/IPS deployment and alert samples |
6. Secure configuration and baseline hardening (Level II)
| What to verify | Typical evidence |
|---|---|
| Documented secure baseline configurations exist for OS, databases, and network devices | Hardening baseline documents (e.g., CIS-aligned) |
| Default passwords and unnecessary services are removed | Configuration review, service-hardening evidence |
| Configuration compliance is periodically scanned | Config-compliance scan reports |
| Change to baseline follows change management | Change tickets, approvals |
7. Anti-virus, patch and vulnerability management (Level I/II)
| What to verify | Typical evidence |
|---|---|
| Endpoint anti-virus/anti-malware is deployed, current and centrally managed | AV console reports, signature currency |
| Critical security patches are applied within defined SLAs | Patch management reports, SLA definition |
| Vulnerability assessments are conducted at the mandated cadence | VA scan reports and remediation tracker |
| High/critical vulnerabilities are remediated and re-tested | Closure evidence, re-scan reports |
8. User access control and authentication (Level I)
| What to verify | Typical evidence |
|---|---|
| Every user has a unique ID; no shared/generic accounts on critical systems | User master, account listing |
| Access follows least privilege and role-based access | Role matrix, access-grant approvals |
| Privileged accounts are inventoried, controlled and monitored | Privileged-account register, PAM/monitoring logs |
| Strong authentication (and MFA for remote/privileged access) is enforced | Password policy, MFA configuration |
| Periodic user access reviews and prompt de-provisioning of exits | Access-review reports, HR-IT exit reconciliation |
9. Secure mail, messaging and anti-phishing (Level II)
| What to verify | Typical evidence |
|---|---|
| Email gateway filters spam, malware and phishing | Mail-security config, quarantine reports |
| Anti-spoofing (SPF/DKIM/DMARC) configured for the bank domain where applicable | DNS records, DMARC reports |
| Staff receive anti-phishing awareness and simulated tests at higher levels | Training records, phishing-simulation results |
10. Removable media and data leakage prevention (Level II)
| What to verify | Typical evidence |
|---|---|
| USB/removable media use is restricted or controlled on critical systems | Endpoint media-control policy and config |
| Sensitive data handling and classification rules exist | Data classification policy |
| DLP controls deployed for higher levels | DLP policy and incident reports |
11. Application security lifecycle (Level III)
| What to verify | Typical evidence |
|---|---|
| Secure SDLC is followed for in-house and vendor applications | SDLC policy, security requirements in SRS |
| Application VA/PT performed before go-live and periodically for critical apps (internet/mobile banking) | App VA/PT reports and closure evidence |
| Source-code / third-party assurance obtained for critical applications | Code-review or vendor assurance certificates |
| Web/mobile apps follow OWASP-aligned secure coding | Secure-coding standards, test evidence |
12. Vendor and outsourcing risk management (Level II/III)
| What to verify | Typical evidence |
|---|---|
| Due diligence performed before onboarding IT/security service providers | Vendor risk assessments |
| Contracts include security, confidentiality, right-to-audit and RBI inspection clauses | Signed agreements/SLAs |
| Fourth-party / sub-contracting is disclosed and controlled | Vendor dependency map |
| Vendor performance and security posture reviewed periodically | Vendor review reports, SOC reports where applicable |
| Data residency and RBI outsourcing guidelines complied with | Data-location attestations |
13. Incident response and reporting to RBI/CERT-In (Level I)
| What to verify | Typical evidence |
|---|---|
| A documented cyber incident response plan with roles and escalation exists | IR plan, contact matrix |
| Unusual cyber security incidents are reported to RBI within the mandated timeline | Incident-reporting records, RBI acknowledgement |
| Incidents are also reported to CERT-In per the CERT-In directions (6-hour rule) | CERT-In reporting evidence, log-retention proof |
| Incidents are analysed for root cause and lessons are applied | Post-incident reports, corrective actions |
| IR plan is tested / tabletop exercised at higher levels | Drill reports |
14. Business continuity and disaster recovery (Level II/III)
| What to verify | Typical evidence |
|---|---|
| A BCP/DR plan with defined RTO/RPO for critical systems exists | BCP/DR document with recovery objectives |
| DR site / arrangement is available for critical applications | DR infrastructure evidence, DC-DR replication |
| DR drills are conducted periodically and results acted upon | DR drill reports, gap closure |
| Backups are taken, secured and restoration-tested | Backup logs, restore-test evidence |
15. Digital signatures and non-repudiation (Level III)
| What to verify | Typical evidence |
|---|---|
| Digital signatures are used for authorising critical transactions (e.g., RTGS/NEFT batch files) | DSC usage records, token inventory |
| Maker-checker and non-repudiation controls exist for high-value transactions | Workflow config, transaction logs |
| Straight-through processing controls prevent unauthorised amendment | STP controls evidence |
16. Logging, monitoring and SOC integration (Level III/IV)
| What to verify | Typical evidence |
|---|---|
| Security-relevant logs are captured and centrally retained | Log-management/SIEM config, retention policy |
| Logs from critical systems, payment channels and perimeter are monitored | SIEM use-case list, alert samples |
| SOC (in-house or managed) monitoring is in place for higher levels | SOC contract/runbook, monitoring reports |
| Clocks are synchronised (NTP) for reliable forensics | NTP configuration |
17. Forensic readiness and advanced assurance (Level IV)
| What to verify | Typical evidence |
|---|---|
| Forensic readiness / evidence-preservation procedures exist | Forensic SOP, chain-of-custody templates |
| A cyber crisis management plan (CCMP) is in place and tested | CCMP document, exercise reports |
| Advanced/red-team penetration testing performed for critical channels | Advanced PT reports |
| Threat intelligence is consumed and acted upon | TI subscription and action logs |
18. Staff awareness and customer education (Level I)
| What to verify | Typical evidence |
|---|---|
| Cyber security awareness delivered to staff, management and board | Training calendar, attendance, board-briefing records |
| Customers educated on phishing, safe internet/mobile banking and grievance channels | Awareness collateral, website notices, SMS campaigns |
| A defined mechanism handles customer-reported fraud/complaints | Grievance-handling records, TAT reports |
Scoping the assessment
Scoping for a UCB engagement begins by fixing the bank's graded level, then bounding the systems, channels and third parties that fall within it. An assessor must confirm the level determination itself, because an under-declared level is one of the most common findings.
- Confirm the graded level (I-IV) against the actual products/channels offered: branch banking, ATMs, internet banking (view vs fund transfer), mobile banking, UPI/BBPS, RTGS/NEFT membership status.
- Enumerate critical applications: core banking system (CBS), internet/mobile banking, ATM switch, UPI/payment interfaces, reconciliation and treasury systems.
- Map delivery channels and their trust boundaries (branch LAN, WAN, DC, DR, DMZ, payment zones, vendor connectivity).
- Identify all third parties: CBS/ASP vendor, data-centre/hosting provider, managed security service provider, ATM switch operator, sponsor bank for sub-membership.
- Fix the assessment period, sampling approach (branches, servers, users) and the evidence cut-off date.
- Record explicit exclusions (e.g., Level IV controls where the bank is validly at Level II) with justification.
Implementation approach
A UCB should implement the framework in phases, sequencing the mandatory Level I baseline first, then layering higher-level controls in line with its digital roadmap. The following phases give activities and deliverables.
Phase 1 - Governance and gap assessment
- Activities: constitute board ownership; appoint/confirm CISO or IT-security officer; adopt a board-approved cyber security policy distinct from IT policy; determine the graded level; run a baseline gap assessment against the applicable Annex.
- Deliverables: board resolution and cyber security policy; level-determination note; gap-assessment report with risk-rated findings and a remediation roadmap.
Phase 2 - Baseline (Level I) remediation
- Activities: build asset inventory; enforce unique IDs, least privilege and MFA for privileged/remote access; deploy endpoint AV and patching; harden physical/environmental controls; stand up an incident response plan and RBI/CERT-In reporting process; deliver staff awareness.
- Deliverables: asset register; access-control matrix; patch/AV reports; IR plan with contact matrix; awareness records.
Phase 3 - Channel and network security (Levels II/III)
- Activities: segment networks and harden firewalls; deploy secure baselines; implement email security and anti-phishing; enable removable-media/DLP controls; formalise vendor/outsourcing governance; establish BCP/DR with drills; introduce digital signatures for critical transactions.
- Deliverables: network architecture and segmentation design; hardening baselines; vendor risk register; BCP/DR plan and drill reports; DSC deployment records.
Phase 4 - Monitoring, assurance and advanced controls (Levels III/IV)
- Activities: implement centralised logging and SOC (in-house or managed); conduct application VA/PT for internet/mobile banking; build forensic readiness and a cyber crisis management plan; run advanced/red-team testing; integrate threat intelligence.
- Deliverables: SIEM/SOC runbooks; VA/PT and closure reports; CCMP; forensic SOP; TI action logs.
Phase 5 - Independent audit and continual improvement
- Activities: commission independent IS audit / cyber security assessment (CERT-In empanelled where required); remediate findings; report posture to the board; feed into the next annual review cycle.
- Deliverables: independent assessment report; board posture report; corrective action plan; updated policy and controls.
Maturity / capability model
While the RBI framework is compliance-graded rather than formally maturity-scored, assessors benefit from expressing each control's implementation as a maturity level to communicate residual risk to the board and to prioritise remediation. The following five-level model is recommended for reporting.
| Level | Label | Description | Typical characteristics |
|---|---|---|---|
| 0 | Absent | Control not implemented | No policy, no evidence, ad hoc practices |
| 1 | Initial | Control exists informally | Undocumented, person-dependent, inconsistent |
| 2 | Defined | Control documented and approved | Policy/procedure exists, partial implementation |
| 3 | Managed | Control operating and monitored | Consistent execution, evidence retained, periodic review |
| 4 | Optimised | Control automated and continually improved | Metrics-driven, automated monitoring, integrated with SOC and risk reporting |
Assessment and audit approach
The following ordered steps describe an auditor-grade assessment of a UCB against the framework, culminating in a board-ready report and, where mandated, an independent certification suitable for RBI supervision.
- Initiation and level confirmation: agree scope, confirm the graded level against products/channels, and gather the applicable Annex control set.
- Documentation review: examine the cyber security policy, IR plan, BCP/DR, asset inventory, prior VA/PT and audit reports.
- Control walkthroughs and interviews: interview the CISO/IT head, network/DB admins, branch operations and the board/IT committee secretary.
- Technical validation: review firewall/network configs, hardening baselines, access controls, patch/AV status, logging and MFA; corroborate with sampled system evidence.
- Vulnerability assessment and penetration testing: conduct/validate VA/PT for internet/mobile banking and perimeter as applicable to the level.
- Third-party and outsourcing review: assess vendor contracts, right-to-audit, data location and service-provider security posture.
- Incident and reporting review: verify incident logs and evidence of timely reporting to RBI and CERT-In.
- Rating and gap analysis: rate each control (Compliant/Partial/Non-Compliant/NA) with maturity and risk rating.
- Reporting: issue an executive summary, detailed findings, evidence references and a prioritised remediation roadmap with owners and dates.
- Closure and re-test: validate remediation of high/critical findings and issue the final assurance opinion for board and RBI submission.
Evidence request list
Request the following, grouped by domain, ahead of fieldwork. Providing these in a structured evidence pack accelerates the assessment and reduces open findings.
- Governance: board-approved cyber security policy; board/IT-committee minutes; CISO appointment; cyber budget approvals.
- Asset and configuration: hardware/software/network inventory; hardening baselines; config-compliance scans; EoL/EoS tracker.
- Access control: user master and role matrix; privileged-account register; MFA configuration; access-review and exit-reconciliation reports.
- Network and endpoint: firewall rule base and reviews; network architecture diagram; AV console and patch reports; VPN/MFA logs.
- Application security: SDLC policy; application VA/PT reports and closure; secure-coding standards.
- Vendor/outsourcing: signed contracts/SLAs with right-to-audit and RBI clauses; vendor risk assessments; SOC reports.
- Incident and continuity: incident register; RBI and CERT-In reporting evidence; IR plan; BCP/DR plan and drill/restore-test reports.
- Monitoring: SIEM/log-management config; retention policy; SOC runbooks/reports; NTP configuration.
- Awareness: staff training records; phishing-simulation results; customer-education collateral.
- Assurance: prior IS audit / VA-PT reports; RBI inspection observations and compliance status.
Roles and responsibilities
| Role | Key responsibilities |
|---|---|
| Board of Directors | Approve cyber security policy, own cyber risk appetite, review posture, sanction budget |
| IT / IT-Strategy Sub-committee | Oversee implementation, review VA/PT and audit findings, monitor remediation |
| CEO / Top Management | Ensure resourcing, drive culture, accountable for framework adoption |
| CISO / IT-Security Officer | Design and operate controls, incident response, RBI/CERT-In reporting, awareness |
| IT / Network / DB Administrators | Implement hardening, patching, access control, monitoring and backups |
| Internal Auditor / IS Audit | Independent verification of controls and evidence, report to audit committee |
| Business / Branch Operations | Enforce maker-checker, physical security, customer education, incident escalation |
| Third-party Service Providers | Deliver contracted security controls, support audits and incident response |
KPIs to track
- Percentage of Level-applicable controls assessed Compliant.
- Number and ageing of open high/critical vulnerabilities against SLA.
- Patch compliance percentage for critical systems within SLA.
- Mean time to detect and mean time to respond to security incidents.
- Percentage of privileged accounts under MFA and periodic review.
- Incident-reporting timeliness to RBI and CERT-In (within mandated windows).
- DR drill success rate and backup restore-test success rate.
- Staff awareness coverage and phishing-simulation failure rate trend.
- Vendor assessments completed on schedule; contracts with right-to-audit clause.
- Percentage of critical applications with current VA/PT closure.
Readiness checklist
- Board-approved cyber security policy, distinct from IT policy, is in place and reviewed annually.
- Graded level (I-IV) is correctly determined and documented.
- Complete, reconciled inventory of IT and information assets exists.
- Unique user IDs, least privilege and MFA for privileged/remote access are enforced.
- Endpoint AV and timely patching are operating on all critical systems.
- Networks are segmented and firewalls have a reviewed rule base.
- Secure baseline configurations are documented and monitored (Level II+).
- Incident response plan exists and RBI/CERT-In reporting process is tested.
- BCP/DR plan with RTO/RPO is documented and drills are conducted (Level II/III+).
- Application VA/PT is performed for internet/mobile banking (Level III+).
- Centralised logging and SOC monitoring are in place (Level III/IV).
- Vendor/outsourcing contracts include security, confidentiality and right-to-audit clauses.
- Staff and customer awareness programmes are active with records.
- Independent IS audit / cyber assessment has been completed and findings remediated.
Common gaps
- Level under-declaration: bank operates internet/mobile banking but self-assesses at a lower level, understating obligations.
- No distinct cyber security policy: cyber controls buried in a generic IT policy without board approval.
- Incomplete asset inventory and untracked end-of-support software.
- Shared/generic administrator accounts and absence of MFA on privileged and remote access.
- Flat networks with no segmentation between branch, DC and payment zones.
- Weak patch and vulnerability management; high/critical findings left open beyond SLA.
- Late or missing incident reporting to RBI and non-compliance with CERT-In 6-hour rule and log retention.
- No DR drills or untested backups; RTO/RPO undefined for critical systems.
- Weak vendor governance: no right-to-audit clause, undisclosed sub-contracting, unclear data location.
- Absent or ineffective logging/monitoring, preventing detection and forensics.
- Awareness treated as a tick-box exercise with no phishing simulation or board briefing.
UCB Cyber Framework mapped to other frameworks
The UCB framework overlaps substantially with allied Indian regulatory mandates and international standards. The mapping below helps a UCB reuse control evidence and rationalise a single audit programme.
| UCB control domain | RBI commercial-bank / Master Direction | CERT-In / other mandate | ISO 27001:2022 reference |
|---|---|---|---|
| Board oversight and policy | RBI 2016 cyber framework; Master Direction on IT Governance, Risk & Assurance (Nov 2023) | - | A.5 Organisational controls / Clause 5 Leadership |
| Asset inventory | IT Governance MD - asset management | - | A.5.9 Inventory of assets |
| Access control and MFA | 2016 framework - access management | - | A.5.15-A.5.18 Access control |
| Network and secure configuration | 2016 framework - network security | - | A.8.20-A.8.22 Network security |
| Vulnerability and patch management | 2016 framework - VA/PT cadence | - | A.8.8 Management of technical vulnerabilities |
| Application security | 2016 framework - secure SDLC | - | A.8.25-A.8.28 Secure development |
| Incident response and reporting | 2016 framework - incident reporting to RBI | CERT-In Directions 28 Apr 2022 (6-hour reporting, log retention) | A.5.24-A.5.28 Incident management |
| Logging and monitoring | SOC / monitoring guidance | CERT-In log-retention (180 days) | A.8.15-A.8.16 Logging and monitoring |
| Business continuity / DR | 2016 framework - BCP/DR | - | A.5.29-A.5.30 / A.8.13 Continuity |
| Payment-channel security | 2016 framework - digital channels | NPCI/UPI and BBPS security guidelines | A.8 controls for online services |
| Aadhaar-based authentication (where used) | RBI KYC guidance | UIDAI AUA/KUA and Aadhaar data-vault requirements | A.5.34 Privacy and PII protection |
| Vendor / outsourcing | RBI outsourcing of IT services (Apr 2023) | - | A.5.19-A.5.23 Supplier relationships |
How CyberSigma helps
CyberSigma is a CERT-In empanelled cyber security auditor and PCI QSA firm with deep experience across India's co-operative banking sector. We help UCBs determine their correct graded level, run a gap assessment against Annexes I-IV, and deliver a prioritised, board-ready remediation roadmap. Our teams design network segmentation, hardening baselines, access-control and MFA, logging/SOC integration and BCP/DR; conduct application and infrastructure VA/PT for internet and mobile banking; and operationalise RBI and CERT-In incident reporting. We then provide the independent IS audit / cyber security assessment required for higher levels and RBI supervision, along with continuous-assurance retainers. Talk to CyberSigma to move your UCB from graded compliance to durable cyber resilience.
Frequently asked questions
What level applies to my UCB?
RBI grades requirements by the UCB’s digital footprint and level; the applicable Basic or Comprehensive (graded) framework is determined by that classification.
Official documents
CyberSigma resources
Need help with UCB Cyber Framework?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.