About methodology
"What methodology do you follow?" Look for alignment with recognised standards — OWASP for web and API testing, PTES (Penetration Testing Execution Standard), or NIST SP 800-115. A provider who can't clearly describe their methodology likely doesn't have a rigorous one. "Is this manual testing, automated scanning, or both?" Get this in writing. Some providers market automated scans as "penetration testing" — a meaningful difference in depth and cost that should be transparent upfront. See automated scanning vs manual penetration testing for what each actually covers. "What's explicitly in scope, and what's excluded?" Scope should be documented clearly before testing begins, not interpreted loosely afterward.
About the testers
"Who will actually be performing the test, and what are their qualifications?" Ask about relevant certifications (OSCP, CREST, CEH, or equivalent) and hands-on experience with your specific technology stack — testing a cloud-native app requires different expertise than testing on-premises infrastructure. "Will the same team handle scoping, testing, and reporting?" Continuity matters. A tester who understands the context from scoping through to the final report tends to produce more accurate, relevant findings than a fragmented handoff between teams.
About the deliverable
"Can I see a sample report (redacted)?" This is the single most revealing question you can ask. A sample report shows you exactly what you're paying for — see what a penetration testing report should include for what to look for. "How are findings prioritised — by CVSS score, business impact, or both?" A report that ranks everything by raw CVSS score alone often misprioritises what actually matters to your organisation. "Is retesting included after remediation?" Confirming a fix actually worked is as important as finding the issue in the first place. If retesting isn't included, ask what it costs separately.
About logistics and communication
"What happens if a critical vulnerability is found mid-test?" A reputable provider will flag critical, actively-exploitable findings immediately — not wait for the final report weeks later. "How do you handle testing in production environments?" Ask about safeguards against downtime or data corruption, especially for live, customer-facing systems. "What's your incident response if something goes wrong during testing?" Testing carries some inherent risk. A provider should have a clear plan if an exploit causes unintended disruption.
About compliance fit
"Does this engagement satisfy [specific framework] requirements?" If you need the test for ISO 27001, NIST CSF, PCI-DSS, or a regional regulatory requirement, confirm explicitly that the scope and methodology will actually satisfy that specific standard — not just "cybersecurity testing" in general terms.
A quick red flag checklist
- Vague answers about methodology or certifications
- Reluctance to share a sample report
- Pricing that seems too low for genuine manual testing at your scope
- No mention of retesting or post-engagement support
How XDefense helps
XDefense welcomes every question on this list before an engagement begins — our methodology, tester qualifications, and reporting approach are built to hold up to exactly this kind of scrutiny. For organisations across Qatar and Kuwait evaluating VAPT providers, we're happy to walk through a sample report and explain precisely how our process fits your compliance requirements.