Business
Find out what an attacker would do first, before one does.
Automated scanners find the obvious. The findings that matter, such as a broken authorisation check between two customers, an OTP flow that can be brute-forced, or an admin panel reachable from a forgotten subdomain, come from a tester reading your application the way an attacker would. We test manually, write for the people who fix things, and re-test when they say it is fixed.
- Web, mobile (Android and iOS), API, internal and external network, and cloud configuration testing
- Every finding reproduced, rated by real-world impact and paired with a specific fix
- Report formats suited to CERT-In audit requirements, RBI and SEBI inspections, and customer due diligence
- Re-test of fixed findings and a closure certificate for the scope tested
Fixed price per scope, quoted in writing after a short scoping call. One re-test of fixed findings is included.
Typical engagement
- Scoping call
- Testing
- Report and walkthrough
- Re-test
Who this is for
- Product and SaaS companies facing customer security questionnaires or an enterprise deal
- NBFCs, fintechs and brokers whose regulator expects periodic VAPT
- Hospitals, schools and institutions running ERPs, portals and payment gateways
- Companies about to launch a new app or expose a new API
- Teams that had a scanner-only "VAPT" last year and suspect it missed things
- Organisations needing a test after an incident to confirm the entry point is closed
What is included
Scoping and rules of engagement
What is in and out, test accounts and data, timing, who to call if something breaks, and whether testing is black-box, grey-box or with source access. Agreed in writing before anything starts.
Manual testing
Authentication and session handling, authorisation between users and roles, business-logic abuse, injection and input handling, file handling, payment and OTP flows, and the cloud or network configuration that surrounds the application.
Mobile and API specifics
Local storage, certificate pinning, root and jailbreak behaviour, hard-coded secrets, and the API behind the app tested directly, including rate limits and object-level authorisation.
Network and cloud
External exposure, internal segmentation, remote-access services, Active Directory weaknesses where relevant, and IAM, storage, logging and network settings on AWS, Azure or GCP.
Report
An executive summary, a findings table with severity and effort, and for each finding the steps to reproduce, the evidence, the impact and a specific fix. Written so the engineer does not need to call us.
Re-test and closure
One re-test of all findings within an agreed window, an updated report and a closure letter stating what was tested, when and what remains open.
How we work
Scoping call
Thirty to sixty minutes on what you run and what you are worried about. We send a scope, a timeline and a fixed price within two working days.
Testing
Usually one to three weeks depending on scope. Critical findings are reported the day they are confirmed, not at the end.
Report and walkthrough
Report delivered, then a call with your engineers to go through the findings and the fixes.
Re-test
When your team says it is fixed, we verify and issue the closure report.
What you walk away with
- A ranked list of real weaknesses with evidence, not a scanner dump
- Fixes your team can implement without a second consultancy
- A report that satisfies auditors, regulators and enterprise customers asking for a VAPT
- A re-tested, documented baseline to build the next year on
What we do not do
We would rather lose an enquiry than mislead you.
- We do not test systems you do not own or have written authority to test
- A VAPT is a point-in-time test; it is not a guarantee against future vulnerabilities or a substitute for secure development
- We do not fix the code ourselves, though we will pair with your developers on tricky fixes
Frequently asked questions
How is this different from running a vulnerability scanner?
Scanners find known patterns in known software. They do not understand that user A can see user B's invoices by changing a number in the URL, or that your refund flow can be called twice. Those are the findings that cause breaches. We run scanners as one input and spend most of the time on manual testing of the logic and the flows.
Will testing break our production system?
We agree the rules first. Most testing is done against staging; where production is necessary we avoid destructive tests, agree timing and keep a contact available. In years of testing, the main risks are load on a fragile server and test data left in a database, and we plan for both.
Do we get a certificate?
You get a closure letter stating the scope, dates, methodology and the status of each finding after re-test, signed by the lead tester. Customers, auditors and insurers accept this as evidence that testing was done and what it covered. We do not issue a "secure" or "hack-proof" certificate, because no honest tester can, and the people who ask for one usually know that.
Our regulator asks for a VAPT from a CERT-In empanelled auditor. Can you provide that?
Ask us directly and we will tell you our current status and, if required, work alongside an empanelled auditor so you meet the requirement without paying for two full tests. We would rather say so plainly than let you find out at audit time.
How often should we test?
Annually at minimum, after any major release or architecture change, and after any incident that may have involved the tested systems. Regulated entities often have a stated frequency in their framework. Between full tests, a smaller targeted test of what changed is usually better value than repeating everything, and we scope it that way when asked.
Tell us what you run
Applications, APIs, cloud accounts, number of hosts, and any deadline from a customer or regulator. We reply with a scope and a fixed price within two working days.