If you work in compliance or IT risk at a Pakistani bank, DFI, microfinance bank or payment firm, you have probably been told that the State Bank of Pakistan mandates annual penetration testing. That is not quite what the circulars say, and the difference matters when you are writing a budget or answering an inspector. This guide quotes the obligations from the source documents and separates what is required from what is widely claimed.
The two documents that actually matter
Most of SBP's cyber security expectations for financial institutions rest on two instruments.
BPRD Circular No. 07 of 2016, "Prevention against Cyber Attacks". Addressed to the Presidents and Chief Executives of all Banks, DFIs and Microfinance Banks. This is the circular that sets the assessment, board oversight and record-keeping obligations.
BPRD Circular No. 05 of 2017, the Enterprise Technology Governance and Risk Management Framework. Issued 30 May 2017 to the same institutions. It sets baseline technology governance and risk management principles, explicitly risk-based rather than one-size-fits-all, with the board reviewing implementation status at least quarterly.
Later instruments build on these. A January 2023 circular on cloud outsourcing, for example, cites the 2017 framework as a related instrument, so it remains live rather than historical.
The thing almost every vendor page gets wrong
Search for SBP and penetration testing and you will find page after page stating that SBP mandates annual penetration testing by an accredited firm. Read the circular and that is not what it says.
What BPRD Circular 07 of 2016 requires is periodic independent assessments. Its exact words on testing are that such assessments "may include vulnerability assessments and penetration testing conducted by officials independent of the area under review".
Read that carefully, because three things follow.
The independent assessment is mandatory. The specific technique is not. "Shall ensure that periodic independent assessments are conducted" is an obligation. "May include vulnerability assessments and penetration testing" is an illustration of how to meet it.
Independence is defined by role, not by company. The wording is "officials independent of the area under review". An internal team can satisfy this if it is genuinely independent of what it is assessing.
External help is permitted, not compelled. The circular says that where internal teams lack the required expertise, institutions "may engage external parties with sufficient experience in IT security assessments".
We sell penetration testing, so it would suit us to tell you SBP forces you to buy it. It does not. What it does is make you responsible for assessing your controls properly and independently, and for most institutions penetration testing is the most practical way to do that. That is an argument on merit rather than on a regulation that was never written.
What the 2016 circular requires, item by item
Board-level obligations
The board shall, preferably on a bi-annual basis, evaluate the adequacy of the institution's cyber security action plan against emerging threats.
Where material gaps are found, the board must ensure a risk management strategy exists for accepting and controlling the resulting risk, supported by a concrete implementation plan with adequate manpower and financial resources.
That last clause is worth noting if you have ever had a security budget refused. The circular puts resourcing on the board.
Senior management obligations
Senior and executive management must maintain an organisational plan of action for cyber security management, reviewed and updated regularly.
They must also periodically brief the board on developments, implementation status, and a summary of major threats and attacks faced by the institution and their possible impact on operations.
The continuing cycle of assessments
The circular requires a continuing cycle of assessment of security against emerging threats, covering at least four areas.
Risk ownership and management responsibility. Ownership for cyber risk must be defined and established across ICT and all relevant business functions, with sufficient skilled resources inside the security function to exercise ongoing checks and balances.
Periodic evaluation and monitoring of controls. A standard mechanism for continuous monitoring, and specifically monitoring of all network communications to detect or block unauthorised or atypical communications among servers, systems and endpoint devices.
Regular independent assessment and tests. Covered above. This also requires institutions to regularly enhance and test their incident response mechanism and business continuity plan against cyber attack scenarios. Note the word test. A plan that has never been exercised does not meet this.
Industry collaboration and contingency planning. Institutions may explore collaboration with other institutions and relevant bodies for sharing and gathering cyber threat intelligence.
The record-keeping obligation nobody talks about
This is the sentence most summaries omit, and it is one of the most consequential in the circular.
Institutions shall maintain records of all attempts and breaches of cyber security, and produce them to SBP whenever required.
Attempts, not just breaches. In practice that means your logging retention, your alert handling records and your incident register are regulatory artefacts that can be called for. If your SIEM retains thirty days and your incident notes live in individual analysts' heads, you cannot meet this on request.
The original compliance deadline for the 2016 circular was 31 December 2016, so this has been in force for years.
The 2018 directive on payment channels
Following a payment card breach affecting Pakistani banks, SBP directed banks and microfinance banks to carry out vulnerability assessments and penetration tests on their alternate delivery channels and payment systems, including card systems, RTGS, SWIFT, and internet and mobile banking.
Assessment reports with action plans and remediation timelines were due to the Payment Systems Department by 31 March 2019, with independent third-party reviews of payment mechanisms following by 31 December 2019.
Those specific deadlines have passed. The reason it still matters is that it shows how SBP responds to a sector incident: with a directed, time-bound testing requirement on named channels. Institutions that already run regular testing absorb that. Institutions that do not are suddenly running an unplanned project to a regulator's deadline.
A claim we could not verify
Several aggregator sites currently describe a joint SBP and SECP circular numbered BPRD/CSD/2026/09, said to require annual penetration tests by CREST or PASHA accredited firms with a deadline of 31 December 2026.
We could not find that circular on any SBP or SECP source. It may exist and simply not be where we looked. It may also be a vendor claim that acquired a circular number through repetition.
Do not budget against it until you have seen it on sbp.org.pk or had it confirmed by your relationship contact. If you do confirm it, we would genuinely like to know, and we will update this page.
What about fintechs, EMIs and payment firms?
The 2016 and 2017 circulars are addressed to banks, DFIs and microfinance banks. If you are an EMI, a PSO or PSP, or a fintech operating under a different licence, your obligations come from your own licensing conditions and the relevant payment systems instructions rather than directly from BPRD circulars addressed to banks.
Two practical consequences follow.
First, check what your specific licence requires rather than assuming the bank rulebook applies to you. The answer differs by category.
Second, it often does not matter, because your bank partners will apply their own requirements to you contractually. A fintech integrating with a bank is part of that bank's supply chain, and the bank's own obligation to manage third-party technology risk lands on you as a clause and a questionnaire. In our experience that arrives sooner than regulation does.
How this maps onto PISF 2026
PISF does not replace any of this. It sits underneath as a national baseline, with sectoral regulators and CERTs as the reporting route.
For a bank, the overlap is substantial. You already have board oversight, risk management, incident response and independent assessment obligations from SBP. PISF adds the national reporting path and timelines, and the data hosting requirement.
The efficient approach is to map PISF onto your existing SBP programme and close the deltas, rather than running a second parallel project with its own documents and its own meetings.
What a realistic SBP-aligned programme looks like
Nothing here is exotic. Most institutions that struggle are not missing capability, they are missing evidence.
Independent assessment, at least annually and after significant change. Scoped to cover internet-facing channels, internal network, core applications and the payment paths. Carried out by people independent of those who built and run them.
Incident response that has been exercised. A written plan plus at least one tabletop exercise a year with the decisions rehearsed, including who contacts the regulator. The circular asks you to test, not to possess.
Continuous monitoring with retention that survives a request. Given the obligation to produce records of attempts and breaches, log retention is a compliance decision rather than a storage cost decision.
Board reporting on a fixed rhythm. Bi-annual evaluation under the 2016 circular, quarterly review of technology governance implementation under the 2017 framework. Put both in the calendar and minute them.
An incident register. Dated, structured, covering attempts as well as confirmed incidents. This is the single cheapest gap to close and one of the most commonly open.
How we help
We are a Pakistani security firm headquartered in Multan. For financial institutions the work is usually the independent assessment itself: penetration testing of internet banking, mobile apps, card and payment paths, internal network and Active Directory, plus incident response tabletop exercises and the gap assessment that tells you where you stand before an inspection does.
Our reports are written so they can be handed to an inspector as they are, with scope, dates, methodology, findings and retest results stated plainly. A single web application starts at USD 399 and a full manual penetration test is USD 1,500.
If you want to know where you stand against the circulars before your next board paper, tell us what is in scope and we will size it.
0 comments
Leave a comment