Questions buyers actually ask.

A full technical report with every finding, the evidence that proves it and the fix; a one-page signed letter of attestation you can forward; a security-questionnaire answer pack; findings mapped to ISO/IEC 27001:2022, SOC 2 and DPDP 2023; and SARIF for your GitHub Security tab.

Attached to all of it is the coverage table, stating what each module actually reached. A free retest is included.

It is the one page you forward to a customer, an investor or a procurement team who needs to know you were tested but should not receive your vulnerability list. Scope, method, testing window, findings by severity, retest status — and the coverage disclosure in the same size type, so nobody can read it as a clean bill of health it does not claim to be.

Yes, without restriction — internally and with auditors, insurers, investors and regulators. That is written into our terms. The report is yours.

Yes, one retest per engagement once you have patched, at no additional cost. It exists so the attestation describes the fixed state rather than the day we started, which is the version anyone outside your company actually cares about.

Yes, and that is where the severe findings live. Someone on your side logs in once in a real browser and exports that session; we work from the capture, which carries the real request shapes a crawler cannot infer — actual query strings, body field names, real object IDs.

We never defeat CAPTCHA, OTP, MFA or SSO. Those are controls doing their job, and breaking one on your production system is not in any engagement letter.

Not for the web, API and mobile assessments — those test your running application from the outside, which is the position an attacker is actually in. Source code review is a separate service you can add.

One consequence worth knowing: because we did not read your source, remediation is given as an illustrative pattern in your framework, never as a diff of your actual code.

We use automation heavily for reconnaissance, payload generation and triage, which is what compresses weeks of manual work into hours. But the model proposes and a deterministic oracle decides — nothing the AI says becomes a finding on its own.

Every claim class has a minimum standard of evidence it has to discharge before it can be reported as a finding. Anything that cannot meet its own standard is demoted to a lead rather than dropped, and a human reviews the report before you see it.

Android APK and AAB, and iOS IPA. iOS is static analysis only — runtime and traffic interception need a physical device, which is not in the package, and the report says so rather than implying the runtime surface was cleared. See the mobile page.

Read-only by default. Anything that writes to your system is an authorisation decision made in writing before the scan, never a judgement call made during it. We do not perform load or denial-of-service testing at all.

Security testing still carries inherent risk. Confirm your backups are current before active testing begins, and give us a contact who can be reached during the window.

No, and you should be wary of anyone who says otherwise. No assessment can find every vulnerability, and an absence of findings is not proof of security.

What we commit to is narrower and checkable: every finding is verified with reproducible evidence, anything we could not prove is reported as an unproven lead rather than quietly dropped, and the coverage table tells you what each module reached.

That a module ran and examined nothing — so we are telling you there is a gap there, and why. It is kept deliberately separate from skipped, which means your engagement chose not to test that area.

Both appear under their own names. A report that merges them lets our gap hide inside your decision. An advisor once suggested we relabel untested as “out of scope” and we refused, for exactly that reason.

A finding carries evidence that discharges its claim — a request and response you can replay. A lead is something we saw that we could not prove to that standard, reported anyway with a note on what would settle it.

Leads exist because the alternative is dropping them, and a silently dropped real issue is the one failure nobody can detect afterwards.

Because a benchmark that only reports wins tells you nothing about the losses. Ours reads 4 of 8 planted vulnerabilities proven, 1 detected but not provable and shipped as a lead, 3 missed entirely, 0 false positives against 21 paths verified absent.

Two of those misses we added ourselves, after the fact. Re-examining the same pinned container turned up two real directory listings — one over cryptographic keys, one over application logs — that our scanner never requests. Writing them into the ground truth moved our own published score down. We could have left them out, or pasted the two paths into our wordlist until the page went green; the first hides a known vulnerability and the second measures nothing but how well we tuned for one container.

The third miss is a POST-body SQL injection that discovery never requested, and we said its fix was a browser session capture. It was. Given one, the same scan proves that login bypass: 5 of 8 proven, 1 lead, 2 missed, 0 false positives. Crawling alone reads 4 of 8, so the number depends on what you can give us and we would rather say which than quote the better one and let you assume it applies.

No. The verification oracle reduces them; it does not eliminate them. Anyone claiming zero is describing a marketing position rather than a measurement.

No. Certification is issued by an accredited certification body after a formal audit of your information security management system, most of which is organisational rather than technical. A penetration test is one input to that process, not a substitute for it. See the compliance page.

No. If your requirement specifically names a CERT-In empanelled auditor, we will tell you that rather than take the work.

No. Our mapping covers ISO/IEC 27001:2022, SOC 2, DPDP 2023, the OWASP standards and CWE. PCI-DSS and GDPR are not in scope, and we would rather you knew that from this page than discover it after signing.

Yes. The Act has no small-business exemption and no revenue threshold. If you handle the digital personal data of people in India you are a Data Fiduciary, whether you are two people or two thousand. It also reaches companies registered outside India that offer goods or services to people in India.

No. Compliance is an organisational state covering contracts, policies, staffing and process, most of which is not a security testing question. What we can do is prove or disprove one specific obligation — §8(4) and §8(5), reasonable security safeguards — and give you evidence toward the rest. See the DPDP page.

It depends on scope: how many applications, whether mobile builds and source review are included, and how much of the surface sits behind authentication. Engagements start at ₹30,000, and the passive attack-surface report is free. See pricing.

Standard terms are 50% on signature and 50% on delivery of the report. Prices are in Indian Rupees and exclude applicable taxes unless stated otherwise. Work outside the agreed scope is quoted separately before it begins.

Defeat CAPTCHA, OTP, MFA or SSO. Evade a WAF — a blocked request is recorded as blocked. Write to your system without a written authorisation decision made beforehand. Test anything not authorized, including when a client asks us to.

Unauthorised access to a computer resource is an offence under sections 43 and 66 of the Information Technology Act, 2000, and good intentions are not a defence.

Assessment evidence is encrypted at rest and deleted within 30 days of report acceptance unless you ask us in writing to retain it. Reports and contracts are kept for 7 years as records of a professional engagement. We never use your data to train a model, and never disclose your findings without written permission. See the privacy policy.

Not without your written permission. We may refer to an engagement in anonymised form only — for example “a mid-sized Indian e-commerce company” — and you may object to even that in writing.