Bangladesh Bank requires every bank, finance company, MFS provider, PSP and PSO to run vulnerability scans at least every six months and penetration tests at least once a year. Its new Cybersecurity Framework raises that bar again, with a compliance deadline of 31 December 2026.
Why does VAPT matter right now?
On 22 October 2026, Bangladesh Bank took its own website offline as a precaution after BGD e-GOV CIRT warned about two critical vulnerabilities in PHP. The site came back on 25 October, after a review of the risks. Several commercial banks also pulled PHP-based websites, and bdnews24 reported that Janata Bank's IT team found signs of two attacks and injected spam on its site even after the precautionary shutdown.
That week is the clearest reminder yet of a simple truth: you cannot patch what you do not know is exposed, and you cannot prove you are secure without testing. This is exactly what Vulnerability Assessment and Penetration Testing (VAPT) is for, and why Bangladesh Bank has made it a formal, recurring obligation.
The timing is also urgent. Bangladesh Bank's new Cybersecurity Framework, Version 1.0 (2026), issued on 29 March 2026 through BRPD Circular No. 02, must be implemented by 31 December 2026. It sits on top of the existing Guideline on ICT Security, Version 4.0 (2023), which already sets clear VAPT rules.
This guide explains, in plain language, what both documents require for VAPT, how often, by whom, and how a CISO, CTO or Head of IT can turn the rules into a practical, audit-ready programme before the deadline.
Bangladesh Bank VAPT requirements: the 60-second summary
Quick answer: under Bangladesh Bank rules, regulated institutions must run internal vulnerability scans at least every six months, have critical systems scanned once a year by an independent party, and perform internal and external penetration testing at least once a year and after any significant change. The 2026 framework adds compromise assessments and 72-hour incident reporting.
- Vulnerability scans: internal scans at least every six months, plus a scan after every significant change. Rescan until all high-risk findings are closed.
- Independent scan: critical systems and applications must be scanned once a year by an independent party, with a time-bound remediation plan.
- Penetration testing: internal and/or external penetration testing at least once a year, and again after any significant infrastructure or application change.
- Methodology: an industry-accepted approach such as NIST SP 800-115, testing from both inside and outside the network.
- New in 2026: the Cybersecurity Framework adds compromise assessments, vulnerability testing with both automated and manual techniques, supplier testing evidence, and 72-hour reporting of critical incidents to Bangladesh Bank and BGD e-GOV CIRT.
- Deadline: framework compliance by 31 December 2026.
- Who: banks, finance companies (NBFIs), MFS providers, payment service providers, payment system operators, and other entities Bangladesh Bank regulates.
What does VAPT mean in plain language?
VAPT combines two different activities. Think of your bank as a building.
- Vulnerability Assessment (VA) is the inspector who walks around and lists every unlocked window, weak lock and broken camera. It is broad, largely automated, and answers the question: "What weaknesses exist?"
- Penetration Testing (PT) is the authorised professional who actually tries to get in through those windows, to see how far they can go. It is deep, manual and expert-driven, and answers the question: "What can an attacker really do with these weaknesses?"
You need both. A scan alone produces long lists of findings with no proof of real-world impact. A penetration test alone goes deep into a few areas but can miss the wider picture. Bangladesh Bank's guideline asks for both, on different schedules. Our guide to VAPT vs penetration testing covers the difference in more detail.
| Vulnerability Assessment | Penetration Testing | |
|---|---|---|
| Goal | Find and list known weaknesses | Prove exploitability and business impact |
| Method | Mostly automated scanners, plus configuration review | Manual, expert-led attack simulation |
| Coverage | Wide (many assets) | Deep (selected critical assets) |
| Bangladesh Bank minimum frequency | Internal: half-yearly; independent: annually for critical systems | At least annually, plus after significant changes |
| Typical output | List of vulnerabilities by severity | Attack paths, evidence, business risk, fix guidance |
Two related terms are also worth knowing. The first is named in the 2026 framework; the second is the natural next step for mature banks:
- Compromise assessment: a hunt to check whether an attacker is already inside your environment, quietly.
- Red teaming: a goal-based, stealthy attack simulation that also tests whether your SOC and incident-response team can detect and respond.
Which Bangladesh Bank documents set the VAPT rules?
VAPT in Bangladesh's financial sector is now shaped by two Bangladesh Bank documents that work together.
| Document | Issued | Status | What it does for VAPT |
|---|---|---|---|
| Cybersecurity Framework, Version 1.0 (2026) | 29 March 2026 (BRPD Circular No. 02) | Mandatory; compliance by 31 December 2026 | Adds compromise assessments, manual and automated testing, supplier testing, annual cybersecurity audits and 72-hour incident reporting |
| Guideline on ICT Security, Version 4.0 (2023) | 2023 | In force | Section 6.2 sets the core VAPT rules: frequencies, independence and methodology |
How they fit together. The ICT Security Guideline is the detailed rulebook for ICT controls. The Cybersecurity Framework is a governance layer modelled on the NIST Cybersecurity Framework, organised around Govern, Identify, Protect, Detect, Respond, Recover and Reporting. Bangladesh Bank describes the framework as a baseline, and expects each institution to run its own risk analysis to go further.
Who must comply?
The ICT Security Guideline applies to every entity Bangladesh Bank regulates, which it collectively calls "the Organization":
- Scheduled banks
- Non-bank financial institutions / finance companies
- Mobile Financial Service Providers (MFSPs)
- Payment Service Providers (PSPs) and Payment System Operators (PSOs)
- White Label ATM operators and Merchant Acquirers (WLAMA)
- Other financial service providers regulated by Bangladesh Bank
The 2026 framework covers scheduled banks, finance companies, MFS providers, PSPs and PSOs. It draws its authority from the Bank Company Act 1991, the Finance Company Act 2023 and the Payment and Settlement Systems Act 2024.
What happens if you fall short? Under the ICT Security Guideline, an institution must fix non-compliance within a set time frame. If it cannot, it must seek a dispensation from Bangladesh Bank, and repeated failure can lead to penalties.
Section 6.2 decoded: what are the core VAPT rules in the ICT Security Guideline?
Section 6.2 of the Guideline on ICT Security (Version 4.0) is titled "Vulnerability Assessment and Penetration Testing (VAPT)". It has seven clauses. Here is what each one means and what an auditor will expect to see.
| Clause | What it requires (plain language) | What to show the auditor |
|---|---|---|
| 6.2.1 | Scan for vulnerabilities periodically and after significant ICT changes: new components, network topology changes, firewall rule changes, product upgrades. | Change records linked to post-change scan reports |
| 6.2.2 | Run internal vulnerability scans at least half-yearly. Rescan until all high-risk vulnerabilities are resolved. Scans must be done by qualified people. | Two scan cycles a year, rescan evidence, scanner operator credentials |
| 6.2.3 | Scan critical systems and applications once a year through an independent party, and keep a time-bound remediation plan based on the report. | Independent assessor's report, signed remediation plan with owners and dates |
| 6.2.4 | Protect public-facing web applications against known attacks, and address new threats continuously. | WAF and secure configuration evidence, web app test results, threat-response records |
| 6.2.5 | Use a mix of review techniques: documentation review, log review, rule-set review, system configuration review, file integrity checking. | Configuration review and firewall rule-review reports |
| 6.2.6 | Base penetration testing on an industry-accepted methodology (for example NIST SP 800-115). Cover critical systems, test from inside and outside the network, consider threats seen in the last 12 months, and define how long test and remediation results are retained. | Approved methodology document, internal and external scope, threat-informed test cases, retention policy |
| 6.2.7 | Perform internal and/or external penetration testing at least annually, and after any significant infrastructure or application upgrade or modification. | Annual PT report plus change-triggered PT reports |
Five points leaders often miss
- "Annually" is the minimum, not the target. Both the scan and the penetration-test clauses add a second trigger: significant change. A new mobile app release, a core banking upgrade, a new API gateway or a data-centre migration can each require fresh testing.
- Independence is explicit. Clause 6.2.3 asks for an independent party for critical systems. Your own IT team scanning its own systems does not satisfy that clause on its own.
- Rescanning is mandatory. Clause 6.2.2 does not end with the report. You must rescan until high-risk issues are fixed, so budget for re-testing.
- Methodology must be documented. Auditors increasingly ask how the test was done, not just whether it happened. Ask your vendor for a methodology aligned with NIST SP 800-115, OWASP testing guides, PTES or similar.
- Testing must be threat-informed. Clause 6.2.6 asks testers to consider threats from the last 12 months. In 2026, that clearly includes issues like the October PHP vulnerabilities, phishing-led intrusions and API abuse.
Which other ICT Guideline clauses create testing duties?
VAPT does not live only in Section 6.2. Several other chapters of the ICT Security Guideline create testing obligations that a good VAPT programme should cover.
| Area | Clause(s) | Requirement in brief | VAPT implication |
|---|---|---|---|
| APIs | 10.8.6, 10.8.12 | Security screening and testing of APIs with third parties before production deployment | API penetration test before every go-live |
| Mobile apps | 11.4.13, 11.4.14, 11.7.15 | Regular SAST and DAST on mobile app code; app hardening or shielding; apps may pass vulnerability assessment and intrusion tests by internal and independent assessors | Mobile app PT (Android and iOS) and code scanning in each release cycle |
| Secure development | 6.1.7, 10.3.7, 10.6.2 | Secure-coding training; code review by someone other than the author; security functions tested during development | Secure code review and SAST built into the SDLC |
| Testing independence | 10.5.1 to 10.5.3 | Testing team separate from development; UAT and post-deployment verification | Security testing signed off independently of developers |
| Patching | 5.11.1, 5.11.2, 6.1.4, 6.1.5 | Categorise and prioritise patches with time frames; test patches before production; alternative controls when no patch exists | Rescans verify patches actually closed the finding |
| Internet-connected systems | 5.5.1.8 | Formal risk analysis before connecting systems to the internet or third parties | Pre-go-live external PT for internet-facing systems |
| SWIFT | 11.8.2(l), 11.8.3 to 11.8.5 | Periodic scenario-based risk assessment; annual security attestation; independent assessment at least annually | SWIFT CSP independent assessment and related testing |
| Disaster recovery | 9.1.4.1, 9.2.1.7 | Well-planned BCP test scenarios; DR site tested at least annually | Include DR environments in VAPT scope |
| Outsourcing | 12.1.10 | Service providers submit third-party audit or risk-assessment reports at set intervals | Ask vendors for their own VAPT evidence |
| IS audit | 2.4.5, 2.5.1 | Internal IS audit at least yearly (risk-based); external IS audit at least annually | VAPT reports feed directly into IS audit evidence |
| Risk assessment | 3.2 | Periodic ICT risk assessment | VAPT findings update the risk register |
The practical takeaway: a "network VAPT once a year" is not enough to satisfy the guideline. A compliant programme covers infrastructure, web applications, APIs, mobile apps, cloud, SWIFT and DR environments, on the right triggers.
What does the 2026 Cybersecurity Framework add to VAPT?
The Cybersecurity Framework, Version 1.0 (2026) keeps the annual rhythm but raises the bar on how testing is done and what happens around it. These are the clauses that matter most for VAPT.
| Clause | What it says (summarised) | Why it matters |
|---|---|---|
| 5.1.2.25 | Perform internal and external vulnerability and penetration testing at least annually, and after significant infrastructure or application changes | Confirms the ICT Guideline frequency under the new mandatory framework |
| 4.1.8.12 | Conduct regular vulnerability assessments using automated tools and manual techniques; web systems must be checked for issues such as SQL injection and cross-site scripting | Scanner-only "VAPT" reports are no longer enough |
| 4.1.8.13 | Carry out penetration tests and compromise assessments that simulate actual attacks | Adds an "are we already breached?" check to the programme |
| 4.1.6.16 | Develop and implement a vulnerability management plan | VAPT must feed a living process, not a one-off report |
| 3.1.4.2, 3.1.4.8 | Identify and document asset vulnerabilities; collect threat intelligence from information-sharing forums | Test scope should reflect current threat intelligence |
| 5.1.2.18 | Use an active discovery tool, run daily or more often, to identify connected assets | You can only test what is in your inventory |
| 5.1.1.11 | Regularly address new threats to public-facing web applications | Continuous attention to internet-facing apps |
| 3.1.6.3, 3.1.7.7, 5.1.2.32 | Routinely assess suppliers through audits and test results; audit third-party cloud providers; monitor external providers, including dark-web monitoring | Ask vendors and cloud providers for their VAPT evidence |
| 2.3.1 | Recruit a qualified CISO and approve the people and budget the role needs | Gives the CISO a mandate to fund testing |
| 8.1.2.1 | Report any critical cyber incident to internal and external stakeholders, including Bangladesh Bank and BGD e-GOV CIRT, within 72 hours of occurrence | A breach found during testing can trigger reporting duties |
| 8.1.3 | Cybersecurity audits at least once a year and after any incident or breach, by internal teams or external firms | VAPT evidence is core audit material |
| 7.1.1.12, 7.1.1.13 | Backup recovery tested quarterly; incident-response exercises at least annually | Testing extends beyond technology into response readiness |
| 7.1.2.4 | Track KPIs such as Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) | Red-team style exercises give real data for these KPIs |
The framework also includes a sample yes/no checklist (Appendix C) that institutions can use for self-assessment. Bangladesh Bank's ICT Audit, Inspection and Compliance Wing is the contact point for implementation questions.
The ICT Security Guideline asked: "Did you test?" The 2026 framework asks: "Did you test like a real attacker, track every fix, check your vendors, and could you detect and report a real breach within 72 hours?"
What does an annual VAPT compliance calendar look like?
The table below turns the rules into a simple yearly plan. The "Bangladesh Bank minimum" column is what the documents require; the "Recommended" column is good practice for a mid-sized bank, MFS or PSP.
| Activity | Bangladesh Bank minimum | Recommended | Source |
|---|---|---|---|
| Asset discovery (internet-facing and internal) | Daily or more often (active discovery tool) | Continuous attack-surface monitoring | CSF 5.1.2.18 |
| Internal vulnerability scan | Every 6 months and after significant changes | Monthly for critical systems; quarterly for the rest | ICT 6.2.1, 6.2.2 |
| Rescan of high-risk findings | Until all high-risk items are closed | Within the agreed SLA for each severity | ICT 6.2.2 |
| Independent vulnerability scan of critical systems | Annually | Annually, aligned with the external PT | ICT 6.2.3 |
| Internal and external penetration test | Annually and after significant changes | Annually, plus a pre-go-live test for every major release | ICT 6.2.7, CSF 5.1.2.25 |
| Web, API and mobile app testing | Before production deployment; ongoing for public-facing apps | Every major release; at least annually | ICT 6.2.4, 10.8, 11.4 |
| Compromise assessment | Required (frequency not fixed) | Annually, and after any suspicious event | CSF 4.1.8.13 |
| Configuration and firewall rule review | Part of assessment techniques | Twice a year | ICT 6.2.5 |
| Supplier and cloud provider security evidence | Routine assessment through audits and test results | Collect vendors' VAPT reports annually | CSF 3.1.6.3, 3.1.7.7 |
| Incident-response exercise | At least annually | Twice a year, one using a real VAPT attack path | CSF 7.1.1.13 |
| Cybersecurity audit | At least once a year and after any incident | Schedule after the annual PT so findings are closed | CSF 8.1.3 |
| SWIFT independent assessment | At least annually | Align with the SWIFT CSP attestation cycle | ICT 11.8.3 to 11.8.5 |
A simple way to schedule it: Q1 for scoping and asset inventory, Q2 for the first internal scan and the annual external and internal penetration test, Q3 for remediation and retesting, Q4 for the second internal scan, the compromise assessment and the cybersecurity audit. Change-triggered tests run whenever a significant change happens.
All yearDaily asset discovery. Scans and penetration tests after every significant change. Rescans until high-risk findings are closed.
- Scope and asset inventory
- Classify critical systems
- Approve the VAPT policy and fix SLAs
- Internal vulnerability scan (1 of 2)
- Independent scan of critical systems
- Annual internal and external pentest
- Remediation against the SLAs
- Rescans and retests
- Collect supplier VAPT evidence
- Internal vulnerability scan (2 of 2)
- Compromise assessment
- Cybersecurity audit and board report
Cybersecurity Framework compliance due by 31 December 2026
What changed in 2025 and 2026?
The regulatory push did not come out of nowhere. Here is the recent timeline, newest first.
| Date | Development | Why it matters for VAPT |
|---|---|---|
| 1 Nov 2026 | Bangladesh Bank says it will soon introduce an AI-based cybersecurity policy for banks and financial institutions | Expect AI-driven attacks and AI systems to enter testing scope |
| 26 Oct 2026 | A Prothom Alo op-ed warns that internet-facing systems missing from inventories may never be tested | Attack-surface mapping should come before every PT scope |
| 22 to 25 Oct 2026 | Bangladesh Bank takes its website offline for three days after BGD e-GOV CIRT flags critical PHP vulnerabilities; Janata Bank reports signs of two attacks on its offline website | Shows the cost of unknown exposure and slow patching |
| 21 Jul 2026 | New Internal Control Management System (ICMS) guidelines support the move to risk-based supervision | Supervisors will look at risk evidence, including test results |
| 10 Apr 2026 | Parliament passes the Cyber Security Bill 2026, replacing the Cyber Security Ordinance 2025 | National-level pressure on critical systems to prove security |
| 29 Mar 2026 | Cybersecurity Framework, Version 1.0 (2026) issued through BRPD Circular No. 02, alongside Guidelines on Partner Network, Version 1.0 (2026) | Mandatory baseline; deadline 31 Dec 2026 |
| 6 Nov 2025 | Personal Data Protection Ordinance 2025 gazetted, with some provisions taking effect after an 18-month window | Data breaches caused by weak controls now carry legal exposure beyond Bangladesh Bank |
| 30 Jul 2025 | Bangladesh Bank issues a 17-point cybersecurity directive to banks, NBFIs and MFS providers: timely patching, least privilege, MFA, SIEM, 24/7 monitoring | Patching and monitoring must be proven, which VAPT does |
| 16 Jul 2025 | A BIBM study on bank IT operations urges all banks to adopt VAPT, SIEM and PAM as baseline tools | Industry research backs VAPT as a minimum control |
| 21 May 2025 | Cyber Security Ordinance 2025 promulgated, with critical information infrastructure later listed under it | National-level pressure on critical systems to prove security |
The background to all of this is still the 2016 Bangladesh Bank heist, when US$81 million was stolen through fraudulent SWIFT messages. Ten years later, it remains the reference case for why testing, segmentation and monitoring cannot be optional.
How can a CISO, CTO or IT head get VAPT-ready before the deadline?
With the 31 December 2026 deadline close, here is a ten-step plan that turns the requirements into evidence an inspector will accept.
- Build a complete asset inventory. List every internet-facing domain, IP, API, mobile app, cloud service and third-party connection. Use an active discovery tool, as the framework requires. Forgotten test servers and old microsites are where attackers start.
- Classify critical systems. Core banking, internet banking, mobile apps, card systems, SWIFT, payment gateways, MFS platforms and their APIs are usually critical. These trigger the independent-testing rule in clause 6.2.3.
- Write (or update) a VAPT policy. Define frequencies, change triggers, methodology, roles, retention periods and remediation time frames. Get it approved by top management, so it carries board-level authority.
- Set remediation SLAs by severity. Clause 5.11.1 requires patch categories with time frames. A common industry practice is: Critical within 7 days, High within 30, Medium within 90, Low within 180. Set what fits your risk appetite and document it.
- Run internal scans every six months, at minimum. Track trends over time. Rescan until every high-risk item is closed, and keep the evidence.
- Commission an independent annual VAPT. Cover external, internal, web, API, mobile and cloud. Insist on manual testing, not just tool output, as framework clause 4.1.8.12 now expects.
- Add a compromise assessment. Clause 4.1.8.13 asks for it. It answers the question every board asks after a headline incident: "Are we already breached?"
- Test before every significant change goes live. Build a security gate into your change-management process for new apps, APIs, core upgrades and network changes.
- Close the loop with vendors. Ask software vendors, cloud providers and outsourced partners for their latest VAPT evidence and remediation status, and record it.
- Report upward and connect to incident response. Present VAPT results, open risks and fix rates to the ICT Risk Management Committee and the board. Agree in advance how a breach discovered during testing is escalated within the 72-hour reporting window.
How do you choose a VAPT partner?
Picking the right tester is as important as the test itself. Use this checklist before signing:
- Independent from the team that built or runs the systems being tested
- Testers hold recognised certifications (for example OSCP, OSWE, CREST, CEH Practical, GPEN) and can show prior banking or fintech work
- Methodology documented and aligned with NIST SP 800-115, OWASP WSTG / MASTG and PTES
- Manual testing included, not only automated scanning
- Coverage of web, API, mobile (Android and iOS), network, cloud and, where needed, SWIFT and core banking
- Report maps each finding to Bangladesh Bank clauses, with severity, evidence and clear fix guidance
- Free or agreed-price retesting to confirm fixes
- Signed NDA, rules of engagement, written authorisation and data-handling commitments
- Local presence to support on-site internal testing and auditor meetings
What are the seven most common mistakes that fail an inspection?
- Calling a scanner report a "VAPT". An automated scan with no manual validation does not meet the penetration-testing requirement, and the 2026 framework explicitly asks for manual techniques.
- Testing only the network. Leaving out mobile apps, APIs and cloud workloads, which are now where most customer-facing risk sits.
- Scoping from an outdated inventory. If an internet-facing system is not on the list, it is never tested. The October 2026 PHP scare showed how quickly unknown exposure becomes a crisis.
- No retest. Findings marked "fixed" without a rescan. Clause 6.2.2 requires rescanning until high-risk issues are closed.
- One test a year, regardless of change. Major releases and upgrades go live untested between annual cycles, which breaks clauses 6.2.1 and 6.2.7.
- Remediation plans without owners or dates. Clause 6.2.3 asks for a time-bound plan. A list of findings is not a plan.
- Ignoring third parties. Vendors with privileged access or hosted platforms are never asked for test evidence, despite framework clause 3.1.6.3.
Frequently asked questions
Is VAPT mandatory under Bangladesh Bank rules?
Yes. Section 6.2 of the Guideline on ICT Security (Version 4.0) requires half-yearly internal vulnerability scans, an annual independent scan of critical systems, and penetration testing at least annually and after significant changes. The Cybersecurity Framework, Version 1.0 (2026) repeats the annual requirement and adds compromise assessments.
How often must a bank do penetration testing?
At least once a year, and again after any significant infrastructure or application upgrade or modification (ICT Guideline 6.2.7; Cybersecurity Framework 5.1.2.25).
Can our internal team do the VAPT?
Partly. Qualified internal teams can run the half-yearly scans. However, critical systems and applications must be scanned once a year by an independent party (clause 6.2.3), and most institutions use an independent external firm for the annual penetration test as well.
Does this apply to MFS providers and PSPs, not just banks?
Yes. The ICT Security Guideline covers banks, NBFIs, MFS providers, PSPs, PSOs, White Label ATM operators, merchant acquirers and other entities regulated by Bangladesh Bank. The 2026 framework also explicitly covers MFS providers, PSPs and PSOs.
What is the deadline for the new Cybersecurity Framework?
Compliance is due by 31 December 2026.
What is a compromise assessment, and do we need one?
It is an investigation to find out whether attackers are already present in your environment. Clause 4.1.8.13 of the 2026 framework asks institutions to carry out penetration tests and compromise assessments that simulate actual attacks.
Which methodology should our tester follow?
The guideline names NIST SP 800-115 as an example. Good vendors combine it with OWASP testing guides for web, API and mobile, and PTES for infrastructure.
What must we report to Bangladesh Bank?
Under the 2026 framework, any critical cyber incident must be reported to internal and external stakeholders, including Bangladesh Bank and BGD e-GOV CIRT, within 72 hours of occurrence. Audit reports must also be preserved for regulators, and your VAPT policy must define how long test and remediation results are kept.
Conclusion: from compliance checkbox to real resilience
Bangladesh Bank's message is now consistent across every recent circular: test regularly, test like a real attacker, fix what you find, and prove it. The ICT Security Guideline sets the rhythm: half-yearly scans, annual independent testing, and annual penetration tests plus change-triggered tests. The 2026 Cybersecurity Framework raises the standard with manual testing, compromise assessments, supplier assurance and 72-hour incident reporting.
For CISOs, CTOs and IT heads, the weeks before 31 December 2026 are the time to close gaps, not discover them during an inspection. A well-run VAPT programme does both jobs at once: it satisfies the regulator and it genuinely makes your institution harder to break into.
Need help getting VAPT-ready before the deadline? PentesterSpace helps banks, NBFIs, MFS providers and payment companies in Bangladesh run Bangladesh Bank-aligned VAPT covering web, API, mobile, network, cloud and AI application testing, secure code review and retesting, with reports mapped to the guideline clauses your auditors check. Book a call or share your scope.
- Email: contact@pentesterspace.com
- Phone: +880 1765-323081
PentesterSpace is an independent firm. This article is not endorsed by Bangladesh Bank, and Bangladesh Bank does not recommend any specific service provider.
Sources
Primary regulatory documents
- Bangladesh Bank: Guideline on ICT Security, Version 4.0 (2023)
- Bangladesh Bank: BRPD Circular No. 02 (29 March 2026) and Cybersecurity Framework, Version 1.0 (2026)
News and analysis
- Cenbank introduces new cybersecurity framework for financial sector, The Business Standard
- Bangladesh Bank website still offline over global PHP security vulnerability, The Business Standard
- Bangladesh Bank shuts website as global cyber threats raise alarm (22 Oct 2026), bdnews24
- Janata Bank website targeted in cyberattack despite precautionary shutdown (25 Oct 2026), bdnews24
- Bangladesh's cyber security challenge: Do we know what is exposed? (26 Oct 2026), Prothom Alo
- BB to introduce AI-based cybersecurity policy soon (1 Nov 2026), Daily Sun
- Parliament passes Cyber Security Bill-2026, DigiBangla Tech News
- BB issues 17-point cybersecurity directive amid rising threats, The Daily Star
- Banks must strengthen IT governance, cybersecurity (BIBM study), The Financial Express
- BB issues new ICMS guidelines for banks, Daily Ittefaq
- Bangladesh Bank issues Guidelines on Partner Network, The Financial Express
- Govt issues gazettes of 2 landmark ordinances on data protection, governance, The Business Standard
- CA orders tighter cybersecurity for polls, bdnews24
This article summarises public regulatory documents and news reports as of 13 November 2026, for general information. It is not legal or regulatory advice. Always confirm requirements against the latest Bangladesh Bank circulars.
All articles