A founder we know forwarded us an email last week from his US client, a SaaS company in Austin. It said, almost casually: "Before we can sign the MSA, please share your most recent VAPT report or third-party pentest, plus a letter of attestation." Under it, a one-line message from him: "What does this actually mean? Can I just send them the Nessus scan I ran on staging?"

Short answer: no. Long answer is this post. If you're the CEO or tech lead of a Pakistani software house and you're reading this with a client email open in another tab, this is for you. We're going to walk through, in plain English, what your overseas client's vendor-risk team is actually asking for, why they're asking, what they'll silently judge your document against, and what you should (and should not) send back.

None of this is meant to be intimidating. The buyer wants to work with you. The email isn't a rejection; it's a checklist item procurement has to clear before the contract lands on legal's desk. Once you understand the shape of the ask, it stops looking like a scary security audit and starts looking like paperwork, paperwork you can absolutely produce.

The order a client's security team reads a VAPT report: executive summary first, then severity breakdown, remediation status, scope and methodology, and the attestation letter.
Fig. What a reviewer actually reads first, in order.

Why they're asking (this isn't paranoia)

Your client is not asking because they suddenly distrust you. They're asking because their own auditor is asking. If they sell to enterprises in the US, UK, or EU, they're almost certainly going through SOC 2 Type II, ISO 27001, HITRUST, or rolling customer security questionnaires. Each one requires a vendor inventory and, for any vendor touching production systems or customer data, evidence that the vendor has been independently security-tested.

You (the dev shop in Lahore or Karachi or Islamabad) are a vendor in their evidence chain. Your pentest report is their evidence. No evidence, no procurement sign-off. No procurement sign-off, no contract. It really is that mechanical. The person emailing you might not even understand half of what they're asking for; they're just copying a line out of their vendor-risk template because their compliance lead told them to.

This is good news. You don't have to defeat a security expert. You have to produce a document that ticks the boxes their auditor will tick when reviewing the vendor folder six months from now.

What "VAPT report" actually means in this context

VAPT stands for Vulnerability Assessment and Penetration Testing. To a Pakistani dev shop hearing the term for the first time, it might sound like two separate things: a scanner run, plus a manual test. To a US or European procurement person, "VAPT report," "pentest report," "third-party security assessment," and "external security audit" are completely interchangeable. They mean one thing: a written document, produced by an independent party (i.e. not your own developers), describing what was tested, what was found, what was fixed, and accompanied by a signed statement of attestation.

That last word (independent) is the part most software houses miss. A Nessus scan you ran yourself on your own staging server doesn't count. Not because Nessus is bad (it's a fine tool), but because the scan was run by you, on a system you control, against a target you chose. The whole point of vendor risk is that an outside party with no skin in the game looked at the system and signed their name to the findings. If your own dev lead ran the scan, you do not have a VAPT report. You have a self-assessment, useful internally, and absolutely not what the auditor will accept.

What they will actually open and read

Here's a small mercy: most of the people on the receiving end will not read your whole 60-page report. They will look at three things, in this order.

1. The Letter of Attestation

This is a one-page signed letter on the tester's letterhead. It states who tested what, when, against which methodology, and that the testing was completed. This is the only piece of paper that goes into the client's SOC 2 evidence folder. Most clients won't even open the full report. Their auditor, however, will demand the letter, and will reject anything that doesn't have a name, a date, a signature, and a clearly identified tester.

2. The Executive Summary

This is page one of the full report. It should say, in one paragraph, something like: "During the period of 12–16 March 2026, VAPT.PK conducted a black-box and authenticated grey-box assessment of [client app]. Five high, eight medium, and twelve low findings were identified. All highs and six of eight mediums have been remediated and re-verified. The system is considered production-ready, with remaining items tracked in the vendor's risk register." That's it. That's the only paragraph the client's CISO will read.

3. The Findings Table

Whoever does open the full report will skim straight to the findings table looking for one thing: are any High or Critical findings still open? If yes, the contract gets put on hold until they're fixed. If no, they close the PDF and forward it to legal with a thumbs-up. This is genuinely how it works.

The 7-question checklist they're applying to your report

While the vendor-risk analyst on the other side is reading your document, they are silently running through a mental checklist. If you understand the checklist, you understand what a "good" report looks like. Here are the seven questions they will ask:

  1. Was it done by an independent party? Your own devs scanning your own code does not count. The tester's name and company should appear on the letterhead, and it should not be your company.
  2. When was it done? Anything older than 12 months is almost always rejected. Six months is the comfortable window. If the test is from 2024 and we're in 2026, expect them to ask for a fresh one.
  3. What was in scope? They want to see your production URLs, your real APIs, your live mobile build. Not "we tested the staging environment we set up just for this." Scope mismatch is the most common reason reports get bounced.
  4. What methodology was used? They want to see OWASP (Top 10 / ASVS / WSTG), PTES, or NIST SP 800-115 named explicitly. At least one. If your report doesn't name a methodology, it doesn't look like a real pentest to them.
  5. How were findings rated? CVSS 3.1 is the universally safe answer. "High / Medium / Low" with no underlying scoring framework looks amateurish.
  6. Have the highs been fixed? The report should show remediation status: Fixed and re-verified, Fix in progress, or Accepted as residual risk with a reason. Open Highs kill deals.
  7. Is there a signed attestation? Letterhead, named tester, date, signature, scope, methodology. One page. Without this, none of the rest matters.

