A CERT-In empanelled VAPT vendor is a security auditing firm officially vetted and listed by the Indian Computer Emergency Response Team under Section 70B of the IT Act. For regulated entities in India—such as banks, fintechs, and brokers governed by RBI, SEBI, or IRDAI—an audit report signed by an empanelled vendor is a mandatory legal prerequisite for going live or clearing compliance filings.
Navigating the Mandatory Security Audit Landscape in India
Choosing a security auditor in India is riskier than it should be. The challenge isn’t a lack of options—it’s that, on paper, every vendor looks identical. They promise the same comprehensive coverage, display the same badges, and offer the same standard checklist. The difference between a deep, manual penetration test and an automated scanner run through a template only becomes clear after you’ve signed the SOW, paid the invoice, and had your regulatory filing rejected.
This section covers why the audit is now a legal gate rather than a security choice, what CERT-In empanelment Security Auditor actually is, and which regulators insist on it.
If you process payments or hold citizen data, the VAPT report is your licence to operate
Not a figure of speech. If your business moves digital payments, handles Aadhaar-linked records, or answers to an Indian financial regulator, there is a point in your launch timeline where nothing moves without a signed audit report. No report, no go-live.
Anyone who has watched a payment aggregator application sit in limbo knows the shape of it. Engineering finished in March. The product was ready in April. In July, the application is still open because a firm signed the audit that the regulator does not recognise, and the whole process restarts.
The same pattern shows up in the fortnight before an exchange submission deadline, when a trading member discovers their auditor’s empanelment expired in the middle of the engagement. Technically, the testing happened. Practically, it did not count.
What worsens the situation is that the failure is silent until the end. Nobody tells you at kickoff that the report will be rejected. You find out at submission, with the deadline already behind you.
So the first thing to understand about Indian VAPT is that you are buying two things at once: security testing and a signature the regulator will accept. These two purchases are not the same, and many firms excel at one but are ineffective at the other.
What CERT-In empanelment actually is
The Indian Computer Emergency Response Team sits inside the Ministry of Electronics and Information Technology and draws its authority from Section 70B of the Information Technology Act, 2000. One of its statutory functions is to maintain a published list of security firms that it has technically vetted to audit Indian organisations.
Getting onto that list is not a registration form. CERT-In evaluates methodology documentation, technical capability, lab infrastructure, staff certifications and the quality of audits the firm has already delivered. Applicants sit practical black-box testing rounds designed to establish whether they can actually find things. Approval runs for a defined term, usually around three years, and has to be renewed.
Each approved organisation is assigned an empanelment number. It looks like 3(15)/2004-CERT-In (Vol. XI), and it prints on every audit certificate the firm issues. When a procurement team says they are verifying the auditor, that number is what they are checking.
It’s worth saying plainly, because the phrasing gets used loosely: a CERT-In empanelled vendor is an organisation on that list, nothing more and nothing less. It is not a certified product, not an accredited tool, and not a guarantee about the individual who will test your application.
Two further clarifications save a lot of confusion later.
Empanelment is category-specific
A firm may be empanelled for general Web/API application security audits and network testing, but not for wireless networks, SCADA/ICS operational technology, or source code reviews. Holding approval in one scope category does not imply authorization in others. Vendors rarely highlight these scope boundaries unprompted—so it is critical to verify that an auditor’s explicit CERT-In empanelment category covers your specific infrastructure assets (e.g., Cloud vs. Mobile/API vs. SCADA) before issuing an SOW.
Empanelment is a floor, not a ceiling
This distinction is the part the marketing pages skip. The panel tells you a firm cleared a baseline at a point in time. It tells you nothing about whether their engineers will find the authorisation flaw sitting in your production environment right now. Two empanelled firms can hand you work of wildly different quality and identical-looking certificates. Use the panel as your first filter, then start asking harder questions.
That distinction between the floor and the ceiling runs through the rest of this article, as it is the entire difference between an audit that satisfies a regulator and one that also makes you safer.
Why Choosing a CERT-In Empanelled VAPT Vendor Matters
Regulatory Acceptance vs. Technical Quality
Choosing from the list of CERT-In empanelled VAPT vendors means your audit report will be accepted. Choosing outside it usually means it will not be accepted, however good the testing was. That is an uncomfortable thing to write, because it is not a quality statement. Excellent security firms sit off the list. Their reports still get rejected at the filing stage.
Multi-Regulator Convergence and Procurement Gatekeeping
RBI, SEBI, IRDAI and UIDAI have converged on the same clause: the audit must be signed by an empanelled auditor. Procurement teams check the empanelment number printed on the certificate. If it is absent or lapsed, the submission fails, and you start again, usually against a deadline that has not moved.
Scale of Threat and Scrutiny
The scale behind the scrutiny is worth knowing. As of the government’s January 2026 update, 231 cybersecurity audit organisations were empanelled nationally. CERT-In handled roughly 29 to 30 lakh cyber incidents across 2025. In March 2026, the Reserve Bank disclosed more than 60 million attack attempts against itself in late 2025 alone.
Impact on SMBs and Mandatory Compliance
Smaller firms are not exempt from any of these incidents. CERT-In has recorded a 30% year-on-year rise in incidents involving small and medium businesses, which is a major reason why annual audits by empanelled auditors will become mandatory for MSMEs from 1 September 2025.
Strict Enforcement and Non-Compliance Penalties
And the deadlines are now real. SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) passed its blanket implementation date of 31 August 2025 with no further extensions. What remains is a strict, recurring compliance obligation: following the completion of the FY 2025–26 audit cycles, regulated entities must adhere to ongoing half-yearly audit submissions. For instance, audits for the period ending 30 September 2026 require CERT-In report submissions by 31 December 2026, followed by Action-Taken Reports (ATR) by 31 March 2027. Missing these windows exposes entities to daily non-compliance penalties ranging from ₹1,500 to ₹5,000, along with exchange-level disciplinary action.
Active Regulator Inspection and Emerging AI Directives
SEBI keeps issuing guidance around the framework without amending it, including a 5 May 2026 advisory on emerging AI tools for vulnerability detection. The consolidated LODR regulations were last amended on 14 July 2026. RBI is moving in the same direction, with its FREE-AI report and draft Model Risk Management guidance, which closed for comments on 24 July 2026.
The pattern is consistent. Regulators have stopped publishing frameworks and started inspecting them.
Why RBI, SEBI, IRDAI and UIDAI all insist on it
Four regulators, four frameworks, one shared clause: the audit must be signed by an empanelled auditor. Here is where it matters for each.
| Regulator | Where the requirement lands | Practical cadence |
|---|---|---|
| RBI | Cyber Security Framework, plus the PA-PG Master Direction naming empanelment for payment aggregator system audits and data-localisation System Audit Reports | Annual minimum, six-monthly vulnerability assessment for banks, plus testing on significant change |
| SEBI | Cybersecurity and Cyber Resilience Framework, covering brokers, AMCs, KRAs and market infrastructure institutions | Annual or half-yearly by entity category; Qualified Stock Brokers and MIIs run half-yearly regardless |
| IRDAI | Information and Cyber Security Guidelines for insurers and intermediaries | Periodic audit with reporting, policyholder data as the focus |
| UIDAI | AUA and KUA obligations for anyone touching Aadhaar authentication | Audit against UIDAI information security requirements, with particular scrutiny of how Aadhaar numbers are stored and transmitted |
CERT-In Incident Reporting and Log Retention
Alongside those, the CERT-In Directions themselves are in place. Direction No. 20(3)/2022, issued on 28 April 2022, requires specified cyber incidents to be reported within six hours of noticing them and ICT logs retained within Indian jurisdiction for a rolling 180 days. Neither obligation mentions an audit, but both assume somebody has established what normal looks like on your systems, which is why they travel together in practice.
Enforcement and Financial Exposure
The deadlines have also stopped being theoretical. SEBI’s framework passed its blanket implementation date of 31 August 2025 with no further extension, leaving a recurring obligation behind it rather than a one-off project. Miss a reporting cycle and entities face daily penalties reported in the ₹1,500 to ₹5,000 range, plus exchange-level action.
The DPDP Act, 2023, sits above all of these regulations. It does not mention CERT-In empanelment anywhere in the Act. What it does is create exposure of up to ₹250 crore for failing to implement reasonable security safeguards, and an audit from a recognised auditor is the strongest evidence you can present to the Data Protection Board that the safeguards existed and were tested.
Does any of this apply to you?
A fair question, because many Indian companies assume it does when it does not, and many assume it does not when it does.
You almost certainly need an empanelled auditor if you are: a bank, NBFC or cooperative bank; a payment aggregator, gateway or wallet; a stockbroker, AMC, KRA, depository participant or any SEBI-registered intermediary; an insurer or insurance intermediary; an AUA or KUA touching Aadhaar authentication; a participant in the ABDM health ecosystem; a supplier bidding on a central or state government tender; or an MSME caught by the September 2025 annual audit mandate.
You probably do not, if you are: an unregulated Indian SaaS company selling to overseas enterprises and pursuing SOC 2 or ISO 27001; a domestic B2B software firm whose customers ask for security evidence but name no specific auditor; or an early-stage product company with no regulated data and no government business.
For that second group, empanelment adds cost without adding acceptance. What your buyers actually want is rigorous testing from a competent firm, often with CREST accreditation or similar, and evidence that findings were retested. Paying an empanelment premium for a credential nobody will ask to see is a common and avoidable waste.
The grey area is companies in the second group that expect to be in the first within eighteen months. If a banking client, a payment licence or a government tender is on the roadmap, building the relationship with an empanelled firm early is sensible, because switching auditors mid-compliance cycle is its own headache.
Put together, the picture is consistent across every regulator: they have moved from publishing frameworks to inspecting against them, and the auditor’s identity is the first thing they check.
What to Look For When Selecting a CERT-In Empanelled VAPT Partner
Once empanelment has narrowed your list, the real work starts. Two firms on the same panel can charge similar money and deliver entirely different things, and the gap is not visible in either proposal. This section covers three areas where it becomes visible: how the testing is executed, who holds the certifications, and what lands in your inbox at the end.
Paperwork auditing versus technical VAPT
Here is what nobody says out loud during a sales call.
Every empanelled organisation can issue a Safe-to-Host certificate. The certificate looks the same whichever firm signs it, carries the same weight with your regulator, and costs roughly the same to produce. What differs enormously is what happened in the three weeks before the signature.
One firm runs a licensed scanner, exports the findings, tidies them into a house template, runs the same scanner again after you patch, and issues the letter. Everything in that process is legitimate. Nothing in it is wrong. It produces a compliant artefact.
Another firm puts two experienced testers against your authorisation logic for nine days. They create accounts in every role, substitute identifiers between them, walk your payment flow one request at a time, and chain three findings nobody rated above medium into a full account takeover.
Both approaches end with the same certificate. Only one of them tells you whether you can be breached.
What the two look like side by side:
| Paperwork-led audit | Technical VAPT | |
|---|---|---|
| Bulk of engagement time | Tool configuration and report assembly | Manual testing against application logic |
| Authorisation testing | Usually absent, or unauthenticated only | Every role against every other role, plus tenancy |
| Business logic | Not attempted | Central to the engagement |
| Findings volume | High, heavily duplicated, severity-inflated | Lower count, higher average severity |
| Finding language | Scanner output, lightly edited | Written for the developer shipping the patch |
| Chained attack paths | Not modelled | Usually the headline finding |
| Retest | Same scanner re-run | Original exploit attempted again |
| Certificate issued | Yes | Yes |
That last row is the uncomfortable one. Both routes end in the same artefact, so the market has very little price pressure on the second column.
The diagnostic question is simple, and I would ask it of any firm you are considering: what proportion of findings on a typical engagement came from manual work rather than tooling? A serious firm gives you a number, usually with a caveat about how it varies by application type. A scanner-led firm gives you a paragraph about their comprehensive hybrid methodology. The answer matters, and how comfortably it arrives matters more.
A second question that works almost as well: ask what they would do if they finished the automated phase and found nothing. A tester who says “then the interesting part starts” is thinking correctly. A tester who treats a clean scan as a finished engagement has told you exactly what you are buying.
The key point is that both firms are on the same government list, so the list alone cannot be your selection criterion.
Credentials that belong to people, not letterheads
Company-level empanelment means that an organisation has passed a review. It says nothing whatsoever about who will be assigned to your project.
This is not a hypothetical concern. A properly empanelled firm with a strong reputation can hand your application to somebody in their first year, and nothing in the empanelment process prevents it. The RBI’s own 2026 Directions now require banks to assess the qualification, expertise and competency of both the testing firm and the individual personnel it assigns at every selection and renewal, which tells you the regulators reached the same conclusion.
The certifications worth asking about, and what each one actually is, are as follows:
| Certification | What it demonstrates | Why it matters for your engagement |
|---|---|---|
| OSCP | Hands-on exploitation under exam conditions, 24 hours, real targets | The holder has actually broken into things, not just read about it |
| CREST (CRT, CCT) | Assessed methodology and reporting against an international standard | Consistency and report quality, not just raw skill |
| CISA | Audit rigour, controls and evidence | Useful when the deliverable has to survive an inspector |
| CEH | Baseline vocabulary and awareness | A starting point, not a differentiator |
| CISSP | Breadth across security domains, management-leaning | Signals a senior reviewer rather than a hands-on tester |
Three questions to put alongside the list. How many testers will be assigned? Whether the people who scoped the work will run it, because in many firms they do not. And whether you can have the assigned engineers named in the contract, which is a reasonable ask and a revealing one.
The point is that you are hiring specific people for a specific fortnight, and the firm’s letterhead is only a proxy for that.
Deliverables that survive contact with an auditor
A report clears an audit when a stranger can read it and follow what happened. This requirement is a higher bar than it sounds, and most reports do not meet it.
What has to be in there:
CVSS-rated severity for every finding –
Adjusted for your business context rather than reported raw. A critical-rated CVE in a library your code never calls is not your most urgent problem, and a report that says otherwise is wasting your engineers’ attention.
Reproduction steps a developer can follow without a phone call –
The request was made, the parameter was changed, and the response was observed. If your team has to book a session with the tester to understand a finding, it means that the finding is not documented.
Business-context risk, not scanner language –
“Broken access control at /admin” is a tool output. “Any authenticated customer can retrieve any other customer’s transaction history by incrementing a sequential identifier, exposing counterparty names and amounts across the entire customer base” is a finding.
A remediation roadmap ordered by exploitability –
not by severity score. Thirty medium findings ordered alphabetically is a list. A plan consists of six items ordered by what an attacker would reach first.
Formal closure validation after retesting –
This issue is the one to negotiate hardest on, so it gets its own paragraph.
Insist that retesting is included rather than billed separately. If a vendor charges extra for the retest, they have quietly turned the closure certificate into an upsell, and closure is the entire point of the exercise. You are not buying a list of problems. You are buying documented evidence that the problems are gone. A report without a verified closure record increasingly fails Indian regulatory review on its own.
Ask for a redacted sample report before you sign anything. Read it properly. If the findings sound like they came out of a tool, they did, and no amount of methodology language in the proposal will change what arrives.
Taken together, these three filters, execution depth, named credentials and deliverable quality, will separate the shortlist faster than any amount of comparing service lists.
Buyer’s Tip: Matching CERT-In Categories to Your Asset Stack
Before committing to any firm on this list, verify their active CERT-In empanelment schedule on the official MeitY CERT-In portal. Ensure their specific empanelment scope matches your target deployment environment:
-
Web, Mobile & API Products / SaaS: Require empanelment in Application Security Audits & VAPT.
-
Cloud & Enterprise Networks: Require empanelment in Network Security Audits & Infrastructure Testing.
-
Hardware, IoT, & OT/SCADA: Require empanelment in ICS/OT & ICT Infrastructure Audits.
-
Regulated Core Logic / Web3: Require empanelment covering Source Code Audits.
(Note: Leading providers like Qualysec structure their CERT-In audits to cover full-stack Application, Cloud, API, and Source Code VAPT under a unified compliance framework).
The Top 10 Empanelled VAPT Firms to Shortlist for 2027
This list is not ordered by company size, marketing spend, or how often a name turns up in directory listings. It is ordered by what matters when you are the one signing: manual testing depth, sector fit, report quality, and whether the team does security work when nobody is paying them to perform.
One caveat before the list. Panels change. Verify your current standing on the CERT-In portal before you sign for any firm here.
| # | Vendor | Core strength | Best suited for |
|---|---|---|---|
| 1 | Qualysec Technologies | Manual-first VAPT across web, mobile, API, cloud, IoT and AI | Fintech, medical devices, SaaS needing developer-usable reports |
| 2 | Payatu | Hardware, IoT, firmware and AI security research | Connected devices, automotive, AI products |
| 3 | SISA Information Security | Payment security and PCI DSS | Banks, payment aggregators, processors |
| 4 | Network Intelligence | Managed compliance and SOC at scale | Conglomerates consolidating audit obligations |
| 5 | Kratikal | VAPT plus phishing simulation and v-CISO | Mid-market maturing on several fronts |
| 6 | SecureLayer7 | Methodology-led offensive testing and PTaaS | Dev-heavy teams on fast release cycles |
| 7 | eSec Forte Technologies | VAPT, forensics, SOC, ICS and OT depth | Public sector and industrial environments |
| 8 | ISECURION | Application security, code review, smart contracts | Fintech, Web3, cloud-heavy startups |
| 9 | Net Square | Deep manual logic bug hunting | Custom and legacy financial systems |
| 10 | CyberQ Consulting | ISO 27001 implementation and structured audit | Organisations running certification programmes |
1. Qualysec Technologies
Qualysec runs manual-first VAPT across web applications, mobile apps on iOS and Android, APIs, cloud environments, IoT and next-generation AI systems. It is a specialised penetration testing company. The company works out of Bhubaneswar and Bengaluru, has delivered over 3,700 penetration test reports to 520-plus clients across 43+ countries, and structures its reports to satisfy 74+ compliance frameworks, including PCI DSS, ISO 27001, SOC 2, HIPAA, GDPR and FDA requirements, and has also found 60,000+ vulnerabilities.
Testing Methodology & Certifications
The methodology runs automation first, deliberately, to clear the mechanical classes quickly and cheaply. Certified consultants then spend the bulk of the engagement on the things tooling cannot reach: business logic abuse, authorisation across role and tenant boundaries, and chained findings that individually look unremarkable.
On credentials, Qualysec is a CERT-In empanelled and CREST-accredited cybersecurity firm, holding ISO/IEC 27001:2022, ISO 9001:2015, and ISO 13485:2016 certifications. That last one is worth pausing on: ISO 13485 is a specialized quality management standard for medical devices, which explains why a significant share of Qualysec’s work involves FDA 510(k) submission support rather than standard application testing.
Ratings & Industry Alignment
The Clutch profile carries 4.9 across 31 reviews with Premier Verified status refreshed in June 2026.
Post-remediation retesting is included rather than invoiced separately, which, as covered above, is worth more than it sounds.
For Indian regulated work specifically, the relevant depth sits where audits touch SEBI CSCRF, RBI, IRDAI, UIDAI or ABDM requirements, and published case studies span SaaS, fintech, e-commerce, HIPAA and FDA programmes.
Core Overview
Services: Web, mobile, API and cloud VAPT · IoT security testing · AI and ML application testing · source code review · compliance-aligned audit for SOC 2, ISO 27001, HIPAA, PCI DSS, RBI and SEBI
Best suited for: Fintech and BFSI platforms, medical device and healthtech firms facing FDA or ABDM scrutiny, B2B SaaS companies working through enterprise security questionnaires, and any team that wants findings their developers can act on without a translation layer.
2. Payatu
Payatu is the firm Indian hardware teams call, and for good reason. The people running your assessment are also the ones publishing CVEs, presenting at DEF CON, and maintaining EXPLIoT. This open-source IoT security framework turns up in other pentesters’ toolkits.
They are CERT-In empanelled, ISO 17025 accredited as a testing laboratory, and were named Best Security Services Company of the Year by the Data Security Council of India. They also founded Nullcon and Hardwear.io, two of India’s longest-running security conferences.
Where they go that most Indian firms do not: hardware reverse engineering, firmware analysis, adversarial testing on LLM applications, and automotive cybersecurity aligned to ISO/SAE 21434 and UN ECE R155 and R156.
Services: IoT and embedded security · AI and ML security audit · automotive cybersecurity · red team assessment · critical infrastructure · web, mobile, API and cloud VAPT
Best suited for: Connected device manufacturers, automotive OEMs and tier-one suppliers, AI product teams, and anyone whose risk is a determined researcher rather than a missed patch.
3. SISA Information Security
SISA has been a payment security specialist since 2006 and holds PCI Qualified Security Assessor status alongside empanelment. Over 400 professionals across delivery centres in India, the USA, UK, Bahrain, UAE, Singapore and Australia, working across 40-plus countries.
Their credential stack includes QSA, ASV, P2PE-QSA, PFI and 3DS Assessor. For a payment aggregator or a core banking platform, consolidating several audit obligations with one firm is the entire value proposition, and few firms can do it.
Services: PCI DSS audit and QSA · payment security · forensic investigation · BFSI compliance
Best suited for: Core banking institutions, payment aggregators, gateways and processors, and large merchants handling high daily transaction volumes.
4. Network Intelligence
Network Intelligence is the firm to which large BFSI and telecom CISOs feel comfortable handing a master service agreement. Assessment, GRC, MSSP, and managed security are all provided under one roof, which is important when you would rather not coordinate five vendors and five reporting formats.
PCI QSA status alongside empanelment means a bank or insurer can consolidate obligations rather than running parallel engagements.
Services: VAPT and assessment · GRC and compliance · managed security services · security training
Best suited for: Conglomerates, global banks, telecom operators, and distributed organisations that need continuous vulnerability management alongside formal audit tracks.
5. Kratikal
Noida-based and long-established, Kratikal pairs penetration testing with phishing simulation, ISO and SOC 2 readiness, and virtual CISO services. It operates the first ISO/IEC 17025 NABL-accredited cyber lab in India and is NSE-authorised for trading-member system audits, serving over 650 enterprises.
The fit is mid-market companies that need to mature on several fronts simultaneously and would rather not run three procurement processes to do it.
Services: Web, mobile and network VAPT · ISO 27001 and SOC 2 audit · phishing simulation · virtual CISO
Best suited for: Mid-market BFSI, e-commerce and IT services firms securing applications and training staff at the same time.
6. SecureLayer7
One of the cleaner methodology-led pentest firms in India, it delivers its services through a Penetration Testing as a Service model, featuring real-time dashboards, repository integration, and live findings rather than a report at the end.
They lean on documented standards alignment across OWASP, NIST, and PCI, which produces an audit trail that procurement teams accept without dispute. An OSCP-weighted team and a visible research habit round it out.
Services: Web and mobile VAPT, API and cloud pentesting, red team, PTaaS
Best suited for: Agile product companies, cloud-native software firms, and dev-heavy teams that want findings landing in their pipeline rather than in a PDF.
7. eSec Forte Technologies
A CMMi Level 3 certified consulting and IT security services company, empanelled and PCI DSS QSA certified, operating across India, the US, Singapore and Sri Lanka for Fortune 1000 and government clients.
Their real differentiator is depth in critical information infrastructure, SCADA and operational technology, plus the institutional knowledge of how public sector procurement actually works. Government and PSU buying is its own discipline, and knowing the paperwork saves months.
Services: VAPT · cloud security · digital forensics · PCI DSS QSA · red team · SOC operations
Best suited for: Energy, heavy manufacturing, PSUs, telecom operators, and anyone running SCADA or OT environments.
8. ISECURION
Bengaluru-based, offering VAPT, compliance audit and SOC 2 services, with secure code review as a genuine strength rather than an add-on. Alongside standard application and network work, they cover smart contract audits and crypto exchange testing, where most Indian firms have thin coverage.
Consistent, unfussy delivery at a price point that works for startups and mid-market firms making their first serious run at ISO 27001 or a large customer’s security questionnaire.
Services: Web and mobile VAPT · secure code review · smart contract and crypto exchange audit · SOC 2 · DPDP compliance
Best suited for: Fintech applications, Web3 startups, and enterprises with multi-layer cloud deployments.
9. Net Square
Founded in 2000 in Ahmedabad and empanelled since 2013. Co-founder Saumil Shah is a regular on the Black Hat, RSA and CanSecWest circuit, and the firm’s work emphasises manual penetration testing and secure code review over tooling.
Net Square is the call when the risk is not a known CVE but something structural that nobody thought to check, which is usually the case in custom-built and legacy systems.
Services: Application security testing · secure code review · IoT security · red teaming · security training
Best suited for: Custom workflows, legacy business systems, mission-critical identity platforms, and government engagements.
10. CyberQ Consulting
Founded in 1997 in New Delhi, with services centred on ISO 27001 implementation, security audit and risk assessment. The positioning is more focused on consulting and compliance than on offensive security, which is a strength rather than a weakness if that is what you need.
This provider is worth shortlisting when the organisation is running a structured certification programme and wants the audit, gap analysis, and implementation support from one place.
Services: VAPT and security audit · ISO 27001 consulting · risk assessment · compliance advisory
Best suited for: Organisations building a certification programme from scratch and needing advisory alongside testing.
Who did not make this list, and why?
It’s worth a short note, because omission is often read as judgement, and usually it is not.
Several hundred organisations are on the panel. Many are excellent regional firms doing solid work for clients who will never appear in a national listicle, and a few are large consultancies whose security practice is real but buried inside a broader advisory business. Neither absence means anything about quality.
What kept firms off: no demonstrable manual testing depth, no published sample report, no sector specialisation that would help a reader narrow a shortlist, or a service mix so broad that security testing is clearly a sideline. None of those is disqualifying for the right buyer. They just make a recommendation hard to justify to a stranger.
The other category deliberately excluded is firms making empanelment claims that do not survive a check against the registry. That happens more than it should.
A note on how to use this list
Empanelment shrinks your options from everyone to just a few hundred. Sector fit shrinks it to perhaps a dozen. The six questions in section two shrink it to two or three, and at that point price becomes a reasonable tiebreaker rather than a selection criterion.
What this list cannot do is tell you which firm will find the bug that matters in your specific application. Nobody can tell you that in advance. What you can do is improve your chances: match expertise to the asset, insist on manual depth, name the engineers, and read a sample report before you commit.
The Critical Steps of a Compliance-Grade VAPT Assessment Lifecycle
A compliance-grade engagement runs eleven steps across roughly two to four weeks for a single application, or six to ten weeks for a multi-asset enterprise scope. This section walks through each step, what should happen inside it, and where engagements most often go wrong.
Indicative timings, which are worth holding a vendor to:
| Scope | Typical duration | Manual testing share |
|---|---|---|
| Single web application | 2 to 4 weeks, including report and one retest | 7 to 12 days |
| Application plus API and mobile | 4 to 6 weeks | 12 to 20 days |
| Multi-asset enterprise, web, mobile, API, cloud | 6 to 10 weeks | 20 days and up |
Anything advertised as a complete audit in two or three days is a scan with a covering letter.
Step 1: Scope definition
Every application, IP range, API, cloud environment, and physical location must be named in writing, along with everything that is explicitly out of scope and the reasons why.
Scope drift discovered mid-test is the single most common cause of a blown deadline. It happens because somebody remembers the admin subdomain in week two, and now the testers either work unpaid or you move the submission date.
Get exclusions written down. Undocumented exclusions become your problem later.
Step 2: Rules of engagement
Testing windows, allow-listed source IP addresses, named escalation contacts on both sides with out-of-hours cover, and an agreed protocol for what happens if a critical system degrades during testing.
The detail teams forget is the out-of-band escalation path. If a tester finds something serious on day three, you want to know about it on that day, not in the final report three weeks later. Agree on that path before testing starts.
Step 3: Information gathering
Open ports, subdomains, active services, technology fingerprinting, and an accurate footprint of what is genuinely exposed to the internet.
This step routinely surfaces assets the client did not know were live. Staging environments indexed by search engines, old API versions still answering, and a partner integration endpoint from a pilot that ended two years ago. In my experience, it is the most reliably surprising forty-eight hours of any engagement.
Step 4: Vulnerability assessment
Automated tooling establishes the baseline: known CVEs, missing patches, outdated components, TLS configuration, and common misconfigurations.
This work is fast and should not dominate the invoice. A weak audit stops here and writes the report. It is also, to be fair, genuinely useful work, and skipping it to look sophisticated would be a mistake.
Step 5: Manual penetration testing
The phase you are actually paying for. Authorisation bypass, business logic abuse, privilege escalation, tenant isolation, and chained exploitation across findings that individually look minor.
What this phase looks like in practice, from an engagement on a lending platform: the scanner returned clean on the loan application module, which should make you suspicious rather than pleased. Opening two borrower accounts and stepping through the flow one request at a time, step four submitted an applicationStage parameter. Changed from documents_pending to approved, resubmitted, and the application moved to approved. No credit check, no document upload, no maker-checker.
Forty minutes, and it was the worst finding of the engagement by a distance. No tool would have found it, because every request involved was well-formed, authenticated, and returned a perfectly valid 200. The application did exactly what it was told. Nobody had written down what it should refuse to accept.
Step 6: Exploitation and validation
Findings proven rather than asserted, false positives removed, and impact demonstrated safely.
The distinction between “the scanner flagged this” and “we did this and here is the response” is most of what separates a useful report from a noisy one.
Step 7: Risk classification
CVSS scoring, adjusted for the business context of the affected asset rather than reported raw from the tool.
An unauthenticated endpoint returning a marketing banner and an unauthenticated endpoint returning transaction history score identically on some scanners. They are not the same finding.
Step 8: Reporting
Findings documented with reproduction steps, evidence, business impact and prioritised remediation, plus an executive summary a board can act on without a translator.
Ask for a walkthrough call rather than just a document. A finding your developer does not understand is a finding that will be closed incorrectly, and that is worse than leaving it open because now everyone believes it is fixed.
Step 9: Remediation
Your engineers fix it with access to the tester who found the issue. That access is the difference between a three-day fix and a three-week one.
Step 10: Retesting
Fixes are verified independently and checked for anything the patch itself introduced. Patches create vulnerabilities with some regularity.
A finding marked resolved without independent verification is a finding somebody has chosen to believe in.
Step 11: Final report and certificate
The closing report, issued alongside the Safe-to-Host or compliance certificate, carrying the auditor’s empanelment number, is ready for regulatory submission.
Confirm before signing how long this final stage takes. Some firms complete the closing document in two working days, while others take three weeks, and against a filing deadline, that gap is the whole difference. Ask for it in writing.
Turnaround here matters against a deadline. For context on what good looks like, Dubai Chambers completed its full retest cycle inside a two-week window in coordination with its technical team, which is the kind of pace a submission date demands.
When run properly, those eleven steps produce two outcomes at once: a system that is measurably harder to attack and a document that will survive an inspector reading it closely. Most engagements deliver only the second.
The High Stakes of Non-Compliance or Poor-Quality Audits
There are two ways the process goes wrong, and organisations worry almost exclusively about the first one. The expensive failure is usually the second. This section covers both.
Regulatory deadlines, and what missing one actually costs
The Indian regulatory calendar has become unforgiving in a specific way: the deadlines are fixed, the audit takes weeks, and you cannot compress the audit to catch up.
What is live right now:
SEBI CSCRF passed its blanket implementation deadline of 31 August 2025 with no further extension. What remains is a recurring cycle rather than a project, with half-yearly audits and action-taken reporting for several entity categories. Entities that miss a cycle face daily penalties reported in the ₹1,500 to ₹5,000 range plus exchange-level action, and the penalty accrues while you scramble.
MSME annual audits by empanelled auditors became mandatory from 1 September 2025, following a recorded 30% year-on-year rise in incidents affecting small and medium businesses. A category of organisation that had never commissioned an audit now has to do so annually.
CERT-In Direction No. 20(3)/2022 still requires incident reporting within six hours of noticing and 180-day log retention within Indian jurisdiction. The six-hour clock is the one organisations consistently have no plan for. It passes rapidly at two in the morning on a Sunday, and “we were still confirming it” is not a defence that the direction contemplates.
DPDP Act, 2023, carries exposure up to ₹250 crore for failure to implement reasonable security safeguards. The Act does not require CERT-In empanelment, but if you ever have to demonstrate reasonable safeguards to the Data Protection Board, an audit from a recognised auditor is the strongest single document you can produce.
What Missing One Actually Costs
The compounding problem is timing. A regulator’s deadline does not move because your auditor’s empanelment lapsed in week two, or because the scope turned out to be twice what anyone estimated, or because remediation took longer than the sprint you allocated. Build backwards from the filing date with a genuine buffer, and verify the auditor’s standing before the engagement rather than after.
Deadlines are the failure everyone plans for. The next one is the failure that nobody plans for.
What manual testing finds that tools cannot
A pattern we see constantly in Indian fintech and KYC platforms: the interface masks the Aadhaar number correctly, and the API behind it does not.
Every scanner in the world returns a clean result on that endpoint. It is a well-formed, authenticated request returning a valid 200. Nothing about it looks wrong to software. But the full Aadhaar number is now in the response body, in the browser’s network log, and very likely in your application logs for the next 180 days.
The masking belongs at the serialisation layer, so every consumer of that endpoint inherits it. Do it in the interface, and the next mobile client, partner integration, or internal dashboard gets the raw value again. Under the DPDP Act, 2023, that is avoidable personal data exposure, which makes it a regulatory problem rather than a code-quality one.
The false sense of security
The costlier failure is quieter, and it does not announce itself for months.
A shallow audit produces a clean report. The clean report goes to the board. The board concludes the risk is handled and reallocates the budget somewhere it is visibly needed. Everybody involved acted reasonably on the information they had, and the organisation is now less safe than before the audit, because it has stopped looking.
A scanner-driven engagement will not find the parameter that moves a loan application to approved. It will not find that transaction identifiers are sequential and unchecked. It will not find that a session token survives a password change or that the API returns the full Aadhaar number to the interface carefully. Every one of those requests is well-formed, authenticated, and returns a valid response. Nothing about them looks wrong to software.
What a Real Engagement Looks Like
A real engagement is instructive here. On a recent Qualysec assessment, Wubble AI came to us with a production environment attackers had already seized. The work covered the SaaS platform, cloud infrastructure and every associated environment, documented precisely how the attackers had gained initial access, walked the engineering team through each fix and retested to confirm zero remaining vectors. The client’s own account is that the root cause of the original breach was something their internal team could not have found alone.
A scanner-driven audit on that platform would have issued a certificate. The certificate would have been genuine. It would also have missed the thing that had already happened.
Commercial Consequences
There is a commercial version of the same failure, and it catches SaaS companies rather than regulated entities. A thin report clears a customer’s security questionnaire this year. Next year the same customer sends a longer questionnaire asking about testing methodology, manual coverage and remediation SLAs, and the thin report cannot answer any of it. The deal that took three weeks to close last time takes three months or does not close.
That asymmetry is worth understanding. A failed deadline costs you money and a stressful quarter. A clean report on an insecure system costs you the breach plus the twelve months of false confidence that preceded it, and the second cost is the one that ends up in the newspaper.
Why Partner with Qualysec for Your Next Security Assessment?
Everything above applies to choosing any firm on the list, including this one. Here is what Qualysec specifically brings, framed against the three filters in section two.
Threat-modelled penetration testing
Engagements start by asking how an attacker would actually monetise your platform, which sounds obvious but is not how most testing is scoped.
For a lending platform, the question is how someone gets money out without repaying it. In the case of a healthtech application, it is how somebody reaches records they have no clinical relationship with. When considering a multi-tenant SaaS product, it is how one customer reaches another customer’s data. That model directs the manual phase, and it is why we find chained business logic flaws rather than catalogue them.
Automation runs first and runs fast, clearing known CVEs, missing headers and configuration issues so they are not soaking up senior tester hours. The bulk of the engagement focuses on areas that tooling cannot structurally reach.
The result is that findings tend to be fewer and more severe than a scanner-led engagement produces, which is initially disconcerting and ultimately the point.
Audit-ready output
Reports are structured to satisfy 52-plus compliance frameworks, with 60-plus clients taken through SOC 2 and 30-plus through HIPAA. Findings map to the specific framework you are filing against rather than to a generic OWASP reference, so the document drops into your submission rather than sitting beside it needing translation.
The outcomes are checkable. FPT achieved 100% remediation of critical and high findings after retesting and full compliance with its vulnerability management controls. GroupTogether closed every critical and high finding before release, with API security and input validation controls strengthened and payment data handling validated. Aicura Solutions cleared eight issues across its customer journey, back-office journey and Azure environment as a prerequisite for a banking licence application.
Every report carries a letter of attestation for procurement, tenders and audit, and the accreditation set behind includes CREST, ISO/IEC 27001:2022, ISO 9001:2015 and ISO 13485:2016.
A note on scope honesty: the rest of this article argues for interrogating vendors, and Qualysec is a testing firm, not a managed security provider. There is no SOC, no twenty-four-hour monitoring, and no GRC consulting practice. If what you need is a single partner to run security operations across a conglomerate, several firms on this list are a better fit, and it is worth saying so. What this solution is built for is finding things in applications and proving they were fixed.
Developer-friendly support
Findings arrive with reproduction steps written for the engineer who has to ship the patch, not for the auditor’s checkbox. Your developers get direct access to the tester who found the issue rather than a ticket queue.
Progress is visible live through the Qualysec Vulnerability Dashboard throughout the engagement, so you are not waiting on a final report to learn what has been found. Levin Software’s CEO described exactly the process: daily progress emails covering pre-assessment, tool setup, pre- and post-authentication testing, manual testing and authorisation testing, alongside live dashboard visibility.
Retesting is included as standard rather than invoiced separately, because a finding marked closed without verification is not closed.
Taken together, that is the argument: manual depth where it matters, output your regulator accepts without rework, and support your engineers can actually use.
Frequently Asked Questions
Is a simple automated vulnerability scan enough to satisfy a CERT-In requirement?
No, and it is important to be precise about this because a lot of budget is wasted on the assumption that a simple automated vulnerability scan is sufficient.
Empanelled audits require manual validation, business logic testing and analyst-verified findings. A raw scan report will not support a Safe-to-Host certificate, and inspectors have learned what scanner output looks like when it arrives dressed as an audit. An “annual VAPT” that turns out to be an automated scan is a documented inspection finding, not a technicality somebody overlooks.
Where scanning genuinely earns its place is the mechanical layer, and it earns it well. Known CVEs in dependencies, missing security headers, outdated TLS configuration, directory listing left enabled, and default credentials still live are all issues that need to be addressed. That work is rapid, cheap and comprehensive in a way no human can match, and any engagement that skips it to look sophisticated is wasting your money differently.
The mistake is treating the baseline as the ceiling.
There is also the security argument, which matters more than the compliance one. Scanners find known CVEs, missing patches and configuration errors, and they detect them well. They cannot find an authorisation flaw, because software has no way of knowing that the record it just fetched belongs to someone else. Those flaws cause a large share of real breaches.
Scanning belongs in the engagement. It just cannot be the engagement.
How often do Indian regulators require businesses to undergo VAPT?
Annually at absolute minimum, and considerably more often in several sectors.
| Regime | Cadence |
|---|---|
| RBI-regulated banks | Six-monthly vulnerability assessment, plus testing on significant change |
| SEBI CSCRF, by entity category | Annual for qualified and mid-size entities, half-yearly for market infrastructure institutions |
| SEBI Qualified Stock Brokers | Half-yearly VAPT and cyber audit regardless of other categorisation |
| SEBI, internet-facing systems | Quarterly vulnerability scanning on top of the audit cycle |
| MSMEs | Annual, mandatory since 1 September 2025 |
| IRDAI-regulated insurers | Periodic, with reporting |
Beyond the calendar, almost every regulator additionally requires testing after significant change to authentication, authorisation, the data model or the exposed surface. That trigger matters more than the annual date for teams shipping weekly, because a report from eleven months ago describes an application that no longer exists.
One planning note that saves grief. The cadence describes when the report must exist, not when the engagement starts. A half-yearly obligation with a six-week engagement and a two-week remediation sprint means you begin roughly two months before the date, every cycle, and permanently. Teams that discover these issues in month five of a six-month cycle end up paying rush rates for shallow work.
The practical answer for most organisations: follow your regulator’s cadence for the formal audit, run continuous scanning between cycles, and treat any significant architectural change as its trigger.
What is a “Safe-to-Host” certificate, and who can officially sign off on it?
A Safe-to-Host certificate is a formal attestation that an application or system has been audited, that the vulnerabilities identified were remediated, and that it is fit to go live.
Only an empanelled auditor can issue one. That is the entire reason empanelment exists as a commercial consideration rather than just a quality signal. Hosting providers, government departments and regulators ask for the auditor’s empanelment number alongside the certificate, and they check it.
Two things worth knowing. The certificate is issued after remediation and retest, not after the initial assessment, so a firm that charges separately for retesting has effectively made the certificate an upsell. And the certificate reflects a specific scope at a specific date. It does not cover the module you shipped last month, which is why the significant-change trigger exists.
If somebody offers you a Safe-to-Host certificate without a retest cycle, something is wrong with the process.
Conclusion
Empanelment gets a vendor past your procurement clause. It does not tell you whether the audit will find anything.
That is the honest summary of a market where every firm on the panel can issue an identical-looking certificate, and where the gap between a real assessment and a scanner wrapped in a template only becomes visible months later, usually at the worst possible time.
So the selection criterion has to be depth rather than listing. Manual testing hours. Individual engineer certifications are specified in the contract. Report quality you have verified by reading a redacted sample. And whether closure validation is included or quietly sold to you afterwards.
Three questions will do most of the work. Request a sample report before you sign. Clarify who is testing, by name. Confirm what happens after the fixes ship. The firms that answer all three comfortably are the ones whose certificates are worth holding.
And verify the panel yourself. Not the badge on the website, not the PDF in the proposal. Check the live registry, the registered legal name, the category, and the expiry date. It takes five minutes, and it is the cheapest insurance in this entire process.
