Inside a Regulatory IS Audit: What a CERT-In Empanelled Assessment Found at a Co-operative Bank

Observation: A Board-approved Cyber Security Policy and Framework was in effect and distinct from the institution's IT/Information Security Policy, as required. However, an updated policy version drafted more recently had not been through documented Board approval, leaving the institution operating against an older approved baseline while a newer, unratified version existed in parallel.

Regulatory Basis: RBI Comprehensive Cyber Security Framework for UCBs - requirement for a distinct, Board-approved Cyber Security Policy separate from general IT/IS policy.

Recommendation: Formally route all policy revisions through Board or Board-committee approval before treating them as effective; maintain a single authoritative, version-controlled policy register; and document approval dates and resolution numbers for every policy revision cycle.

Observation: A Board-approved Cyber Crisis Management Plan (CCMP) existed, but did not align with the guidance issued by CERT-In, NCIIPC and RBI, nor with prevailing industry best practice. The plan lacked defined incident-reporting procedures, including notification requirements to the regulator's Department of Co-operative Bank Supervision.

Regulatory Basis: RBI Cybersecurity Framework requirement to reference CERT-In, NCIIPC and RBI/IDRBT guidance in crisis management planning; mandatory incident reporting circular.

Recommendation: Rebuild the CCMP against current CERT-In and NCIIPC templates; define explicit escalation paths, response roles and regulator notification timelines (including the required 6-hour CERT-In reporting window where applicable); and rehearse the plan through tabletop exercises at least annually.

Observation: No Chief Information Security Officer (CISO) or formally designated official responsible for information security policy formulation and enforcement had been appointed. No clear point of contact existed for staff to escalate security concerns.

Regulatory Basis: RBI Cybersecurity Framework requirement that security concerns be routed to appropriately designated officials to enable rapid organisational response.

Recommendation: Formally designate a CISO or equivalent accountable security leadership role (proportionate to institution size, which may be a part-time or shared function for smaller UCBs); publish an internal escalation contact for security concerns; and define the role's reporting line to the Board or a Board-level committee.

Observation: No evidence was available confirming that the Board of Directors conducted or documented quarterly reviews of the institution's cybersecurity posture, as required under the applicable RBI circular on Board-level reviews.

Regulatory Basis: RBI Calendar of Reviews - mandatory quarterly Board or Board-committee review of cybersecurity posture for UCBs.

Recommendation: Institutionalise a standing quarterly cybersecurity agenda item at Board or Board-committee meetings; maintain formal minutes documenting the review, key metrics discussed, and any resulting action items; and retain this documentation as ongoing audit evidence.

Observation: The Core Banking Solution (CBS) application operated over HTTPS with TLS 1.2 encryption for data-in-transit. However, the underlying production database containing sensitive customer information was not encrypted at rest, leaving stored customer data exposed to potential interception in the event of unauthorised database-level access.

Regulatory Basis: RBI Cybersecurity Framework requirement to preserve confidentiality, integrity and availability of customer data across its lifecycle, whether at rest or in transit.

Recommendation: Implement transparent data encryption (TDE) or equivalent at-rest encryption for the production database; extend encryption key management to a dedicated key management system; and review database access logs for anomalous query patterns as a compensating control until encryption is deployed.

Observation: The institution's Cyber Crisis Management Plan did not prescribe procedures for mandatory incident reporting to the regulator's supervisory department, including required notification content and channels, despite this being an explicit regulatory requirement regardless of whether an incident has yet occurred.

Regulatory Basis: RBI requirement for immediate reporting of all unusual cybersecurity incidents - successful or attempted - to the Department of Co-operative Bank Supervision.

Recommendation: Embed a documented incident-reporting workflow directly into the CCMP, specifying exact notification recipients, required information fields, and maximum reporting timelines; assign named backup owners for the reporting function to avoid single points of failure.

Observation: An IT asset inventory register was maintained covering the data centre, disaster recovery site, head office and branch locations. However, the register did not capture whether each asset stored customer data, the asset's criticality classification, or an approved software inventory - all mandated fields under the framework.

Regulatory Basis: RBI requirement for an up-to-date business IT asset inventory including customer-data indicators, associated business applications, and criticality ratings.

Recommendation: Extend the asset register schema to include data-sensitivity flags, criticality ratings and linked business applications; automate inventory discovery where feasible rather than relying solely on manual spreadsheet maintenance; and review the register on a defined periodic cycle.

Observation: No centralised, up-to-date inventory of authorised software, applications and libraries existed across endpoints and servers, limiting the institution's ability to detect or prevent unauthorised software installation systematically.

Regulatory Basis: RBI requirement to maintain a centralised inventory of authorised software as a baseline control against unauthorised application use.

Recommendation: Deploy an application allow-listing or software asset management tool integrated with the existing endpoint protection platform; establish a formal software approval workflow before any new application is deployed to production endpoints.

