WASA Audit Explained: Complete Checklist, Sample Report, and Tools

What Is a WASA Audit?

A WASA audit, short for Web Application Security Assessment or Audit, is a structured examination of how a web application behaves under attack and is delivered as evidence that a regulator, auditor, or enterprise buyer will accept. It combines automated scanning with manual testing of authentication, authorisation, session handling, APIs and business logic, then maps every finding to a recognised control framework.

This process is the part that causes confusion in India. A WASA audit is only half a technical exercise. The other half is evidentiary, because the output must convince someone who does not work for you and has no reason to trust you. Usually that is an RBI inspection team. Sometimes the task means a SEBI compliance portal submission, an IRDAI filing, a tender evaluation committee, or the information security lead at a bank you are trying to sell to.

This changes how the work should be scoped. A test can find genuinely good bugs and still be useless to you if the report comes back with no control mapping, no attestation and no record that anything was retested. I have watched that happen. The client had paid for competent testing and could not use a page of it.

What a WASA Audit Is Not

So, it is not three things.

Not a vulnerability scan. A scan points a tool at your application and exports whatever comes back: missing headers, old libraries, and known CVEs. It’s useful and cheap, but structurally incapable of finding an authorisation flaw, because software has no way of knowing that the record it just fetched belonged to somebody else.

Not just a penetration test, either. A pentest asks whether someone can get in. An audit asks that too, then keeps going: was the system built correctly? Do the controls hold when you switch roles? Will the evidence survive an inspector? Indian RFPs use both words for both things, which is most of the reason two quotes for the same application arrive seven times apart.

And it is not a certification. There is no WASA certificate. Nobody issues one. What you get is a report plus, usually, a letter of attestation, and every bit of its credibility comes from who did the work.

Why WASA Audits Matter in India Right Now

Three forces converged between 2024 and 2026 to turn web application audits from a good practice into a filing requirement for most regulated Indian organisations.

• The money changed. IBM’s research put the average cost of a data breach in India at ₹22 crore, the highest ever recorded here. A decent audit on a mid-sized application runs ₹1 lakh to ₹4 lakh. Nobody argues about that ratio in a budget meeting any more.
• The rules got specific. This is the bigger shift. CERT-In’s 2022 Directions, SEBI’s CSCRF, the RBI’s 2026 Directions: each of them now names who may test, how often, and what has to be in the report. We went from guidance you could interpret generously to paragraph numbers with dates attached and inspectors who quote them.
• And buyers started asking. Any Indian SaaS company selling into banking or insurance knows this one. The security questionnaire arrives, it wants an independent web application assessment, and somebody goes looking for last year’s report. Then they discover it was a scan. The deal does not die; it just sits there for six weeks.

Secure Your Business with an Expert-Led Security Assessment

Partner with certified security specialists to identify, prioritize, and remediate real-world risks across your systems.

Book a Security Assessment →

What has actually changed for buyers

The last row is the one that catches organisations out. An audit that satisfied an inspector in 2022 will not necessarily satisfy one in 2026, because the inspectors have learned what a scanner export looks like.

WASA Audit vs Penetration Testing vs VAPT vs Vulnerability Scanning

Four terms, used interchangeably in most Indian RFPs, describe four different amounts of work at four different price points. Getting the vocabulary right is the first cost control you have.

The practical rule: the word on the invoice tells you nothing. Ask how many tester-days are allocated, how many are manual, whether testing is authenticated, and how many user roles will be tested against each other. Those four answers determine what you are actually buying.

A quote below of roughly ₹75,000 for a full web application in the 2026 Indian market is almost always an automated scan with a new cover page. That is not a moral judgement; it is arithmetic. Two senior tester-days at Indian market rates cost more than that before anyone writes a report.

Who Needs a WASA Audit in India: The Regulatory Map

Most Indian organisations discover they need a web application audit through a regulator, a tender, or a customer, and each one wants something slightly different. Here is the landscape as it stands in 2026.

CERT-In Directions, 2022

Direction No. 20(3)/2022, issued on 28 April 2022 under Section 70B(6) of the Information Technology Act, applies to service providers, intermediaries, data centres, body corporates and government organisations. The two obligations everyone quotes:

• Six-hour incident reporting. Specified cyber incidents must be reported to CERT-In within six hours of noticing them. The six-hour reporting period starts from when the incident is first noticed, not from when it is confirmed.
• 180-day log retention. ICT system logs must be maintained securely within Indian jurisdiction for a rolling 180 days.

Both presuppose that you know what a normal day looks like on your application, which in turn presupposes that somebody has assessed it. This is why the Directions and the audit requirement travel together even though the Directions do not command an audit in so many words.

RBI (Commercial Banks) Directions, 2026

The Directions set a higher standard for who may test, not just how often. Para 156 requires the bank to assess the qualification, professional expertise, credentials and competency of the testing firm and of the individual personnel it assigns at every selection, appointment, engagement and renewal. Para 159 imports CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines into the supervisory relationship whenever an empanelled auditor is engaged.

