SEBI's Cybersecurity and Cyber Resilience Framework, in force since August 2024, now requires most regulated entities to run VAPT annually, with Market Infrastructure Institutions and Qualified Stock Brokers required to run it every six months. The framework also sets a fixed remediation clock: high-severity findings tied to unpatched systems must be closed within a week, and every VAPT finding needs to be closed within three months and revalidated within five. On top of that, the report itself has to follow a standardized submission format, accompanied by a declaration from the MD or CEO confirming compliance. The Bombay Stock Exchange issued a circular in May 2026 formalizing exactly this submission cycle for the 2025-26 financial year.
That level of specificity says something important about where penetration testing has landed as a discipline. A test report is no longer a technical document that lives in a security team's inbox. It is increasingly a regulatory artifact with a named executive's signature attached to it, and it has to survive scrutiny from an auditor or a regulator who was not in the room when the testing happened. Getting there requires more than running a scanner and listing what it found.
Here is where a lot of engagements fall short before the technical work even starts. Penetration testing methodology and scope definition are usually treated as paperwork to get through quickly, when they are actually what determines whether the eventual findings are legally defensible, properly authorized, and acceptable to whichever regulator or auditor eventually reads the report. A technically excellent test built on a vague scope, or missing a signed authorization, can create legal exposure for the tester and produce a report nobody can actually use.
This guide covers what penetration testing methodology means in practice, how the major frameworks compare, what a defensible scope document has to include, how current Indian regulation is raising the bar on both testing cadence and reporting quality, what evidence-grade reporting actually looks like, and a readiness playbook for running an engagement that holds up under scrutiny. It is written for security leads, compliance owners, and the engineering teams who have to act on what a report says.
What Penetration Testing Methodology Actually Means
Vulnerability assessment and penetration testing get bundled together as VAPT for a reason, but they answer different questions. A vulnerability assessment identifies weaknesses systematically, through automated scanning, configuration review, and version checks. Penetration testing goes further: a qualified professional attempts to actually exploit the identified weaknesses, chain them together where possible, and demonstrate real business impact rather than a theoretical risk score. Assessment without exploitation misses business-logic flaws and multi-step attack chains that only appear once someone tries to combine smaller issues into something more serious. Exploitation without a systematic assessment first tends to be unfocused and inconsistent from one engagement to the next.
A methodology is what turns that second half, exploitation, into a structured, repeatable process instead of ad hoc hacking. Several established frameworks cover this ground, each with a different emphasis.
Talk to Our Security Experts →
Comparing the Major Methodology Frameworks
| Framework | Best suited for | What it emphasizes |
|---|---|---|
| PTES (Penetration Testing Execution Standard) | End-to-end engagements needing full-lifecycle consistency | A practitioner-focused, seven-phase process running from pre-engagement through reporting |
| NIST SP 800-115 | Government-aligned and regulated environments | Formal documentation and integration with a broader risk management programme |
| OWASP Testing Guide | Web application assessments specifically | Granular, application-focused test cases, 91 of them in version 4.2 |
| OSSTMM | Organization-wide posture, beyond pure technical controls | Physical, human, and wireless factors alongside network and application testing |
| MITRE ATT&CK-aligned testing | Red team and adversary simulation engagements | Mapping test activity to documented, real-world adversary techniques |
None of these fully replaces the others. A consultancy running a full infrastructure engagement often follows PTES for overall structure while pulling in OWASP's specific test cases for any web application inside scope, and layering MITRE ATT&CK mapping on top where the engagement is a red team exercise rather than a standard test.
The Seven Phases of a Professional Engagement
PTES's seven-phase structure is a useful lens for describing what a well-run engagement actually looks like end to end, regardless of which specific framework a provider follows.
| Phase | What happens | Primary output |
|---|---|---|
| 1. Pre-engagement interactions | Scope, rules of engagement, and legal authorization are agreed with the client before any technical work begins | A signed authorization letter and a documented rules-of-engagement agreement |
| 2. Intelligence gathering | Passive and active reconnaissance within the agreed scope | A profile of exposed assets, technology stack, and information footprint |
| 3. Threat modeling | Mapping realistic attack paths against the client's business-critical assets | A prioritized set of attack scenarios worth testing |
| 4. Vulnerability analysis | Identifying and validating technical weaknesses, removing false positives | A confirmed vulnerability list ready for exploitation attempts |
| 5. Exploitation | Controlled, authorized attempts to exploit validated vulnerabilities | Proof that a weakness is genuinely exploitable, not just theoretically present |
| 6. Post-exploitation | Assessing what access or impact a successful exploit actually grants, within the agreed boundaries | A business-impact narrative attached to each successful exploit |
| 7. Reporting | Structuring findings into a prioritized, evidence-backed deliverable | The final report a client, auditor, or regulator can act on |
The first phase and the last phase get the least attention in most discussions of penetration testing, and they are usually where an otherwise technically sound engagement either becomes defensible or becomes a liability.
Scope Boundaries: Why They Matter as Much as the Testing Itself
A scope boundary is not paperwork sitting alongside the real work. It is what separates authorized security testing from unauthorized access under Indian law. Sections 43 and 66 of the Information Technology Act, 2000 make unauthorized access to a computer system a civil and, where done with dishonest or fraudulent intent, criminal matter, punishable with up to three years imprisonment, a fine of up to five lakh rupees, or both. A penetration test without documented, signed authorization covering exactly what may be tested is, in the eyes of that law, indistinguishable from the activity it is meant to simulate.
A properly defined scope covers more than a list of IP addresses. It sets explicit exclusions, systems or techniques the client wants left alone, a testing window that avoids business-critical hours, clear rules on whether live exploitation is permitted or whether testers must stop short of actually triggering an impact, an emergency contact and escalation path in case testing causes unexpected disruption, and the signed legal authorization itself. Testers who discover access extending beyond the agreed boundary during an engagement are expected to stop and seek renewed authorization rather than continue, since exceeding scope, even with good intentions, moves the activity back into the same legal grey area the authorization was meant to resolve.
What a Defensible Scope Document Includes
| Element | Purpose |
|---|---|
| Authorized targets (IP ranges, domains, applications) | Defines precisely what may be tested, and by extension what may not |
| Explicit exclusions | Protects production systems and third-party infrastructure from unintended impact |
| Testing window | Limits the risk of business disruption during critical operating hours |
| Rules on live exploitation versus safe-mode testing | Controls the risk to production data and system availability |
| Emergency contact and escalation path | Ensures a rapid response if testing causes an unexpected effect |
| Signed legal authorization | Establishes the lawful basis for testing under the IT Act, protecting both tester and client |
Where Regulation Is Raising the Bar on Methodology and Reporting
The SEBI framework described at the outset is not an isolated example. The RBI's Directions, 2026 set a six-monthly vulnerability assessment requirement for banks, non-banking financial companies, and payment aggregators under its own cybersecurity framework, a cadence that, where scope covers the relevant systems, can satisfy SEBI's CSCRF obligations too for entities regulated by both bodies. PCI DSS Requirement 11.4 sets out its own penetration testing mandate for any organization handling payment card data, independent of either Indian regulator. Where these frameworks converge is on a shared expectation: testing has to be performed by a qualified party against a recognized methodology, findings need to be tracked to remediation on a defined timeline, and the resulting report has to be submittable in a form the regulator can actually use as evidence of compliance, not just a narrative summary of what a team found interesting.
That convergence changes what counts as an acceptable outcome for an engagement. A technically thorough test that produces a report nobody can submit to an auditor, or one that lacks the reproduction detail an engineering team needs to actually fix what was found, has not fully done its job even if every vulnerability was genuinely identified.
Evidence-Grade Reporting: What Separates a Defensible Report from a Scan Printout
A report built to survive scrutiny needs several elements a raw vulnerability scan output does not provide on its own. Consistent severity scoring, typically using CVSS, lets findings from different engagements or different testers be compared on the same scale rather than relying on subjective labels. Proof-of-concept evidence, screenshots, logs, and timestamps demonstrating that exploitation genuinely occurred, needs to exist for every claimed finding, handled with the same access control and retention discipline as any other sensitive security artifact given what it reveals about the target environment. Reproduction steps detailed enough for the client's own engineering team to verify a finding and confirm a fix, rather than requiring the original tester to be re-engaged for every question, are what actually get a vulnerability closed rather than argued about.
A business-impact narrative attached to each finding, translating a technical flaw into what it would actually mean if exploited, financial loss, data exposure, operational disruption, is what makes a report usable by leadership rather than only by the engineering team that has to fix the underlying issue. That is also why a report needs a clear separation between an executive summary written for board-level and MD or CEO consumption and the technical findings section written for the people doing the remediation work; conflating the two audiences into one document tends to serve neither well. Finally, a retest or verification step, confirming that a previously reported finding has actually been closed rather than simply marked resolved in a tracker, closes the loop that SEBI CSCRF's own five-month revalidation window is built around.
Report Sections and Their Intended Audience
| Report section | Primary audience | Purpose |
|---|---|---|
| Executive summary | Board, MD or CEO, non-technical leadership | A high-level risk picture and compliance status at a glance |
| Methodology and scope | Auditors and regulators | Confirms the test followed a recognized framework inside an agreed boundary |
| Findings with CVSS scores | Security and engineering leadership | Enables consistent prioritization across findings |
| Proof-of-concept and reproduction steps | Technical and engineering teams | Allows the finding to be verified and fixed without re-engaging the original tester |
| Remediation roadmap | Security and engineering leadership | Converts findings into an owned, dated action plan |
| Retest and verification results | Auditors, regulators, leadership | Confirms that remediation actually closed the gap, not just that it was attempted |
What a Weak Methodology or Report Costs
| Gap | Consequence |
|---|---|
| No signed authorization or rules of engagement before testing | Exposure under IT Act Sections 43 and 66 for both the tester and the commissioning organization |
| Scope that does not match what a regulator will actually require | A rejected SEBI CSCRF or RBI submission, forcing a repeat engagement on a tighter timeline |
| Findings reported without CVSS scoring or business-impact context | A report that sits unprioritized and unread by leadership, stalling remediation |
| No retest or verification step | Reported fixes are never confirmed, and the same vulnerability resurfaces in the next cycle |
| Evidence without adequate reproduction detail | The engineering team cannot independently verify or fix the finding, wasting both the testing spend and the time already invested |
| High-severity findings left open past CSCRF's remediation windows | An audit finding in its own right, on top of whatever the original vulnerability already represented |
A Maturity Model for a Penetration Testing Programme
Most organizations sit somewhere on a five-level path between ad hoc testing and a fully mature, continuously verified programme.
Level 1: Testing happens without written authorization or a fixed methodology, if it happens at all ↓ Level 2: An annual VAPT engagement runs to satisfy a compliance checkbox, with minimal reporting detail ↓ Level 3: A named methodology, PTES, NIST SP 800-115, or OWASP, is followed consistently, with CVSS-scored findings ↓ Level 4: Evidence-grade reporting includes reproduction steps, business-impact narratives, and a tracked remediation roadmap ↓ Level 5: Testing runs on a continuous, release-triggered cadence rather than a fixed annual date, with retest verification built in and findings mapped directly to every applicable regulatory submission
The jump from Level 2 to Level 3, adopting a named, consistently applied methodology rather than treating each engagement as a one-off, is usually what determines whether a programme's reports start holding up under external scrutiny.
A Readiness Playbook for a Defensible Engagement
- Define scope precisely and get it in writing before any testing begins. Verbal agreement on what is in bounds is not sufficient legal cover under the IT Act, and it leaves both parties exposed if a dispute arises later.
- Select a methodology matched to what is actually being tested. OWASP for a web application, PTES for a full-lifecycle infrastructure engagement, NIST SP 800-115 where a formal, government-aligned documentation trail is required.
- Obtain signed authorization establishing the legal basis for the engagement, naming exactly who is authorizing the work and on what authority.
- Set explicit exclusions and a defined testing window before reconnaissance starts, rather than leaving those decisions to be made mid-engagement.
- Require CVSS scoring and a business-impact narrative for every finding, not a severity label alone.
- Separate the executive summary from the technical findings in the final report structure, since the two sections serve different readers with different needs.
- Build a retest or verification step into the engagement from the outset, rather than treating it as an optional add-on once the main report is delivered.
- Map the reporting requirements of every applicable regulator, SEBI CSCRF, RBI, PCI DSS, before finalizing the report template, so one engagement's output can satisfy more than one submission requirement.
Common Mistakes and Edge Cases
Running tests without a written, signed scope and authorization document. Good intentions do not substitute for the legal cover a signed authorization provides under the IT Act.
Treating a vulnerability scan as equivalent to a penetration test. A scan finds known weaknesses systematically; it does not demonstrate whether those weaknesses can actually be chained into something exploitable, which is precisely the gap a genuine penetration test is meant to close.
Reporting a severity label with no reproduction steps or business context. A finding an engineering team cannot independently verify or reproduce tends to sit unresolved regardless of how accurately it was originally identified.
Ignoring the agreed testing window and disrupting production during business-critical hours. This is exactly the failure a properly scoped engagement is supposed to prevent, and it damages trust in the testing programme even when the underlying finding was legitimate.
Treating report delivery as the end of the engagement. Without a retest or verification cycle, there is no confirmation that a reported fix actually closed the gap, and the same vulnerability commonly reappears in the following cycle.
Choosing a methodology mismatched to the target. Running only web-application-focused testing against a broader network and infrastructure environment leaves significant ground uncovered, regardless of how thoroughly the web application itself was assessed.
When to Use What: A Few Decision Points
An in-house red team versus an external penetration testing provider. Several Indian regulatory frameworks require testing to be performed by a specifically empanelled or accredited third party for certain regulated engagements, which effectively decides this question for those specific submissions. Outside of those requirements, an organization with a mature internal red team can run more of its own routine testing, reserving external engagements for independent validation and regulatory submissions where third-party independence carries more weight.
A full-lifecycle engagement versus a targeted web-application assessment. What is actually in scope should decide this. A single web application with no broader infrastructure exposure is well served by a focused OWASP-based assessment. An organization's wider network and infrastructure estate needs the fuller PTES-style lifecycle to cover ground a web-application-only methodology was never built to reach.
Annual testing versus a continuous, release-triggered cadence. A slow-moving, infrequently updated system may reasonably stay on an annual cycle. An environment with frequent releases, or one falling under a framework like SEBI CSCRF that expects additional testing cycles tied to major changes, needs a cadence that matches how often the underlying system actually changes.
Black-box, grey-box, or white-box testing. Black-box testing, with no internal knowledge shared, most closely simulates an external attacker starting from zero information. Grey-box testing, with some internal knowledge provided, tends to surface more issues in the time available since testers spend less time on pure reconnaissance. White-box testing, with full internal access and documentation, goes deepest but simulates the least realistic attacker starting position. The right choice depends on whether the goal is realism or thoroughness within a fixed budget.
How SecNinjaz Fits Into This
Penetration Testing sits within SecNinjaz's Cybersecurity practice alongside Vulnerability Assessment, Red Teaming, Purple Teaming, Breach and Attack Simulation, Social Engineering, and AI and LLM Security Testing, giving an engagement access to the full methodology stack this guide describes rather than a single fixed test type applied regardless of what is actually in scope. The regulatory mapping side, matching an engagement's scope and reporting format to SEBI CSCRF, RBI, or ISO 27001 requirements specifically, runs through SecNinjaz's GRC and DPDP practice, including Audit and Gap Assessment.
SecNinjaz holds ISO/IEC 27001:2022 certification, which matters here beyond the credential itself: an information security management system built to that standard shapes how evidence from a penetration test, findings, proof-of-concept material, and remediation records, gets handled internally with the same access control and retention discipline the standard requires elsewhere. For organizations that need a testing engagement built to survive a regulator's or an auditor's scrutiny rather than only their own internal review, that combination of methodology depth and governance discipline is the pairing worth looking for, whether the organization works with SecNinjaz or anyone else.
Talk to Our Security Experts →
Frequently Asked Questions
What is the difference between vulnerability assessment and penetration testing?
A vulnerability assessment identifies weaknesses systematically through scanning, configuration review, and version checks. Penetration testing goes further, with a qualified professional attempting to actually exploit identified weaknesses and chain them together to demonstrate real business impact. The two are commonly paired as VAPT because assessment alone misses chained and business-logic flaws, while exploitation without a systematic assessment first tends to be inconsistent.
What are the main penetration testing methodologies?
The most widely used frameworks are PTES, a seven-phase, practitioner-focused standard covering the full engagement lifecycle; NIST SP 800-115, a formal, government-aligned guide for information security testing; the OWASP Testing Guide, focused specifically on web application security; OSSTMM, which extends testing to physical and human factors alongside technical systems; and MITRE ATT&CK-aligned testing, used mainly for red team and adversary simulation engagements.
Why does scope definition matter as much as the technical testing?
Sections 43 and 66 of the IT Act, 2000 make unauthorized access to a computer system a civil and potentially criminal matter. A signed scope and authorization document is what establishes that a penetration test is lawful security testing rather than the exact activity the law prohibits. Testing that exceeds an agreed scope, even with good intentions, moves back into that same legal exposure.
What does a penetration testing report need to include to be considered evidence-grade?
Consistent severity scoring such as CVSS, proof-of-concept evidence for each finding, reproduction steps detailed enough for an engineering team to verify independently, a business-impact narrative alongside the technical description, a clear separation between the executive summary and technical findings, and a retest or verification step confirming that reported fixes were actually effective.
How often does regulation require penetration testing in India?
Under SEBI's Cybersecurity and Cyber Resilience Framework, most regulated entities must run VAPT annually, while Market Infrastructure Institutions and Qualified Stock Brokers must run it every six months. The RBI's Directions, 2026 set a six-monthly vulnerability assessment requirement for banks and non-banking financial companies. High-severity findings tied to unpatched systems under CSCRF must be closed within one week, with all findings closed within three months and revalidated within five.
What is the difference between black-box, grey-box, and white-box testing?
Black-box testing gives the tester no internal knowledge of the target, most closely simulating an external attacker. Grey-box testing provides some internal information, which tends to surface more findings within a fixed testing window since less time goes into pure reconnaissance. White-box testing gives full internal access and documentation, allowing the deepest coverage but simulating the least realistic attacker starting position.
Why is a retest step necessary after a penetration test?
A reported fix is not confirmed simply because a ticket was marked resolved. A retest verifies that the remediation actually closed the vulnerability rather than only appearing to. Frameworks such as SEBI's CSCRF build this expectation directly into their remediation timelines, requiring findings to be revalidated within a set window after the initial closure deadline.
Where should an organization start if it has never run a formally scoped penetration test before?
Start by defining scope precisely and putting it in writing, including explicit exclusions and a signed authorization, before any technical work begins. Selecting a methodology matched to what is actually being tested, and requiring CVSS-scored, business-impact-linked reporting from the outset, prevents the two most common failures: legal exposure from an unclear scope and a report that leadership and engineering teams cannot actually act on.
