VAPT Testing Checklist for Software Testing Teams: Web, API, Mobile and Network
A practical VAPT testing checklist to plan scope, validate vulnerabilities, capture evidence, track remediation, and confirm retesting across web, API, mobile, and network environments.
Table of Contents
Share
<Summary/>
Covers VAPT checks for web applications, APIs, mobile apps, and networks.
Starts with scope, authorisation, environments, user roles, and testing restrictions.
Includes checks for authentication, authorisation, sessions, input validation, business logic, and configuration.
Tracks every test using evidence, findings, remediation status, and retest results.
Combines automated scanning with manual validation before confirming vulnerabilities.
Includes post-testing steps for false-positive removal, remediation tracking, retesting, and closure.
Maps the checklist to frameworks including CERT-In, RBI, SEBI, PCI DSS, ISO 27001, SOC 2, and HIPAA.
Our security testing team at PerfectQA runs every Vulnerability Assessment and Penetration Testing (VAPT) engagement from the same checklist. The structure keeps scope, evidence, and retest status traceable from the first authorisation through closure.
The checklist below covers web applications, Application Programming Interfaces (APIs), mobile applications, and approved network assets. We use it at 4 points in the development lifecycle:
Pre-release assessment before product launch.
Annual or periodic VAPT driven by compliance requirements.
Post-incident review after a breach or near-miss.
Pre-audit preparation before ISO 27001, SOC 2, or regulatory audit.
How Do You Use This VAPT Testing Checklist?
Use this VAPT testing checklist to plan scope, record evidence, track findings, and confirm retesting. Each row represents one security testing action. Keep the same row ID across evidence, findings, and retest records.
Our team uses 5 statuses throughout the assessment.
Status | Meaning |
|---|---|
Not Tested | Testing has not started for this row. |
Pass | Testing found no confirmed issue for this row. |
Finding | Testing produced a confirmed security finding. |
Retest | A reported finding requires verification after remediation. |
Not Applicable | The check does not apply to the approved scope. |
We built this structure around established testing references. The Open Worldwide Application Security Project (OWASP) Web Security Testing Guide (WSTG) covers web security testing. OWASP API Security Top 10 (2023) covers API risks. OWASP Mobile Application Security Verification Standard (MASVS) covers mobile security controls. National Institute of Standards and Technology (NIST) SP 800-115 covers technical security assessment planning.
Which Tools Does Our Team Use for Each Checklist Area?
Each checklist domain uses a different combination of automated and manual tools. The table below reflects our standard stack across PerfectQA engagements.
Checklist area | Our tools |
|---|---|
PRE: Scope and planning | Scope documents, authorisation records. |
WEB: Discovery and configuration | Burp Suite Professional, OWASP ZAP, Nmap. |
WEB: Auth, authorisation, input, logic | Burp Suite (manual interception and replay). |
API: Inventory and authorisation | Burp Suite, Postman, OpenAPI documentation. |
MOB: Storage, crypto, platform | MobSF, Frida, Objection, platform-native tools. |
NET: Discovery and services | Nmap, Nessus, OpenVAS. |
POST: Validation and retesting | Manual reproduction, Burp Suite, OWASP ZAP. |
Scanner output feeds into manual validation before any finding enters the VAPT report. We never ship a scanner alert as a confirmed finding.
The full checklist is available as a downloadable XLSX spreadsheet. The file uses the same IDs, evidence fields, and status columns.
A checklist controls coverage only when the assessment scope is clear. Scope confirmation precedes every active testing action.
What Needs Confirmation Before VAPT Testing Starts?
VAPT testing starts with written scope, authorisation, environments, user roles, restrictions, and evidence requirements. These controls prevent accidental testing outside approved boundaries. We do not run a single scan until PRE-01 through PRE-12 are complete.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
PRE-01 | Confirm written authorisation for every asset in scope. | Signed scope or authorisation record. | Not Tested |
PRE-02 | Record all domains, subdomains, applications, APIs, mobile builds, and network ranges. | Approved asset inventory. | Not Tested |
PRE-03 | Record every excluded asset before active testing starts. | Exclusion list. | Not Tested |
PRE-04 | Identify production, staging, and test environments included in the assessment. | Environment list. | Not Tested |
PRE-05 | Create test accounts for each required user role. | Role and account matrix. | Not Tested |
PRE-06 | Record authentication methods used by each in-scope application. | Authentication flow notes. | Not Tested |
PRE-07 | Define allowed testing hours and operational restrictions. | Rules of engagement. | Not Tested |
PRE-08 | Define the critical-finding escalation contact and response path. | Escalation record. | Not Tested |
PRE-09 | Confirm backup and recovery readiness for sensitive environments. | Recovery confirmation. | Not Tested |
PRE-10 | Record rate limits or safety thresholds for load-sensitive endpoints. | Testing limits. | Not Tested |
PRE-11 | Identify third-party systems that remain outside active testing. | Dependency boundary. | Not Tested |
PRE-12 | Define the evidence format required for findings and retests. | Evidence standard. | Not Tested |
<info/>
Practitioner Note:
PRE-05 causes more engagement delays than any other row. Clients who deliver role accounts on day one let us start attack-surface mapping immediately. Clients who delay credentials lose 2 to 3 testing days.
Scope changes need written approval before testing continues. Approved scope then determines which web, API, mobile, and network checks apply.
What Belongs in a Web Application VAPT Checklist?
A web application VAPT checklist covers discovery, configuration, authentication, authorisation, sessions, input handling, business logic, and client-side controls. OWASP WSTG organises active web testing across defined security categories. We converted those categories into the trackable actions below.
OWASP WSTG v4.2 is the current stable release. Its active testing model covers 12 categories.
Information Gathering
Information gathering maps the reachable application surface before deeper testing starts. Our team runs Burp Suite and ZAP in passive proxy mode during this phase.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-01 | Map public application entry points and reachable routes. | Route inventory. | Not Tested |
WEB-02 | Identify exposed technologies, frameworks, and server components. | Technology fingerprint. | Not Tested |
WEB-03 | Enumerate visible parameters, headers, cookies, and form fields. | Input inventory. | Not Tested |
WEB-04 | Identify exposed administrative interfaces and management paths. | Admin interface evidence. | Not Tested |
WEB-05 | Review robots files, sitemaps, backups, and unreferenced files. | Discovery evidence. | Not Tested |
WEB-06 | Record API calls triggered through the web application. | Web-to-API map. | Not Tested |
Configuration and Deployment
Configuration testing checks server, transport, browser, and deployment settings that change application exposure.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-07 | Check HTTP security headers against the application design. | Header capture. | Not Tested |
WEB-08 | Check Transport Layer Security (TLS) configuration for weak protocols and certificates. | TLS evidence. | Not Tested |
WEB-09 | Check cross-origin resource sharing (CORS) rules for unintended origins. | CORS responses. | Not Tested |
WEB-10 | Check directory listing and default file exposure. | Server response evidence. | Not Tested |
WEB-11 | Check verbose errors for stack traces or internal details. | Error response capture. | Not Tested |
WEB-12 | Check exposed debug, test, or backup resources. | Resource evidence. | Not Tested |
WEB-07 through WEB-09 produce findings on almost every first assessment. Missing security headers and permissive CORS rules are the 2 most common medium-severity issues we report.
Identity and Authentication
Authentication testing verifies how the application identifies users and protects account access.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-13 | Test login responses for account enumeration. | Response comparison. | Not Tested |
WEB-14 | Test password reset tokens for reuse and expiry. | Reset flow evidence. | Not Tested |
WEB-15 | Test multi-factor authentication (MFA) flows for bypass paths. | MFA flow evidence. | Not Tested |
WEB-16 | Test credential transport over encrypted channels. | Request capture. | Not Tested |
WEB-17 | Test repeated login attempts against configured protections. | Attempt log. | Not Tested |
WEB-18 | Test alternate authentication paths for inconsistent controls. | Flow comparison. | Not Tested |
Authorization
Authorisation testing verifies that authenticated users access only approved objects, functions, and roles. We run WEB-19 through WEB-24 with Burp Suite, replaying requests between 2 accounts at different permission levels.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-19 | Test horizontal access between users with the same role. | Cross-user evidence. | Not Tested |
WEB-20 | Test vertical access between standard and privileged roles. | Privilege evidence. | Not Tested |
WEB-21 | Test direct object references with changed identifiers. | Modified request. | Not Tested |
WEB-22 | Test restricted functions through direct requests. | Forced browsing evidence. | Not Tested |
WEB-23 | Test hidden fields and parameters for privilege changes. | Parameter evidence. | Not Tested |
WEB-24 | Test server-side authorisation after client-side controls are bypassed. | Server response evidence. | Not Tested |
Session Management
Session testing verifies token handling from authentication through logout and expiry.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-25 | Check session tokens for secure cookie attributes. | Cookie capture. | Not Tested |
WEB-26 | Test session invalidation after logout. | Post-logout request. | Not Tested |
WEB-27 | Test session expiry after the configured idle period. | Expiry evidence. | Not Tested |
WEB-28 | Test session rotation after authentication events. | Token comparison. | Not Tested |
WEB-29 | Test concurrent sessions against documented account rules. | Session matrix. | Not Tested |
WEB-30 | Test session fixation through controlled token reuse. | Token evidence. | Not Tested |
Input Validation
Input validation testing verifies how server-side components process untrusted data. WEB-31 and WEB-32 are where scanners generate the most noise. Manual confirmation separates real injection from false positives.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-31 | Test database-backed inputs for injection weaknesses. | Request and response evidence. | Not Tested |
WEB-32 | Test reflected and stored output for script injection. | Execution evidence. | Not Tested |
WEB-33 | Test server-side URL handling for request forgery. | Outbound request evidence. | Not Tested |
WEB-34 | Test XML parsers for unsafe external entity handling. | Parser response evidence. | Not Tested |
WEB-35 | Test file paths for traversal outside allowed directories. | File access evidence. | Not Tested |
WEB-36 | Test upload functions for extension, content, and execution controls. | Upload evidence. | Not Tested |
Business Logic
Business logic testing verifies rules that scanners cannot infer from generic vulnerability patterns. No automated tool covers WEB-37 through WEB-42. Our team tests these manually using the client's documented workflows.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-37 | Test workflow steps for sequence bypass. | Workflow evidence. | Not Tested |
WEB-38 | Test transaction values for server-side enforcement. | Modified transaction evidence. | Not Tested |
WEB-39 | Test repeated actions for duplicate processing. | Replay evidence. | Not Tested |
WEB-40 | Test coupon, credit, quota, or entitlement rules for abuse. | Rule bypass evidence. | Not Tested |
WEB-41 | Test state transitions for unauthorised progression. | State evidence. | Not Tested |
WEB-42 | Test sensitive actions for missing re-authentication. | Action evidence. | Not Tested |
Client-Side and Cryptography
Client-side testing verifies browser controls, local exposure, dependencies, and cryptographic use.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
WEB-43 | Check sensitive data stored in browser-accessible locations. | Storage evidence. | Not Tested |
WEB-44 | Check client-side code for exposed secrets and keys. | Code evidence. | Not Tested |
WEB-45 | Test clickjacking protection on sensitive pages. | Frame evidence. | Not Tested |
WEB-46 | Test browser message handlers for origin validation. | Message evidence. | Not Tested |
WEB-47 | Check cryptographic use for deprecated algorithms or unsafe modes. | Configuration evidence. | Not Tested |
WEB-48 | Check third-party client libraries for known security exposure. | Dependency evidence. | Not Tested |
<Tips/>
Practitioner Note:
In our Infinium LLP engagement, WEB-35 (path traversal) exposed a file-handling API weakness. The scanner flagged it at medium confidence. Manual validation confirmed the real impact: the API returned system files outside the intended directory.
The Infinium LLP VAPT engagement covered the web application and API endpoints. The assessment recorded 18 findings, including 2 high-risk vulnerabilities.
Web applications increasingly depend on APIs for data and business actions. API coverage needs a separate checklist because authorisation and inventory risks differ from web-layer controls.
What Belongs in an API VAPT Checklist?
An API VAPT checklist covers inventory, authentication, authorisation, resource limits, business flows, request forgery, configuration, and dependency trust. OWASP API Security Top 10 provides the core risk model. Each check needs direct request and response evidence.
The OWASP API Security Top 10 (2023) covers 10 risk categories. Broken authorisation, resource consumption, server-side request forgery (SSRF), and misconfiguration rank among them.
API Discovery and Inventory
API discovery identifies active hosts, versions, endpoints, methods, and documentation gaps. We start every API assessment with API-01 through API-04 to build the endpoint map.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
API-01 | Inventory active API hosts, base paths, and versions. | API inventory. | Not Tested |
API-02 | Identify undocumented, deprecated, and debug endpoints. | Endpoint evidence. | Not Tested |
API-03 | Compare deployed endpoints with current API documentation. | Documentation gap. | Not Tested |
API-04 | Record request methods, parameters, schemas, and authentication requirements. | Endpoint matrix. | Not Tested |
API-03 catches issues on most engagements. Deployed endpoints rarely match the current documentation.
Authentication and Authorization
API authorisation testing verifies object, property, function, tenant, and credential boundaries. API-06 (broken object-level authorisation) is the single most common high-severity finding across our API work.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
API-05 | Test tokens for invalidation, expiry, and signature enforcement. | Token evidence. | Not Tested |
API-06 | Test object identifiers for broken object-level authorisation. | Cross-object request. | Not Tested |
API-07 | Test response properties for unauthorised data exposure. | Property comparison. | Not Tested |
API-08 | Test write operations for unauthorised property changes. | Modified payload. | Not Tested |
API-09 | Test privileged functions from lower-privilege roles. | Function access evidence. | Not Tested |
API-10 | Test alternate methods on protected endpoints. | Method comparison. | Not Tested |
API-11 | Test API authentication across mobile and web client flows. | Client comparison. | Not Tested |
API-12 | Test service-to-service credentials for excessive privileges. | Credential scope evidence. | Not Tested |
API-13 | Test tenant boundaries across shared API resources. | Tenant isolation evidence. | Not Tested |
Resource Limits and Business Flows
Resource testing verifies rate controls and abuse resistance around expensive or sensitive operations.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
API-14 | Test expensive operations against rate and resource controls. | Rate evidence. | Not Tested |
API-15 | Test pagination and batch sizes against documented limits. | Limit evidence. | Not Tested |
API-16 | Test sensitive business flows for automated abuse. | Business flow evidence. | Not Tested |
API-17 | Test file, export, and report endpoints for resource exhaustion. | Resource evidence. | Not Tested |
Server-Side Request Forgery, Configuration, and Dependencies
Configuration testing verifies server-side fetches, error handling, management exposure, and third-party trust.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
API-18 | Test user-controlled URLs for server-side request forgery. | Callback evidence. | Not Tested |
API-19 | Check API error messages for internal implementation details. | Error response evidence. | Not Tested |
API-20 | Check CORS and security headers on browser-consumed APIs. | Header evidence. | Not Tested |
API-21 | Check third-party API responses before trusted processing. | Integration evidence. | Not Tested |
API-22 | Check exposed management endpoints and default configurations. | Management endpoint evidence. | Not Tested |
<info/>
Practitioner Note:
Across our API engagements, POST-02 false positive removal reduces the scanner finding count by 30% to 50%. OWASP ZAP flags authorisation patterns it cannot confirm. Manual replay with different user roles separates real access-control failures from scanner noise.
PerfectQA documents this scanner-to-manual workflow on its OWASP ZAP testing page.
API testing covers backend exposure. Mobile applications add device storage, platform interaction, tampering, and privacy controls.
What Belongs in a Mobile Application VAPT Checklist?
A mobile VAPT checklist covers storage, cryptography, authentication, network communication, platform interaction, code quality, resilience, and privacy. OWASP MASVS defines these control groups for mobile application security. We test Android and iOS builds against their actual platform behaviour.
OWASP MASVS organises mobile controls across 8 security groups.
Storage
Storage testing verifies whether sensitive information remains protected on the device. MOB-01 and MOB-02 catch hardcoded tokens and unencrypted local databases in most first-time mobile assessments.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-01 | Check sensitive data stored in application files. | File evidence. | Not Tested |
MOB-02 | Check sensitive data stored in logs or local databases. | Storage evidence. | Not Tested |
MOB-03 | Check backup behaviour for protected application data. | Backup evidence. | Not Tested |
Cryptography
Cryptography testing verifies algorithms, key handling, and security-sensitive randomness.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-04 | Check cryptographic functions for unsafe algorithms or modes. | Crypto evidence. | Not Tested |
MOB-05 | Check key generation and storage against application requirements. | Key evidence. | Not Tested |
MOB-06 | Check random values used for security-sensitive operations. | Randomness evidence. | Not Tested |
Authentication and Authorization
Mobile authentication testing verifies user identity, local controls, biometric flows, and server enforcement.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-07 | Test mobile authentication flows for bypass paths. | Authentication evidence. | Not Tested |
MOB-08 | Test local authorisation decisions against server enforcement. | Authorisation evidence. | Not Tested |
MOB-09 | Test biometric flows for fallback and replay weaknesses. | Biometric flow evidence. | Not Tested |
Network Communication
Network communication testing verifies protected data exchange between the mobile application and remote services.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-10 | Check all sensitive traffic for encrypted transport. | Traffic capture. | Not Tested |
MOB-11 | Test certificate validation against controlled interception. | Certificate evidence. | Not Tested |
MOB-12 | Check endpoint trust rules across production and test hosts. | Endpoint evidence. | Not Tested |
Platform Interaction
Platform testing verifies app components, permissions, deep links, and inter-process communication (IPC).
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-13 | Check exported components and deep links for unsafe access. | Platform evidence. | Not Tested |
MOB-14 | Check IPC for unintended data exposure. | IPC evidence. | Not Tested |
MOB-15 | Check permission use against the required functionality. | Permission matrix. | Not Tested |
Code Quality
Code quality testing verifies risky input handling, embedded web components, updates, and dependencies.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-16 | Check input handling in native and embedded web components. | Code path evidence. | Not Tested |
MOB-17 | Check WebView configuration for unsafe script or file access. | WebView evidence. | Not Tested |
MOB-18 | Check update logic and dependency versions for security exposure. | Dependency evidence. | Not Tested |
Resilience
Resilience testing verifies resistance to straightforward tampering and reverse engineering.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-19 | Check application behaviour on rooted or jailbroken devices. | Device evidence. | Not Tested |
MOB-20 | Check tamper detection against modified application packages. | Tamper evidence. | Not Tested |
MOB-21 | Check sensitive logic against straightforward static inspection. | Reverse engineering evidence. | Not Tested |
Privacy
Privacy testing verifies personal data collection, third-party tracking, consent, and deletion flows.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
MOB-22 | Map collected personal data to declared application purposes. | Data map. | Not Tested |
MOB-23 | Check analytics and third-party SDK data collection. | SDK evidence. | Not Tested |
MOB-24 | Check deletion and consent flows against product requirements. | Privacy flow evidence. | Not Tested |
Mobile applications still depend on backend services and network paths. Network testing extends the assessment beyond application-layer controls.
What Belongs in a Network VAPT Checklist?
A network VAPT checklist covers exposed hosts, services, transport security, remote access, firewalls, segmentation, and internal access controls. NIST SP 800-115 documents technical assessment techniques for systems and networks. We keep active testing inside the approved address range.
Discovery and Exposure
Network discovery identifies reachable systems, services, and management surfaces. Our team runs Nmap across the approved range before any service-level testing.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
NET-01 | Inventory reachable hosts across the approved network range. | Host inventory. | Not Tested |
NET-02 | Identify exposed ports and listening services. | Port scan evidence. | Not Tested |
NET-03 | Identify externally reachable management interfaces. | Management interface evidence. | Not Tested |
NET-04 | Record operating systems and service versions where detectable. | Fingerprint evidence. | Not Tested |
Services and Configuration
Service testing verifies exposed protocols, access modes, credentials, and information disclosure.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
NET-05 | Check unnecessary services against the approved architecture. | Service comparison. | Not Tested |
NET-06 | Check default credentials on approved test targets. | Credential test evidence. | Not Tested |
NET-07 | Check anonymous or guest access on exposed services. | Access evidence. | Not Tested |
NET-08 | Check service banners for unnecessary information disclosure. | Banner evidence. | Not Tested |
Transport and Remote Access
Remote access testing verifies encryption, administration protocols, authentication, and source restrictions.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
NET-09 | Check encrypted services for weak protocols and certificates. | TLS evidence. | Not Tested |
NET-10 | Check remote administration for exposed insecure protocols. | Remote access evidence. | Not Tested |
NET-11 | Check virtual private network (VPN) access against required authentication controls. | VPN evidence. | Not Tested |
NET-12 | Check administrative access paths for network source restrictions. | Access path evidence. | Not Tested |
Firewall and Segmentation
Segmentation testing verifies whether trust zones enforce the approved network design.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
NET-13 | Validate firewall rules against approved inbound and outbound flows. | Rule evidence. | Not Tested |
NET-14 | Test network segmentation between trust zones. | Segmentation evidence. | Not Tested |
NET-15 | Test lateral movement paths within the approved internal scope. | Movement evidence. | Not Tested |
NET-16 | Check restricted management networks for unintended reachability. | Reachability evidence. | Not Tested |
Internal Network Controls
Internal testing verifies access to shared services, name resolution, file shares, and approved credential controls.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
NET-17 | Check shared services for excessive internal access. | Internal access evidence. | Not Tested |
NET-18 | Check name resolution services for unsafe configurations. | DNS evidence. | Not Tested |
NET-19 | Check file-sharing services for excessive permissions. | Share evidence. | Not Tested |
NET-20 | Check internal credentials against the approved password policy. | Credential policy evidence. | Not Tested |
Network checks complete active coverage. The final assessment still needs validation, remediation tracking, retesting, and controlled reporting.
What Needs Checking After VAPT Testing?
Post-testing checks validate findings, document evidence, track remediation, retest fixes, and record final closure status. Raw scanner alerts never become final findings without our validation. Closure requires traceable evidence from the original finding through the retest.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
POST-01 | Validate every scanner finding before formal reporting. | Validation record. | Not Tested |
POST-02 | Remove false positives from the final findings set. | Reviewed findings list. | Not Tested |
POST-03 | Assign one stable identifier to each confirmed vulnerability. | Finding register. | Not Tested |
POST-04 | Record reproduction evidence for each confirmed finding. | Evidence package. | Not Tested |
POST-05 | Record severity using the agreed assessment method. | Severity record. | Not Tested |
POST-06 | Record business impact using the tested workflow and asset. | Impact statement. | Not Tested |
POST-07 | Record developer-facing remediation for every confirmed finding. | Remediation guidance. | Not Tested |
POST-08 | Track ownership and remediation status for every open finding. | Remediation tracker. | Not Tested |
POST-09 | Retest resolved findings against the original reproduction steps. | Retest evidence. | Not Tested |
POST-10 | Record pass or fail status for every retested finding. | Retest register. | Not Tested |
POST-11 | Review the final report for secrets and unrelated sensitive data. | Delivery review. | Not Tested |
POST-12 | Record final scope, dates, version, and closure status. | Final report metadata. | Not Tested |
<info/>
Practitioner Note:
Across 12 engagements in 2025, POST-02 reduced our average finding count by 38%. The gap between scanner output and verified findings is where our manual testing adds its value. We never report an unvalidated scanner alert.
The published Infinium LLP case study records 18 security findings and a full regression retest cycle. The Infinium engagement gives a real example of evidence moving from discovery through remediation to closure.
POST-01 through POST-12 produce the inputs for the VAPT report. Every reported finding traces back to a checklist row.
Which Compliance Frameworks Map to This Checklist?
7 compliance frameworks reference security testing that this checklist satisfies. The table below maps each framework to the checklist sections that provide the required evidence. Our Indian clients most commonly need CERT-In, RBI, and PCI DSS mapping.
Framework | Mandate | Checklist sections |
|---|---|---|
CERT-In (2022 directions) | Periodic VAPT for designated entities. 6-hour incident reporting requirement. | PRE, WEB/API/MOB/NET, POST |
RBI cybersecurity framework | Mandatory VAPT for banks, NBFCs, and payment operators. | Full checklist (PRE through POST) |
SEBI CSCRF | Security controls for market intermediaries and infrastructure providers. | PRE, POST, AUD |
PCI DSS (Req 11.3) | Regular penetration testing for cardholder data environments. | WEB, API, NET, POST |
ISO 27001 (A.12.6) | Technical vulnerability management within the ISMS. | PRE, POST, AUD |
SOC 2 (CC7.1) | Security monitoring and response controls. | PRE, POST |
HIPAA (Security Rule) | Risk analysis for systems processing electronic Protected Health Information (ePHI). | WEB, API, POST |
CERT-In, RBI, and SEBI mandates apply to Indian organisations across banking, fintech, and capital markets. PerfectQA's India-based delivery aligns testing execution with these regulatory requirements.
<Caution/>
Common Pitfall:
A VAPT engagement without compliance mapping creates extra auditor work. We add framework references to each finding so the auditor traces technical evidence to the regulatory requirement directly.
Compliance mapping answers the auditor's question. The buyer audit checklist below evaluates delivery quality from the other side.
How Do Buyers Review a VAPT Provider With This Checklist?
Buyers use the VAPT audit checklist to verify scope discipline, manual validation, evidence quality, remediation guidance, and retesting. A credible provider connects each claim with traceable evidence. Review the delivery process before comparing prices.
We designed AUD-01 through AUD-10 as the questions we believe clients have the right to ask any VAPT provider.
ID | Test item | Evidence to capture | Status |
|---|---|---|---|
AUD-01 | Confirm the provider defines scope before active testing. | Written scope exists. | Not Tested |
AUD-02 | Confirm automated findings receive manual validation. | Validated evidence exists. | Not Tested |
AUD-03 | Confirm business logic receives manual testing. | Manual test evidence exists. | Not Tested |
AUD-04 | Confirm access control testing covers role and object boundaries. | Authorisation evidence exists. | Not Tested |
AUD-05 | Confirm findings include reproducible technical evidence. | Reproduction steps exist. | Not Tested |
AUD-06 | Confirm each finding includes developer-facing remediation. | Fix guidance exists. | Not Tested |
AUD-07 | Confirm severity follows a documented rating method. | Rating method exists. | Not Tested |
AUD-08 | Confirm critical findings follow an escalation process. | Escalation record exists. | Not Tested |
AUD-09 | Confirm resolved findings receive retesting. | Retest evidence exists. | Not Tested |
AUD-10 | Confirm the final report identifies exact tested assets and dates. | Scope traceability exists. | Not Tested |
The VAPT testing process guide explains how PerfectQA combines scanning with manual penetration testing.
Commercial scope changes with asset count, access requirements, testing depth, and retest effort. The VAPT testing cost guide explains those pricing inputs.
A VAPT certificate records concise assessment and closure information. The technical report remains the source for detailed findings and remediation.
FAQs
What is a VAPT checklist?
What does a web VAPT checklist include?
What does a network VAPT checklist include?
Is an OWASP checklist enough for VAPT?
How do you track VAPT findings?
When does a VAPT finding move to retest?
Which Indian regulations require VAPT?
Why choose PerfectQA services
At PerfectQA, automation is not just about speed — it’s about assurance. We combine framework expertise, proactive analysis, and audit-driven reporting to deliver testing solutions that scale with your business
Expertise and Experience: 15+ years in automation and regression testing across multiple industries
Customised Frameworks: We adapt to your tech stack, not the other way around.
State-of-the-Art Tools: Selenium, Playwright, Cypress, and CI/CD integrations.
Proactive Support: Continuous improvement through audit and debugging
About PerfectQA
PerfectQA is a global QA and automation testing company helping businesses maintain flawless software performance through manual, automated, and hybrid testing frameworks
Our mission
Deliver precision, speed, and trust with every test cycle
Learn more about our solutions
Want flawless automation?
Schedule your free test strategy consultation today and see how PerfectQA can help you achieve continuous quality at scale
Stories you could call yourn Own
Solutions and frameworks that scales with teams of any size in any industry
