One argument from CISOs and IT heads at Nepali banks and financial institutions goes like this: "We already comply with the NRB IT Guidelines. ISO 27001 is an additional cost for a certificate we don't strictly need." That argument was defensible for years. It is much harder to defend now.
In March 2025, Nepal Rastra Bank amended its Unified Directive on Payment Systems (Directive No. 12/080) to tighten cyber risk management for institutions in the payment system, including banks' mobile and internet banking channels and payment service providers. As reported by Kantipur, the amendment defines non-compliance with standards such as ISO 27001 and ISO 20022 as a technology risk. NRB has since carried these provisions into its consolidated 2081 edition of the payment systems directive and later updates.
That definition matters. Once missing ISO 27001 alignment is itself a named technology risk, the gap stops being a documentation shortfall and becomes a risk the institution has to identify, monitor and manage — and explain to its supervisor.
What actually changed
The same amendment asks institutions to manage cyber risk across identification, protection, detection, response and recovery; to deploy fraud detection based on AI and machine learning; to monitor software and hardware across their lifecycle with regular technical audits; and to stop customers reaching mobile and internet banking through unauthorized VPNs. These are not technology purchases you bolt on individually. They are outcomes of having a structured information security management system (ISMS) already running: risk assessment cycles, documented control ownership, change management, and continuous monitoring that produces evidence, not just intentions.
This is the actual argument for ISO 27001 in this context. It is not "get a certificate the regulator likes." It's that ISO 27001 is the fastest, most defensible path to building the management system NRB is now asking for — because the standard's clauses and Annex A controls already map onto most of what the directive demands.
| Directive Requirement Area | ISO 27001:2022 Mapping |
|---|---|
| Identify, protect, detect, respond, recover | Clauses 6.1.2–6.1.3 (Risk Assessment and Treatment), A.5.24–A.5.30 (Incident Management and Continuity) |
| AI/ML-based fraud detection | A.8.16 (Monitoring Activities), A.5.7 (Threat Intelligence) |
| Lifecycle monitoring and technical audits | A.8.8 (Management of Technical Vulnerabilities), A.8.9 (Configuration Management), Clause 9.2 (Internal Audit) |
| Unauthorized VPN / remote access control | A.8.20 (Networks Security), A.8.5 (Secure Authentication) |
| Governance and accountability | Clause 5 (Leadership), A.5.1–A.5.4 (Policies, Roles, Segregation of Duties) |
Use this table to scope a gap assessment, then confirm each row against the current text of the directive. NRB amends its directives frequently, and the payment systems directive has been reissued since the March 2025 change.
The dual-compliance trap most BFIs fall into
Institutions that treat NRB compliance and ISO 27001 as two separate projects end up running two audit cycles, two sets of evidence repositories, and two sets of policy documents that quietly drift out of sync with each other. That drift is where actual audit findings come from — not from either framework individually, but from the gap between them.
The institutions that get this right build one evidence base — logs, risk registers, control test results — that satisfies both the ISO 27001 external auditor and the NRB inspection team simultaneously. The institutions that get it wrong discover during an NRB inspection that their "ISO-compliant" firewall change log doesn't match what their internal NRB compliance file says happened.
What to do before your next NRB inspection cycle
- Pull your current Statement of Applicability (SoA) and check whether it explicitly addresses fraud detection oversight and VPN/remote access governance — most SoAs drafted before 2024 don't.
- Cross-reference your NRB compliance file against your ISMS risk register. If they were built by different teams at different times, they will not agree with each other on terminology, let alone evidence.
- Treat this as a Board-level risk conversation, not an IT ticket. NRB's Cyber Resilience Guidelines 2023 already make the board ultimately responsible for cyber risk. A named technology risk tied to ISO 27001 belongs in the board's risk reporting alongside the institution's other principal risks.
For institutions still weighing whether ISO 27001 certification is worth the investment against simply maintaining baseline NRB compliance, the honest answer is that the two are converging fast enough that the distinction is becoming academic.