Penetration Testing Requirements for Banks and Fintechs in Pakistan

What SBP, the card schemes and auditors expect banks, EMIs, payment companies and lending apps in Pakistan to test, how often, and what evidence to have ready before an inspection.

What are penetration testing requirements for banks in Pakistan?

Penetration testing requirements for banks in Pakistan come from three sources: the State Bank of Pakistan, the card schemes through PCI DSS, and standards such as ISO 27001. All three expect a regulated institution to commission independent, periodic simulated attacks on its critical and internet-facing systems, fix what is found, and keep evidence of the whole loop. A penetration test is an authorised, simulated attack on an application, system or network, carried out by qualified testers to find and prove exploitable weaknesses before a real attacker does. A vulnerability assessment is the broader, largely scan-driven exercise in which an analyst identifies, validates and prioritises possible weaknesses without exploiting them. Pakistani institutions normally procure the two together under the label VAPT.

For a bank, electronic money institution or payment company in Pakistan, those three sources are the regulator that licenses you, the card schemes and acquirers you connect to, and the standards you have chosen to certify against. None hands you a single checklist. Each expects testing that is commissioned from outside the team that built the system, runs on a defined cycle, follows your risk assessment and is evidenced. Each also leaves you to design a programme that satisfies all three.

Who is in scope for security testing in Pakistan's financial sector?

Testing expectations follow the licence and the data, not the size of the company, which is why fintech security testing in Pakistan looks much like bank testing at a smaller scale. If you hold customer funds, move payments or store card or identity data, someone will eventually ask for your latest report. The following are commonly in scope:

• Commercial, Islamic and microfinance banks, across internet and mobile banking, cards and ATMs, SWIFT and core banking.
• Electronic Money Institutions (EMIs) and branchless banking providers offering wallets, prepaid instruments and merchant payments.
• Payment System Operators and Payment Service Providers (PSOs/PSPs): gateways, aggregators, switches and payment initiation services.
• Digital lending and buy-now-pay-later apps, whether run through SBP-regulated entities or as SECP-regulated non-bank finance companies.
• Telecom-led wallets, where PTA cybersecurity expectations for the operator sit alongside SBP expectations for the financial service.
• Third parties in the payment flow: core banking vendors, know-your-customer (KYC) providers, card bureaux, cloud hosts and outsourced development teams.

Why third parties count

The last group matters more than most boards expect. Supervisors and auditors treat outsourced systems as part of your perimeter, so your evidence should cover vendor-hosted components or show that the vendor's own testing has been reviewed and accepted by you.

How do SBP expectations, PCI DSS and ISO 27001 fit together?

Think of the three as answering different questions. The regulator asks whether you manage technology risk responsibly. PCI DSS asks whether cardholder data is protected in a specific, prescriptive way. ISO 27001 asks whether your controls, testing included, run as a managed system that improves over time.

State Bank of Pakistan and other regulators

SBP's technology governance and cybersecurity expectations for banks, microfinance banks, EMIs and payment operators are framed around risk management rather than a fixed test menu. In practice, supervisors and external auditors expect independently performed penetration tests of the systems that matter most, vulnerability management with defined remediation timelines, and board-level visibility of results. PTA sets comparable cybersecurity expectations for telecom operators, SECP issues guidance for the non-bank financial sector, and the Prevention of Electronic Crimes Act 2016 (PECA) is the legal backdrop for unauthorised access and data breaches. Treat these as frameworks that expect periodic, independent testing, and confirm the current wording with your compliance team rather than relying on summaries.

PCI DSS penetration testing

If you store, process or transmit cardholder data, or can affect its security, PCI DSS reaches you through your acquirer or the card schemes. It is also the most specific: internal and external testing of the cardholder data environment (CDE) is expected, along with testing of the segmentation controls that isolate the CDE, regular vulnerability scanning, and retesting until exploitable findings are closed. Your assessor or self-assessment questionnaire will ask for the reports directly.

ISO 27001 and SOC 2

ISO 27001 prescribes no frequency. It expects you to identify and manage technical vulnerabilities, test controls under your risk treatment plan, and keep records showing the loop closes. A well-run ISO 27001 programme therefore becomes the wrapper that holds SBP and PCI DSS evidence together: scope decisions, tester selection, findings, remediation and management review in one system. SOC 2 plays the same role for fintechs selling to overseas partners.

What types of penetration testing are expected?

A single annual external scan satisfies none of the three frameworks. Expectations follow where risk actually sits, which in a modern bank or fintech is largely in applications and APIs rather than at the network edge. A complete programme typically covers:

• Web application testing of internet and corporate banking, merchant portals, admin consoles and onboarding journeys: authentication, session management, authorisation and business logic.
• Mobile application testing of Android and iOS apps: local data storage, certificate pinning (locking the app to your own server certificates), root and jailbreak detection, binary protections and the APIs behind the app.
• API testing of interfaces used by your own apps and those exposed to partners and aggregators, focused on object-level and function-level authorisation, rate limiting and token handling.
• External and internal network testing, including segmentation testing where PCI DSS applies, Active Directory privilege escalation paths, and the systems supporting ATMs, card switches and SWIFT.
• Red team or adversary simulation for larger institutions, testing detection and response across people, process and technology rather than listing vulnerabilities.
• Secure source code review for in-house or vendor-built payment and core components, where dynamic testing alone cannot reach cryptographic, logging or transaction integrity flaws.
• Cloud configuration review for workloads on public cloud: identity, storage exposure, network controls and logging.

