VAPT in Pakistan: what a security test should cover, and what to ask before you hire

By the FarSec team · Updated

In short: VAPT is two jobs. A vulnerability assessment finds known weaknesses across everything you own. A penetration test proves which of them an attacker could really use, and how far they would get. A good provider does both, gets your written permission first, and hands you a report your team can act on.

What VAPT means

Vulnerability Assessment (VA) is wide and systematic. Testers map every system you expose (websites, email, VPN, remote desktop, cloud accounts, office network) and check each one for known weaknesses: missing patches, weak settings, default passwords, old software, open services that should be closed.

Penetration Testing (PT) is deep and manual. A tester takes the most promising weaknesses and tries to use them the way a real attacker would: logging in where they should not, moving from one system to the next, reaching data that should be out of reach. The point is to show real impact, not a list of theoretical issues.

A scan alone produces long reports full of noise. A pentest alone can miss whole areas. Together they tell you what is exposed and what actually matters.

What a proper test covers

How a proper engagement runs

  1. Scoping. Agree exactly which systems, IP addresses and apps are in scope, what is off limits, and the testing window.
  2. Written authorisation. You sign a document allowing the test. This matters in Pakistan: unauthorised access to an information system is an offence under the Prevention of Electronic Crimes Act (PECA) 2016. A tester who starts without your signed permission is a warning sign.
  3. Reconnaissance. Testers find what is exposed, often including systems you forgot you had.
  4. Assessment and exploitation. Automated scanning plus manual testing, carefully, so business systems stay up.
  5. Reporting. An executive summary in plain language for management, and a technical section with evidence, risk rating and fix steps for each finding.
  6. Retest. After your team fixes the issues, the tester checks that the fixes work.

10 questions to ask before you hire a tester

  1. Will you test manually, or only run automated scanners?
  2. Who exactly will do the testing, and what is their experience or certification (for example OSCP, CEH, CREST)?
  3. Can I see a sample report with client details removed?
  4. What written authorisation and NDA will we sign before you start?
  5. How do you avoid crashing our live systems, and who do we call if something breaks?
  6. How do you rate risk (critical, high, medium, low), and why?
  7. Will the report tell my IT team how to fix each issue, step by step?
  8. Is a retest included after we fix the findings?
  9. How will you store and delete our data after the engagement?
  10. Do you use subcontractors? If yes, who, and are they bound by the same NDA?

How often should you test?

At least once a year, and again after any big change: a new website or app, a move to the cloud, a new office network, or a merger. Businesses that handle payments, health or customer financial data, or that supply banks and government, usually test more often because their clients or regulators ask for it.

Red flags

What you should get at the end

A clear picture of your real exposure, a prioritised list of what to fix first, evidence your management and auditors can trust, and proof (after the retest) that the important gaps are closed. If the report sits in a drawer, the money was wasted, so ask for findings your team can work through in order.

Want a second pair of eyes? FarSec checks businesses in Pakistan for exactly these gaps and helps fix them. Email [email protected] and tell us what worries you.