In practice this means six-monthly vulnerability assessment, production environment testing, cloud environments in scope, and a quarterly closure pack for the IT Strategy Committee and the Information Security Committee. That last artefact did not exist in most banks before the Directions and is now routinely requested.

SEBI Cybersecurity and Cyber Resilience Framework

CSCRF, issued under circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated 20 August 2024 and amended on 30 April 2025 and 28 August 2025, replaced the patchwork of separate cyber circulars for stock brokers, portfolio managers and KYC registration agencies with one framework covering the whole securities market.

What matters for a web application audit:

The principal implementation deadline was 31 August 2025 after two extensions, so the live obligation now is the recurring audit and reporting cycle rather than a one-off project. Two failure patterns recur during inspection: self-categorising lower than warranted and re-titling last year’s RBI or IT audit as a CSCRF audit. The control surfaces are different, and auditors have learned to check.

IRDAI, UIDAI, NPCI and sectoral regimes

• IRDAI requires insurers to undergo information security audits by CERT-In empanelled firms, with periodic reporting.
• UIDAI requires AUA and KUA entities handling Aadhaar authentication to undergo audits against UIDAI’s own information security requirements, with an emphasis on the handling and storage of Aadhaar numbers and biometric data.
• NPCI imposes its audit expectations on UPI participants and payment ecosystem members.
• RBI’s PA-PG Master Direction specifically names CERT-In empanelment for the payment aggregator system audit and the data-localisation System Audit Report.
• ABDM participants in the digital health ecosystem face security and privacy requirements around health records.

Digital Personal Data Protection Act, 2023

The DPDP Act obliges data fiduciaries to implement reasonable security safeguards to prevent personal data breaches. The Act does not prescribe a web application audit by name. What it does is create liability for the absence of safeguards, and an independent assessment report is the most straightforward way to demonstrate that safeguards existed and were tested. Significant Data Fiduciaries carry additional obligations, including periodic data protection impact assessments and independent audits.

The overlap dividend

If you sit under two or more of these, scope one engagement to satisfy all of them rather than running separate audits. A single well-structured WASA audit report for compliance purposes can carry SEBI CSCRF control identifiers, RBI closure-pack evidence, ISO 27001 A.8.29 evidence and SOC 2 CC4.1 evidence at once. Organisations that run separate audits for each regulator usually pay two or three times for overlapping work.

CERT-In Empanelment: What It Actually Means and How to Verify It

CERT-In empanelment is a government technical vetting of an auditing firm, not a marketing badge, and it is category-specific. For a large share of Indian regulated work, it is the gate. Getting this wrong wastes an entire audit cycle.

What empanelment is

CERT-In, the Indian Computer Emergency Response Team under the Ministry of Electronics and Information Technology, maintains a published list of organisations that have been technically assessed and authorised to perform information security audits. Empanelment is granted for a defined period, typically three years, is renewable, and follows a documented assessment covering methodology, tooling, personnel qualifications and report quality.

The list is published on the CERT-In website in the information security auditing organisations section.

The categories, and why they matter

A firm may hold some categories and not others. The structure, subject to refinement at each cycle:

A firm empanelled for compliance audits cannot deliver the category of work that a web application assessment requires, even if it is not empanelled for general IT security audits. Vendors do not always volunteer this distinction.

How to verify a vendor’s claim in five minutes

1. Go to the CERT-In site directly. Do not accept a PDF emailed by the vendor, and do not accept a logo on a website. Vendors have been known to display badges they are not entitled to.
2. Find the firm by its registered legal name, not its trading name. These frequently differ.
3. Check the category against your requirement. Confirm the specific category your engagement needs appears against that firm’s row.
4. Check the cycle dates. Note the effective-from date and the cycle-end date. Empanelment lapses, and a missed documentation deadline or a failed reassessment can delay renewal.
5. Ask who will actually test. Empanelment is firm-level. RBI’s para 156 requires you to assess the personnel as well. Ask for the names, certifications, and CVs of the testers assigned to your engagement, and ensure they are named in the contract.

Step five is the one nearly everybody skips, and it is increasingly the one an inspector asks about. Empanelment sits at the firm level. It says the organisation passed an assessment at some point in some category. It says nothing whatsoever about who will be sitting at the keyboard on your engagement, and a properly empanelled firm can still hand your application to somebody in their first year. Ask for names and CVs. Get them written into the contract.

When you do not need an empanelled auditor

Plenty of Indian organisations do not need one. If you are a SaaS company selling to overseas enterprises, pursuing SOC 2 or ISO 27001, and not regulated by RBI, SEBI, IRDAI or UIDAI, empanelment adds cost without adding acceptance. What your buyers want is a rigorous report from a competent firm, often with CREST accreditation or equivalent, and evidence of retesting.

