Two weeks into a VAPT engagement, a familiar problem surfaces. The testers report that the payments API was never in scope. The staging environment does not match production. Half the user roles needed for authorisation testing have no test credentials.

The report may still arrive on time, but it will describe a narrower view of risk than the CISO expected.

Most VAPT engagements that fall short do not fail during testing. They fail during preparation. The gaps become visible only when an auditor or a real attacker finds what the test missed.

A structured VAPT checklist helps prevent this by turning each stage of the engagement into a set of checks you can verify before moving forward.

This guide follows the typical VAPT lifecycle: preparation, asset-type testing, reporting, remediation, and retesting. Security leaders can use it to brief a testing provider. Engineering teams can use it to confirm coverage. Compliance teams can use it as a VAPT audit checklist before submitting evidence to a regulator.

Key Takeaways

• A VAPT checklist is most valuable before testing begins because scope and access determine what the final report can prove.
• Web, API, mobile, network, and cloud environments require different security checks.
• Manual testing remains important for identifying business logic and authorisation vulnerabilities that automated tools may miss.
• A complete VAPT report should include evidence, risk ratings, remediation guidance, regulatory mapping, and attestation where required.
• Retesting is an important part of the VAPT lifecycle because it provides evidence that reported vulnerabilities have been addressed.
• For regulated Indian organisations, working with a CERT-In empanelled provider can help meet applicable regulatory testing requirements.

VAPT Checklist: Quick Overview

After reviewing each phase in detail, use the following checklist as a final reference before starting a VAPT engagement. It brings the key checks from scoping, testing, reporting, and retesting into one place.

Phase	Key Checks	Completion Criteria
Phase 1: Scoping and Preparation	Asset inventory, regulatory requirements, testing approach, environment, access, rules of engagement, authorisation	All required assets are in scope and the testing environment, access, and permissions are ready
Phase 2: Web Application Testing	Authentication, sessions, authorisation, input validation, business logic, client-side controls, configuration	Critical application vulnerabilities and business logic risks have been tested
Phase 3: API Security Testing	Endpoint discovery, object and function authorisation, data exposure, rate limiting, token handling, mass assignment	All relevant APIs have been identified and tested
Phase 4: Mobile Application Testing	Local storage, transport security, reverse engineering, root and jailbreak controls, permissions and components	Mobile applications and their backend interactions have been assessed
Phase 5: Network and Cloud Testing	External and internal networks, remote access, segmentation, Active Directory, privilege escalation, IAM, storage, logging	Key infrastructure and cloud attack paths have been identified and assessed
Phase 6: Reporting	Executive summary, scope, methodology, risk ratings, evidence, remediation, regulatory mapping, attestation	The report provides clear evidence and actionable findings for security, engineering, leadership, and audit teams
Phase 7: Retesting and Closure	Fix prioritisation, retest timelines, remediation validation, closure report, next testing cycle	Remediated findings are verified and formally documented as closed

Phase 1: Scoping and Preparation

Scope determines what a VAPT report can prove. Testing the wrong assets or the right assets in the wrong environment can produce evidence that does not reflect the organisation’s actual exposure.

This phase should involve the CISO, application owners, infrastructure teams, and the testing provider.

Scoping and Preparation Checklist

• List every web application, API, mobile app, external IP range, internal segment, and cloud account. Identify assets handling personal, financial, or regulated data.
• Identify relevant requirements such as RBI guidelines, SEBI’s cybersecurity framework, PCI DSS, ISO 27001, or the DPDP Act. These requirements can influence testing depth and reporting.
• Decide whether black box, grey box, or white box testing is appropriate for each asset. Also define internal and external testing positions.
• Test production where appropriate, or use a staging environment that closely matches production configuration.
• Create test accounts for every required user role. Share API documentation and collections. Provide appropriate mobile builds where white box testing is agreed.
• Document testing windows, excluded activities, data handling requirements, and escalation contacts for critical findings.
• Get approval from the asset owner and include third-party hosting or cloud providers where their terms require notification.

