When to choose ASVS, MASVS, or both for OWASP ASVS vs OWASP MASVS
Choose OWASP ASVS for the web and API layer and OWASP MASVS for the installed mobile client. Pick both when the backend and the app each hold sensitive logic or data, because a single standard cannot describe what the server enforces and what the device protects. A security lead buying assurance for a web application usually needs ASVS alone, a mobile banking or health app with its own local storage and session tokens usually needs MASVS plus the backend assessed against ASVS, and a product with a thin client over a rich API should not let the client assessment stand in for the server.
ASVS matters most when the application's trust decisions happen on the server: authentication, session handling, authorization and the API surface. Its chapters on API and web services, authentication, authorization and OAuth and OIDC map directly to the endpoints your backend exposes. ASVS levels L1 to L3 let you match depth to risk, and OWASP advises starting at L1 and moving up. MASVS matters when the client stores data, pins certificates, handles keys or contains logic that an attacker could reverse engineer or tamper with. Its control groups cover storage, cryptography, authentication, network, platform, code, resilience and privacy, and the MAS testing profiles (L1, L2 and R) let you ask for resilience against reverse engineering only where the app justifies it.
A single engagement can cover both when the same team tests the app binary and the API it calls, and the statement of work names the standards and levels for each layer. Confirm with the testing provider that it is accredited for both: CREST's OWASP Verification Standard accreditation covers web assessments against ASVS and mobile assessments against MASVS at Levels 1 and 2. Ask whether the scope includes backend tests against ASVS at the level you chose, whether the mobile testing follows the current MASTG procedures, and how findings that span both layers, such as a token that the client stores insecurely but the server should have revoked, will be recorded and retested.
How ASVS 5.0.0 and MASVS v2.1.0 differ on structure, levels and scope
This table sets the web and API standard against the mobile standard on purpose, structure, levels, testing guides, accreditation and typical buyer. Read it as a buyer's view of which standard fits which part of an app, not as a control-by-control mapping, because the two documents are not interchangeable.
| Dimension | OWASP ASVS 5.0.0 | OWASP MASVS v2.1.0 |
|---|---|---|
| Primary purpose | Verifiable security requirements for web applications and their APIs, usable as a build, design and assessment baseline | Verifiable security requirements for the mobile app itself, covering the client code, local data and its interaction with the platform |
| Target | Web applications, APIs and the server-side services behind them | Android and iOS apps, including the device-side behavior they rely on |
| Structure | 17 requirement chapters, V1 Encoding and Sanitization through V17 WebRTC, including V4 API and Web Service, V6 Authentication, V8 Authorization and V10 OAuth and OIDC | Eight control groups: storage, crypto, authentication, network, platform, code, resilience and privacy |
| Levels or profiles | Verification levels L1 to L3, each increasing in depth and complexity; OWASP advises starting at L1 | MAS testing profiles L1 (basic), L2 (advanced, for apps handling sensitive data) and R (resilience against reverse engineering and tampering) |
| Testing guide | OWASP Web Security Testing Guide (WSTG) describes how to test many web and API requirements | OWASP Mobile Application Security Testing Guide (MASTG) gives procedures for Android and iOS; v2.0.0 released 30 June 2026 |
| Current release | ASVS 5.0.0, dated May 2025 | MASVS v2.1.0, released 18 January 2024 |
| Accreditation tie-in | CREST OVS assesses web application testing against ASVS at Levels 1 and 2 | CREST OVS assesses mobile testing against MASVS at Levels 1 and 2 |
| Typical buyer | Teams owning web portals, APIs and back ends, often named in procurement for web application or API assurance | Teams publishing consumer or regulated mobile apps, often needing store listing or mobile assurance evidence |
| Source code and documentation | Higher levels expect deeper design and code evidence; confirm the level and evidence needs with the assessor | Confirm with the assessor whether resilience (R) and deeper code checks need access to build artifacts and binaries |
What web verification finds that mobile testing misses, and the reverse
ASVS and MASVS verify different halves of an application that usually shares one backend. Each card names a risk area where one approach gives coverage the other cannot, so teams can scope the server side and the shipped client deliberately.
Server-side authorization and business logic
ASVS covers authorization decisions, including object-level access checks and workflow rules, because those run on the server. A MASVS assessment can show that the app sends a request, but it cannot prove the server refuses a user who edits an identifier to reach another customer's record. Ask whether the ASVS scope includes V8 Authorization and whether testers receive two user roles to probe it. Mobile testing alone leaves this gap open.
API and token handling
ASVS chapters for API and web services, authentication, and OAuth and OIDC test how the server issues, validates and expires tokens. A mobile assessment sees tokens only where the client stores or transmits them, so it cannot confirm that a stolen token is rejected after logout or that scopes are enforced. Confirm which API endpoints the mobile app calls and whether they are in the ASVS scope.
Client-side storage and certificate pinning
MASVS storage and network controls examine what the shipped app writes to the device, such as cached responses, keychain entries or plaintext preferences, and whether it pins certificates. An ASVS assessment of the backend never sees those files, so it cannot show that a session token sits unencrypted on a rooted phone. Ask the tester to inspect a built package on Android and iOS, not only the source repository.
Reverse engineering and tampering resilience
MASVS resilience requirements, tested at the R profile, cover whether the app detects debugging, hooking or repackaging and responds sensibly. These checks assume an attacker holds the binary, which backend testing never considers. Resilience cannot replace server-side controls, because a determined attacker can bypass client checks. Confirm the R profile applies to your threat model before you pay for it.
Privacy controls and data minimization
MASVS privacy controls check what personal data the app collects, how it appears in logs and analytics SDKs, and what permissions it requests. The backend may store data correctly while the mobile app leaks identifiers to third-party services, which only a client-side review reveals. Ask whether your privacy requirements are written into the scope, since neither standard alone covers third-party data flows at the organizational level.
Which testing guides sit behind each standard
Start with the question a statement of work will ask: which guide tells the tester how to run the checks? For mobile, the answer is the OWASP Mobile Application Security Testing Guide (MASTG), which gives the testing procedures for MASVS controls on Android and iOS. MASVS says what the app must do, and MASTG shows how to test it on each platform. MASTG v2.0.0 was released on 30 June 2026 according to its GitHub releases, so confirm that your testers are working from that version or the one your contract names, because procedure numbering and platform detail can change between releases. Ask the provider which MASTG version their test plan cites and how they map each finding back to a MASVS control and profile (L1, L2 or R).
ASVS works differently. It is a requirements standard, not a test procedure, and it does not name a single companion guide for every step. For web and API verification, the test procedures most teams reference are in the *OWASP Web Security Testing Guide* (WSTG). Before you name WSTG in a statement of work, compare it with ASVS 5.0.0 and confirm which version and sections your testers will use, since the WSTG and ASVS version histories are separate. Be explicit about whether an ASVS chapter such as V4 API and Web Service or V10 OAuth and OIDC will be verified by a checklist of WSTG tests, by code review, or by a mix, because the evidence each method produces is different.
For an app with both a mobile client and a web or API backend, this split means two guides, two version pins and two evidence trails. Write both into the scope: MASTG for the client, and the WSTG-based ASVS verification for the backend services the app calls. Ask each provider to state the guide version, the MASVS or ASVS level they will test to, and how they will record results for the controls that sit on the boundary, such as authentication and network communication. A vague line that says the app will be tested to OWASP standards does not tell you which procedures will run.
How to scope an app whose backend and client both need assurance
When a mobile app talks to a backend that the vendor also operates, the client and the server are separate assessment targets. MASVS covers the app binary and its local behavior, and its control groups for storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy apply to the client. The backend API is not a MASVS target. Its authentication, authorization, input handling and session logic fall under ASVS, most often V4 API and Web Service, V6 Authentication and V8 Authorization. The testing guide for the client is the OWASP Mobile Application Security Testing Guide (MASTG), while the API is tested against ASVS. A tester needs the app build for both Android and iOS where both ship, test accounts at each privilege level, and a non-production backend or agreed test windows on production. Source access for the backend is optional for ASVS Level 1 but becomes important at higher levels. Write the trust boundary down: the device is untrusted, so anything the app enforces locally, such as feature gating or role checks, must also be enforced by the API. Agree in writing which MASVS profile (L1, L2 or R) applies to the client and which ASVS level applies to the API, and confirm whether the tester will test the backend under the same statement of work.
A web application with a thin client moves most logic to the server, and the browser mainly renders pages and calls endpoints. In this case, ASVS is the primary standard for both layers, because the browser code and the server code are both part of the web application. MASVS does not apply unless a companion mobile app exists. The chapters that usually carry most of the weight are V1 Encoding and Sanitization, V3 Web Frontend Security, V6 Authentication, V7 Session Management, V8 Authorization and V4 API and Web Service where the front end calls internal endpoints. Because the client is thin, the tester's main job is to confirm that the server enforces every control the page appears to enforce. Access that matters includes an architecture diagram, a list of endpoints and roles, and a test environment that mirrors production configuration. Source access is more valuable here than in the mobile case, since server logic is where most authorization decisions live, and the level chosen should reflect that. Mark the boundary between the browser and the server explicitly in the scope document, and state which content delivery, third-party scripts and hosting controls are excluded. Confirm with the tester in writing which ASVS version and level will be verified, and whether a separate web application penetration test is included.
A SaaS product with a public API, a web console and a mobile client has three client surfaces that share one backend. Scope usually works best as two linked assessments: an ASVS verification covering the web console and public API, and a MASVS assessment covering each mobile client, with the MAS testing profile agreed per app. The public API is the shared trust boundary. Every client, whether browser, mobile app or customer integration, reaches the same authorization logic, so the API should be tested for object-level and function-level access control under ASVS V8 Authorization and V10 OAuth and OIDC where tokens are issued. On mobile, tokens are stored and refreshed on the device, which places MASVS storage and authentication controls in scope. Access needs to cover at least two tenants or accounts, admin and standard roles, API documentation, and the mobile builds for each platform. Source access for the API and the authorization layer typically carries the most value, because the tester can check whether each client gets the same server decision. Set out in the statement of work which surfaces are in scope, which tenant data may be touched, and whether the test covers third-party integrations. Ask the tester to confirm this boundary map in writing before fieldwork begins.
Choosing ASVS levels L1 to L3 and MAS profiles L1, L2 and R
Level choice drives how deep the testing goes and what evidence a tester will ask you to produce. The cards below walk through the decisions in order, from the starting level for a web or API application to the mobile profiles that apply when the client and backend both need assurance.
Start at ASVS L1
OWASP advises starting with ASVS Level 1 and moving up according to the needs of the organization and the application. For a web or API application that is new to formal verification, L1 gives a baseline that every team can meet and test against. Check whether your current testing covers the L1 requirements in the chapters that matter most to you, such as authentication, authorization and API security, before you commit to a higher level.
Move to L2 for sensitive data
Level 2 suits applications that handle sensitive data, where a failure in authentication, access control or data protection carries significant business or regulatory impact. On the mobile side, the MAS L2 profile is designed for advanced security in apps that handle sensitive data. Ask your team which data classes the app stores or transmits, and whether a breach of those classes would trigger notification duties, then use the answer to set the level.
Reserve L3 for high-assurance apps
Level 3 applies the deepest verification in ASVS and suits the most critical applications, where the consequences of compromise are severe. Choosing L3 raises the depth of testing and the evidence expected from the tester, so it should be a deliberate decision rather than a default for every system. Confirm with your risk owner and assessor which applications genuinely require it before you write L3 into a statement of work.
Apply R for reverse engineering risk
The MAS resilience profile R addresses resistance to reverse engineering and tampering on the device. It is relevant when an app holds logic, keys or content that an attacker would gain by decompiling or modifying the client, such as payment flows or licensed content. Check whether your threat model names these risks. If it does not, R may be unnecessary, and the effort is better spent on the L1 or L2 controls.
Match levels to evidence
The level you select determines the evidence a tester will request, including whether source code, architecture documents and configuration records must be provided. Higher levels usually ask for more of this material, so ask the tester to state the evidence list in the written scope. Confirm with your assessor how the chosen level will appear in reports, since the same application can yield different findings at different levels.
Confirm accredited test coverage
CREST's OVS accreditation assesses whether a testing organization can run web application assessments against ASVS and mobile assessments against MASVS at Levels 1 and 2. If your chosen level is L1 or L2, ask prospective testers whether they hold this accreditation and which levels it covers. For L3 or the R profile, ask them to describe how they will meet the requirements and what they will deliver.
What CREST OVS accreditation tells a buyer
CREST announced its OWASP Verification Standard (OVS) accreditation on 28 October 2022. The scheme assesses whether a testing organization can run web application assessments against OWASP ASVS and mobile assessments against OWASP MASVS, at Levels 1 and 2. For a buyer, the practical reading is narrow: the firm has been checked for the ability to perform these assessments at those levels. It says nothing about whether your application needs ASVS Level 2 or MASVS Level 2, whether the backend API is in scope, or whether a given engagement will use source code. Confirm the accreditation details directly with the provider and with CREST's announcement of the first accredited companies, and ask whether the individuals named on your engagement hold the relevant CREST certifications.
Put the accreditation into the statement of work. Ask the provider to name the standard and version it will verify against (for web, the ASVS version and chapters; for mobile, the MASVS version and the MAS testing profile, L1, L2 or R), the level for each control group, and the testing guide it will follow for procedures, such as the Web Security Testing Guide for web work or the Mobile Application Security Testing Guide for mobile work. Ask whether the provider will produce a per-requirement results matrix, how it records requirements it did not test, and whether it will test the web or API backend and the mobile client under the same engagement or separate ones. Ask for the tester's access model (black box, gray box or source-assisted) in writing.
Accreditation of the firm does not replace the scope decisions you make. Choosing the ASVS chapters, the MASVS control groups, the MAS profile and the environments to test (production, staging or a build of your own) remains your call, and it drives the effort and the findings you receive. An accredited firm can test well against a scope that leaves out your authentication flows or your mobile token storage. Write down the data your app handles, the threat model you rely on, and the requirements you are not testing, and agree them with the provider before work starts. Those decisions, not the accreditation badge, determine whether the assessment answers your question.
Questions buyers ask before hiring help for ASVS or MASVS work
What drives the cost of an ASVS or MASVS assessment and who gets paid for what?
The fee is driven by how many requirements apply, which verification level is in scope, how many platforms and components are tested, and how much access the assessors receive. Most engagements are fixed-scope, so the written scope sets the deliverables before any work starts. The client pays the assessor for testing time, reporting and any retest, and may also pay for internal remediation effort, which is separate from the assessment itself. Ask each bidder to price the level, the platforms, the backend APIs and the retest round as separate line items, so you can see which scope change moves the total. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does an ASVS or MASVS assessment take?
Duration depends on the number of requirements at the chosen level, the size of the application or mobile app, the number of user roles and API surfaces, and how quickly the client provides access and answers questions. No duration figure is given here because none is supplied for this comparison. Ask the bidder for a schedule with named phases (scoping, access setup, testing, reporting, retest) and the dates each phase depends on from your side. A schedule that does not list client dependencies usually understates the calendar time.
What does the client need to provide for an ASVS or MASVS assessment?
Plan to supply a stable build of the application, test accounts for every role, architecture and data-flow documents, and an agreed rules of engagement. For ASVS at higher levels, ASVS expects more evidence than running the app alone, so ask whether the work needs source code access, configuration files and design documents. For MASVS, the client typically provides builds for Android and iOS, the matching backend environment, and test devices or emulator images. Confirm in writing who owns the test environment, how credentials are issued and revoked, and whether testing is allowed against production or only staging.
Can an internal security team run an ASVS or MASVS assessment on its own?
An internal team can run verification against the requirement lists if it has people who understand the chosen level, the testing guides and the platform under test. Independence is the weak point: developers and the team that built the app are poor judges of their own controls. The OWASP testing guides exist to support internal work, so an internal program can use them. If a customer, auditor or accreditation scheme asks for a third-party result, the internal result alone may not satisfy that request. Confirm the independence rule with the party asking for the evidence before deciding.
Can ASVS and MASVS be bought together as one engagement?
Yes, the two standards cover different targets, so a combined scope is common when an app has a mobile client and a web or API backend. ASVS covers the web and API side, including the API and authentication chapters, while MASVS covers the mobile client through its control groups such as storage, network and platform. Write the scope so each target lists its own standard, level and test profile, and so the backend endpoints the app calls are named explicitly. Without that split, the backend often falls between two statements of work.
What does a certificate or badge prove, and what does it not prove?
A CREST OVS accreditation shows that a testing company is accredited to run web assessments against ASVS and mobile assessments against MASVS at Levels 1 and 2, based on the accreditation scheme. It does not prove that a particular application passed a particular set of requirements. Individual assessment reports, their scope and their level are the evidence for a single application. Confirm the standard version, the level, the test profile and the date on the report, and check whether any listing badge reflects a specific app. DeployOpen does not issue audit reports, attestations or certifications; independent assessors and certification bodies do.
What should a quote for ASVS or MASVS work include?
Ask for the standard version, the verification level or MAS testing profile, the list of platforms and endpoints in scope, and the test methods, including whether source code review is included. The quote should also name the deliverables, the retest terms, the access the assessor needs, and the client responsibilities that affect the timeline. Ask which costs recur, such as a repeat assessment after a major release, and which are one-time. A quote that lacks a version, level or list of endpoints cannot be compared with another bid.
Writing the statement of work that names the right standard
This sequence turns a vague request for an application security test into a statement of work that names the standards, levels, guide, evidence and deliverables a provider must meet. Each step closes with a check that the item is written into the agreement, not left to the provider's discretion.
Name the application layers in scope
Start by listing every layer the test must cover: the web front end, the back-end APIs, the mobile client, and any shared services or identity components behind them. Your architecture and product owners should confirm the list, because a missing layer is the most common gap. The step is done when each layer is named with its owner and a note on whether it is web, API or mobile, so the right standard can be attached to each one.
Choose the ASVS and MASVS versions and levels
Attach a specific version and level to each layer. Use OWASP ASVS for the web and API layers and OWASP MASVS for the mobile client, and name the exact release, such as ASVS 5.0.0 or MASVS v2.1.0, so both parties test against the same requirement set. For mobile, choose the MAS testing profile (L1, L2 or R) that matches the data the app handles. The step is done when every layer has a standard, version and level written into the statement of work.
Name the testing guide for each standard
Requirements state what must be true, but the testing guide states how to check it. Name the OWASP Web Security Testing Guide for web and API work and the Mobile Application Security Testing Guide for the Android and iOS procedures, and state the guide version. Ask the provider to map each finding to the requirement and test procedure it came from. The step is done when the agreement names both guides and requires that mapping in the report.
Require accreditation evidence where it matters
Where the assurance will be relied on by customers, regulators or assessors, require evidence that the testing organization is qualified for the standard. CREST's OWASP Verification Standard accreditation covers web application assessments against ASVS and mobile assessments against MASVS at Levels 1 and 2, so ask whether the provider holds it for the levels you chose. Confirm the current status with CREST directly, since accreditation is not a certification of the application. The step is done when the agreement states what evidence the provider must produce and when.
Specify build and account access
Write down what the testers receive: the build or release candidate under test, source code or design documents where the chosen level expects them, test accounts with each role the application uses, and any test data or API keys needed for the mobile backend. Confirm the environment, whether staging or production, and who approves access changes. The step is done when a written access list exists and the build identifier is recorded in the statement of work, so findings can be traced to a fixed version.
Define the deliverable and its mapping
Specify what the report contains: each finding with the ASVS or MASVS requirement it breaches, the level tested, the test procedure used, evidence, severity and a retest path. Also state which requirements were tested and which were not applicable or out of scope, with reasons. Ask the provider to state the result of each requirement, not only a list of defects, so you can see coverage. The step is done when the report format is an appendix to the agreement and both parties have signed off on it.
What drives cost and effort for each assessment
Application assessments against ASVS and MASVS are priced and staffed from the same handful of scope decisions. The cards below cover what each driver adds, who is paid for it, and what should appear in a written quote, so two offers can be compared on the same footing.
Number of mobile platforms
Each platform in scope, Android and iOS, needs its own build, device set and MASTG procedures, so a second platform adds testing time rather than reusing the first. Ask the tester whether the quote covers both platforms at the chosen MASVS level, which devices and OS versions are included, and whether a single report or two separate reports will be delivered. Platform count is a one-time cost per assessment cycle, but it recurs with each release that changes either app.
Backend services in scope
A mobile app assessment that stops at the client misses the APIs it calls. Including the backend means the tester also works through ASVS chapters such as V4 API and Web Service and V6 Authentication, which adds endpoints, roles and token handling to the work. Ask whether the backend is quoted as a separate ASVS assessment or folded into the MASVS scope, and who owns the findings for server-side issues.
Chosen verification levels
Moving from a basic level to an advanced one increases the number of requirements the tester must verify and the evidence they must collect. OWASP advises starting with L1 and moving up according to the organization's and application's needs, and MASVS adds the R profile for resilience testing against reverse engineering and tampering. Ask the vendor to name the level and profile in writing, and to price each profile separately if you may add one later.
Source code and documentation access
Source review and architecture documents let testers verify controls directly instead of inferring them from behavior, which generally takes more time at higher levels. Preparing repositories, build instructions and design docs is usually the client's effort, and providing them can be a one-time setup cost. Ask what access is required for the chosen level, who prepares it, and whether the vendor will need a test environment with debug or instrumented builds.
Number of user roles
Authorization testing scales with the number of roles and the permissions each one holds. Each role needs test accounts, and access control checks run across role pairs, which lengthens the work on multi-tenant or administrative functions. Ask how many roles and test accounts the quote assumes, who creates and maintains them, and whether additional roles discovered during testing change the fixed price.
Number of retests
Retesting confirms that fixes close the findings, and it is often quoted separately from the initial assessment. Each retest is a recurring cost tied to remediation cycles, and a second release of the app may require a fresh assessment of changed controls. Ask whether retests are included, how many rounds are covered, the window for requesting them, and how a vendor treats changes that touch previously verified requirements.
When to run ASVS and MASVS together and how to sequence them
A combined scope is worth buying when the backend and the mobile client both hold sensitive logic, because the gaps tend to sit at the trust boundary between them. If the app enforces authorization only in the client, or the API trusts a client-side check for a transaction limit, a backend assessment against ASVS and a client assessment against MASVS can each pass their own scope while the flaw survives. Start by listing which decisions happen where: token issuance and refresh, role checks, pricing or entitlement logic, and certificate pinning or request signing. Each decision that spans both layers needs an owner in the statement of work. For sequencing, the backend requirements that the client depends on are a sensible first pass. ASVS chapters such as V4 API and Web Service, V6 Authentication, V8 Authorization and V10 OAuth and OIDC define the server-side behavior the app relies on, so confirm which level applies to those chapters before testing starts. Then run the MASVS testing against the build that calls them, using the MASTG procedures for storage, network and authentication controls. Check the MASTG release used for the engagement and the MASVS version named in the scope, because both are versioned and the test cases change between releases.
Shared findings need a rule before the engagement begins. A weak token lifetime may appear as an ASVS authentication finding on the server and as a MASVS storage finding on the device, and the report should record one root cause with two affected layers rather than two unrelated items. A combined report should separate findings by layer, label each with the requirement identifiers it fails in ASVS or MASVS, and state which layer must be fixed to close it. Ask the tester to confirm whether the backend work was done with source or documentation access, since that changes the depth of the ASVS results, and to state the MASVS profile used, L1, L2 or R, for each mobile control.
What you receive from each engagement type
This sequence shows how an ASVS assessment and a MASVS assessment move from agreed scope to the written results you keep. It also shows which artifacts each engagement produces, so you can compare them before you sign.
Agree the scope and level in writing
Before work starts, the written scope names the standard version, the verification level for each chapter or control group, and the components under test, such as a web front end, an API, or an Android and iOS client with its backend. DeployOpen agrees this scope with your team in writing, and no testing begins until both sides have signed it. You know this step is complete when the scope lists the standard version, the levels, the in-scope builds and endpoints, and the exclusions. Ask whether the deliverable format and requirement list are fixed in that document.
Map requirements to test evidence
Testers work through the applicable requirements for the agreed level and record which test procedure covers each one. For an ASVS engagement, the requirement list follows the chapters of the standard; for a MASVS engagement, testers use the control groups and the matching MASTG procedures for each platform. You know this step is complete when every applicable requirement has a recorded outcome or an explicit note on why it does not apply.
Record requirement-by-requirement results
The core deliverable is a results register with one entry per requirement in scope. Each entry states whether the requirement was met, not met, not applicable, or not verified, along with the test performed and the evidence reviewed. Ask for this register in a spreadsheet or machine-readable form if your evidence workflow needs it, because the format is set in the written scope and not in this comparison. You know this step is complete when the register covers the full agreed scope without gaps.
Document findings with reproduction steps
Each failed requirement becomes a finding with a title, a description of the affected component, reproduction steps, the observed result, and a recommended fix. For mobile work, findings also state the platform and build version tested. Testers keep the reproduction steps specific enough that your engineers can repeat them without a call. You know this step is complete when every finding can be reproduced from its write-up alone and is linked to the requirement it fails.
Package evidence for each claim
Evidence includes request and response captures for web and API checks, and for mobile checks, notes on the device, build, and tools used, plus screenshots or logs where they support a result. Evidence is stored with the matching requirement so an assessor can trace a conclusion back to its source. Confirm with DeployOpen how long evidence is retained and whether it can be delivered to your repository. You know this step is complete when each recorded result links to at least one piece of evidence or to a stated reason for having none.
Deliver the final report
The final report summarizes scope, methods, levels tested, results by chapter or control group, and the list of findings with their severity and status. It also states any limits of the test, such as requirements that could not be verified without source code or a test account. You know this step is complete when the report is delivered and both teams have walked through the scope and the open items. Ask whether an executive summary and a separate results register are both included.
Retest fixed findings and issue retest reports
After your team ships fixes, DeployOpen retests the affected findings and updates each one with a retest result, such as resolved, partly resolved, or still open, along with the evidence used to decide. Retest reports should show which build was tested and whether any new issues appeared during the retest. You know this step is complete when every finding in scope has a documented retest outcome. Confirm in the written scope whether retests are included in the fixed price or billed separately, and how many retest rounds are covered.
How DeployOpen scopes, delivers and supports ASVS and MASVS testing
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it runs application and API security testing. For OWASP ASVS and OWASP MASVS work, we start by agreeing in writing which chapters, levels and mobile profiles apply to the backend and the client, then deliver against that scope inside your environment.
How we scope
- We agree in writing which ASVS chapters and verification level apply to the web or API backend under test.
- For mobile work, we confirm which MASVS control groups and MAS testing profiles apply to the app and its backend.
- Engagements are fixed-scope, so deliverables and timelines are agreed before any testing starts.
How we build
- We test against the ASVS and MASVS requirements in scope, using the matching OWASP testing guides for each target.
- Work runs inside your cloud accounts, data centers or air-gapped networks, with your test accounts and environments.
- We confirm with you which source code, design documents and device builds are available, since some levels depend on them.
How we hand over
- Each requirement in scope is recorded with its test result, evidence and the reasoning behind it.
- We document the testing approach so your team and your independent assessor can follow how each conclusion was reached.
- Findings are handed over with remediation guidance, and we prepare control evidence but do not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
- A retainer can re-verify requirements after major releases, new API versions or mobile OS and app updates.
- Ask us to confirm which ASVS version and MASTG release your scope references, so future re-tests stay comparable.