Buy empanelment when a regulator or a tender requires it by name. Buy testing quality always.

The Complete WASA Audit Checklist for Web Applications

This is the working checklist, organised across ten domains. Use it two ways: to scope an engagement before you sign and to check a delivered report for coverage gaps. Any domain your vendor cannot evidence testing against is a domain nobody tested.

1: Reconnaissance and attack surface mapping

• All subdomains enumerated, including forgotten and staging hosts
• Certificate transparency logs reviewed for undisclosed hostnames
• Every application route and endpoint catalogued, documented or not
• API endpoints discovered from JavaScript bundles and mobile binaries
• Technology stack, framework versions and third-party components identified
• Publicly exposed administrative interfaces identified
• Cloud storage buckets referenced by the application checked for public access
• Historical versions and deprecated API paths tested for continued availability

2: Authentication

• Password policy strength, including length, complexity and breach-list checking
• Brute-force protection, account lockout behaviour and rate limiting on login
• Multi-factor authentication enforcement and whether it can be bypassed on any route
• OTP handling: length, expiry, reuse, rate limiting, and whether it is returned in the response body
• Password reset flow: token entropy, expiry, single use, and whether it discloses account existence
• Credential transmission over TLS only, with no fallback
• Default and test credentials removed from production
• Account enumeration through login, registration, reset and error message differences
• Session invalidation on password change and on logout across all devices

3: Authorisation and access control

• Horizontal privilege escalation tested between two accounts of the same role
• Vertical privilege escalation tested from every lower role to every higher role
• Insecure direct object references on every parameter carrying an identifier
• Function-level authorisation tested by changing the HTTP method and the path
• Multi-tenant isolation tested across tenants, where applicable
• Forced browsing to administrative and privileged URLs
• Mass assignment through additional parameters in create and update requests
• Authorisation enforced server-side on every request, never client-side
• API authorisation tested independently of the user interface

This domain produces the highest-severity findings in most Indian engagements and is the domain that automated tools cannot cover. If your report contains no authorisation testing across roles, treat it as incomplete regardless of its length.

4: Session management

• Session token entropy and unpredictability
• Secure, HttpOnly and SameSite attributes set on session cookies
• Session fixation prevented by regenerating identifiers on privilege change
• Absolute and idle timeout enforced server-side
• Concurrent session handling defined and enforced
• Token revocation working on logout, password change and role change
• JWT signature verified, algorithm pinned, aud and exp checked
• Refresh token rotation implemented, with reuse detection

5: Input validation and injection

• SQL injection across parameters, headers, cookies and JSON bodies
• NoSQL injection where applicable
• Command injection in any feature invoking system processes
• Server-side template injection
• LDAP and XPath injection where relevant
• XML external entity processing disabled
• Cross-site scripting: reflected, stored and DOM-based
• Deserialisation of untrusted input
• File upload validation: type, size, content inspection, storage location, execution prevention
• Server-side request forgery through any user-supplied URL

6: Business logic

• Price, quantity and discount manipulation in transactional flows
• Workflow step skipping and out-of-order execution
• Negative value and integer overflow handling in financial fields
• Race conditions in balance, refund, coupon and inventory operations
• Coupon and referral abuse through replay and concurrency
• Payment flow tampering, including callback and webhook verification
• Rate limiting on business-sensitive operations, not just on login
• Approval and maker-checker workflows tested for bypass

Business logic is where Indian fintech and e-commerce engagements find their most damaging issues, and it is entirely manual work.

7: Data protection

• TLS 1.2 minimum, 1.3 preferred, with no downgrade path and strong cipher suites
• Sensitive data absent from URLs, query strings, logs and browser storage
• Personal data encrypted at rest, with documented key management
• Data minimisation in API responses, allow-listed rather than model-dumped
• Masking of Aadhaar, PAN, card and bank details in interfaces and logs
• Data residency verified where localisation applies, including actual cloud bucket regions
• Secure deletion and retention policy implemented
• Backup encryption and access control

8: Configuration and infrastructure

• Security headers: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy
• CORS policy reviewed for wildcard origins and credential exposure
• Error handling: no stack traces, framework versions or internal paths in responses
• Directory listing disabled
• Debug endpoints, actuator paths and admin consoles unreachable in production
• Default installations, sample applications and documentation removed
• Dependency inventory current, with known vulnerable components identified
• Secrets absent from source code, repositories and client-side bundles
• Cloud storage permissions, IAM roles and least privilege verified

9: APIs

• Authentication enforced on every endpoint, including undocumented ones
• Object-level authorisation on every identifier parameter
• Rate limiting per authenticated identity rather than per IP
• Payload size limits and pagination caps
• GraphQL introspection disabled in production, with query depth and complexity limits
• Webhook signature verification and replay protection
• API versioning, with deprecated versions confirmed retired rather than merely undocumented

10: Logging, monitoring and response

