Pakistan Information Security Framework (PISF) Compliance
The Pakistan Information Security Framework (PISF) defines national cybersecurity controls,
including web application security and a secure SDLC. Learn how ImmuniWeb helps you comply.
Pakistan Information Security Framework (PISF) Compliance
The Pakistan Information Security Framework (PISF) is the national cybersecurity framework published by PKCERT, Pakistan's National Computer Emergency Response Team. It groups security requirements into domains and controls that organizations are expected to adopt — and to evidence during audits — to protect their systems, applications and data. Among them, the application-security controls under Domain 11 are directly relevant to any organization that builds or runs web and mobile applications. The official framework is published on the PKCERT website (pkcert.gov.pk).
What Is the Pakistan Information Security Framework (PISF)?
PISF is Pakistan's national framework for information security, published by PKCERT (the National CERT, established in 2024 and operating under the Cabinet Division). It translates national cybersecurity expectations into a structured set of domains, each containing specific, auditable controls that organizations implement to protect their information assets.
PISF is designed around real-world adoption: organizations perform a gap assessment against the controls, build an implementation roadmap, and prepare for formal audits. To support this, PKCERT has introduced a registration scheme for cybersecurity consultants across IT security, operational technology (OT) security and cloud security, organized into professional tiers — so that gap assessments and audit-readiness work are carried out to a consistent standard.
PISF sits within Pakistan's broader cybersecurity reforms, including the Cybersecurity Act 2025, which establishes the National Cybersecurity Authority (NCA) and expands PKCERT's mandate for national incident response and threat intelligence.
How PISF Fits Into Pakistan's Cybersecurity Landscape
PISF does not exist in isolation. It complements national initiatives and sector rules, and it aligns conceptually with international standards, which makes it familiar to organizations already working toward ISO 27001 or NIST:
- PKCERT & NCA: national incident response, advisories and threat intelligence; PISF is the control framework organizations align to.
- Cybersecurity Act 2025: creates the National Cybersecurity Authority and strengthens national obligations.
- Sector expectations: financial institutions also work to the State Bank of Pakistan's security expectations; PISF provides a common baseline across sectors.
- International alignment: PISF's control-and-domain model mirrors ISO/IEC 27001 and the NIST Cybersecurity Framework, and its application-security controls map cleanly to the OWASP Top 10 and secure-SDLC best practice.
Who Must Comply with PISF?
PISF is aimed at organizations whose security materially affects national resilience, and at the suppliers that serve them:
- Government bodies and public-sector entities.
- Operators of critical national infrastructure (energy, telecom, transport, etc.).
- Financial services — banks and fintech, complementing State Bank of Pakistan expectations.
- Technology suppliers and vendors that build or operate systems and applications for the above.
In practice, compliance is a cycle: a gap assessment against the PISF controls, an implementation roadmap to close gaps, evidence collection, a formal audit, and ongoing monitoring. Any organization that develops or runs internet-facing web and mobile applications handling sensitive data will need to satisfy the Domain 11 application-security controls.
How PISF Is Structured: Domains and Controls
PISF organizes requirements into numbered domains, each holding individual controls identified by codes (for example, the application-security domain referenced in this page is Domain 11). Controls describe a specific, testable expectation — what must be in place and demonstrable to an auditor.
This page focuses on the two controls most relevant to application security: EDC-WAS-07.6 (Web Application Security) and ESSDLC-SDLC-2.1 (Secure Software Development Life Cycle). The exact wording of each control should always be taken from the official PISF document published by PKCERT.
PISF Application-Security Requirements in Depth
EDC-WAS-07.6 — Web Application Security
This control addresses the security of web applications: organizations are expected to protect web apps against common vulnerabilities and to test them regularly. In practice this means defending against the OWASP Top 10 (injection, broken access control, authentication flaws and more), validating input and encoding output, securing sessions and APIs, and verifying — through testing — that these protections actually hold before and after release.
ESSDLC-SDLC-2.1 — Secure Software Development Life Cycle
This control requires security to be embedded across the software development life cycle rather than bolted on at the end. That means threat modelling and security requirements up front, secure coding and code review during development, security testing before release, and continuous testing in CI/CD — the “shift-left” approach also known as DevSecOps.
Common Web Application Vulnerabilities PISF Expects You to Address
The application-security controls map closely to the OWASP Top 10 — the industry-standard list of the most critical web application risks. Auditors and attackers both look for them:
- Broken Access Control — users reaching data or actions they should not.
- Cryptographic Failures — weak or missing encryption exposing sensitive data.
- Injection — SQL, command or other injection via unvalidated input.
- Insecure Design — missing security controls by design, not just by bug.
- Security Misconfiguration — default, incomplete or unsafe configuration.
- Vulnerable & Outdated Components — unpatched libraries and frameworks.
- Identification & Authentication Failures — weak login, session or credential handling.
- Software & Data Integrity Failures — untrusted updates, insecure CI/CD pipelines.
- Security Logging & Monitoring Failures — attacks going undetected.
- Server-Side Request Forgery (SSRF) — the server tricked into making malicious requests.
For mobile apps, the equivalent reference is the OWASP Mobile Top 10 (insecure data storage, insecure communication, weak cryptography, and so on). Reliably finding these issues requires testing the running application — not just a documentation review.
Building a Secure SDLC for PISF (ESSDLC-SDLC-2.1)
A secure SDLC integrates a security activity into every phase. This is what an auditor expects to see evidenced:
| SDLC phase | Security activity | ImmuniWeb |
|---|---|---|
| Requirements | Security requirements, threat modelling | - |
| Design | Secure architecture & design review | - |
| Implementation | Secure coding standards, code review | - |
| Testing | DAST, manual penetration testing | On-Demand, Neuron, MobileSuite, Neuron Mobile |
| Release / CI-CD | Automated testing gates in the pipeline | Continuous |
| Operations | Continuous scanning, periodic re-testing, ASM | Continuous, Discovery |
How to Prepare for a PISF Audit (Step-by-Step)
- Scope your assets. Inventory internet-facing web apps, APIs and mobile apps with attack surface management (ImmuniWeb Discovery).
- Run a gap assessment of your applications against the Domain 11 controls (web app security, secure SDLC).
- Test web applications with manual penetration testing (On-Demand) and automated scanning (Neuron).
- Test mobile applications with MobileSuite and Neuron Mobile.
- Remediate and retest using actionable, zero-false-positive reports to produce audit evidence.
- Embed testing in CI/CD with Continuous to satisfy the secure-SDLC control on an ongoing basis.
- Maintain evidence with continuous monitoring and periodic re-testing between audits.
How ImmuniWeb Helps You Achieve PISF Compliance
ImmuniWeb directly supports the Domain 11 application-security controls with testing that produces clear, audit-ready evidence.
| Requirement | What it requires | ImmuniWeb products |
|---|---|---|
| EDC-WAS-07.6 | Secure and regularly test web applications against vulnerabilities (OWASP Top 10), with timely remediation. | ImmuniWeb On-Demand, Neuron, Continuous |
| ESSDLC-SDLC-2.1 | Embed security testing into every phase of the SDLC (DevSecOps, CI/CD). | ImmuniWeb Continuous, Neuron, On-Demand |
ImmuniWeb On-Demand delivers manual web application penetration testing with a zero-false-positives SLA and compliance-ready reporting. ImmuniWeb Neuron and Neuron Mobile provide automated web and mobile scanning. ImmuniWeb MobileSuite covers full mobile penetration testing. ImmuniWeb Continuous embeds testing into CI/CD for a secure SDLC, and ImmuniWeb Discovery maps your external attack surface so no application is left untested.
PISF vs International Frameworks
If you already work to international standards, PISF will feel familiar — and the same ImmuniWeb testing supports all of them:
| Framework | Application-security angle | How ImmuniWeb maps |
|---|---|---|
| PISF (Pakistan) | Domain 11: web app security + secure SDLC | Web/mobile pentest, scanning, CI/CD testing |
| ISO/IEC 27001 | Annex A technical controls | Penetration testing & scanning as control evidence |
| NIST CSF 2.0 | Protect / Detect functions | Application testing & continuous monitoring |
| PCI DSS 4.0.1 | Req 6 (secure dev) & Req 11 (testing) | Web app pentest + vulnerability scanning |
| OWASP ASVS | Verification levels for web apps | Testing aligned to ASVS requirements |
Penetration Testing vs Security Scanning for PISF
Both are needed. Automated scanning (DAST) gives broad, frequent coverage and is ideal for continuous testing in CI/CD; manual penetration testing finds business-logic and complex vulnerabilities that scanners miss and produces the depth auditors expect. For PISF, combine continuous scanning with periodic manual penetration testing — and re-test after significant changes.
PISF Compliance Checklist (Application Security)
- Full inventory of internet-facing web apps, APIs and mobile apps
- Web applications tested against the OWASP Top 10
- Mobile applications tested against the OWASP Mobile Top 10
- Security testing integrated into the CI/CD pipeline (secure SDLC)
- Findings remediated and re-tested, with evidence retained
- Continuous monitoring and periodic re-testing in place
- Audit-ready reports mapped to Domain 11 controls
Why PISF Compliance Matters
PISF is becoming the common reference for security maturity in Pakistan, especially for the public sector, critical infrastructure and financial services. Demonstrating conformity supports government and enterprise contracts, audits and regulatory relationships, and signals trustworthiness to partners and customers.
It also addresses real risk. Pakistan has seen high-profile data exposures, and web and mobile applications remain among the most exploited entry points for attackers. Meeting the Domain 11 controls — through real testing, not paperwork — materially reduces the chance of a breach, service disruption, financial loss and reputational damage.
Frequently Asked Questions
Glossary
- PKCERT —Pakistan's National Computer Emergency Response Team — publisher of PISF.
- NCA — National Cybersecurity Authority, established under the Cybersecurity Act 2025.
- Domain / Control — PISF groups requirements into domains; each control is a specific, auditable expectation.
- Secure SDLC — A software development life cycle with a security activity built into each phase.
- DAST —Dynamic Application Security Testing — testing a running application for vulnerabilities.
- Penetration testing — Manual, expert-led testing that finds complex and business-logic vulnerabilities.
- OWASP Top 10 — The industry-standard list of the most critical web application security risks.
- Gap assessment — A review of current controls against PISF to identify what is missing before an audit.