Phase 2: Web Application VAPT Checklist

Web applications remain a major attack surface and are central to many regulatory security testing requirements in India. The OWASP Top 10 provides a useful baseline, but a complete web application VAPT checklist should also cover authorisation and business logic.

Key Web Application Checks

• Crawl pages, parameters, hidden endpoints, and administrative interfaces. Identify frameworks and server versions.
• Review password policies, brute force protection, MFA bypass, password reset processes, and account enumeration.
• Check token randomness, expiry, fixation, logout behaviour, and cookie security flags.
• Assess horizontal and vertical privilege escalation, insecure direct object references, and access across different user roles.
• Check SQL injection, cross-site scripting, command injection, server-side request forgery, template injection, and path traversal.
• Look for price manipulation, workflow bypass, race conditions, coupon or limit abuse, and transaction replay.
• Review DOM-based issues, clickjacking, CORS configuration, and sensitive information stored in browser storage.
• Check security headers, TLS configuration, error handling, verbose messages, and exposed debug endpoints.

Business logic testing requires strong manual testing because automated scanners cannot fully understand how an application is supposed to work. You can also refer to our guide on OWASP Top 10 updates every CISO should know.

Phase 3: API Security Testing Checklist

Modern applications rely heavily on APIs, while many organisations do not maintain a complete inventory of their API endpoints. An API security testing checklist should therefore begin with discovery.

Key API Security Checks

• Compare documented endpoints with endpoints observed in application traffic. Identify deprecated and shadow API versions.
• Confirm that changing an identifier cannot expose another user’s data.
• Confirm that standard users cannot access administrative functions.
• Review whether API responses return more information than the client requires.
• Check login, OTP, search, export, and other resource-intensive endpoints for appropriate throttling.
• Test JWT signature validation, algorithm handling, token expiry, and scope enforcement.
• Check whether users can modify server-controlled fields such as roles, balances, or account status.

Phase 4: Mobile Application Checklist

Mobile applications combine client-side security risks with the same backend APIs discussed above. Android and iOS also have different platform behaviours, so assess them separately. See our guide on why iOS and Android testing needs to be conducted separately.

Key Mobile Security Checks

• Check credentials, tokens, and personal data stored in shared preferences, keychains, databases, logs, and caches.
• Review certificate pinning, TLS configuration, and interception resistance.
• Check for hardcoded secrets, API keys in binaries, and weak code obfuscation.
• Assess whether security controls can be bypassed on compromised devices.
• Check exported activities, deep links, intents, and unnecessary permissions.

Teams developing financial applications can also refer to the CyRAACS resources on root and tamper detection for Android apps and bypassing SSL pinning during testing.

Phase 5: Network and Cloud VAPT Checklist

Infrastructure testing helps determine whether an attacker who gains access to an application or internal network can move towards critical systems.

A complete network VAPT checklist should cover external infrastructure, internal networks, and cloud environments.

External Network

• Enumerate exposed services: Identify open ports, service versions, and forgotten hosts across public IP ranges.
• Test remote access: Review VPN gateways, remote desktop services, and administrative interfaces exposed to the internet.
• Check email and DNS security: Review SPF, DKIM, DMARC, zone transfer exposure, and subdomain takeover risks.

Internal Network

• Test network segmentation: Confirm whether user networks can reach payment, database, or management segments that should be isolated.
• Assess Active Directory: Check weak service account passwords, Kerberoasting exposure, excessive privileges, and legacy protocols.
• Test lateral movement and privilege escalation: Assess whether a standard user can move towards domain or critical system access.
• Review patching and default credentials: Check servers, network devices, and appliances for outdated software and default credentials.

Cloud Security

• Review identity and access management: Identify overprivileged roles, unused keys, and missing MFA for privileged accounts.
• Check storage exposure: Review publicly accessible buckets, snapshots, and databases.
• Validate network controls: Check security groups, exposed management ports, and workload segmentation.
• Confirm logging: Ensure appropriate audit trails exist for important administrative and security activities.

