Web applications
Assess authentication, sessions, permissions, file handling and business logic across the browser and server.
Explore web application testingPlan penetration testing around your applications, cloud environment, network or AI feature and the decision your team needs to make. We work remotely with teams in India, agree the access and coverage for each workstream, and explain confirmed findings in a report your engineers can act on.
For vulnerability assessment and penetration testing (VAPT), start with the system, user roles and business workflows that matter. We agree on coverage before access is granted.
Assess authentication, sessions, permissions, file handling and business logic across the browser and server.
Explore web application testingCheck object access, tokens, role boundaries, data exposure and important REST, GraphQL or webhook workflows.
Explore API testingTest tenant isolation, administration, SSO and the workflows where one customer or role must not affect another.
Explore SaaS testingScope approved AWS, Azure or GCP resources, IAM, storage and workloads. Identify configuration review separately from impact validation and confirm provider rules.
Explore cloud testing coverageDefine external hosts, internal networks or segmentation paths. Agree remote access, operational limits and the evidence needed before testing begins.
Explore internal and external network testingAssess the AI application you deploy: data access, retrieved content, agent tools and approval boundaries. This is a separate scope from using AI to assist a conventional pentest.
Explore AI and LLM penetration testingSeveral surfaces can share one engagement. Name the extra depth for each workstream, allocate overlapping checks once and consolidate shared findings. For mobile, identity or specialist requirements, explore the broader services; coverage depends on confirmed skills and access.
VAPT is often used as a combined label. Ask whether a proposal includes discovery, manual validation, authenticated workflows, and a re-test. These are separate coverage decisions, and the abbreviation alone does not define them.
| Assessment | Useful question | Confirm in the proposal |
|---|---|---|
| Vulnerability assessment | Which potential weaknesses need review and prioritization? | Asset coverage, access level, validation effort and how uncertain findings are labelled. |
| Manual penetration testing | Can a weakness affect access, data or an important business workflow? | Roles, tenants, workflow coverage, safe impact evidence and exclusions. |
| Remediation re-test | Did the agreed fixes address the reported issues? | Finding IDs, changed version, checks repeated, outcome and anything not re-tested. |
For example, a fictional SaaS brief could name one staging application, its documented API, two controlled tenants and member/admin roles. It would record approved sharing workflows, synthetic data and the report deadline. The production environment and unrelated provider systems would require their own written scope.
Use our vulnerability assessment vs penetration testing guide to compare approaches, then draft a web or API testing brief.
The project starts with a written scope, not a scan. Testing begins only after the system owner has authorized it and the safety rules are agreed.
Share the systems, environments, roles, integrations and reason for testing. We agree on exclusions, test accounts, data handling and what the report needs to answer.
We set a testing window with your team, including the time zone, monitoring contact and escalation path. Production testing needs explicit safety limits.
Manual work focuses on access rules and important workflows. We verify reported findings, describe their effect and flag urgent issues through the agreed channel.
You receive reproducible findings, risk context and repair guidance. We walk the team through the results; any re-test is agreed in the scope.
Use this short brief to make a remote test easier to scope and compare:
Document where engagement material may be stored or processed, who may access it and which tools may be used. We discuss those terms before private diagrams, credentials or customer information are shared.
Our fictional sample report shows the style of evidence and remediation guidance. It is an illustration, not a client outcome or certification.
Our fictional sample uses two controlled test tenants to show the evidence behind an access-control finding. It illustrates a report format, not a client result.
A standard user in synthetic Tenant A requests an invoice owned by controlled Tenant B by changing only the object ID on GET /api/v1/invoices/{id}.
The fictional response returns Tenant B's invoice instead of denying access. The finding records the test accounts, request, response and potential cross-tenant data exposure.
Constrain invoice lookup to the authorized tenant. Then check that cross-tenant reads and exports are denied while the same-tenant read still works; record any routes outside the re-test scope.
Explore the full fictional sample finding and report to see the evidence, remediation and bounded re-test together.
For an example drawn from private research notes, read our anonymized field note on a draft authorization failure. Its HTTP examples are synthetic, and it does not claim a client outcome or a confirmed current fix.
When comparing penetration testing quotes in India, ask what is actually tested and what your team receives. A lower number is hard to compare until the scope is clear.
Does the proposal name the applications, APIs, environments, roles, tenant relationships and critical workflows? Ask which third-party assets and risky techniques are excluded.
Each finding should show what was tested, how it can be reproduced, its business effect and a practical fix. Ask how findings are checked before they enter the report.
Compare the testing window, urgent-issue escalation, engineer walkthrough and re-test terms. If a customer or auditor will read the result, say so before the work begins.
For a deeper comparison of effort and price drivers, read our web and API pentest cost guide.
Share the product and deadline first. The scope determines the effort and deliverables.
Yes. We plan an authorized remote assessment for teams in India. The proposal identifies application, cloud, network or AI coverage, required access, confirmed specialist skills and the report; each workstream has its own testing boundary.
It depends on the number of systems, user roles, integrations, environments and depth of testing. Tell us your goals and timeline; we will write a scope and quote before any testing starts. The cost and scope guide explains the main effort drivers.
Share the reviewer's exact requirements, including any named assessor or report format. We will check whether the proposed scope and deliverables fit before starting. A pentest alone does not certify compliance or guarantee audit acceptance.
Check the exact customer, tender or regulatory requirement. If it names an empanelled auditor, verify the proposed provider against CERT-In's current list before commissioning the work. This page does not claim CERT-In empanelment; a general VAPT report should not be presented as an empanelled audit.
When authorized and appropriate, yes. We agree on safe techniques, test accounts, rate limits, escalation contacts and stop conditions first. Higher-risk scenarios may need a representative test environment.
Send the product type, main roles, target date and reason for the assessment. Do not send passwords or customer data in the first enquiry.
See our penetration testing services for US companies for scheduling, compliance, and remote delivery details.