A mobile pentest quotation may cover an Android package, an iOS app, both platforms, or the complete transaction including backend APIs. Those are not interchangeable services. Device access, builds, platform protections, roles and test depth can change effort substantially.

Indian buyers should define the mobile delivery model before requesting price. When every vendor receives the same build, platform, identity, API and evidence assumptions, commercial differences become explainable rather than mysterious.

Separate Android, iOS and shared code

State whether one or both platforms are in scope and whether the app is native, hybrid or cross-platform. Shared business code can reduce duplication, but manifests, entitlements, storage, signing and OS integrations still require platform-specific work.

Ask vendors what will be repeated on each platform and what will be sampled. A single blended price is useful only when this allocation is visible.

  • Android package, flavours and signing model.
  • iOS build, entitlements and distribution method.
  • Shared framework and native modules.
  • Platform-specific features and third-party SDKs.

Fix the build and release assumptions

Identify production-equivalent, test and debug builds, version numbers and backend environments. Test-only logging or disabled controls can invalidate conclusions, while a production build may require special instrumentation effort.

Require a process for build changes during testing. A late replacement can trigger regression work and should not silently consume time intended for analysis.

  • Build provenance and version.
  • Debug symbols, source maps or test hooks.
  • Certificate pinning and integrity controls.
  • Change cut-off and rebuild rules.

Choose a representative device matrix

A credible test does not require every supported device, but it must cover meaningful OS and hardware differences. State minimum versions, current customer distribution and any managed-device assumptions.

Physical devices, emulators, rooted or jailbroken devices and specialist hardware have different availability and purpose. Ask the provider to name the planned matrix and explain exclusions.

  • Supported OS range and representative versions.
  • Physical and virtual test devices.
  • Root or jailbreak conditions.
  • Biometric, secure hardware or NFC dependencies.

Define static analysis depth

Binary review can inspect permissions, exported components, deep links, entitlements, local storage, cryptography, endpoints and embedded dependencies. Obfuscation and native libraries may increase expert time.

Ask whether the quote includes framework-aware review and validation of suspicious artefacts at runtime. A strings dump or dependency scan alone is not complete static analysis.

  • Manifest and entitlement analysis.
  • Decompilation and native-library review.
  • Embedded secret and endpoint investigation.
  • Third-party component and configuration assessment.

Define runtime and platform testing

Runtime work observes storage, logs, clipboard, screenshots, inter-process communication, web views, cryptographic calls and client checks while workflows execute. Instrumentation and proxy setup can be material parts of the effort.

Require impact-led testing. The goal is not to count bypassed client checks, but to determine whether an attacker-controlled device gains data or authority beyond the threat model.

  • Local artefacts across login, logout and account switching.
  • Deep links, intents, schemes and app extensions.
  • Web-view bridges and untrusted navigation.
  • Runtime manipulation tied to server effects.

Include transport and backend APIs explicitly

List API hosts, authentication, GraphQL or real-time channels and whether direct API testing is included. Intercepting app traffic does not equal systematic authorization and business-logic coverage.

Backend scope often drives more effort than the client. Roles, tenants, objects and high-risk workflows must be priced as a defined API matrix rather than assumed inside “mobile VAPT.”

  • First- and third-party network destinations.
  • Token and device-binding flows.
  • Direct API operation inventory.
  • Cross-role, cross-tenant and workflow tests.

Account for integrity and attestation controls

Device integrity, application attestation, jailbreak detection and pinning may protect production flows and complicate observation. Describe test accommodations and who approves them.

Ask whether the provider will evaluate binding, replay and server reliance, not merely bypass the client check. This distinction affects both time and assurance.

  • Attestation actors and protected operations.
  • Freshness, binding and failure behaviour.
  • Test-build exceptions versus production logic.
  • Server-side controls when signals are absent.

Price identities and business journeys

A consumer login and one happy path cannot represent a wallet, marketplace or enterprise app. List user types, tenants and sensitive journeys such as payment, document sharing, approval and recovery.

Each journey may cross client, API and asynchronous systems. Ask how the quote allocates time to state, replay, concurrency and authoritative result verification.

  • Role and tenant account matrix.
  • High-impact operations and state transitions.
  • Offline queues, notifications and callbacks.
  • Customer, support and administrator paths.

Add safety, evidence and retest requirements

Production apps can trigger real messages, payments and account effects. Set test identities, value limits, excluded actions, monitoring and stop contacts. These controls should be planned, not negotiated after testing starts.

Define finding evidence, platform and build identifiers, coverage matrix, readout and retest cycles. A lower fee may omit the closure work your assurance process requires.

  • Production-safe operating envelope.
  • Build, OS and device evidence.
  • Client-to-backend coverage traceability.
  • Retest platform and cycle assumptions.

Compare quotations as platform matrices

Break each offer into Android, iOS, shared framework, backend API, specialist features, reporting and retest. Record GST, devices, onsite work, travel, data location and subcontractors.

Ask vendors to identify reused versus platform-specific tests. Fair efficiency is valuable; unexplained duplication or unexplained omission is not.

  1. Freeze builds, platforms, devices and backend scope.
  2. Normalize identities, workflows and test depth.
  3. Add options, retest, tax and change assumptions.
  4. Select the team that can prove end-to-end effects.

Build an internal mobile cost model

Estimate platform-specific static and runtime work, then shared framework and API work. Add complexity for device controls, specialist hardware, business workflows, safety, evidence and closure.

Use quotations to refine the model. Avoid publishing or relying on one “India price” detached from these assumptions; it will not predict the service being purchased.

Use the official OWASP Mobile Application Security Testing Guide to describe techniques, the OWASP MASVS for control objectives and the OWASP API Security Top 10 for backend risk context. Obtain current written quotations for the exact platform matrix.

Price the released product, not just the package

The customer’s mobile transaction spans binary, device, operating system, network and backend. A useful quote says which of those boundaries will be tested on which platforms and builds.

WIMD scopes mobile assessments through platform matrices, static and runtime depth, device controls, API authorization, workflows, safety and retesting so Indian buyers can compare the same end-to-end assurance.