Phase 6: Reporting Checklist

The VAPT report is often the main deliverable leadership, engineering teams, auditors, and clients review. It should provide enough detail for each audience to understand the risk and take action.

A Complete VAPT Report Should Include

• Overall risk position, major findings, and business impact in clear language.
• Assets tested, dates, environment, testing approach, and standards followed.
• CVSS score or equivalent rating, affected assets, and business context.
• Screenshots, requests, responses, and reproduction steps for validated findings.
• Specific recommendations that engineering teams can implement.
• Relevant controls from the frameworks identified during scoping.
• Provider letterhead and tester details where required by a regulator or client.

For regulated Indian organisations, the report should come from a CERT-In empanelled provider where applicable.

Phase 7: Remediation Validation and Retesting

Reporting a vulnerability does not close the risk. The finding should be retested after remediation to confirm that the fix works and that the issue has not been reintroduced.

Retesting Checklist

• Address critical and high-risk findings on internet-facing and data-handling assets first.
• Define when remediation should be completed and when validation will take place.
• Confirm that the original vulnerability has been resolved and no regression has been introduced.
• Document the status of every original finding after retesting.
• Consider major releases, infrastructure changes, and applicable regulatory testing frequency.

For organisations with frequent releases, annual testing can leave significant gaps between assessments. Continuous security testing and a managed VAPT programme can help maintain security coverage as the environment changes.

Common Gaps This Checklist Helps Identify

Several recurring gaps can reduce the effectiveness of a VAPT engagement:

• APIs or third-party integrations handling sensitive data are excluded from scope.
• Testing relies heavily on automated scanning, with insufficient manual testing.
• Only one user role is provided, limiting authorisation and privilege escalation testing.
• Reports lack sufficient evidence or practical remediation guidance.
• Retesting is skipped or poorly documented.
• Regulatory requirements are identified late in the engagement.

These issues are easier to address before testing begins than after the final report has been issued.

How CyRAACS Approaches VAPT Engagements

CyRAACS has been CERT-In empanelled since 2017 and delivers VAPT across web applications, APIs, mobile applications, networks, and cloud environments.

Every engagement starts with structured scoping based on the client’s architecture, assets, and regulatory requirements. This helps establish clear coverage before testing begins.

Testing combines automated discovery with manual exploitation by experienced consultants, with particular focus on authorisation and business logic testing. Reports are designed for leadership, engineering, and audit teams, while retesting provides documented evidence of remediation.

You can learn more about the CyRAACS VAPT services and explore the broader range of technical services that support VAPT, red teaming, and other offensive security requirements.

Bottom Line

A VAPT engagement is only as effective as the preparation, coverage, and follow-up behind it. A structured VAPT checklist helps security teams make sure the right assets are tested, vulnerabilities are properly documented, and remediation is verified.

For regulated and enterprise organisations, the focus should go beyond simply completing a security test. The objective should be to achieve meaningful coverage, actionable findings, clear reporting, and documented remediation. A well-planned VAPT process helps turn security testing into a continuous improvement cycle rather than a one-time compliance exercise.

Frequently Asked Questions

What Is a VAPT Checklist?

A VAPT checklist is a structured set of checks used to plan, execute, report, and validate a Vulnerability Assessment and Penetration Testing engagement. It helps ensure that critical assets, vulnerabilities, reporting requirements, and retesting are properly covered.

What Should Be Included in a VAPT Checklist?

A complete checklist should cover scoping, web applications, APIs, mobile applications, networks, cloud environments, reporting, remediation, and retesting. It should also consider applicable regulatory and compliance requirements.

How Often Should VAPT Be Performed?

Perform VAPT based on regulatory requirements, organisational risk, major application or infrastructure changes, and release frequency. Organisations with frequent changes may also benefit from continuous security testing.

What Is Included in a VAPT Report?

A VAPT report generally includes the scope and methodology, executive summary, risk ratings, affected assets, evidence, technical findings, remediation recommendations, regulatory mapping, and, where applicable, closure or retest details.