Observation: The perimeter firewall had Intrusion Prevention System (IPS) capability enabled with current signatures, tuned rules restricting traffic to required services and ports, and log integration with a syslog server. However, review identified 17 zero-hit firewall rules - configured rules never actually matching live traffic - indicating that the monthly rule-review process claimed by the institution was not being applied with full rigour.

Regulatory Basis: RBI requirement that critical device configurations, including firewalls, be evaluated periodically and maintained at the highest appropriate security level.

Recommendation: Formalise the firewall rule-review process with documented sign-off; remove or justify every zero-hit rule identified; and implement automated rule-usage reporting to make stale-rule identification continuous rather than dependent on periodic manual review.

Observation: The institution's documented password policy mandated a minimum eight-character, complex password with a defined expiry cycle. However, the Core Banking Solution's actual password configuration enforced only a six-character minimum - falling short of the institution's own documented policy, let alone regulatory expectation, on the single most business-critical application in scope.

Regulatory Basis: RBI requirement for complex, lengthy passwords and avoidance of trivial credentials, particularly for systems supporting financial transactions.

Recommendation: Reconfigure the CBS application's password policy to match or exceed the institution's documented standard immediately; conduct a policy-versus-configuration audit across all critical systems, not just CBS, to catch similar drift; and consider passwordless or FIDO2-based authentication for administrative access where the application supports it.

Observation: A SIEM platform was deployed with dozens of agents covering servers, databases and network devices, with custom detection rules configured and actively monitored. However, disaster recovery site devices and branch/head office endpoints had not yet been integrated into the SIEM, leaving a meaningful visibility gap outside the primary data centre.

Regulatory Basis: RBI requirement for centralised systems to allow, manage, log and monitor privileged and administrative access to critical systems.

Recommendation: Extend SIEM agent coverage to disaster recovery infrastructure and endpoint devices as a priority; define and document a formal senior-management approval workflow for granting privileged access, rather than relying on informal IT-team practice; and schedule periodic access-entitlement reviews against role-based, least-privilege principles.

Observation: Email authentication protocols (DMARC, DKIM, SPF) were correctly configured and enforced on the institution's mail domain, providing solid protection against spoofing and basic phishing. However, no controls existed to detect or block look-alike or homoglyph domains impersonating the institution's brand.

Regulatory Basis: RBI requirement for secure mail and messaging systems that prevent spoofing, identical mail domains, and malicious attachment or link delivery.

Recommendation: Implement look-alike domain monitoring to detect newly registered domains mimicking the institution's brand; extend email security controls to cover partner and vendor communication channels; and layer attachment sandboxing on top of existing DMARC/DKIM/SPF enforcement.

Observation: A training session had been conducted and attendance recorded in a training register, but no supporting evidence documented the training content or awareness materials used, making it impossible to verify whether core topics such as phishing recognition and incident reporting were actually covered. No structured awareness initiatives existed for vendors or third-party service providers at all.

Regulatory Basis: RBI requirement for a high level of cybersecurity awareness among staff, Board, Top Management, customers, vendors and other concerned parties.

Recommendation: Retain training materials and session content alongside attendance records as standard practice; establish a formal, recurring awareness curriculum covering phishing, incident reporting and secure data handling; and extend awareness obligations contractually to critical vendors and service providers.

Observation: Daily backups of the core banking database were performed to a dedicated machine, with database replication to the disaster recovery site occurring at short intervals. However, offline backups - copies detached from the network after creation - were not being taken, and backups were reported as performed on an as-needed basis rather than a formally defined, auditable schedule.

Regulatory Basis: RBI requirement for periodic backup of important data, stored offline, as protection against destructive incidents including ransomware that can compromise network-connected backup copies.

Recommendation: Implement a defined offline (or immutable, air-gapped) backup schedule alongside existing online replication; document backup frequency, retention and restoration-testing procedures formally; and conduct periodic restoration drills to validate recoverability rather than assuming backup success from job logs alone.

Observation: Master Service Agreements with critical vendors - including the core banking application provider and payment switch vendor - were not made available for review. Where an SLA with an IT infrastructure vendor was reviewed, it included an appropriate "right to audit" clause, but no evidence existed of background verification, non-disclosure agreements, or periodic performance reviews for vendor personnel with access to critical systems and customer data.

Regulatory Basis: RBI requirement for comprehensive risk assessment, due diligence, oversight and contractual audit rights over outsourced vendors and service providers, including background verification of vendor personnel accessing critical assets.

Recommendation: Centralise and formally maintain all critical vendor agreements with security, audit-rights, grievance-redressal, and background-verification clauses; institute a periodic (at minimum annual) vendor security review cycle; and require signed NDAs and BGV clearance evidence for any third-party personnel with system or data access.

