A customer asked for a pen test report
Bigger clients send a security questionnaire before they sign. Somewhere around question twelve: "Have you had an independent penetration test in the past 12 months?" A "no" can stall the deal for weeks.
We break into your web apps, APIs, mobile apps and cloud accounts (with your written permission, of course) so that a real attacker can't. When we find a hole, we show your developers exactly how we got in and what to change. No 200-page scanner dump.
Almost nobody books a pen test just for fun. It's usually one of these.
Bigger clients send a security questionnaire before they sign. Somewhere around question twelve: "Have you had an independent penetration test in the past 12 months?" A "no" can stall the deal for weeks.
ISO 27001, SOC 2, PCI DSS, HIPAA. They all expect regular security testing, and the auditor will want two things: the report, and proof you fixed what it found.
Maybe you're launching payments or opening up a public API. Or something odd turned up in the logs last month and people are nervous. Either way, an outside pair of eyes before go-live is cheap insurance.
You'll often see them bundled as VAPT (vulnerability assessment and penetration testing). They're related, but they aren't the same thing, and mixing them up is how companies end up paying for a scan when they needed a real test.
Mostly automated. Scanners sweep your systems and flag known problems: old software versions, missing patches, settings left on default. It's fast and wide, and worth running often, but it can't tell you what an attacker could actually do with those findings.
Answers
What weaknesses might we have?
Mostly manual, and much slower. A tester takes those weak spots and actually tries them. Small issues get chained together. Sometimes a "low" finding turns out to be the first step to the customer database. That's the part a scanner never shows you.
Answers
What could someone really do with them?
Book one, or bundle a few. Whatever you pick, you get a written report at the end, and we come back to retest the issues you fix at no extra charge.
Logins, search boxes, file uploads, checkout, the admin panel nobody remembers is public. As a web application penetration testing company, these are the first places we poke, because they're the first places attackers do.
A scanner won't notice that your coupon code can be applied twice, or that a refund can exceed the order total. People notice that. Our testers hold [OSCP, CEH or your team's certifications] and do most of their work by hand.
Full tests happen once or twice a year, but new vulnerabilities get published every week. Scheduled scans fill that gap. We sort through what they flag, throw out the false alarms and only bother you with what's real.
APIs tend to trust whatever they're sent. Our API penetration testing services check what happens when someone sends malformed data, hammers an endpoint thousands of times a minute, or asks for fields the app never displays.
How do people sign in, reset a password, stay logged in? Each step is a chance to get it wrong. Weak session management in particular can hand an account to someone who never knew the password.
Can an ordinary user open the admin page just by typing the URL? Can customer A see customer B's orders? Broken access control is one of the most common serious problems we find, and it's usually simple to fix once you know it's there.
Each test is mapped to the OWASP Top 10. If you need deeper assurance, for a bank or a large enterprise buyer, say, we test against the relevant level of the OWASP ASVS as well.
This is white-box testing, where we get your source code. Static analysis tools do the first pass. Then a person reads the sensitive bits line by line: login, payments, permission checks.
A typical app is mostly other people's code: frameworks, packages, plugins. We check all of it against known vulnerability databases and tell you which updates can wait and which can't.
Android and iOS apps get checked for data saved in plain text on the phone, API keys baked into the app, weak encryption, and traffic that could be read on public Wi-Fi.
On AWS, Azure or Google Cloud, the usual problem isn't a clever exploit. It's a storage bucket left public, or an admin role given to the wrong account. We review the configuration, then test what's reachable from the internet.
Doing this for an audit? We'll map each finding to the controls in your standard, which saves your auditor (and you) a lot of back-and-forth.
Ethical hacking is still hacking, so the rules get agreed before anyone touches a keyboard. Here's how an engagement runs.
What's in scope, what isn't, which dates, which test accounts, and who we call at 2 am if we find something critical. All of it in writing.
We map out the application and run scans to get a long list of places worth a closer look.
This is most of the work. Testers go through the list by hand, with Burp Suite, Metasploit and similar tools when they help, and confirm every issue before it goes in the report.
You get the report, then we get on a call with your developers and walk through it. Questions are welcome; that's the whole point of the call.
Your team fixes things. We test those issues again and reissue the report showing what's closed.
Plenty of pen test reports end up unread in a shared drive. We try hard to avoid that. The front is written for leadership, the back for the people who'll do the fixing.
VAPT report
Front written for leadership, back for the people who'll do the fixing
Executive summary
One page, no jargon. What we tested, what we found, how worried to be.
Risk rating for each finding
Critical, high, medium or low. We weigh how easy the issue is to exploit against how much harm it could do.
Proof of concept
The exact steps, requests and screenshots, so a developer can reproduce it in a few minutes.
How to fix it
Advice written for your stack. If you run Laravel, you get Laravel advice, not text pasted from a scanner.
Remediation retest results
After the retest we reissue the report with closed issues marked. This is normally the copy auditors and customers ask for.
An hour or two of prep on your side saves days on ours. Ideally, before we start, you'll have:
Once a year is the usual minimum, and many standards ask for exactly that. But a big change is a good reason to test again, such as:
In between, continuous scanning keeps an eye out for anything new.
Healthcare
Patient portals, telehealth apps, lab systems. Penetration testing for healthcare means paying close attention to where health records live and who can reach them. For HIPAA, we map findings to the Security Rule safeguards.
Software
Our secure code review services for software companies slot into your release cycle. Better to catch an injection flaw in a pull request than in a breach notice.
Fintech
Wallets, payment flows, customer accounts: places where a bug turns straight into lost money. We also help pull together evidence for PCI DSS.
SaaS
Enterprise buyers keep asking for your latest pen test? A yearly test with a clean retest report answers that before procurement even asks.
Honestly, it depends on size. A small app with two user roles is a few days' work; a platform with dozens of APIs is a lot more. After a short scoping call we send a fixed price, and that's the price you pay.
₹35,000 fixed
One web app or one API, tested properly, with the report and a free retest.
₹75,000 fixed
Web, API, mobile and cloud in one go, mapped to your compliance standard. Ends with a retest and a report you can hand to an auditor.
₹18,000 / month
Scanning that never stops, code review on new releases, and the yearly pen test included.
Tell us what you want tested, and why. On a free 30-minute call, one of our security testers will suggest the right kind of test and give you a fixed price.
One of our security leads will reply within a working day.
to help our experts understand your business objectives and create your customized plan.