Information technology compliance has become a central part of RBI supervision. Banks, NBFCs, payment companies and other regulated entities depend on applications that process customer information, financial transactions and regulatory records. Weak controls over these systems can affect confidentiality, integrity, availability and the reliability of regulatory reporting. RBI’s Information Technology Governance, Risk, Controls and Assurance Practices Directions address governance, risk management, controls, assurance and business continuity requirements for applicable regulated entities.
An organisation should begin by identifying its critical information systems. These may include core banking or lending platforms, payment systems, customer onboarding applications, accounting software, regulatory reporting tools, mobile applications, data warehouses and interfaces with external service providers. Each system should have a documented owner, business purpose, data classification, risk rating and recovery requirement.
A critical application should have adequate audit and system logging capability. Logs should capture relevant user activity, administrative actions, authentication events, configuration changes, data changes, transaction events and security incidents. The purpose is not merely to collect large volumes of technical data. Logs should support accountability, investigation, operational monitoring and regulatory review.
Logging controls should be designed to preserve accuracy and reliability. System clocks should be synchronised, log records should be protected from unauthorised alteration and access to logs should be restricted. The organisation should define how long logs are retained, how they are reviewed and what events require escalation. Log retention periods should be aligned with applicable RBI directions, legal requirements, contractual duties and the organisation’s risk assessment.
Privileged access requires special attention. System administrators, database administrators, developers and infrastructure teams may have the ability to change configurations or access sensitive information. Their access should be approved, limited to business need and reviewed periodically. Shared administrator accounts should be avoided. Where technically unavoidable, compensating controls such as individual accountability, session recording and detailed activity logging should be implemented.
User access should follow a joiner, mover and leaver process. New employees should receive only the access required for their role. When an employee changes department, access should be reassessed. When employment ends, access should be revoked promptly. Periodic access reviews should be documented, and exceptions should have an owner and expiry date.
Change management is another essential requirement. Application code, databases, network configurations and security settings should not be changed without an approved process. A change record should describe the reason, risk, testing, approval, implementation plan and rollback method. Emergency changes should be reviewed after implementation. Development, testing and production environments should be separated wherever practical.
RBI-regulated entities should also maintain an incident management process. The process should explain how employees report suspected incidents, how the security team investigates, who makes escalation decisions and how evidence is preserved. Incidents involving unauthorised access, data leakage, ransomware, payment disruption or manipulation of records should be handled according to the applicable reporting and communication requirements.
Vendor and outsourcing arrangements must be included in the IT control framework. Contracts should address confidentiality, access control, incident notification, audit rights, data handling, subcontracting, business continuity and return or deletion of information. The regulated entity remains responsible for understanding the risks created by outsourced technology, even when daily operations are performed by a service provider.
Business continuity and disaster recovery should be tested rather than treated as documents prepared for inspection. The entity should identify recovery time objectives and recovery point objectives for critical systems, maintain backups and conduct periodic restoration tests. Test results, failures and corrective actions should be recorded. Backup systems should be protected from unauthorised access and, where appropriate, isolated from production environments.
The board and senior management should receive meaningful technology risk information. Reports should cover major incidents, overdue vulnerabilities, access review status, audit findings, vendor risks, recovery testing and remediation progress. Technical data should be translated into business impact so that management can make informed decisions.