• Security-relevant events logged with actor, action, object and outcome
• Logs retained for 180 days within Indian jurisdiction where CERT-In Directions apply
• Log integrity protected against tampering
• Sensitive data excluded from log content
• Alerting configured for authorisation failures, enumeration patterns and privilege changes
• Incident response runbook exists and has been exercised
• Six-hour CERT-In reporting path defined, with named owners and out-of-hours cover

Using the checklist commercially

Here is the cheapest trick in this whole article. Paste those ten domains into your RFP as an annexure and make every bidder fill in one column: automated, manual, or excluded.

Twenty minutes of your time. The responses sort the field on their own, because the firms running a scan cannot write “manual” against Domain 3 and Domain 6 without lying in writing, and most of them will not. You will also get a handful of bidders who ask thoughtful questions back about scoping, and those are usually the ones worth talking to. For an Indian buyer about to sign a web application VAPT services contract, nothing else you can do in under half an hour returns as much.

How a WASA Audit Is Actually Run

A credible engagement runs seven phases across three to six weeks for a typical mid-sized Indian application. Any vendor promising a full audit in two days is selling a scan.

Phase 1: Scoping and pre-assessment (3 to 5 days)

The vendor should be asking: how many applications, how many user roles, how many API endpoints, is testing authenticated, is it production or staging, which compliance framework must the report satisfy, and what are the blackout windows?

Deliverable: a scope document naming the assets, the roles, the exclusions and the framework mapping. Get exclusions in writing. Undocumented exclusions are how a report ends up not covering the thing that later breaks.

Phase 2: Legal and access preparation (2 to 5 days)

This phase requires a non-disclosure agreement, rules of engagement, an authorisation letter, test account provisioning across every role, source IP allow-listing, and a named escalation contact on both sides.

Provisioning at least two accounts per role is essential. Horizontal privilege escalation cannot be tested with only one account per role, and this scenario is the most common cause of an authorisation testing gap.

Phase 3: Automated assessment (2 to 3 days)

Baseline scanning to clear the mechanical classes quickly: known CVEs, missing headers, outdated components, TLS configuration, and obvious misconfigurations. This work is fast and should not dominate the invoice.

Phase 4: Manual testing (7 to 15 days)

This is the phase you are actually paying for. Authorisation across roles and tenants, business logic abuse, chained paths, session handling, and the API tested on its own rather than through the interface that fronts it.

An example of what that looks like in practice. On a lending platform last year the scanner came back clean on the loan application module, which is the sort of result that should make you suspicious rather than pleased. So I opened two borrower accounts and started walking the application flow one step at a time, watching what the browser sent. Step four submitted a applicationStage parameter. I changed it from documents_pending to approved and then resubmitted. The application was moved to approved status. No credit check, no document upload, no maker-checker.

It took maybe 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, correctly authenticated and returned a perfectly valid 200. The application did exactly what it was told. Nobody had written down what it should refuse to be told.

Ask how many of the total engagement days are in this phase. For a credible mid-market Indian engagement, most of them should be manual work. If the proposal does not break the days down, that is your answer.

Phase 5: Validation and risk rating (2 to 3 days)

Every finding was reproduced and confirmed, false positives were removed, severity was assigned using the application’s context rather than raw CVSS, and each finding was mapped to the relevant framework control.

Phase 6: Reporting (3 to 5 days)

Draft the report, hold a walkthrough call with the engineering team, and revise it. The walkthrough matters more than the document. A finding that a developer does not understand will be closed incorrectly.

Phase 7: Remediation support and retest (variable, then 3 to 5 days)

Your team fixes. The vendor retests. A revised report and letter of attestation are issued reflecting the closed state.

Confirm before signing that retesting is included and how many rounds. Vendors who charge separately for retesting create an incentive you do not want, and a report without a retest record fails an increasing number of Indian regulatory reviews.

What a WASA Audit Report Should Contain: Sample Structure

A report has three readers who want entirely different things, and most reports are written for one of them. The regulator wants traceability. The engineer wants reproduction steps. The CISO wants to know what to worry about first. Write for one, and the other two need translation, which means your team does the vendor’s job after the fact.

The structure below covers all three without getting longer.

The eleven sections

Sections 4, 7, 9 and 10 are the ones missing from most reports, and they are the ones that determine whether the document is usable outside your engineering team.

Sample finding, written in full

This is the level of detail every finding should carry. Anything less and your developer is guessing.

Finding ID:

WASA-2026-004 Title: Broken Object Level Authorisation on transaction detail endpoint Severity: Critical (CVSS 3.1: 8.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) Status: Closed, retested and verified on 22 August 2026

Affected asset:

GET /api/v2/transactions/{transactionId} (production)

Description:

The endpoint authenticates the caller but does not verify that the requested transaction belongs to them. Any authenticated user can retrieve the full transaction record of any other user by substituting the transaction identifier, which is sequential and therefore trivially enumerable.

Steps to reproduce:

1. Authenticate as User A (test account wasa_user_a) and capture the bearer token.
2. Retrieve your own transaction list, note an identifier such as 88412.
3. Issue GET /api/v2/transactions/88413 with User A’s token.
4. Observe HTTP 200 returning a transaction belonging to a different customer, including counterparty name, account fragment and amount.

Evidence:

Request and response captures in Appendix C, items 4.1 to 4.3, with personal data redacted.

Business impact:

Enumeration of the identifier range would expose the full transaction history of the customer base, including counterparty identities and amounts. This is personal data under the DPDP Act, 2023 and would constitute a reportable personal data breach.

Framework mapping:

OWASP API Security Top 10 API1:2023 · OWASP Top 10 A01:2021 · CWE-639 · ISO/IEC 27001:2022 A.8.3 · SEBI CSCRF access control domain · PCI DSS 4.0.1 Requirement 7

Remediation:

Enforce ownership server-side within the data query, deriving the owner identifier from the verified token claim rather than from any request parameter. Return HTTP 404 rather than 403 so the endpoint does not confirm the existence of records the caller may not access. Replace sequential identifiers with UUIDs as a defence-in-depth measure.

Retest result:

Verified closed. The endpoint now returns 404 for identifiers not owned by the authenticated principal. Identifier migration to UUID confirmed in production on 21 August 2026.

Notice what the entry does that a scanner output cannot. It names the affected roles, states the regulatory consequence under Indian law, maps to five control frameworks, and closes the loop with a dated retest.

The attack narrative section

Individually low-severity findings rarely persuade anyone to act. Chained, they do. A short narrative showing how a verbose error message, a predictable identifier and a missing rate limit combine into full customer data exposure will move a remediation budget that a list of thirty medium findings will not.

This is the section that turns a technical document into a decision-making one, and almost no Indian vendor includes it.

Want a Sample Security Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report →

Web Application Security Audit Cost in India (2026)

A web application security audit in India costs between ₹25,000 and ₹8,50,000 in 2026, and the sevenfold spread inside that range is the whole story. Two quotes carrying identical wording can describe entirely different products.

The three bands

Indicative pricing by asset type

Treat these as market context rather than quotes. Every scope is different, and any vendor who gives you a price before asking about roles and endpoints is just guessing.

What actually drives the price?

The manual to automated ratio. The single largest factor. Tool licences cost the vendor almost nothing per engagement. Senior tester days are significantly more expensive.

Tester seniority. Indian security consultants range roughly from $25 to $60 per hour against $150 to $300 in the United States, which is why Indian buyers get more manual depth per rupee than most markets. Within India the spread between a first-year tester and a senior consultant is still substantial, and it shows up in what gets found.

Authenticated versus unauthenticated testing. Most real risk sits behind a login. Unauthenticated-only testing is cheaper, but it misses the entire authorisation class.

Number of roles. Every additional role multiplies the authorisation test matrix. Four roles means twelve directional privilege tests before you consider tenancy.

Retest rounds included. One included round is standard. Zero should concern you.

Compliance mapping depth. Mapping findings to SEBI CSCRF control identifiers or RBI closure-pack format is real work and legitimately costs more than a generic OWASP mapping.

Empanelment. Empanelled firms price above non-empanelled ones for equivalent work. Where a regulator names it, you have no choice. Where nobody names it, you are paying for a credential you will not use.

Cost red flags

• A price quoted before anyone asked how many user roles exist
• No mention of retesting in the proposal
• A two-day or three-day timeline for a full application
• A refusal to share an anonymised sample report
• Per-vulnerability pricing, which creates an incentive to inflate finding counts
• A quote that does not distinguish manual from automated days

What actually gets it approved internally?

The breach-cost comparison is available to you: A ₹22 crore average against a ₹2 lakh audit works out to roughly two hundredths of one percent of the downside. Fine as a slide.

In my experience, it is not what moves the budget. Finance teams have heard the breach number and mentally discounted it, because it is a probability and they deal in certainties. What moves the budget is the deal sitting in security review. One stalled enterprise contract is a real number with a name attached to it, and the audit that unblocks it costs less than the sales team’s travel for the quarter. Lead with that.

WASA Audit Tools

Tools do perhaps forty percent of a WASA audit. Naming them matters because “we use industry-standard tools” tells a buyer nothing. Ask any prospective vendor for this list filled in.

The honest limitation

Every tool above finds mechanical defects well and logic defects poorly. Not one of them will tell you that transaction 88413 belonged to a different customer, because the response was a valid HTTP 200 to a well-formed authenticated request. Nothing about it looks wrong to software.

That is why the tool list is a qualifying question rather than a deciding one. A vendor who cannot name their toolchain is a concern. A vendor whose entire methodology is their toolchain is a bigger one.

Findings We See Most Often in Indian Web Applications

Five patterns recur across engagements, and four of them are invisible to scanners. These are worth checking in your application before an auditor does.