The RBI's Comprehensive Cyber Security Framework for UCBs is a graded, tiered set of cybersecurity requirements that scales with an institution's size and business complexity. It covers governance (Board-approved cyber security policy, organisational arrangements, security awareness), technical baseline controls (network security, access control, secure configuration, patch and antivirus management), incident response and reporting, and vendor/outsourcing risk management. It works alongside RBI's Calendar of Reviews circular, which mandates periodic Board-level review of cybersecurity posture, and sector-specific fraud-prevention advisories.

CERT-In (the Indian Computer Emergency Response Team) maintains an official empanelment list of auditing organisations and individual auditors recognised as qualified to conduct information security audits for regulated entities. Being CERT-In empanelled - and having individual auditors listed in CERT-In's published snapshot - gives an audit report regulatory standing and credibility. Many RBI-regulated entities, including UCBs, are expected to engage empanelled auditors for IS audit and VAPT exercises.

A VAPT engagement tests for exploitable technical vulnerabilities in specific systems. A red team engagement simulates a realistic adversary across the broader attack surface. An IS audit is broader still: it evaluates governance, documentation, policy enforcement, operational process and technical controls together against a defined regulatory or standards framework (in this case, the RBI Cybersecurity Framework and ISO/IEC 27001:2022), producing a compliance rating for each individual control rather than a list of exploitable vulnerabilities. Many regulated institutions require both a VAPT/IS audit for compliance purposes and periodic red teaming for realistic attack-readiness testing.

This is a common pattern across mid-sized financial institutions. Technical controls - firewalls, antivirus, patch management, email authentication - are typically procured and deployed by IT teams as discrete projects with clear vendors and clear success criteria. Governance controls - Board review cadence, dedicated security leadership, documented policy enforcement, vendor due diligence - require sustained organisational discipline and senior stakeholder time, which is harder to sustain without a formally accountable owner. The absence of a designated CISO in this engagement is itself a partial explanation for why governance controls lagged behind technical ones.

A Cyber Crisis Management Plan (CCMP) is the institution's documented playbook for detecting, responding to, and recovering from a cybersecurity incident, including defined escalation paths and regulatory notification procedures. In this engagement, a CCMP existed and had Board approval - but it did not align with CERT-In, NCIIPC and RBI guidance, and critically, did not define the specific incident-reporting workflow to the regulator's supervisory department. A plan that exists on paper but doesn't meet the specific content requirements of the governing framework, or doesn't function operationally when tested, does not satisfy the compliance requirement.

Network-connected replication (such as database replication between a primary data centre and a DR site) protects against hardware failure and site-level outages, but it does not protect against threats that propagate across connected systems - most notably ransomware, which can encrypt or corrupt data at both the primary and replicated copy if both remain network-accessible. Offline (or immutable/air-gapped) backups are a specifically required, distinct control precisely because they remain recoverable even when online systems, including replication targets, are compromised.

RBI-regulated entities, including UCBs, are typically expected to undergo IS audits and VAPT exercises on at least an annual (and in some cases half-yearly, particularly for VAPT of DMZ-facing systems) basis, alongside the mandated quarterly Board-level cybersecurity posture review. Follow-up review of prior audit findings - to confirm corrective actions were actually implemented, not just committed to - should occur at the next audit cycle at minimum, and ideally on an interim basis for high-severity findings.

This engagement was conducted on-site over five working days, combining interviews, document review, technical system assessment and walkthroughs across governance, technical and operational domains, followed by report drafting, internal quality review, and final release. Duration scales with the number of sites, systems and vendor relationships in scope, and whether the audit is combined with a fresh VAPT exercise rather than relying on a recently completed one.

Yes. In addition to serving regulated institutions across major Indian cities - Bangalore, Mumbai, Delhi NCR, Noida, Chennai, Hyderabad, Pune, Kolkata, Ahmedabad and Kochi - ISECURION delivers ISO/IEC 27001, SOC 2 readiness, and broader regulatory compliance audit engagements for organisations in the United States, United Kingdom, the European Union, the GCC region, Singapore and Australia, alongside India-specific frameworks such as RBI and CERT-In requirements for Indian-regulated entities and their international subsidiaries.

1. Present the findings formally to the Board or an appropriate Board-level committee, with the risk profile of each finding clearly communicated.
2. Prioritise remediation using an impact-based roadmap rather than attempting to fix every finding simultaneously - customer-data and fraud-risk items first, documentation and governance-cadence items on a defined but slightly longer timeline.
3. Assign named owners and target dates for every finding, and track progress centrally rather than leaving remediation informally distributed across IT staff.
4. Retain evidence of remediation actions as they are completed, in a form that will satisfy the next audit cycle without requiring reconstruction after the fact.
5. Schedule a follow-up review, ideally before the next full audit cycle, to confirm high-priority findings have been genuinely closed rather than only planned.