Month: June 2026

FAQ: VAPT Questions Your IT Security Manager Is Asking

Posted on by admin
Scope and Planning Questions
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.


Methodology and Technical Questions
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.

Compliance and Regulatory Questions
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.

Remediation and Reporting Questions
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.

Q: How long does a typical penetration test take?
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.
QRC provides VAPT services covering web, mobile, API, network, and thick client testing. Contact us for a security testing assessment.

Third-Party Risk in Payment Ecosystems: A Practical Guide

Posted on by admin
Payment ecosystems are built on interconnection. A single card transaction can involve the merchant, the payment gateway, the acquiring bank, the card network, the issuing bank, the token service provider, and multiple technology vendors. Each connection represents a potential security weakness, and each vendor in your supply chain extends your attack surface. The payment industry has learned this lesson repeatedly through high-profile breaches where the initial compromise occurred through a third-party vendor rather than a direct attack on the primary organization. The challenge for payment companies is that traditional vendor risk assessment approaches were designed for a simpler era. Annual questionnaire-based assessments, point-in-time compliance certifications, and contractual security requirements are necessary but insufficient. They capture the vendor’s security posture at a specific moment but provide no visibility into how that posture changes over time. A vendor might be PCI DSS compliant on the day they complete their assessment and have a critical vulnerability introduced two weeks later. Regulatory expectations have evolved to reflect this reality. PCI DSS 4.0.1, RBI’s guidelines for PSOs, and SEBI’s CSCRF all include requirements for ongoing third-party risk management that go beyond annual assessments. The bar has been raised from checking compliance status to continuously monitoring vendor risk.
What PCI DSS 4.0.1 Requires for Third-Party Management
PCI DSS 4.0.1 Requirement 12.8 establishes clear obligations for managing third-party service providers that handle cardholder data or could affect its security. You must maintain a list of all service providers with a description of each service provided. You must have a written agreement with each provider acknowledging their responsibility for cardholder data security. You must conduct due diligence before engaging a provider, including verification of their PCI DSS compliance status. And you must monitor their compliance status at least annually. Requirement 12.9 expands the expectations for service providers themselves. Providers must acknowledge in writing their responsibilities for securing cardholder data. They must provide evidence of their PCI DSS compliance, typically through an Attestation of Compliance. The practical challenge is that many payment companies maintain dozens of third-party relationships, ranging from critical payment processors to niche technology vendors. Applying the same level of scrutiny to every vendor is neither practical nor necessary. A risk-based approach — categorizing vendors by criticality and applying proportionate due diligence — is both compliant and operationally sustainable. Tier your vendors based on the volume and sensitivity of data they handle, their access to your cardholder data environment, and their criticality to your payment processing operations.
Building a Practical Third-Party Risk Assessment Framework
Start with a vendor inventory. Document every third party that processes, stores, or transmits cardholder data on your behalf, plus any vendor with access to systems that could affect the security of your CDE. This inventory should include the vendor name, the service provided, the type of data they handle, their access to your environment, their PCI DSS compliance status, and the date of your last assessment. Classify each vendor into risk tiers. Tier 1 includes vendors with direct access to cardholder data or your CDE — these require comprehensive assessment including PCI DSS validation, penetration test results review, and security architecture review. Tier 2 includes vendors with indirect access or access to systems connected to the CDE — these require PCI DSS validation and security questionnaire assessment. Tier 3 includes vendors with no data access but who provide supporting services — these require basic due diligence and contractual security requirements. For Tier 1 vendors, go beyond the compliance certificate. Review their latest ROC or SAQ, examine their scope of assessment to ensure it covers the services they provide to you, ask for vulnerability scan summaries and penetration test executive summaries, and evaluate their incident response capabilities. A vendor who is PCI DSS compliant but has no documented incident response plan for notifying their clients creates risk that compliance alone does not mitigate.
Continuous Monitoring Versus Annual Assessment
Annual vendor assessments tell you about yesterday’s risk. The regulatory expectation — and the practical necessity — is moving toward continuous monitoring of third-party risk. This does not mean conducting a full assessment every day, but it does mean maintaining visibility into your vendors’ security posture between formal assessments. Implement automated monitoring where possible. External attack surface monitoring tools can track changes in your vendors’ internet-facing infrastructure — new services, expired certificates, DNS changes, exposed databases. These signals do not replace formal assessments, but they provide early warning of deteriorating security posture. Review your vendors’ public breach disclosures and regulatory actions. Subscribe to notifications from regulatory bodies, industry information sharing groups, and threat intelligence providers. If a vendor experiences a breach or receives a regulatory finding, you need to assess the impact on your environment immediately, not wait for the next annual review. Establish contractual rights to receive prompt notification of security incidents, material changes to the vendor’s security posture, and changes to their PCI DSS compliance status. These notification requirements should be specific — define what constitutes a material change and set timelines for notification. Include audit rights in your vendor contracts that allow you to conduct additional assessments when triggered by risk indicators. These rights are rarely exercised, but their existence provides leverage and demonstrates due diligence.
Managing Vendor Risk Across Multiple Compliance Frameworks
If your organization complies with PCI DSS, RBI guidelines, SEBI CSCRF, ISO 27001, and DPDP, you have vendor management requirements in each framework. Managing these separately creates redundancy and inconsistency. Build an integrated vendor risk management program that satisfies all applicable frameworks through a single process. Create a unified vendor assessment questionnaire that maps each question to the relevant framework requirement. This allows you to collect information once and validate it against multiple frameworks. Your PCI DSS Requirement 12.8 assessment, your RBI vendor due diligence, your ISO 27001 supplier security assessment, and your DPDP processor due diligence can all be addressed through a single comprehensive assessment process. Maintain a centralized vendor risk register that tracks each vendor’s compliance status across all applicable frameworks. When a vendor provides their SOC 2 report, map the findings to your PCI DSS, ISO 27001, and SEBI CSCRF requirements simultaneously. This reduces duplicate effort for both your team and the vendor. Automate vendor risk workflows. Use a GRC platform or vendor risk management tool to track assessment schedules, send automated reminders, collect and store evidence, and generate compliance reports. Manual vendor management processes break down when you manage more than twenty vendors — and most payment companies manage far more than that.
Q: How often should we assess our third-party vendors?
A: PCI DSS requires at least annual assessment. For Tier 1 vendors with direct access to cardholder data, supplement annual assessments with continuous monitoring of their external security posture.
Q: What happens if a vendor loses their PCI DSS compliance?
A: You must assess the impact on your own compliance posture immediately. If the vendor handles cardholder data on your behalf, their non-compliance may affect your own PCI DSS status. Engage your QSA to determine the appropriate response.
Q: Can we rely solely on a vendor’s SOC 2 report for PCI DSS compliance?
A: No. SOC 2 and PCI DSS are different frameworks. A SOC 2 report provides assurance about the vendor’s controls but does not replace PCI DSS validation. You still need their Attestation of Compliance for PCI DSS.
QRC helps payment companies build vendor risk management programs that satisfy PCI DSS, RBI, and ISO 27001 requirements. Contact us for a vendor risk assessment.