1. Authorisation checked at the interface, not the API

The application hides the admin button from ordinary users, and the underlying endpoint has no server-side role check. Anyone who reads the JavaScript bundle finds the route.

Four lines, and three of them are fine:

// Vulnerable: authenticated, but ownership never verified

authenticate runs. It works perfectly. It confirms there is a real, logged-in human behind the request, and then hands off to a query that fetches whatever identifier was in the URL. Nobody ever asked whose transaction it was.

// Fixed: ownership enforced in the query, from the verified token

The ownerId line is the actual repair, and where it comes from matters more than that it exists. req.user.sub is a claim off the token your own server verified. Anything from req.params, req.body or req.query is a string the caller typed, and I have seen teams add an ownership check that reads the owner out of the request body, which is a check that does nothing at all.

The 404 is the smaller detail people skip. Returning 403 is honest and it tells an attacker they have found a real record they are not allowed to see, which is precisely the confirmation they were enumerating for.

2. Sequential identifiers on sensitive resources

Auto-incrementing integers on invoices, transactions, tickets, KYC documents and user records. Individually, a low-severity finding. Combined with a missing authorisation check, it turns one exposed record into the entire database.

3. Aadhaar, PAN and card data in logs and responses

A recurring Indian-specific pattern. The interface masks the number correctly, the API returns it in full, and the application log records it unmasked. Under the DPDP Act, this is exactly the kind of avoidable exposure that converts a technical finding into a regulatory one. Mask at the serialisation layer, not at the interface layer.

4. Verbose errors disclosing stack and framework detail

An unhandled exception returning a stack trace tells an attacker your framework, version, file paths and sometimes database schema. It is the reconnaissance step that makes everything after it faster.

5. Session tokens surviving a password change

The user changes their password after suspecting compromise, and the attacker’s existing session continues working. This one is easy to test and easy to miss, and it appears in a surprising share of Indian fintech applications we assess.

Preparing for Your First WASA Audit: A 30-Day Readiness Plan

Preparation determines how much of your budget goes into finding problems rather than into the vendor working out how your application is put together. Thirty days of internal work before testing starts routinely improves what an engagement surfaces.

Days 1 to 10: Know what you have

Build the asset list. Every application, subdomain, API endpoint, admin interface and environment is reachable from the internet, with an owner named against each. Include the ones nobody has touched in two years, because those are the ones that will be found.

Write down every user role and what each is supposed to be able to do. This document becomes the authorisation test matrix, and if it does not exist, the tester will reconstruct it by guessing, badly and slowly.

Identify which regulatory regimes apply to you. Getting this wrong at scoping is expensive to correct at reporting.

Days 11 to 20: Clear the obvious

Run a free scanner against your application first. Fix the missing headers, the outdated libraries, the directory listing, and the debug endpoint left enabled. There is no value in paying senior tester rates for findings that a free tool would have surfaced in an afternoon.

Remove test and default credentials. Check whether any secrets are sitting in your repository history. Confirm your error pages do not return stack traces.

Days 21 to 30: Prepare the engagement

Provision test accounts, at least two per role, and confirm each one works before the engagement starts. Losing three days of a two-week test to broken credentials is common and entirely avoidable.

Get the paperwork done: non-disclosure agreement, rules of engagement, authorisation letter, IP allow-listing, and named escalation contacts on both sides with out-of-hours cover.

Agree on the blackout windows. Align on what happens if testing degrades performance. Agree the out-of-band path for a critical finding.

Then brief your engineering team. A team that knows an audit is coming and understands why tends to fix things faster afterwards than one that receives a surprise report from procurement.

How to Choose a Web Application VAPT Services Partner

Judge vendors on their sample report and their retest terms before you judge them on price. Everything else is marketing.

Ten questions worth asking

1. Can I see an anonymised sample report? If they won’t show one, expect what you can’t see. This single question filters more vendors than the other nine combined.
2. How many tester-days are there, and how many of those are manual? Get the split in writing.
3. Who specifically will test my application? Names, certifications, and years of experience. RBI’s 2026 Directions require you to assess these issues anyway.
4. How many accounts per role will you need? A vendor who does not ask for at least two per role is not planning to test horizontal privilege escalation.
5. Is testing authenticated and against production or staging? Both answers have consequences you should understand before signing.
6. How many retest rounds are included? Is the attestation reissued after the retest?
7. Which compliance framework will findings be mapped to? Name yours and confirm they can map to it at the control-identifier level.
8. Are you CERT-In empanelled? In which category, and until when? Verify independently rather than accepting the answer.
9. What is excluded from scope? Get it in writing. Exclusions discovered later become your problem.
10. What happens if you find a critical issue mid-engagement? There should be a defined out-of-band escalation path, not a wait for the final report.

Warning signs

A quote arriving within an hour of first contact. A methodology section that consists solely of tool names. Per-vulnerability pricing. No named testers. Reluctance to run a walkthrough call with your engineers. Claims of empanelment that do not survive a check against the CERT-In list.

