Which Rules Really Require an Accredited Pentester

No. PCI DSS v4.0.1 states the requirement in its own normative text, and the parenthetical is explicit: organizational independence of the tester exists, and the tester is not required to be a QSA or an ASV. The requirement is that testing is performed by a qualified internal resource or a qualified external third party, with organizational independence from the systems being tested. That parenthetical appears alongside Requirements 11.3.1.3, 11.4.2, 11.4.3 and 11.4.6. The one place the standard does mandate a specific accredited party is Requirement 11.3.2, which covers quarterly external vulnerability scanning and does require an Approved Scanning Vendor. So the accreditation requirement is real and it attaches to scanning, not to penetration testing, and conflating the two is the single most common error we see in vendor marketing.

No rule we could find in the primary text says so. The FCA authorisation process for AISP and PISP firms does not require a penetration test at authorisation. Post-authorisation, the EBA Guidelines on security measures for operational and security risks under PSD2, reference EBA/GL/2017/17, ask at Guideline 7 for testing by independent testers who were not involved in the development of what they are testing. That is an independence condition, not an accreditation gate. The single CREST mention we located across the FCA, Open Banking Limited, EBA and OpenID Foundation material is a 2018 Open Banking Limited recommendation that lists OSCP alongside CREST in a non-exhaustive example, and a body imposing a firm-level accreditation gate does not put an individual practitioner certification in the same list.

The phrase CERT-In does not appear in the RBI Master Direction governing Account Aggregators, and we did not find it in the Sahamati material we reviewed either. The empanelment that does apply in that ecosystem is Sahamati's own empanelment of certifiers, which gates who may certify a participant, not which firm may run a penetration test for that participant. The likely origin of the confusion is that at least one firm, AQM Technologies, appears on both lists: as a CERT-In empanelled auditor and as a Sahamati empanelled certifier. Two unrelated empanelments held by one firm read, at a glance, like one requirement. Verify against the Master Direction and the Sahamati certifier list rather than against a vendor's page.

Yes, and this is the part that cuts against the pattern, so it belongs on the same page. SEBI's Cybersecurity and Cyber Resilience Framework material includes an FAQ stating that software DAST and SAST should be carried out by CERT-In empanelled organisations. That is a real accreditation gate in a real Indian regulation and we are not empanelled. Separately, the VAPT auditor eligibility annexure of the same framework is something we have not read, so our knowledge of SEBI's full position is incomplete and we are saying so rather than implying a clean answer. Government and Critical Information Infrastructure engagements also commonly carry empanelment requirements. If your regulator names empanelment, that requirement is real and you should meet it.

Because the myth is commercially useful to whoever holds the accreditation, and because the real requirement in each case is a qualification-and-independence condition that is harder to summarise than a badge. PCI DSS asks for a qualified tester with organizational independence. The EBA guidelines ask for independent testers not involved in the development. RBI's IT framework asks for appropriately trained and independent information security experts or auditors. None of those compresses into a single logo, so a badge gets substituted for the condition in the retelling. The practical cost to a buyer is a narrowed vendor list and a higher price for the same work, justified by a requirement that the standard's own text does not contain.

Four steps, and they take under an hour. First, get the name and version of the actual document: PCI DSS v4.0.1, EBA/GL/2017/17, the specific RBI Master Direction, the SEBI framework annexure. A requirement that cannot be named to that level is usually a retelling. Second, find the normative requirement text rather than guidance or a vendor summary, because guidance frequently softens or hardens what the requirement says. Third, search that text for the accreditation term itself: QSA, ASV, CREST, empanelled. Fourth, check whether the hit sits in a requirement or in an example. In our reading, the accreditation terms that survive step four attach to scanning and to certification issuance far more often than to penetration testing.

It means the person testing is not the person who built or runs the system under test. PCI DSS v4.0.1 permits a qualified internal resource, which surprises buyers who assume an external firm is mandatory, but it pairs that with an organizational independence condition that most in-house teams fail on. A security engineer testing an application their own team wrote and operates is not independent of it, regardless of how skilled they are. An internal team in a separate reporting line, with no build or operate responsibility for the target, can satisfy it. The EBA formulation is narrower and more specific: testers not involved in the development of what they are testing.

No, and we do not claim to be. CERT-In empanelment is a panel maintained by the Indian Computer Emergency Response Team, and it binds in specific regulated categories rather than universally. It has no relationship to SOC 2, which is an AICPA attestation standard, and none to PCI DSS penetration testing under Requirement 11.4. If your regulator, your enterprise customer or your contract names CERT-In empanelment, that is a real requirement, you should meet it, and we will tell you so at scoping rather than after you have paid. What we deliver is the testing and the evidence: reports mapped to the frameworks your auditor works from, and a retest that closes findings.

The ones attached to issuing a certificate or an attestation, rather than to performing a test. An ISO 27001 certificate is issued by an accredited certification body. A SOC 2 report is issued by an independent licensed CPA firm. PCI DSS quarterly external scanning requires an Approved Scanning Vendor, and a Report on Compliance requires a Qualified Security Assessor. Those are structural and no amount of technical capability substitutes for them. The pattern is consistent and worth internalising: accreditation gates cluster around who may sign the paper, not around who may do the testing that the paper relies on.

Ask them to name the document, the version and the clause. Then read that clause. A vendor who holds an accreditation has a legitimate commercial interest in your believing it is mandatory, which does not make them dishonest but does mean the claim deserves the same verification as any other sales claim. Three follow-ups are useful. Does the clause name the accreditation, or name a qualification and an independence condition? Does it apply to penetration testing, or to scanning, or to issuing a certificate? And does it apply to your entity category, since most of these obligations attach to regulated entities rather than to every company in a sector.

No. An accreditation is evidence about a firm, and evidence is useful. The argument here is narrower: an accreditation is not a legal requirement unless a rule says it is, and in penetration testing the rules usually specify a qualification and an independence condition instead. Treat accreditation as one signal among several rather than as a filter that removes everyone else from consideration. The signals that correlate with a usable report, in our experience of what auditors and enterprise reviewers actually push back on, are a named lead tester with a verifiable credential, a named methodology at a released version, a sanitised sample report you can read before buying, and a retest included rather than quoted afterwards.

Separate the three buckets before you shop. Bucket one is what your regulator requires, which is where a genuine empanelment or accreditation gate lives if you have one, and SEBI regulated entities should assume they do. Bucket two is what your customers and auditors require, which is usually a qualified independent tester and a report they can read, with no accreditation named. Bucket three is what your investors ask in diligence, which is usually evidence that testing happens on a cadence. Most Indian SaaS companies selling to private enterprises sit entirely in buckets two and three, and buy against a bucket-one requirement they do not have because a vendor told them it was standard.