FAQ: VAPT Questions Your IT Security Manager Is Asking

Q1: What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment identifies known vulnerabilities in your systems through automated scanning and manual verification. It tells you what weaknesses exist. A penetration test goes further – it attempts to exploit identified vulnerabilities to determine the actual impact of a successful attack. It tells you what an attacker can achieve if they exploit those weaknesses. Both are necessary, and they serve different purposes in your security program.

Q2: How do we define the scope of a penetration test?
Start with your risk. Identify the systems, applications, and network segments that hold your most sensitive data or support your most critical business functions. For PCI DSS compliance, the scope must include all systems in the cardholder data environment and the network segmentation controls that separate the CDE from other networks. For general security testing, prioritize internet-facing systems, applications that handle personal data, and systems with recent significant changes.

Q3: Should we test our production environment or a staging environment?
Ideally, test both, but they serve different purposes. Production testing reveals the real security posture of your live environment, including configuration issues and integration vulnerabilities that only exist in production. Staging testing allows more aggressive testing without risking service disruption. For PCI DSS, the requirement is that the tested environment accurately reflects the production environment. If your staging environment differs significantly from production, production testing is necessary.

Q4: What is the difference between authenticated and unauthenticated scanning?
Unauthenticated scanning examines your systems from an external perspective, identifying vulnerabilities visible to an attacker without credentials. Authenticated scanning uses valid credentials to log into systems and identify vulnerabilities that are only visible from an authenticated perspective – missing patches, misconfigurations, and vulnerable software that would not be detected externally. Authenticated scanning provides significantly more comprehensive results and is required by PCI DSS for internal vulnerability scans.

Q5: What testing methodologies should our vendor follow?
Look for alignment with established frameworks – OWASP Testing Guide for web applications, OWASP API Security Testing Guide for APIs, PTES for general penetration testing, and NIST SP 800-115 for technical security testing. For PCI DSS, the PCI Penetration Testing Guidance document provides specific requirements. Ask your vendor to specify which methodology they follow and ensure their test plan covers all relevant areas.

Q6: How do we assess the security of our mobile applications?
Mobile application testing covers three layers – the client application, the communication channel, and the server-side APIs. Test the app binary for hardcoded credentials, insecure data storage, weak cryptographic implementations, and reverse engineering vulnerabilities. Test the communication channel for certificate pinning, TLS implementation, and data exposure in transit. Test the server-side APIs for authentication, authorization, and input validation vulnerabilities. OWASP Mobile Application Security Testing Guide provides a comprehensive framework.

Q7: Should we conduct red team assessments in addition to penetration testing? Red team assessments and penetration tests serve different purposes. Penetration testing focuses on identifying technical vulnerabilities in specific systems. Red teaming simulates a real adversary targeting your organization holistically, including social engineering, physical security, and multi-stage attack chains. Organizations with mature security programs benefit from periodic red team exercises – typically annually – in addition to regular penetration testing.

Q8: How often does PCI DSS require penetration testing?
PCI DSS Requirement 11.4 mandates penetration testing at least annually and after any significant change to the environment. Significant changes include network architecture modifications, operating system or application upgrades, and new system deployments. For segmentation controls, testing is required every six months if segmentation is used to reduce PCI DSS scope.

Q9: Do we need an ASV for our vulnerability scans?
If you need to demonstrate PCI DSS compliance, external vulnerability scans must be conducted by a PCI SSC Approved Scanning Vendor. Internal scans can be conducted by internal staff or any qualified third party – ASV certification is not required for internal scans. However, the scanning must be conducted by qualified personnel following the PCI DSS scanning requirements.

Q10: How do we handle vulnerabilities found during a PCI DSS assessment?
PCI DSS requires that critical and high-severity vulnerabilities be remediated within 30 days. Medium and low-severity vulnerabilities should be addressed based on a targeted risk analysis. Document your remediation timeline, track progress, and rescan to verify that remediation was effective. Vulnerabilities that cannot be remediated within the required timeframe need documented compensating controls and a remediation plan with a specific target date.

Q11: Does RBI mandate specific security testing for payment companies?
RBI’s cybersecurity framework requires regular vulnerability assessments and penetration testing for banks, non-bank PSOs, and payment aggregators. The specific frequency and scope requirements vary by entity type. Banks are expected to conduct comprehensive VAPT at least annually, with critical systems tested more frequently.

Q12: How should we prioritize remediation of identified vulnerabilities?
Use a risk-based approach that considers three factors: the severity of the vulnerability as rated by CVSS score, the exposure of the affected system to potential attackers, and the business impact if the vulnerability is exploited. A critical vulnerability on an internet-facing payment application demands immediate attention. The same vulnerability on an isolated development server with no access to production data can be scheduled for the next maintenance window.

Q13: What should a good penetration test report include?
A quality report includes an executive summary for management, a detailed technical findings section with proof-of-concept evidence, a risk rating for each finding using a standardized methodology, specific remediation recommendations prioritized by risk, and a retest plan for verifying remediation effectiveness. The report should map findings to relevant compliance requirements – PCI DSS, RBI, ISO 27001 – so that compliance implications are clear.

Q14: How do we verify that remediation was effective?
Request a retest from your testing vendor after remediation is complete. Retesting should verify that the specific vulnerability has been addressed and that the remediation did not introduce new vulnerabilities. For PCI DSS, rescanning is required to demonstrate that previously identified vulnerabilities have been resolved.

Q15: How do we use VAPT results to improve our security program?
Look for patterns across findings. If multiple applications have the same type of vulnerability – SQL injection, for example – the root cause is likely a gap in your secure development lifecycle rather than a problem with a specific application. Address both the symptoms through remediation and the root cause through process improvement. Track vulnerability trends over time to measure whether your security posture is improving.

A: Scope-dependent. A focused web application test takes 1-2 weeks. A comprehensive network and application assessment across a large environment can take 4-6 weeks. Plan for additional time for reporting and remediation verification.

Q: Should we share previous test results with our new testing vendor?

A: Yes. Sharing previous results helps the new vendor focus on areas of concern, validate previous remediation, and provide a more comprehensive assessment. It also demonstrates maturity in your security testing program.