How Can Qualysec Help You?

Qualysec is a CREST-accredited VAPT leader that has completed 2,500+ assessments and found 45,000+ vulnerabilities to deliver tailored VAPT reports.

Book a VAPT Consultation→

Common Mistakes Indian Organisations Make

Treating the audit as a certificate rather than a process:

The report is evidence of a point in time. Six months and forty releases later, it describes an application that no longer exists.

Scoping to staging only:

Regulators increasingly ask whether production was tested. A staging clone with sanitised data and a different configuration is not the same system.

Providing one test account per role:

Sounds like a scheduling detail. It is not. With one account per role, there is no second user to steal data from, so the entire horizontal privilege escalation class silently drops out of the engagement, and nobody notices until the report arrives. This is the most common reason a critical finding gets missed, and it is a five-minute fix on your side.

Re-titling last year’s audit:

An RBI IT audit relabelled as a CSCRF audit is a documented inspection finding. The control surfaces differ.

Excluding legacy modules:

The admin panel from 2019, the internal API nobody documented, and the reporting module migrated from the monolith. These hold real data, and attackers prefer them precisely because they are out of sight.

Buying on price alone:

A CTO once sent me two quotes for the same application, ninety thousand and six lakh eighty. He wanted to know how anyone justified the gap. The cheaper one was a Nessus scan with a cover page. The other option involved two senior testers working for nine days. Both were legally entitled to call themselves VAPT. Only one of them was going to find the IDOR in his customer portal.

No retest:

A finding marked resolved without independent verification is a finding you have chosen to believe in. It also fails a growing number of Indian regulatory reviews.

Ignoring the six-hour clock:

Organisations under the CERT-In Directions frequently have no named owner for incident reporting and no out-of-hours path. Six hours passes quickly at 2am on a Sunday.

Testing annually when releases are weekly:

Cadence should follow the change rate, not the calendar. A yearly audit on a codebase that ships forty times a year describes an application that stopped existing in February.

Never reading the report:

This is more common than it sounds. The report arrives, procurement files it against the compliance requirement, and nobody in engineering opens it. The findings sit unremediated until the next audit rediscovers them, at which point you have paid twice to learn the same thing. Insist on a walkthrough call between the testers and your engineers, and treat the remediation roadmap as a sprint input rather than an attachment.

Assume the vendor will find your scope for you:

Testers work from what you give them. An undocumented admin subdomain that never made it onto the asset list is an asset nobody tested, and its absence from the report is not the vendor’s error. The 30-day readiness plan above exists to prevent exactly such situations.

How Qualysec Delivers Web Application Security Audits

Qualysec is a specialized penetration testing company that offers assessments with compliance-ready reporting and complimentary post-remediation retesting. We have delivered over 2,500 assessments for 350+ clients across 38+ countries, with reports structured to satisfy 52+ compliance frameworks.

Automated scanning runs first to clear the mechanical classes. Certified consultants then manually test authorisation logic across role and tenant boundaries, as that is where the findings scanners cannot actually reach.

A finding automation could not have produced

On a recent engagement with a regulated cryptocurrency exchange preparing for VARA compliance, the trading platform passed automated scanning with no critical authorisation findings. We authenticated as two separate funded accounts and began substituting object identifiers by hand.

The wallet endpoint accepted a transaction identifier as an API parameter and never verified that the transaction belonged to the authenticated caller. Incrementing it returned another user’s wallet balance, transaction history and metadata. That was one of 18 findings in that engagement, alongside source code disclosure through unhandled stack traces, an open redirect usable for phishing from the exchange’s own domain, missing anti-CSRF protection on account settings, and session tokens that survived a password change.

We worked directly with the client’s engineers on error handling and redirect allow-listing, structured the report to match the regulator’s submission requirements, and retested every fix.

What you receive

Findings are severity-rated with reproduction steps and developer-ready remediation guidance, in the format shown in the sample above. A letter of attestation for procurement, tenders and audit. Live progress tracking through the Qualysec Vulnerability Dashboard, so you are not waiting on a report to know what has been found. Retesting included as standard.

We hold ISO/IEC 27001:2022, ISO 9001:2015 and ISO 13485:2016 certifications, are CREST-accredited for penetration testing, and rate 4.9 out of 5 across 31 verified Clutch reviews. A financial services entity in the Philippines describes risk-based prioritisation and follow-up validation testing against ISO 27001, NIST and CIS benchmarks in an ongoing engagement, and a London banking platform cleared eight issues across its customer journey, back-office journey and Azure environment as a prerequisite for its banking licence.

If you need a web application audit that will hold up in front of a regulator, a tender committee or an enterprise buyer, talk to our team or review a sample report.

Prepare for Your Cybersecurity Audit with Qualysec

Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.

Talk to an Expert→

Conclusion