Pass all seven and the contract moves. Fail two or more and you'll get a polite follow-up asking for clarifications, which usually translates to a four-to-six-week delay you can't afford.

What to send them, and what NOT to send

When the report is ready, keep the response simple and professional. Don't over-explain, don't apologise, don't include twelve attachments.

Send

  • The Letter of Attestation as a standalone, single-page PDF. This is the one they'll forward to their auditor.
  • The full report as a separate PDF. Password-protect it if it contains PII, internal hostnames, or detailed exploitation paths. Send the password in a second email or over Slack.
  • A short cover note: "Attached are the Letter of Attestation and the full assessment report from our most recent engagement. Happy to schedule a 30-minute call with our security partner to walk your team through the findings if useful." Offering the call signals confidence and almost always wins points even if they never take you up on it.

Don't send

  • Raw Burp Suite or Nessus or Acunetix output. It's noisy, full of false positives, and screams "we don't know what we're doing."
  • Screenshots with real customer data unredacted. This will fail their data-handling check on the spot.
  • Your devs' internal Slack discussion or Jira tickets about the findings. That's your internal mess; keep it internal.
  • Vague promises like "we'll have something in two weeks." If you don't have a report yet, see the next section. Promises in writing are how trust evaporates.

If you don't have a pentest yet

Be honest. Pakistani software houses lose more deals by sending bad evidence than by admitting they need a couple of weeks. Don't try to dress up something else as a pentest. Specifically:

  • Your SonarQube or CodeClimate code-quality report is not a pentest. Don't send it.
  • Your Cloudflare WAF dashboard screenshot is not a pentest. Don't send it.
  • The ISO certificate of the cloud provider you rent servers from is not your pentest. Don't send it.
  • A free online vulnerability scanner's PDF is not a pentest. Definitely don't send it.

Instead, reply something like: "Thanks for sending this through. We are currently commissioning an independent third-party penetration test with delivery expected within 10 working days. I can send across the Letter of Attestation directly to your security team as soon as it is signed, with the full report to follow. Would that work for your timeline?"

Nine out of ten clients respect this answer. What kills the deal is forwarding a Nessus PDF and hoping no one notices.

What a VAPT.PK engagement gives you to send

When we run an assessment for a Pakistani software house facing one of these client requests, the deliverable is specifically built to survive the seven-question checklist above. Concretely, every Security Audit & Reporting engagement produces:

  • An independent tester who is not on your engineering team, which is the single most important thing the auditor on the other side is looking for.
  • Testing aligned with OWASP WSTG / ASVS for web and API work, PTES for the overall engagement structure, and NIST SP 800-115 references where appropriate.
  • Findings rated using CVSS 3.1, with a clearly labelled severity column.
  • A signed Letter of Attestation on VAPT.PK letterhead, formatted to drop straight into a SOC 2 evidence folder.
  • A full report with executive summary, scope, methodology, findings, evidence, and remediation guidance, the kind of structure overseas vendor-risk teams expect.
  • A retest pass so that fixed highs and mediums are re-verified and the report you hand over isn't littered with "open" items.

Typical turnaround for a standard web application or API engagement is three to five testing days, with the deliverable in your client's hands within seven to ten working days of kickoff. If you have a procurement deadline ticking, tell us when you book and we'll work the schedule backwards from your client's date.

Reality check

We see this same pattern play out every quarter. A Pakistani software house, often with a great team and a solid product, loses a six-figure US contract not because they did anything wrong technically, but because they couldn't produce a credible pentest report within five working days of being asked. The buyer wanted to work with them. The buyer's auditor wouldn't allow it without the evidence. The deal went to a competitor in India or the Philippines who had a report on file.

The hard truth is that in 2026, a current independent pentest report has become standard procurement furniture, exactly like a W-9, a certificate of insurance, or a signed NDA. If you're chasing US, UK, or EU clients, treat it the same way: something you keep current, on the shelf, ready to send in the first reply. The deal you save will be your own.

If you're staring at a client email right now and you're not sure what to send back, that's literally what we're here for. Reply to that client with a timeline, then book a call with us, and we'll get the evidence into their hands before their patience runs out.