The frameworks and standards we test against
Key takeaways
- Every application finding is scored with CVSS v3.1 and classified against CWE.
- PTES structures the test phases and the evidence we capture, so results are reproducible.
- Indian obligations — CERT-In and the DPDP Act 2023 — are assessed separately from technical findings.
- We map findings to ISO 27001 and 27002 controls where a client needs that for their own audit.
What we test against
| Framework | Applied to | How we use it |
|---|---|---|
| OWASP Top 10 | Web application risk | The standard reference set for web application testing and the basis of our web and API methodology. |
| OWASP API Security Top 10 | API risk | Applied to every API engagement, including the authorisation matrix we test for. |
| OWASP MASVS | Mobile application risk | The mobile verification standard used to structure our iOS and Android testing. |
| PTES | Test methodology | The penetration testing execution standard our test phases and evidence capture follow. |
| CVSS v3.1 | Severity scoring | The scoring standard used for every finding, so severity is comparable across engagements. |
| CWE | Weakness taxonomy | The common weakness enumeration used to classify root causes rather than just symptoms. |
| STRIDE | Threat modelling | The framework used in our threat modelling and secure design review engagements. |
| CIS Benchmarks | Configuration hardening | The configuration baselines used in our cloud and infrastructure assessments. |
| CERT-In directions | Indian incident reporting | The reporting obligations and timelines we build into incident response plans. |
| DPDP Act, 2023 | Data protection | The data protection obligations we assess against in our compliance readiness work. |
| NIST SP 800-115 | Security testing | Referenced in our scoping and evidence handling procedures. |
| ISO 27001 / 27002 | Security management | Referenced where a client needs their findings mapped to a control set. |
A note on our own certifications
We are careful about the difference between a framework we test against and a certification we personally hold. Our analysts hold individual certifications — including OSCP, CEH and CISSP — and we publish them on request and on individual profiles. But the frameworks in the table above are industry references, not a claim that AAVETech is certified by any of them. A firm describing itself as "ISO 27001 certified" is usually describing an audit of its own management system, which is a real and worthwhile thing — but it is not the same as the quality of the testing delivered on your systems.
What this means for a client
When a procurement questionnaire asks how you test, the frameworks above are the answer that matters. When it asks whether your tester is certified, ask for the individual's certification numbers and verify them. When it asks whether the firm is certified, ask which standard, against which statement of applicability, and by which accredited body — and request the certificate rather than the logo.
Ask for our credentials
We will share individual analyst certifications, our methodology and our evidence handling procedures under NDA, as part of a normal procurement process.
Request a quote See pricingLast reviewed: 24 October 2026. Information on this page is general guidance, not legal advice. Prices are indicative bands for a typical scope and are confirmed in a written quote before any work begins.