ISO 27001:2022 Post-Transition: What Happens to Your ISMS Now

Posted on by admin
October 31, 2025 was the deadline for transitioning from ISO/IEC 27001:2013 to ISO/IEC 27001:2022. If your organization completed the transition, your certificate now references the 2022 version, and your ISMS should reflect the updated standard’s requirements including the restructured Annex A controls. If you missed the deadline, your 2013 certificate has expired, and you are technically operating without a valid ISO 27001 certification. This has real consequences — clients who require ISO 27001 as a contractual condition may flag your organization as non-compliant in their vendor risk assessments. The path forward depends on your situation. Organizations that transitioned on time now need to focus on operationalizing the new controls, preparing for their next surveillance audit under the 2022 standard, and integrating the new control categories into their daily operations. Organizations that missed the deadline need to pursue recertification against the 2022 standard, which involves a more comprehensive assessment than a transition audit would have required. Regardless of which situation you are in, understanding the practical differences between the 2013 and 2022 versions is essential for maintaining a healthy ISMS.

What Actually Changed Between 2013 and 2022
The main body of ISO 27001 received relatively minor updates — mostly clarifications in terminology and alignment with the ISO Harmonized Structure. The significant changes are in Annex A, which was completely restructured from 14 control categories with 114 controls to 4 themes with 93 controls. The four themes are Organizational, People, Physical, and Technological. Eleven new controls were introduced that reflect the evolving threat landscape. These include threat intelligence, information security for cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. For organizations that were already following security best practices, many of these controls were likely already implemented informally. The difference now is that they must be formally documented, implemented, monitored, and evidenced as part of your ISMS. The Statement of Applicability needs to be updated to reflect the new control structure. If your SoA still references the 114-control format from 2013, it needs to be remapped to the 93-control format even if the underlying controls have not changed.
Preparing for Your First Surveillance Audit Under 2022
Your certification body will conduct surveillance audits at defined intervals to verify that your ISMS continues to meet the standard’s requirements. Your first surveillance audit under the 2022 version will likely receive closer scrutiny than previous audits because the auditor will be verifying that the transition was substantive, not just a document update. Focus on three areas. First, demonstrate that the new Annex A controls are operationally effective, not just documented. If your SoA includes the threat intelligence control, show that you have a process for collecting, analyzing, and acting on threat intelligence relevant to your organization. If data leakage prevention is applicable, demonstrate the technical controls and monitoring processes you have in place. Second, ensure your risk assessment methodology reflects the updated control set. Your risk treatment plan should reference the 2022 controls, and the mapping between identified risks and selected controls should be current. Auditors will check that controls were selected based on risk, not just because they appear in Annex A. Third, update your internal audit program to cover the new controls. Your internal audit schedule should ensure that every applicable control is audited within the certification cycle, with priority given to the new controls that may not have been previously audited.
Five Controls Most Organizations Struggle to Implement
Threat intelligence is the control most organizations implement superficially. It is not enough to subscribe to a threat feed — you need to demonstrate that threat intelligence is analyzed in the context of your organization’s specific threat landscape and that it informs your security decisions. Establish a regular threat intelligence review process and document how specific intelligence has influenced your security controls or incident response preparation. Cloud security controls are challenging because they span both your responsibilities and your cloud provider’s. Document your shared responsibility model clearly. Map which security controls are your responsibility, which are the provider’s, and which are shared. Evidence this through your cloud provider’s SOC 2 report, your own configuration audits, and your cloud security monitoring processes. Data leakage prevention requires both technical controls and process discipline. Implement DLP controls at key data egress points — email, web uploads, removable media, and cloud storage. But also address the process dimension — data classification policies, user awareness training, and incident response procedures for data leakage events. Secure coding is often treated as a development team responsibility without ISMS integration. Bring your secure coding practices under the ISMS umbrella — include secure coding standards in your documented information, conduct periodic reviews of code security practices, and maintain evidence of developer security training. Configuration management requires a baseline configuration standard for each technology in your environment and a process for detecting and remediating configuration drift. Automated configuration monitoring tools are practically essential for implementing this control effectively.
Building a Continuous Improvement Cycle for Your ISMS
The most common failure mode for ISO 27001-certified organizations is treating the ISMS as a compliance artifact rather than a living system. The 2022 version’s emphasis on monitoring and continuous improvement makes this distinction even more important. Establish quarterly ISMS review meetings that evaluate the effectiveness of controls, review incident trends, assess the relevance of risk treatment plans, and identify areas for improvement. These reviews feed into your management review, which remains a requirement of the standard. Implement metrics that tell you whether your ISMS is working, not just whether it exists. Useful metrics include the number of security incidents detected versus those reported by third parties, the time to remediate identified vulnerabilities, the percentage of employees completing security awareness training, the number of nonconformities found in internal audits and their remediation timelines, and the coverage of your asset inventory. Integrate your ISMS with other compliance programs. If your organization also maintains PCI DSS compliance, SOC 2 reports, or DPDP compliance, there is significant control overlap. An integrated compliance approach reduces duplication, improves consistency, and provides a more comprehensive view of your security posture. Use ISO/IEC TS 27103 as the bridging mechanism between ISO 27001 and other cybersecurity frameworks.
Q: What happens if we missed the ISO 27001:2022 transition deadline?
A: Your ISO 27001:2013 certificate has expired. You need to pursue recertification against the 2022 version through a full certification audit, which is more comprehensive than a transition audit.
Q: How many controls are in ISO 27001:2022?
A: Annex A contains 93 controls organized into four themes: Organizational (37), People (8), Physical (14), and Technological (34). This replaces the previous 114 controls across 14 categories.
Q: Can we maintain both ISO 27001 and PCI DSS simultaneously?
A: Yes. Approximately 60-70% of controls overlap between the two frameworks. An integrated compliance approach is more efficient than managing them separately.
QRC provides ISO 27001 certification and surveillance audit support. Contact us to ensure your ISMS meets the 2022 standard.