GUARDIAN SECUREAPP™ · ASSURANCE LEVEL 3
Level 3 (High-Risk / Critical) — Guardian SecureApp™ Certification
The deepest evaluation depth available under Guardian SecureApp™. Level 3 (High-Risk / Critical) is accredited certification at OWASP ASVS Level 3 — comprehensive source code review across the in-scope codebase, formal threat-modelled architecture review (STRIDE / PASTA), adversarial / threat-led testing methodology, and extensive abuse-case and chained-attack testing. The right level for products in regulated, financially-systemic, or critical-infrastructure contexts.
Level 3
Level 3 — The Deepest Evaluation Available
Level 3 (High-Risk / Critical) of Guardian SecureApp™ is the right level when your product handles financial transactions of material value, regulated data classes, or operates as part of critical infrastructure — and the breach consequences are systemic rather than individual. Level 3 maps directly to OWASP ASVS Level 3, which extends the ASVS Level 2 evaluation with comprehensive (rather than sample-based) source code review across the in-scope codebase, formal threat-modelled architecture review using STRIDE or PASTA methodology, adversarial / threat-led testing methodology, and extensive abuse-case and chained-attack testing.
Level 3 is offered under the same ISO/IEC 17065 accreditation by UAF (accreditation number 52605385601, IAF Scope Code 33, valid until 05 May 2030) as Levels 1 and 2. The procedural integrity is identical: independent certification decision, public directory listing, surveillance, complaints and appeals rights, certification mark licence, and recognition through the international accreditation infrastructure. What is genuinely different at Level 3 is the depth of the technical evaluation — comprehensive in source code coverage, formal in threat modelling, adversarial in testing methodology, and substantially longer in elapsed engagement time.
Typical Level 3 candidates include: net-banking and mobile banking platforms; UPI / payment platforms and payment gateways; trading platforms and capital markets infrastructure; electronic health record (EHR) and electronic medical record (EMR) systems; identity providers and authentication-as-a-service platforms; embedded-finance APIs and Banking-as-a-Service (BaaS) rails; open-banking AISP / PISP platforms; government tax, identity and benefit-disbursement systems; and SaaS platforms serving regulated buyers in banking, insurance, healthcare or critical infrastructure where the buyer’s procurement specifically requires Level 3-equivalent depth.
Evaluation depth
The Highest Assurance Signal Under the Scheme
Level 3 is the deepest evaluation depth offered under Guardian SecureApp™. There is no Level 4. The path forward from Level 3 — for products whose risk profile or buyer expectation continues to evolve — is depth/scope expansion within Level 3, not escalation to a deeper level. This is worth saying explicitly because it shapes how Level 3 should be understood.
What Level 3 Does Mean
A Level 3 certificate is the highest available assurance signal under the scheme. It confirms that the certified product, at the named version, in the named scope, has been evaluated at the deepest depth Guardian SecureApp™ offers — comprehensive source code review across the in-scope codebase, formal threat-modelled architecture review, adversarial / threat-led testing — and met the certification criteria. For buyers performing technical due diligence at the highest end of the procurement maturity spectrum, that is the strongest documentary evidence we issue.
What Level 3 Does Not Mean
Level 3 is not, and cannot be, a guarantee against future compromise. No certification level is. Security is dynamic — code changes, dependencies update, new attacks emerge, threat actors evolve — and a certificate confirms criteria-met-at-evaluation, not future impregnability. Level 3 surveillance and recertification exist precisely to track change over time. What Level 3 does provide is documented, accredited, third-party assurance that the most defensible application security depth available under our scheme was evidenced at the time of evaluation, and is being maintained through semi-annual surveillance and mandatory re-evaluation on major releases.
Why That Distinction Matters
Mature security buyers — the audience most often asking for Level 3 — understand the distinction. They do not interpret Level 3 as ‘this product cannot be breached’. They interpret Level 3 as ‘this vendor has invested in the deepest available accredited evaluation, has remediated whatever findings emerged, is subject to twice-yearly surveillance plus change-driven re-evaluation, and would be issuing a public correction in the directory if material non-conformity emerged’. That is the assurance signal Level 3 is engineered to produce.
On adversarial methodology: Level 3’s threat-led / adversarial testing methodology means the evaluation team approaches the product as a sophisticated adversary would: with knowledge of the architecture, with the patience to chain findings together, with attention to abuse cases and unusual sequences, and with an understanding of which controls would be most consequential to bypass. This is materially different from the scenario-based testing of Level 1 or even the comprehensive ASVS Level 2 testing of Level 2.
Level 3 Evaluates
The Specific Coverage of Level 3
Level 3 evaluates the certified product against OWASP ASVS Level 3 controls across all 14 control families (V1–V14), with the OWASP Top 10 risk framework applied as a prioritisation lens. Specifically, Level 3 includes the following evaluation activities, each substantively deeper than the Level 2 equivalent and each delivered to the rigorous standard required for products in high-stakes contexts.
| Activity | What This Means at Level 3 |
|---|---|
Documentation Review (Stage 1) | Comprehensive review of architecture, data flow diagrams, threat models, authentication and authorisation design, change history, prior assessment evidence, breach history where applicable, and integration documentation. A formal threat model is expected as input; where one is not provided, Stage 1 includes its construction. |
Automated Scanning | DAST, SAST, SCA, secrets scanning, configuration scanning, and Infrastructure-as-Code (IaC) scanning. Findings are prioritised against ASVS Level 3 controls and used to inform, but not substitute for, adversarial manual testing. |
Adversarial / Threat-Led Manual Testing | Full ASVS Level 3 manual testing coverage executed with adversarial mindset. The evaluation team chains findings together, pursues abuse cases and unusual sequences, and approaches the product as a sophisticated adversary would. This is materially different from Level 2 scenario-based comprehensive testing. |
Multi-Role + Chained-Escalation Testing | Testing across all defined roles plus chained-escalation scenarios where multiple findings combine into systemic vulnerabilities. Privilege escalation, horizontal authorisation breaches, and cross-tenant boundary failures in Module B are tested in chained sequences. |
Comprehensive Source Code Review | Mandatory and comprehensive at Level 3. Review covers the in-scope codebase rather than sample-based critical-component review. The selection rationale, depth applied per area, and findings are documented in the Evaluation Report. Comprehensive review materially differs from Level 2 sample-based approach. |
Threat-Modelled Architecture Review | Formal threat-modelling exercise using STRIDE or PASTA methodology, producing a documented threat model alongside the Evaluation Report. This is substantively deeper than Level 2 detailed architecture review with data flow analysis. |
Extensive Business-Logic and Abuse-Case Testing | Exhaustive scope at Level 3. Includes complex multi-step exploits, race-condition testing under realistic concurrency, anti-automation defence verification under sustained load, and adversarial abuse cases that would not surface in standard authorisation testing. |
Configuration / Hardening Review | Comprehensive review against CIS benchmarks, vendor-specific hardening guides, and any sector-specific baselines applicable to the certified product. Goes beyond Level 2 documented review against established benchmarks. |
Findings Reporting and Closure | Findings are issued with severity ratings, Critical / High / Medium / Low / Informational, referenced to ASVS Level 3 controls, OWASP Top 10 categories, CWE codes, and where applicable, MITRE ATT&CK techniques. One round of re-verification of corrective actions is included; additional rounds are billed separately. |
Independent Certification Decision | The same procedural rigour as Level 1 and Level 2 applies. The certification decision is taken by an independent decision-maker, separate from the evaluation team, in line with ISO/IEC 17065 Clause 7.6. |
This activity set produces the deepest documented body of application security evidence available under our scheme. It is engineered for products in high-stakes contexts where the buyer’s procurement, the regulator’s mandate, or the product’s own threat profile genuinely requires the depth — not as a procurement-positioning luxury, but as a proportionate response to the actual risk.
Three Modules
How Level 3 Differs by Module
Level 3 is available under each of the three Guardian SecureApp™ Modules — Module A (Web Application Security), Module B (SaaS / Multi-Tenant Platforms), and Module C (API / Microservices Security). The Level 3 evaluation activities described above apply across all three Modules; the Module-specific additions reflect the higher-stakes contexts each Module supports at Level 3.
| Module + Level 3 Combination | Level 3 Specifics |
|---|---|
Module A + Level 3 | OWASP ASVS Level 3 evaluation across the 14 control families, V1 to V14, with adversarial manual testing, comprehensive source code review across the in-scope codebase, threat-modelled architecture review using STRIDE / PASTA, all defined roles plus chained-escalation paths, and exhaustive abuse-case testing. Suitable for net-banking, mobile banking, payment apps, EHR portals, and trading platforms. |
Module B + Level 3 | Module A’s Level 3 evaluation plus adversarial / threat-led testing across all six tenant-aware areas with multi-tenant and chained-attack scenarios, including cross-tenant chained-attack testing under realistic conditions, formal evaluation of customer-managed key BYOK integration including failure modes, comprehensive verification of audit log integrity under operator-action scenarios, and edge-case testing of subscription-lifecycle transitions. Suitable for banking SaaS, healthcare SaaS, identity platforms, and payment platforms. |
Module C + Level 3 | OWASP API Security Top 10, 2023 edition, at full Level 3 depth with adversarial / threat-led testing across all ten categories, multi-role, multi-tenant, and chained-attack scenarios, comprehensive shadow-API and version-history discovery, adversarial automation testing for cost-amplification, API4, and business-flow abuse, API6, plus comprehensive upstream-consumption testing, API10. Suitable for open-banking APIs, payment APIs, embedded-finance rails, and AI inference platforms serving regulated buyers. |
Combined-module engagements at Level 3 are the typical structure for fintech and banking-grade SaaS providers — a single certificate covering Modules A, B and C at Level 3 produces the most comprehensive available attestation. Detailed Module-specific information is at /certification/web-application-security, /certification/saas-security and /certification/api-security.
Evaluation
How a Level 3 Engagement Runs
A Level 3 engagement runs through the same five-stage certification lifecycle as Levels 1 and 2, with Level-3-appropriate evaluation depth at Stage 4. The engagement is materially longer — typically 10–18 weeks — reflecting the comprehensive source code review, formal threat modelling, and adversarial testing activities.
1
Stage 1 — Application
You submit Application Form GSA-F-01 with substantive supporting documentation: product description, architecture diagram, data flow diagrams, formal threat model (recommended), authentication and authorisation design, hosting and integration details, change history, prior assessment evidence, breach history (where applicable), and integration / partner documentation. Level 3 supporting documentation requirements are the most rigorous of the three levels.
2
Stage 2 — Application Review
Guardian reviews the application against ISO/IEC 17065 Clause 7.3 — confirming scope match, resource availability, absence of impartiality conflicts, completeness of documentation. For Level 3, the impartiality screening is particularly rigorous given the stakes — including verification that no evaluator on the team has had consulting involvement with the applicant in the prior two years. Outcome: acceptance, request for clarification, or rejection. Certification Agreement executed on acceptance.
3
Stage 3 — Stage 1 Documentation Review
Comprehensive documentation review against the architecture, threat model, data flow, change history, and any prior incident or assessment evidence. Where a formal threat model has not been provided, Stage 1 includes its construction by Guardian’s evaluators using STRIDE or PASTA methodology — this output is shared with the applicant. Stage 1 outputs include the Documentation Review Report and a refined Stage 2 evaluation plan. For Level 3, this stage is typically 2–3 weeks.
4
Stage 4 — Stage 2 Technical Evaluation
The core technical evaluation, executed at Level 3 depth as described in Section 3.3 above. Comprehensive source code review and adversarial testing are the most time-intensive activities and run in parallel where possible. Findings issued with severity throughout the engagement; re-verification of corrective actions is conducted as findings close. For Level 3, this stage is typically 7–13 weeks (with Module B and combined-module engagements running toward the higher end).
5
Stage 5 — Decision and Certificate Issuance
Evaluation Report submitted to the independent Certification Decision Authority (separate from the evaluation team, per ISO/IEC 17065 Clause 7.6). For Level 3, the Decision Authority review is itself substantively deeper — given the volume of evidence and the stakes — and may include a formal review meeting with the evaluation team. Decision: grant, defer, or refuse. On grant, certificate issued with public directory listing, Mark Usage License, and (at Level 3) a formal handover meeting to ensure the certified client understands the surveillance regime that follows. For Level 3, this stage is typically 1–2 weeks.
Total typical engagement: 10–18 weeks elapsed time, with combined-module Level 3 engagements (A+B+C) typically at the upper end of this range. Largest variable is applicant responsiveness during findings closure and the breadth of the comprehensive source code review scope.
Surveillance
How Level 3 Certification Stays Valid
Level 3 certification is issued for a defined cycle (typically 3 years) and remains valid through the cycle subject to successful semi-annual surveillance, mandatory re-evaluation on major releases, change-driven re-evaluation on other material changes, and absence of material non-conformity. Level 3 surveillance is the most rigorous of the three levels — reflecting the higher stakes the certificate is engineered for and the dynamic nature of the threat environment in regulated and critical-infrastructure contexts.
Semi-Annual Surveillance
Twice per year, Guardian conducts a surveillance audit that re-tests a substantial set of controls against the certified product as it then exists. Level 3 surveillance scope typically includes: re-testing of authentication, session management and authorisation across all defined roles; re-execution of adversarial testing against the most consequential ASVS Level 3 controls; targeted code review of any material code changes during the period; threat-model refresh to incorporate any architectural evolution; and review of any breach incidents or material change-areas notified during the period. Semi-annual cadence reflects the higher rate of change and higher stakes of Level 3 certified products.
Mandatory Re-Evaluation on Major Releases
At Level 3, mandatory re-evaluation on major releases is the default — distinct from Level 2’s targeted re-evaluation and Level 1’s notification-only approach. The Certification Agreement defines what constitutes a ‘major release’ for the certified product (typically: new authentication mechanisms, new authorisation models, architecture changes, significant feature additions affecting security boundary, version-number major increments, or any change the Decision Authority assesses as materially affecting the certified scope). Major releases trigger formal re-evaluation activity outside the surveillance schedule, scoped to the change but executed at Level 3 depth. Re-evaluation cost is billed separately.
Change-Driven Re-Evaluation
Beyond major releases, change-driven re-evaluation also addresses any other material changes — breach incidents, regulatory developments affecting the product, material changes to upstream dependencies (where they affect API10 evaluation), and changes to operational controls of the platform (where they affect Module B evaluation). Notification of such changes is required by the Certification Agreement; the Decision Authority assesses each notified change.
Recertification (End of Cycle)
Before the 3-year cycle expires, recertification is required for continued certification. Level 3 recertification is a comprehensive re-evaluation against the then-current scheme criteria — including any updates to OWASP ASVS, OWASP Top 10, OWASP API Top 10, GSA-PR-01, or other normative documents adopted by Guardian since initial certification. Recertification at Level 3 is typically scoped at roughly the depth of the original Level 3 evaluation, with credit given for unchanged areas. For products that have evolved materially during the cycle (which is common at Level 3, given the typical product velocity in this segment), recertification engagement scope reflects the changed surface.
Suspension and Withdrawal
Where a certified client fails to comply with scheme requirements — fails surveillance, breaches the Certification Agreement, fails to address corrective actions arising from change-driven re-evaluation, fails to notify of material changes, misuses the certification mark — Guardian may suspend or withdraw the certificate. At Level 3, given the stakes and the visibility of the certified products, suspension is the most consequential of the three levels: a suspended Level 3 certificate is publicly visible in the directory as suspended, and the suspension is itself a procurement signal to the certified product’s buyer base. All such actions are subject to appeal under the Complaints and Appeals procedure at /complaints-appeals.
Timeline and Pricing
How Long, How Much
Below are indicative timeline and pricing figures for typical Level 3 engagements. The figures apply when the engagement is scoped to a single, low-complexity product on a single technology stack in a single environment, under a single Guardian SecureApp™ Module. Level 3 engagements at the higher end of complexity — combined modules, multi-environment, large in-scope codebases, complex architectures — are typically materially above the indicative starting fee, and pricing is quoted on request.
Module A + Level 3
$7,000
onwards
10–16 weeks
Annual + change-driven
Module B + Level 3
$7,000
onwards
12–18 weeks
Annual + change-driven
Module C + Level 3
$7,000
onwards
11–16 weeks
Annual + change-driven
*Indicative starting fees in USD, exclusive of applicable taxes (e.g., GST in India), and payable for the work performed regardless of certification outcome. Annual surveillance fees are billed semi-annually in advance. Change-driven and mandatory-major-release re-evaluation fees are billed separately, scoped to the specific change. Recertification fees billed at the start of the recertification engagement. Travel and out-of-pocket expenses for any required on-site activities billed at actuals with prior approval. Fees do not influence the certification decision (ISO/IEC 17065 Clause 4.2 — impartiality requirement).
Combined-module Level 3 engagements (typical for banking-grade SaaS providers and embedded-finance platforms) are quoted on request. Module B + C combined at Level 3 typically runs 14–20 weeks; Modules A + B + C combined at Level 3 typically runs 16–24 weeks. Full fee structure, basis of fees, and surveillance fee policy at /process/fees. Quotations on request at /quote.
Choice
When Level 3 Is Disproportionate
Level 3 is engineered for a specific product profile: high-stakes contexts where the breach consequence is systemic, the threat profile includes sophisticated adversaries, and the buyer’s procurement specifically requires the deepest available depth. Outside that profile, Level 3 is disproportionate — overkill in evaluation depth and cost, with no proportionate increase in assurance value over Level 2. We say this explicitly because over-applying Level 3 is a real error pattern, particularly when buyers conflate ‘highest assurance’ with ‘always best’.
Below are situations where Level 3 is the wrong choice and Level 2 (or Level 1) is the proportionate decision.
- Your product is internal-only, low-criticality, and does not handle financial transactions, regulated data classes, or critical-infrastructure controls. Level 1 or Level 2 is proportionate; Level 3 is wasted depth.
- Your product is customer-facing and handles PII or transactions, but operates in non-regulated buyer ecosystems where customer due diligence is satisfied by Level 2 evidence. Level 2 is proportionate; Level 3 is procurement-positioning luxury rather than assurance necessity.
- Your product is in early-stage commercial deployment with limited scale and revenue. The Level 3 cost-benefit ratio is unfavourable at this stage; Level 2 (or Level 1) is the proportionate starting point, with upgrade as the product matures.
- Your codebase is large and rapidly-evolving, and you would struggle to maintain the documentary discipline that Level 3 requires (formal threat model, change notification rigour, semi-annual surveillance plus mandatory re-evaluation on major releases). Level 2’s annual + change-driven cadence may be more sustainable.
- Your customers do not specifically ask for Level 3-equivalent depth. If your buyer base is satisfied with Level 2 evidence, Level 3 produces no marginal procurement value.
- Your product surface is genuinely simple — limited authentication paths, limited data classes, limited integrations. Level 3’s adversarial methodology and comprehensive code review have diminishing returns where the attack surface is small to begin with.
The error pattern we see most often: ‘we want the highest available level for marketing reasons’. The error is misunderstanding what the certificate signals — a Level 3 certificate on a low-risk product signals over-investment, not security maturity, to mature buyers. Level selection should reflect actual risk profile and actual buyer expectation. Where Level 3 fits, it fits powerfully. Where it does not, Level 2 is more honest and more proportionate.
Upgrade Path
When Your Risk Profile Continues to Evolve
Level 3 is the deepest evaluation depth Guardian SecureApp™ offers. There is no Level 4. For products whose risk profile or buyer expectation continues to evolve beyond a baseline Level 3 engagement, the path forward is depth/scope expansion within Level 3 — not escalation to a higher level. The mechanics of that expansion are as follows.
Scope Expansion at Level 3
The most common path is widening the scope covered by a Level 3 certificate: adding modules (Module C added to a Module A + B Level 3 certificate as an API surface launches); adding environments (production + DR site, where DR was previously out of scope); adding partner-facing integrations or new tenant-isolation strategies. Scope expansion is scoped to the additional surface and evaluated at Level 3 depth; the existing certificate’s evaluation work is retained where it covers the existing scope. A revised certificate is issued reflecting the expanded scope, retaining the original certification cycle’s expiry date.
Evaluation Frequency Customisation
For products where the standard Level 3 surveillance cadence (semi-annual + mandatory major-release re-evaluation) is insufficient — typically due to regulatory expectation or buyer agreement — Guardian can agree custom surveillance arrangements: quarterly surveillance, more granular change-driven thresholds, formal post-incident re-evaluation triggers, or surveillance activities tied to specific regulatory reporting cycles. Custom surveillance is documented in the Certification Agreement and is priced based on the additional evaluation man-days required.
Combined Modules and Cross-Product Certification
Where a Level 3 certified client operates multiple products, certifying additional products at Level 3 is straightforward — each product is a separate certificate with its own scope. Where the products share infrastructure (multi-tenant architectures, shared identity systems, shared API surfaces), evaluation efficiencies can be captured at scoping by combining modules across products where the boundary supports it. Combined cross-product Level 3 certification is uncommon (each product is typically evaluated separately) but supported.
Post-Level-3 Buyer Expectations
Buyers whose due diligence asks for evidence beyond what Guardian SecureApp™ Level 3 produces — formal SOC 2 Type 2 reports, ISO/IEC 27001 organisational certification, sector-specific empanelment (CERT-In in India, FedRAMP in the United States, equivalent regimes elsewhere), or regulator-licensed evaluation regimes — are asking for complementary attestations rather than ‘higher-level’ certification. Level 3 typically combines with these, not substitutes for them. Mature regulated entities often hold Level 3 + ISO 27001 + SOC 2 + sector-specific empanelment as a complementary stack.
On the absence of Level 4: We could, in principle, define a ‘Level 4’ with even deeper evaluation activities. We have chosen not to, because the marginal assurance value of activities beyond Level 3 is not, in our scoping experience, proportionate to the additional cost — and because the audiences that would consume a Level 4 attestation are typically asking for complementary instruments (sector-specific licensure, regulator-led evaluations) rather than for incremental scheme depth. Level 3 is the deepest depth we offer, and is engineered to be the genuine ceiling of what the OWASP-anchored, ISO/IEC 17065-accredited scheme model produces.
Frequently Asked Questions
Common Questions, Answered
No. No certification level is a guarantee against future compromise — Level 3 included. Security is dynamic: code changes, dependencies update, new attacks emerge, threat actors evolve. A Level 3 certificate confirms criteria-met-at-evaluation, not future impregnability. What Level 3 does provide is the highest available assurance signal under our scheme — comprehensive source code review, formal threat-modelled architecture review, adversarial / threat-led testing — combined with semi-annual surveillance plus mandatory re-evaluation on major releases. Mature security buyers understand this distinction; they interpret Level 3 as deepest-available evidence, not as guarantee.
Comprehensive source code review at Level 3 means review of the in-scope codebase rather than sample-based review of critical components (which is Level 2). The selection rationale, the depth applied per area, and the findings are documented in the Evaluation Report. Comprehensive review materially differs from Level 2’s sample-based approach — it provides documented evidence of the entire codebase being subject to security-focused inspection at Level 3 depth, not just the components most likely to harbour critical findings.
Indicative starting fee is USD 7,000 onwards for small organisations certifying a single, low-complexity product on a single technology stack in a single environment, under a single Module. Most Level 3 engagements are materially above the indicative starting fee — combined modules, larger codebases, and more complex architectures are the norm in this segment. Combined Module B + C engagements typically run from USD 12,000 onwards; combined A + B + C engagements typically from USD 18,000 onwards. Final fees depend on scope, codebase size, and architecture complexity. Quotations on request at /quote.
Typical Level 3 engagement: 10–18 weeks elapsed time. Module A and Module C engagements typically run 10–16 weeks; Module B engagements 12–18 weeks; combined Module B + C engagements 14–20 weeks; combined Module A + B + C engagements 16–24 weeks. Largest variables are applicant responsiveness during findings closure and the breadth of the comprehensive source code review scope.
Threat-led testing means the evaluation team approaches the product as a sophisticated adversary would: with knowledge of the architecture, with patience to chain findings together, with attention to abuse cases and unusual sequences, and with understanding of which controls would be most consequential to bypass. This contrasts with scenario-based testing (Level 1) and comprehensive ASVS Level 2 testing (Level 2) — both of which test against expected threat patterns. Adversarial testing tests against unexpected ones, executed with the mindset of a determined attacker.
No. Level 3 is the deepest evaluation depth Guardian SecureApp™ offers. The path forward from Level 3 — for products whose risk profile or buyer expectation continues to evolve — is depth/scope expansion within Level 3 (additional modules, additional environments, custom surveillance frequency) or complementary attestations (SOC 2 Type 2, ISO/IEC 27001, sector-specific empanelment) rather than escalation to a higher level. We could in principle define a Level 4, but the marginal assurance value of activities beyond Level 3 is not proportionate to additional cost in our scoping experience.
Surveillance reports issued under Level 3 are confidential to Guardian and the certified client, but the certificate itself, the Public Scope Statement, and the directory listing are public — and the surveillance status (active, suspended, withdrawn) is reflected in the directory in real time. Some regulators accept this public verifiability; others require regulator-specific reporting that Level 3 surveillance does not directly produce. Discuss your regulatory reporting requirements at scoping; Guardian can structure surveillance to align with regulatory cycles where appropriate, but cannot substitute for regulator-specific licensure or empanelment.
Yes. Threat-modelled architecture review using STRIDE or PASTA methodology is mandatory at Level 3 — distinct from Level 2’s detailed architecture review with data flow analysis (which is structured but not formally threat-modelled). Where the applicant has produced a formal threat model, Guardian’s review uses it as input. Where one has not been produced, Stage 1 includes its construction by Guardian’s evaluators, with the output shared with the applicant. The threat model is a deliverable of the engagement and accompanies the Evaluation Report.
Most Level 3 engagements are conducted remotely under IAF MD 4:2025. Some engagements may benefit from limited on-site presence — typically for observation of operator workflows in a controlled environment (Module B), or for source code review where the applicant’s security policy precludes remote source access. The decision is risk-based and is made at scoping. On-site activity costs (travel, accommodation) are billed at actuals with prior approval and are exclusive of the engagement fee.
Critical findings must be addressed for certification to be granted. Guardian issues the finding with technical detail and the relevant ASVS Level 3 / OWASP Top 10 / OWASP API Top 10 / GSA-PR-01 reference. Remediation is the applicant’s responsibility — Guardian does not provide consulting or fix-support. Guardian re-verifies corrective actions; one round of re-verification is included, additional rounds billed separately. If the product cannot meet the criteria at Level 3, the certification is not issued — fees for work performed are payable per the Certification Agreement, and there is no record of the failed application in the public directory. The applicant may, in some cases, accept certification at Level 2 in lieu — subject to scoping that the Level 2 criteria are met.
Level 3 produces interpretable, accredited evidence that some regulators consider in their supervisory work — but it does not substitute for regulator-led licensure, empanelment, or supervisory inspection. Whether Level 3 reduces specific regulatory scrutiny depends entirely on the regulator’s framework. We do not make claims that Level 3 produces regulatory relief; we do produce evidence that regulators find more interpretable than self-declarations or private VAPT reports. Discuss your specific regulatory drivers at scoping.
Yes, though it is uncommon. A product may shift to a lower-stakes context (a regulated product moved into an internal-only deployment, for example) where Level 3 is no longer cost-justified. Downgrade is mechanically simple at the certification level — a new Level 2 certificate is issued, the prior Level 3 history retained for audit-trail purposes — but should be considered carefully because the public directory shows the level change, which is itself a signal to your buyer base.
Some will. Mature regulated entities — particularly in banking, payments, healthcare and critical infrastructure — often request a complementary stack: Level 3 + ISO/IEC 27001 + SOC 2 Type 2 + sector-specific empanelment (CERT-In in India, FedRAMP in the United States, equivalent regimes elsewhere). These are complementary attestations, not higher-level certification. Level 3 is engineered to fit into that complementary stack, not to substitute for it.
Level 3 produces an accredited third-party certificate against OWASP ASVS Level 3, OWASP Top 10, and (for Module C) OWASP API Security Top 10 — at the deepest depth available under our scheme. Specific regulatory acceptability for any specific Indian regulator depends on the regulator’s mandate and any empanelment requirements (CERT-In empanelment is a separate accreditation under the Government of India). We are happy to discuss your specific regulatory driver at scoping; in regulated procurement processes, Level 3 typically serves as evidence alongside regulator-specific requirements rather than as a substitute for them.
Guardian’s evaluator pool covers JavaScript / TypeScript, Python, PHP, Ruby, Java, C# / .NET, Go, Rust, Elixir and others — at all three levels. Level 3 comprehensive source code review is technology-stack agnostic; what affects pricing and timeline is codebase size and complexity rather than language choice. Where the applicant uses a less common stack, scoping may include verification of evaluator availability with the appropriate competency.
Yes — every Guardian SecureApp™ certificate, at any level, is publicly listed in the directory at /directory, searchable by certificate number, product name or applicant name. Level 3 certificates are not separately segregated; they are listed alongside Level 1 and Level 2 certificates with the level visible on each entry. Public listing is required by ISO/IEC 17065 Clause 4.6 and is part of what makes the certificate procurement-grade.
Ready to Get Started?
Apply for Certification
Submit a formal application. Initial response within 5 working days.
Apply NowRequest a Quote
Tell us about your product. Indicative quote within 3 to 5 working days.
Get a QuoteTalk to Our Team
Specific question or regulatory driver to discuss?
Contact Us