PISF turns security in Pakistan from something organisations were encouraged to do into something they are expected to evidence. What the framework covers, who it applies to, and where to start if you are beginning from very little.
For most of the last decade, security in Pakistan was a matter of persuasion. You could argue for a budget on the grounds that an incident would be expensive, and if the person across the table was unconvinced, that was usually the end of it. There was no external party who would eventually ask.
That has changed. The Pakistan Information Security Framework sets a national baseline for information security, and it arrives alongside a set of directives that carry timelines rather than encouragement. The argument is no longer whether security is worth doing. It is whether you can show what you have done.
That is a harder question, and a great many organisations who genuinely are secure will struggle with it, because being secure and being able to prove you are secure have never been the same skill.
PISF is a control framework. It describes what an organisation is expected to have in place, organised into domains, with individual controls carrying their own reference codes. If you have worked with ISO 27001 Annex A or the NIST Cybersecurity Framework, the shape will be familiar, because PISF was built to sit alongside them rather than compete with them.
That decision matters more than it sounds. A national framework invented from scratch would have forced every organisation with existing certification to run two parallel programmes forever. Instead the overlap is substantial, which means the work you have already done is mostly reusable, and the gap you need to close is smaller than the page count suggests.
The framework is published by the national CERT, and organisations in scope should read it directly rather than relying on any summary, including this one. Frameworks get revised, and the version you are audited against is the one on the official site on the day.
The scope is broader than people expect on first reading. Government bodies and regulatory authorities are the obvious population. Critical national infrastructure follows, which takes in energy, telecommunications, transport and water. Financial services sit inside it, where PISF overlaps with what the State Bank already expects of banks.
Then there is the category that catches organisations by surprise. If you supply technology or services into any of the above, the obligation reaches you commercially even where it does not reach you legally, because the organisation you serve has to evidence its supply chain and will pass the question down. A small software house with three public sector clients is inside this whether or not it considers itself in scope.
A framework aimed at national infrastructure never stops at national infrastructure. It travels down every contract that touches it.
There is a reasonable objection to national frameworks, which is that ISO 27001 already exists and is internationally recognised, so why build another one.
The answer is that a certificate is not the same as a floor. ISO 27001 certifies that an organisation has a management system appropriate to a scope it defined itself. Two certified organisations can have very different security postures, and both certificates are valid, because the standard certifies the process rather than the outcome. That is workable for a buyer who can read a statement of applicability. It is useless as a national baseline.
A country with a growing digital economy and a rising volume of attacks needs something that says what the minimum is, uniformly, for the organisations whose failure would be felt beyond their own balance sheet. The national CERT has reported hundreds of incidents against Pakistani organisations across the last two years, and the ones that made the news were not the ones with mature programmes.
There is also a sovereignty argument that has nothing to do with defence posturing. When a country's hospitals, banks and grid operators are assessed against a framework written elsewhere, audited by firms accredited elsewhere, and hosted on infrastructure operated elsewhere, the country has limited visibility into its own risk. PISF is one part of a wider move that also takes in cloud residency policy and SOC accreditation, and the through line in all of it is that Pakistan wants to be able to see its own exposure.
Whether you find that argument compelling or not, it is the reason the framework exists, and it explains why the obligations lean towards demonstrable evidence rather than attestation.
Reading any control framework for the first time is discouraging, because the volume looks impossible. It helps to know that the controls cluster into a small number of recurring demands.
You are asked to know what you have. An asset inventory covering systems, data and who owns each one. Almost nothing else in the framework can be evidenced without this, and it is the single most common thing organisations are missing.
You are asked to control who can reach it. Identity, access, privilege, and a review that actually happens rather than a policy saying it should.
You are asked to watch it. Logging, monitoring, and the ability to notice something going wrong without a customer telling you first.
You are asked to be able to respond. A plan, named people, and evidence that the plan has been exercised rather than filed.
You are asked to build securely. Where you develop software, security belongs inside the development lifecycle rather than in a test at the end, and applications are expected to be tested against common vulnerability classes regularly rather than once.
And underneath all of it, you are asked to keep records. This is the part that separates organisations who pass from organisations who are surprised.
You are in a good position and you are not finished.
The overlap does real work. Your policies, your risk methodology, your asset register and your management review will map across with editing rather than rewriting. Expect a large share of the control set to be satisfied by what you already run.
What tends not to map is the evidence expectation. An ISO audit samples. A national baseline with a third party audit provision behind it is a different conversation, and the gap that opens is usually not a missing control but a control that genuinely operates and has never been recorded operating. The access review that happens every quarter in a meeting nobody minutes is a real control and an unevidenced one, and only one of those survives an audit.
This is the same problem we wrote about in what a regulator actually wants to see, and the answer has not changed. The record is the control.
Not the technology. The bookkeeping.
By the time an assessment arrives, a mature programme has produced thousands of artefacts. Configuration exports, test reports, review minutes, training records, tickets, approvals. They live wherever the person who created them put them, named however made sense at the time, and the relationship between a given artefact and the control it proves exists only in somebody's memory.
Then that person changes role, and the organisation discovers that it cannot prove things it definitely did.
Solving this is unglamorous and it is most of the work. Evidence needs to be attached to the control it satisfies at the moment it is created, and it needs a named person who accepted it. Done that way, an audit is a retrieval exercise. Done the other way, an audit is an archaeology project with a deadline.
We built CyberNexus around exactly this problem, holding assessment, evidence, review and corrective action as one record so that a control marked closed is closed against something a named reviewer accepted. ControlGraph takes the next step and holds the control once, linked to every obligation that asks for it, so evidence gathered for ISO counts for PISF at the same moment rather than being gathered twice.
If you would rather start with people than platforms, our GRC and compliance practice runs the gap assessment and builds the roadmap, and our VAPT team covers the application and infrastructure testing the framework expects on a recurring basis. If monitoring is your gap, SOC design and monitoring is where that conversation starts.
We are a Pakistani company and this is our own national framework. We would be building towards it whether or not it were commercially interesting.
Do not begin with the control list. Beginning with the control list produces a spreadsheet with hundreds of red rows and a team that loses heart in week two.
Begin with an asset inventory, because nothing else can be evidenced without one, and because building it will tell you things about your own estate that you did not know. Most organisations find systems nobody owns.
Then take ten controls, not two hundred. Pick the ten where failure would hurt most, evidence those properly, and learn what evidencing properly costs you. That number is the one you need in order to plan the rest honestly, and you cannot get it from a framework document.
PISF is Pakistan's national information security framework. It sets a baseline of security controls, organised into domains, that public sector bodies, critical infrastructure operators, financial institutions and their suppliers are expected to implement and evidence.
Government and regulatory bodies, critical national infrastructure across sectors such as energy, telecommunications and transport, and financial services. Suppliers to those organisations are pulled in through contracts even where the framework does not name them directly.
No. They do different jobs and they are designed to coexist. ISO 27001 certifies a management system against a scope you define. PISF sets a national minimum. Existing ISO work maps across substantially, which is why the frameworks were aligned rather than kept separate.
It depends almost entirely on whether you have an asset inventory and a habit of keeping evidence. An organisation with both can move in months. An organisation with neither should expect the inventory alone to take a meaningful part of the first quarter, and should plan around that rather than against it.
Broadly, an asset inventory, test reports mapped to specific controls, remediation records showing what was fixed and when, and proof that monitoring and testing are ongoing rather than one off. The recurring theme is that a control is only counted where it can be shown operating.
Pakistani organisations have been told to stand up security operations centres on a short timeline. Most of what gets built under that pressure watches everything and catches nothing. What a working SOC needs first.
Read the article
Moving data inside the country satisfies the letter of a residency rule and often changes very little about who can actually reach it. What the harder questions are, and what to ask a cloud provider before signing.
Read the article
Encrypted traffic is being collected today by people who cannot read it yet and expect to later. If your data still matters in ten years, that is a problem you already have rather than one you will get.
Read the articleIf this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.
