Penetration Testing: A Practical Guide to Scoping, Reports and Retests
What penetration testing covers, how VAPT differs, which test types you need, how to scope a test, what a good report contains and how often to retest.
Penetration testing is a controlled, authorised attack on your systems by skilled testers, who try to find and exploit weaknesses before a real attacker does. A good test is scoped to your highest-risk assets, combines automated scanning with manual exploitation, and ends with a prioritised report and a retest that confirms the fixes actually work.
The value of a test depends on the scoping, the skill of the testers and what you do with the findings. This guide covers the decisions a CTO has to make, in the order they come up.
Penetration testing vs VAPT: what is the difference?
In India, most requests for proposal ask for VAPT (vulnerability assessment and penetration testing). The two halves are related but different.
- Vulnerability assessment is broad and largely automated. Scanners check your hosts, applications and cloud configuration against known weaknesses and produce a long list of potential issues.
- Penetration testing is narrower and manual. A tester takes the most promising weaknesses, chains them together and proves what an attacker could actually reach: customer data, admin access, payment flows or internal networks.
A scan tells you a door might be open; a test walks through it and shows what is in the room. You need both. Scanning should run continuously; a manual test is a periodic, deeper exercise.
Types of penetration testing
Most organisations need more than one type of test, depending on where data lives and how customers reach you.
| Test type | What it covers | Typical findings |
|---|---|---|
| Web application | Public and internal web apps, admin panels, authentication and session handling | Broken access control, injection, insecure direct object references, weak session management |
| Mobile application | Android and iOS apps, local storage, the APIs they call | Hardcoded secrets, insecure local storage, missing certificate pinning, trusting the client |
| API | REST, GraphQL and partner APIs, including undocumented endpoints | Missing authorisation checks per object, excessive data exposure, weak rate limiting |
| Cloud | AWS, Azure or GCP accounts, IAM, storage, serverless and Kubernetes | Over-privileged roles, public buckets, exposed management interfaces, weak network rules |
| Network (external and internal) | Internet-facing hosts, VPNs, office and data centre networks | Unpatched services, default credentials, flat networks that allow easy lateral movement |
For most digital businesses, web and API tests carry the most risk, because that is where business logic lives. Scanners miss logic flaws, such as changing an order ID and seeing someone else's invoice; skilled manual testers find them.
Black box, grey box and white box
The second decision is how much the testers know before they start.
- Black box: testers get only a URL or IP range, like an outside attacker. Realistic, but much of the budget goes on discovery rather than depth.
- Grey box: testers get user accounts at different privilege levels and some documentation. This is the most common choice and usually the best value, because it mirrors a malicious customer or a compromised account.
- White box: testers get source code, architecture diagrams and configuration. Slower to prepare, but it finds the deepest issues and suits high-risk systems such as payments or lending decisions.
As a rule of thumb, choose grey box unless you have a specific reason not to.
How to scope a penetration test
A poor scope is the most common reason a test disappoints. Work through these steps before you ask anyone for a quote.
- List your assets and rank them by impact. Which systems hold customer data, move money or would stop the business if compromised? Start there.
- Decide the test types. Web, mobile, API, cloud or network, based on the list above.
- Choose the knowledge level. Black, grey or white box, and prepare the accounts and documents the testers will need.
- Define what is out of scope. Third-party services you do not own, production databases that must not be modified, and any denial of service testing.
- Agree the environment. Testing production is more realistic; testing a faithful staging copy is safer. Many teams test staging and run a lighter pass on production.
- Set rules of engagement. Testing windows, source IP addresses, emergency contacts and what testers must do if they find evidence of a real compromise.
- Get written authorisation. The system owner signs off, and if you use a cloud provider or hosting partner, check their policy on customer-initiated testing.
- Book the retest upfront. Agree a retest window in the same contract so fixes are verified without a second procurement cycle.
Effort scales with the number of roles, features and the complexity of the business logic, not the number of URLs.
What a good penetration testing report looks like
The report is what you are really buying. A good one is useful to three audiences: the board, the engineers and the auditor.
Executive summary
One or two pages in plain language: what was tested, the overall risk posture, the most serious issues and what they would mean for the business. No jargon, and no padding with low-risk findings to look thorough.
Findings with evidence
Each finding should include a clear title, a severity rating (commonly based on CVSS, adjusted for your context), the affected asset, step-by-step reproduction, screenshots or request and response pairs, and the business impact. If your engineers cannot reproduce a finding from the report alone, the report is not good enough.
Practical remediation
Generic advice such as "validate all input" is not remediation. Look for specific guidance tied to your stack, with a suggested priority and, where useful, references to the relevant secure coding guidance.
Methodology and coverage
A good report states what was tested, what was not and why. It should reference a recognised methodology, such as the OWASP testing guides for web, mobile and API work. This section is what an auditor will read most closely.
Be wary of reports that are mostly pasted scanner output; it suggests little manual testing took place.
How often should you run penetration testing?
There is no single right answer, but a sensible baseline for most companies looks like this:
- At least once a year for each critical application and your external perimeter.
- After significant change, such as a new product launch, a major architecture change, a cloud migration or a new payment integration.
- Before audits or large customer security reviews, so you have a recent report and evidence of fixes.
- Continuously for scanning, wired into your CI/CD pipeline and cloud accounts, so the annual test is not your only line of sight.
Teams that ship weekly often prefer smaller, more frequent tests focused on new features.
Penetration testing and compliance
Many frameworks expect regular testing. PCI DSS requires penetration testing for environments that handle card data. SOC 2 and ISO 27001 audits commonly look for evidence of vulnerability management, which usually includes testing. Regulated entities in India, such as those overseen by RBI or SEBI, are typically expected to run periodic VAPT and track findings to closure. Requirements differ by entity and change over time, so treat this as general information, not legal advice, and confirm specifics with your compliance team or auditor. Note too that a penetration test provides evidence for an audit; it is not a certification in itself.
How to choose a penetration testing provider
Quality varies widely. Ask these questions:
- Who will do the testing? Ask for the named testers and their experience with your stack, not just company credentials.
- How much is manual? Ask what proportion of effort is manual exploitation versus automated scanning.
- Can we see a sample report? A redacted sample tells you more than any sales deck.
- How do you handle critical findings? Serious issues should be reported the same day, not saved for the final report.
- How do you protect our data? Ask where test data and evidence are stored, who can access it and when it is deleted.
- Is the retest included? And within what window.
- Do you understand our business? A tester who understands lending, healthcare or marketplaces will find logic flaws that a generalist misses.
Independence matters too: if the team that builds your systems also tests them, ask how they keep the testing objective.
Retesting: closing the loop
A penetration test without a retest is half finished. Once your team has fixed the findings, the testers should try the same attacks again and confirm each issue is resolved, or explain why it is not.
Track findings in your engineering backlog with owners and target dates based on severity. Then ask the deeper question: why did this class of bug get through? Recurring access control issues, for example, usually point to a missing shared authorisation layer rather than a series of individual mistakes. Fixing the pattern is worth more than fixing the instance.
Frequently asked questions
What is penetration testing?
Penetration testing is an authorised simulated attack on your applications, APIs, cloud or network, carried out by skilled testers to find and exploit weaknesses before real attackers do. It goes beyond automated scanning by proving what an attacker could actually reach. The output is a report of findings with evidence, severity and remediation advice.
What is the difference between VAPT and penetration testing?
VAPT combines a vulnerability assessment, which is broad and mostly automated, with penetration testing, which is narrower and manual. The assessment finds potential weaknesses; the penetration test exploits the important ones to confirm real impact. Most organisations need both, with scanning running continuously and manual testing periodically.
How long does a penetration test take?
A focused test of a single web application or API often takes one to two weeks of testing, plus time for reporting. Larger scopes covering several applications, mobile apps and cloud accounts can take several weeks. The timeline depends on the number of features, user roles and environments in scope.
Is penetration testing safe for production systems?
It can be, with clear rules of engagement, agreed testing windows and experienced testers who avoid destructive actions. Many teams test a faithful staging environment in depth and run a lighter, careful pass on production. Always have backups in place and an emergency contact available during testing.
How much does penetration testing cost?
Costs vary widely by scope, from a modest fee for a small single application to a substantial budget for a multi-application, cloud and network engagement. The main drivers are the number of applications and roles, the knowledge level and whether retesting is included. Ask for quotes tied to a written scope so you can compare like with like.
How Sunday Labs can help
Sunday Labs runs security assessments covering web, mobile, API and cloud penetration testing, with grey box testing as the default and a retest agreed in the scope. Testing is done by senior engineers who have built and run production systems, so findings come with remediation your team can actually apply, and our founders review the work weekly. If you also want help fixing what we find, our application security team can work alongside your engineers. To scope your next test, start a conversation.