Scope follows risk, not a template

Not every entity needs every layer every year. A small EMI with one wallet app and a handful of APIs has a very different scope from a bank with dozens of channels. What matters is that scope is chosen deliberately from a documented risk assessment and can be explained to a supervisor.

How often should banks and fintechs test?

Each regulator publishes its own minimum cycle and revises it, so treat what follows as sector practice rather than a legal minimum. What is consistent across SBP expectations, PCI DSS and ISO 27001 is the principle: test on a defined cycle, and test again when something significant changes. Common practice in the sector looks like this:

• A full penetration test of critical and internet-facing systems at least annually, with the next date planned rather than discovered by an auditor.
• Targeted testing after major change: a mobile release with new features, a new payment rail or partner integration, a core banking upgrade, a cloud migration, or a change to the segmentation protecting card data.
• Vulnerability scanning continuously, or at least monthly for internet-facing systems and quarterly for internal ones, feeding a remediation tracker with owners and deadlines.
• Retesting of every critical and high finding once fixed, with the evidence attached to the original report.
• For fintechs shipping weekly, a rolling testing arrangement that keeps pace with releases instead of one annual exercise that is stale within a quarter.

The usual failure

The most common failure is not skipping the annual test but treating it as the only test, so a year of releases goes live without anyone outside the development team looking at them.

What do auditors and regulators ask to see?

Testing that is not evidenced did not happen, as far as an auditor is concerned. Supervisory inspections, PCI DSS assessments and ISO 27001 audits ask for broadly the same artefacts, so assemble them once and keep them current. Expect to be asked for:

• Scope and rules of engagement: which systems, IP ranges, apps and APIs were tested, what was excluded and why.
• The full technical report with methodology, severity-rated findings, evidence of exploitation and remediation guidance, not only an executive summary.
• Retest evidence that critical and high findings were fixed and verified, or a signed risk acceptance from an accountable executive where they were not.
• An attestation letter or certificate of testing that can be shared with acquirers, partners and regulators without exposing technical detail.
• Proof of tester independence and competence: testers organisationally independent of the team that built or runs the system, whether an external firm or a genuinely separate internal function, with recognised credentials such as OSCP or eWPTX.
• A remediation tracker linking each finding to an owner, deadline and closure date, with ageing visible to management.
• Committee or board papers showing results were reported and discussed.

Scan reports are not test reports

Auditors are also alert to reports that are really vulnerability scans with a new cover page. A genuine penetration test shows manual work: chained findings, business logic abuse, and request logs or screenshots that prove impact.

What are the common gaps in mobile banking apps and APIs?

The same weaknesses recur across the sector, largely because mobile apps and their APIs are built quickly, often by outsourced teams, to deadlines set by product rather than security. In mobile banking apps, testers typically find:

• Tokens, account numbers or transaction history cached in local storage, logs or screenshots without adequate protection.
• Certificate pinning that is missing, bypassable or switched off in production builds.
• Root, jailbreak and emulator detection and anti-tampering controls that are absent or trivially patched out of the binary.
• Hard-coded API keys, encryption keys or third-party credentials inside the app package.
• Weak device binding, so a registered session can be replayed from another handset, and biometric or PIN checks enforced only in the app rather than at the API.

In the APIs behind them

API findings tend to be more serious because they bypass every control in the app. None of what follows is exotic; these issues are found because someone looked properly, which is the whole argument for independent testing. Testers commonly find:

• Broken object-level authorisation: changing an account, card or transaction identifier returns another customer's data.
• Broken function-level authorisation: customer roles can reach endpoints meant for staff or partners.
• Business logic flaws in transfers, limits, one-time password (OTP) handling and refunds, such as negative amounts, race conditions or limit checks performed only client-side.
• Missing or inconsistent rate limiting on login, OTP verification and account enumeration endpoints.
• Long-lived tokens not revoked on logout, password change or device change, and legacy endpoints still reachable in production.

Readiness checklist for your next penetration test

Whether you call it VAPT for banks or penetration testing, the preparation is the same. Before commissioning a test, or before an auditor asks, work through the following:

• Maintain an inventory of every internet-facing application, API, mobile app and network range, each with a business owner.
• Classify systems by criticality and by whether they touch cardholder data, so scope decisions trace back to risk.
• Confirm which frameworks apply: SBP or SECP as regulator, PCI DSS through your acquirer, ISO 27001 or SOC 2 by choice, PTA if telecom-led.
• Set a testing calendar tied to the annual cycle and your release plan, with change triggers written down.
• Choose an independent provider whose testers hold recognised credentials, and confirm that a retest and an attestation letter on a clean retest are included.
• Prepare test environments, credentials for each user role, API documentation and a named technical contact so the test does not stall in week one.
• Agree severity definitions and remediation timelines in advance, and decide who may sign a risk acceptance.
• Keep the last two or three years of reports, retests and attestations in one place, ready for a supervisory visit or PCI assessment.
• Report results to the risk committee or board and minute the discussion.

Frequently asked questions.

If a supervisory visit, PCI DSS assessment or partner due diligence is approaching and your mobile app and its APIs have not been tested since the last major release, that is the place to start. Zencryptix tests banking and fintech applications for institutions in Pakistan and abroad, with testers who hold the hands-on certifications auditors look for, includes one retest in every engagement and issues an attestation letter on a clean retest. See our Mobile Application Penetration Testing service for scope and approach.