A WASA audit is worth commissioning when you need to prove something to somebody who is not obliged to believe you. That is the whole category in one sentence.

Four things to carry into your next engagement.

The word on the invoice tells you nothing. Tester-days, manual split, authenticated coverage and role count tell you everything. Ask for all four before you compare prices.

Authorisation testing is the key differentiator. It is where the severe findings live; it is entirely manual, and it is the first thing dropped from a cheap quote. Two accounts per role are tested in every direction.

The report is the product. Control mapping, attack narrative, dated retest and attestation are what make a technical exercise usable in front of a regulator or a buyer. Ask to see a sample before you sign, not after.

Verify credentials yourself. CERT-In empanelment is category-specific and time-bound, and it takes five minutes to check against the official list. Empanelment is firm-level, so ask who will actually test as well.

One last thing, and it is the difference between the clients who get value out of this process and the ones who do not. Treat the audit as a recurring process with a trigger list attached to it, not a certificate you renew every March because you renewed it last March. The organisations doing the former tend to see their critical count fall year on year. The ones doing the latter usually find out what they missed from somebody who was not on their payroll.

Frequently Asked Questions

What does WASA stand for?

Web Application Security Assessment, sometimes rendered as Web Application Security Audit. The two are used interchangeably. It is a descriptive term rather than a formal standard, which is worth knowing because nobody issues a WASA certification, and any vendor offering one is describing their own document.

Is a WASA audit the same as VAPT?

They overlap heavily, and Indian RFPs use both words loosely. VAPT describes the technical activity of vulnerability assessment plus penetration testing. A WASA audit includes that activity and adds an evidentiary layer around it, which consists of control mapping, structured reporting, attestation, and a retest record. In practice, when an Indian regulator or enterprise buyer asks for VAPT, what they will accept is what this article describes as a WASA audit.

Do I need a CERT-In empanelled auditor?

Only if a regulator or tender names it. Payment aggregator audits, data-localisation audit reports, SEBI market infrastructure institution audits, and most government tenders require it. IRDAI requires it for insurers. If you are an unregulated SaaS company pursuing SOC 2 or ISO 27001 and selling to overseas enterprises, empanelment adds cost without adding acceptance. Verify any claim directly against the CERT-In list rather than accepting a badge.

How much does a security audit for a web application cost in India?

Between ₹25,000 and ₹8,50,000 in 2026, depending on the band. Budget work at ₹25,000 to ₹75,000 is generally automated scan output. Professional work at ₹1,00,000 to ₹3,50,000 is methodology-driven manual testing accepted by SOC 2 and ISO 27001 auditors. Regulated work at ₹3,50,000 and above covers multi-week engagements with full compliance mapping. The largest cost driver is the ratio of manual to automated testing, not the tool licences.

How long does a WASA audit take?

Three to six weeks end-to-end for a typical mid-sized application, including scoping, testing, reporting and retesting. Manual testing alone should account for seven to fifteen days of that. Anything advertised as complete in two or three days is a scan.

How often should we run one?

At least annually, and after any significant change to authentication, authorisation, the data model or the exposed surface. Sector rules override these: six-monthly vulnerability assessments for banks under the RBI 2026 Directions, half-yearly VAPT for qualified stockbrokers and market infrastructure institutions under SEBI CSCRF, plus quarterly scanning of internet-facing systems. Teams shipping weekly should consider quarterly testing of the authorisation layer specifically, as regression testing does not cover it.

Can a WASA audit report be used for more than one compliance framework?

Yes, and it is the main way to control cost if you sit under multiple regimes. One well-structured report can carry SEBI CSCRF control identifiers, RBI closure-pack evidence, ISO 27001 A.8.29 evidence and SOC 2 CC4.1 evidence simultaneously. Specify the frameworks during scoping rather than afterwards, because retrofitting a mapping onto a delivered report is awkward and sometimes impossible.

What is the difference between testing production and staging?

Production is the system that holds real data and real configuration. Staging is an approximation, and the differences are usually exactly where the risk sits: different environment variables, different third-party integrations, and different access controls. The RBI 2026 Directions expect production environment testing. Where production testing carries genuine operational risk, agree a controlled window and rules of engagement rather than silently substituting staging.

What should we do if the audit finds a critical issue?

Your engagement should define an out-of-band escalation path before testing starts, so a critical finding reaches you within hours rather than in the final report. On receipt, contain first, then remediate, then retest. If the issue involves personal data exposure, assess your reporting obligations immediately: the CERT-In six-hour clock and DPDP Act breach notification requirements may both apply, and both start from when you become aware.

Do we need a fresh audit every time we release?

No, and nobody expects that. What is expected is a defined trigger list: significant changes to authentication, authorisation, payment flows, the data model or the externally exposed surface. Routine feature releases inside an unchanged security architecture do not require a new full audit. Continuous scanning between audits, with an annual or half-yearly full assessment, is the pattern most Indian regulators now expect.