GUARDIAN SECUREAPP™ · APPLICATION PROCESS
How to Apply for Guardian SecureApp™ Certification
Applying for Guardian SecureApp™ certification is a structured six-stage process from initial enquiry to engagement kickoff. This page walks you through every step — what to gather, what to expect at each stage, what decisions Guardian makes when, and what your obligations and rights are throughout. Applications can be initiated for Module A (Web Application Security), Module B (SaaS / Multi-Tenant Platforms) or Module C (API / Microservices Security), at Level 1 (Basic), Level 2 (Advanced) or Level 3 (High-Risk / Critical) — under our ISO/IEC 17065 accreditation by UAF (52605385601, valid until 05 May 2030).
Eligibility and Fit
Confirming Certification Is the Right Path for You
Before initiating an application, it is worth confirming that Guardian SecureApp™ certification is the appropriate next step for your product and your context. Certification is a substantive commitment of time, money and engineering attention; it produces correspondingly substantive procurement-grade evidence — but only when applied to products where the procurement-grade signal is genuinely required. The eligibility and fit discussion typically covers four areas.
Product Type and Module Fit
Guardian SecureApp™ certifies software products in three specific module types: web applications (Module A), SaaS / multi-tenant platforms (Module B), and APIs / microservices (Module C). Combined-module engagements (typically B + C for SaaS providers exposing both customer UIs and partner APIs, or A + C for web applications with public APIs) are common. Products outside these module types — desktop applications, native mobile applications without significant API surfaces, embedded firmware, IoT devices — are not within Guardian SecureApp™’s current scope of accreditation. If your product does not fit one of the three modules, scoping conversation will identify this clearly and suggest alternative paths.
Level Selection Appropriateness
Choosing the right Level (1 Basic / 2 Advanced / 3 High-Risk Critical) before applying is important because the Level chosen materially affects scope, timeline and fees. The Levels Hub at /levels provides a five-question decision framework that helps establish the proportionate Level for your product. The most common error pattern is Level over-application — selecting Level 3 when Level 2 is genuinely proportionate, typically for marketing-positioning reasons rather than risk-profile reasons. Mature buyers do not interpret Level 3 as universally better; they interpret over-applied Level 3 as evidence of over-investment. Scoping conversation maps your specifics if you are uncertain.
Procurement Driver Clarity
Certification is most valuable when there is a clear procurement driver — a regulator asking for it, a customer’s vendor security questionnaire requiring it, a competitive context where peer products carry it, an enterprise deal blocked on its absence. Where there is no clear driver, certification can still be valuable — for engineering discipline, for product-quality signalling, for future readiness — but the urgency and the Level selection conversation are different. Knowing your driver before applying makes the scoping conversation substantially more productive.
Resource Readiness
Certification engagements require the certified client’s active participation: providing documentation, responding to evaluator questions during testing, addressing findings in defined windows, attending scoping and decision meetings. The level of engagement scales with the chosen Level (Level 3 engagements involve more substantive applicant-side time than Level 1). Confirming that your engineering, security, and compliance teams have the capacity to engage during the engagement window — and that the right people are identified to be points of contact — is worth doing before you apply. Engagements that stall on applicant unresponsiveness produce delays and, in some cases, fees for re-engagement effort.
Initial enquiry costs nothing: An initial enquiry / scoping conversation with Guardian carries no cost or commitment. It is the lightest first step — a 30-to-60-minute conversation in which we discuss your product, your driver, your timeline, and which Module + Level configuration fits. There is no obligation to proceed after this conversation. Many prospective applicants use it to refine their understanding of certification before deciding whether and when to apply.
Who Publishes ISO/IEC 17065
The Documentation Checklist
The application form GSA-F-01 (described in Section 3.3 below) requires certain supporting documentation as input. Gathering this material before you start the application form is substantially more efficient than gathering it during. The list below covers the documentation Guardian typically requests; not every item is mandatory at every Level, and scoping conversation will confirm what specifically applies to your engagement.
| Document | When Required | What It Is |
|---|---|---|
Product Description | All Levels | A 1-2 page narrative describing what the product does, who uses it, what data it handles, and the business context. Plain language. Engineering jargon is optional but not required. |
Architecture Diagram | All Levels | A current diagram showing the major components of the product: frontends, backends, databases, third-party services, and authentication providers. Need not be at any particular level of detail; clarity matters more than completeness. |
Data Flow Diagram | Levels 2 and 3 | A diagram showing how data moves through the system, from user input through processing, storage, and any external transmission. Identifies trust boundaries and sensitive-data paths. |
Authentication / Authorisation Summary | All Levels | A 1-page summary of how users authenticate, what roles exist, and how authorisation is enforced. The detail required scales with the selected level. |
Hosting and Integration Details | All Levels | Where the product runs, including cloud provider and region, what integrations are present, such as payment gateways, identity providers, and partner APIs, and what third-party services it depends on. |
Threat Model | Recommended L2; mandatory L3 | A documented threat model identifying assets, threats, mitigations and residual risk. STRIDE or PASTA-based threat models are common formats. At Level 3, it is mandatory; if not provided, Stage 1 includes its construction by Guardian. |
Prior Assessment Evidence | Optional, recommended | Any prior internal or third-party security assessments, penetration tests, code reviews, or audits, particularly recent ones. Helpful as input to scoping and reduces redundant effort. |
Change History (Recent) | L3 only | Summary of major changes to the product in the previous 12 months, including feature additions, architecture modifications, security incidents, and dependency updates of consequence. |
Breach / Incident History | L3 only, where applicable | Disclosure of any material security incidents affecting the product in the previous 24 months, including remediation actions taken. Affects scoping but not eligibility. |
Compliance Context | Optional, recommended | If the product operates under specific regulatory frameworks such as banking, healthcare or payments, or holds related certifications such as ISO/IEC 27001 or SOC 2 Type 2, this context informs scoping. Not a Guardian requirement, but a useful applicant-side input. |
None of this material is graded. Guardian uses it to understand the product enough to scope the engagement accurately, to identify any clarifying questions, and to staff the right evaluator competencies. We do not assess the material itself for quality — it is input to scoping, not part of the certification evaluation. Scoping is what produces the formal application; the application is what produces the formal evaluation.
The Eight Clauses of ISO/IEC 17065
What the Application Form Captures
The Guardian SecureApp™ Application Form is identified as GSA-F-01 in the scheme document. It is the formal record of an application — the structured input on which Guardian’s application review (per ISO/IEC 17065 Clause 7.3) is conducted. The form is provided through the website at /apply or through your scoping contact. It captures information across six sections.
Section 1 — Applicant Information
Legal name, registered address, jurisdiction of incorporation, principal contact for the application, billing contact (if different), and the regulatory or commercial registration identifiers appropriate to the applicant’s jurisdiction (CIN in India, EIN in the United States, equivalent identifiers elsewhere). Where the certified product is operated by a different legal entity from the applicant (a subsidiary, a contracted operator), this is captured here.
Section 2 — Product Identification
The name(s) under which the product is offered, the version or release that the applicant proposes for evaluation, the URL(s) at which the product is reachable (where applicable), and a clear statement of what is in scope and what is explicitly out of scope. For multi-product applicants, each certification application is a distinct GSA-F-01 — one product per form.
Section 3 — Module and Level Selection
The Module(s) for which certification is sought (A, B, C, or combinations) and the Level (1, 2, or 3). This is the formal record of the level-selection decision; if scoping conversation has concluded that a different Module / Level fits better than what the applicant initially specified, this is reconciled here before form submission.
Section 4 — Supporting Documentation
Either uploaded as attachments to the form or referenced as separately-shared documents (where size or sensitivity requires it). The supporting documentation requirements are those described in Section 3.2 above. Guardian’s scoping contact confirms which specific documents are required for the chosen Module + Level combination.
Section 5 — Impartiality Declaration
The applicant declares any prior or current relationship with Guardian or with Guardian’s evaluators that might raise impartiality concerns. This includes consulting engagements, employment relationships, financial interests, or other connections that could compromise — or appear to compromise — Guardian’s independence. The declaration is reviewed against Guardian’s impartiality policy (per ISO/IEC 17065 Clause 4.2). Most applications have no impartiality issues to declare; where they do, the declaration triggers Guardian’s impartiality review process before application acceptance.
Section 6 — Acknowledgements
The applicant acknowledges that submission of GSA-F-01 is a non-binding application until a Certification Agreement is executed (see Section 3.6 below); that fees for any chargeable activities will be quoted before commencement; that Guardian’s certification decision is independent of fees paid (Cl. 4.2); that information shared during application is subject to Guardian’s Confidentiality Policy; and that the applicant has authority to make the application on behalf of the legal entity named in Section 1.
Submission of the completed form does not commit the applicant to anything beyond the application review itself. Specifically, applicants may withdraw their application at any time before signing the Certification Agreement, with no fees payable other than any pre-agreed scoping or quotation fees. This non-binding nature is important applicant protection and is restated in the Certification Agreement itself.
Application Process
From Initial Enquiry to Engagement Kickoff
The application process — from initial enquiry through engagement kickoff — runs through six stages. The full elapsed time is typically 2–4 weeks for Level 1, 3–5 weeks for Level 2, and 4–6 weeks for Level 3, depending substantially on applicant responsiveness during the documentation and clarification phases. Each stage is described below.
Stage 1
Initial Enquiry
Prospective applicant contacts Guardian via /quote, /contact, or directly. A scoping contact is assigned. A 30-to-60-minute scoping conversation is scheduled within 3–5 business days. No cost or commitment.
Stage 2
Scoping
Scoping conversation establishes Module + Level fit, identifies the in-scope product surface, names the supporting documentation requirements, and produces an Indicative Quote. Quote covers fees for the certification engagement (not application review, which is no-charge). Typically 1–5 business days from initial enquiry to indicative quote.
Stage 3
Application Submission
Applicant submits GSA-F-01 with supporting documentation. Submission can occur immediately after scoping (typical) or weeks later (where the applicant requires internal approvals before formally applying). Submission is confirmed by Guardian within 2 business days.
Stage 4
Application Review
Guardian’s application review against ISO/IEC 17065 Cl. 7.3. Confirms scope match, resource availability, completeness of documentation, and impartiality clearance. Outcome (Section 3.5 below) is one of three: acceptance, request for clarification, or rejection. Typically 5–10 business days for Level 1; 7–14 business days for Level 2 and 3.
Stage 5
Certification Agreement
Where application is accepted, the Certification Agreement is issued for execution. Applicant has typically 10–15 business days to review, negotiate clarifications (limited scope of negotiation given the standardised nature of the agreement), and execute. Engagement is not started until the agreement is executed.
Stage 6
Engagement Kickoff
6 Engagement Kickoff Kickoff meeting with the applicant’s identified points of contact and Guardian’s evaluation team. Confirms the engagement plan, timelines for Stage 1 documentation review and Stage 2 technical evaluation, escalation contacts on both sides, and any logistics specific to the engagement. Stage 1 of the certification engagement begins immediately after kickoff.
The largest variable in elapsed time across these six stages is applicant-side: how quickly the documentation is gathered, how quickly the GSA-F-01 is formally submitted after scoping, how quickly the Certification Agreement is reviewed and executed. Where applicant decision-making on these is rapid, the entire six-stage cycle from initial enquiry to engagement kickoff can complete in 2–3 weeks; where it is slower, 6–8 weeks is not unusual.
Outcomes
What Happens After You Submit
Guardian’s application review under ISO/IEC 17065 Clause 7.3 produces one of three outcomes. The outcome — and the rationale for it — is communicated formally to the applicant in writing, typically within the timelines stated in Section 3.4 above. Each outcome is described below.
Outcome 1 — Acceptance
Most applications result in acceptance. Acceptance means Guardian has confirmed: that the proposed scope falls within Guardian’s accreditation scope; that Guardian has the evaluator competencies and capacity to conduct the engagement on the proposed timeline; that the supporting documentation is sufficient to support an evaluation engagement; and that no impartiality conflicts preclude Guardian from accepting the application. On acceptance, Guardian issues the Certification Agreement (Section 3.6 below) for the applicant’s execution. The engagement begins after the Agreement is executed.
Outcome 2 — Request for Clarification
Where the application is fundamentally sound but specific points require clarification or augmentation, Guardian issues a Request for Clarification rather than an acceptance or rejection. Common clarification triggers include: documentation that is internally inconsistent (architecture diagram does not match data flow narrative); scope statement that is ambiguous about what is in or out; supporting evidence that references items not provided; impartiality declaration that needs further explanation. Requests for Clarification are typically resolved through a brief follow-up exchange — a clarifying call, a revised document, an additional declaration. Once resolved, the application is re-reviewed and proceeds (typically) to acceptance.
Outcome 3 — Rejection
A small minority of applications are rejected. Common rejection grounds include: proposed scope that falls outside Guardian’s accreditation scope (a product type Guardian is not accredited to certify); resource constraints on Guardian’s side that mean the engagement timeline cannot be supported; impartiality conflicts that cannot be managed (e.g., a previous consulting engagement on the same product within the impartiality look-back window); or supporting documentation that is fundamentally insufficient for application review (rather than merely incomplete). Rejection is communicated formally with the rationale; where the rejection grounds are addressable (Guardian’s scope expansion in future, applicant providing additional documentation), the applicant may reapply. Rejection is not a comment on the product’s security posture — application review is procedural; product evaluation has not yet started at this stage.
Application review is not graded: It is worth saying explicitly that application review is procedural — not technical. The application review does not assess whether the product is secure; it only confirms that the engagement can be conducted procedurally. Acceptance does not pre-judge the certification outcome; the certification decision is taken much later, by an independent decision-maker, based on the evaluation evidence (per ISO/IEC 17065 Cl. 7.6).
Agreement
What You Sign and What It Says
The Certification Agreement is the legally binding document between Guardian (as certification body) and the applicant (as certified client). It is the formal commitment to proceed with the engagement; it is also the document that defines the rights and obligations of both parties throughout the certification cycle. Its principal contents are summarised below.
Scope and Standards
Names the certified product, the Module(s), the Level, the version under evaluation, the OWASP standards (and version) the evaluation is against, and the version of GSA-PR-01 (Guardian’s scheme document) that governs the engagement. The Public Scope Statement that will eventually accompany the certificate is derived from this scope clause.
Fees and Payment Terms
Names the engagement fee (per the Indicative Quote, refined by application review), the surveillance fees (typically annual or semi-annual depending on Level), payment milestones, and any expense reimbursement arrangements. Includes the locked impartiality disclosure: fees are payable for work performed regardless of certification outcome; fees do not influence the certification decision (ISO/IEC 17065 Clause 4.2).
Applicant Obligations
The applicant’s obligations during and after the engagement: providing access to the product and supporting materials; making relevant personnel available for evaluation activities and decision meetings; addressing findings within defined windows; notifying Guardian of material changes during the certification cycle (per the Level-appropriate change notification requirements); using the certification mark only as authorised; not making certification-related claims that misrepresent scope or status.
Guardian Obligations
Guardian’s obligations: conducting the evaluation per the documented methodology; protecting confidential information per Guardian’s Confidentiality Policy; making certification decisions independently per Cl. 7.6; conducting surveillance per the Level-appropriate cadence; maintaining the public directory; making the Complaints and Appeals procedure accessible to the applicant; notifying the applicant of any changes to scheme criteria during the cycle.
Suspension, Withdrawal, Termination
The grounds and procedure for Guardian to suspend or withdraw certification (failure of surveillance, breach of agreement, mark misuse, fee non-payment, material undisclosed change). The grounds and procedure for the applicant to terminate the agreement (typically with notice, settlement of fees for work performed, and surrender of the certificate). Notice periods, escalation, and dispute-resolution mechanics.
Confidentiality
Mutual confidentiality obligations covering information shared during the engagement. Guardian’s specific confidentiality commitments — that source code, architecture details and finding details are not disclosed externally except as required by accreditation oversight (limited disclosure to UAF during accreditation surveillance) or applicable law. Applicant’s confidentiality of any materials Guardian shares during the engagement.
Term and Renewal
The certification cycle (typically 3 years) and the recertification mechanics. The conditions under which the agreement renews automatically (typically through executed recertification engagement) versus terminates (where recertification is not pursued). The handling of certificate expiry, archival, and continued public-directory presence (with status appropriately marked).
The Certification Agreement is standardised — Guardian uses the same agreement template for all clients, with the variable elements (scope, fees, dates, contact details) populated per engagement. This standardisation is itself an impartiality safeguard: terms are not negotiated case-by-case in ways that might create commercial pressure on the certification decision. Limited negotiation of specific clauses is supported (jurisdictional clauses for clients in non-Indian jurisdictions, for example), but the substantive structure does not vary.
Pricing
Costs Associated with Applying
Below is a summary of fees specifically associated with the application process — distinct from the engagement fees that apply once the Certification Agreement is executed. Most application-stage activities are no-charge; engagement fees begin only after the Certification Agreement is executed.
| Activity | Charge | Notes |
|---|---|---|
Initial Enquiry / Scoping Conversation | No charge | 30-to-60-minute conversation; no commitment. |
Indicative Quote | No charge | Provided after scoping conversation. Valid for 60 days. |
Application Form GSA-F-01 Submission | No charge | Submission is non-binding until Certification Agreement is executed. |
Application Review (Cl. 7.3) | No charge | Applies to all applications, regardless of outcome: acceptance, clarification, or rejection. |
Certification Agreement Issuance | No charge | Where application is accepted; agreement is issued for execution at no cost. |
Engagement Kickoff | Engagement fee applies | Engagement fees per the Certification Agreement begin once execution is complete. |
Locked disclosure: Fees do not influence the certification decision (ISO/IEC 17065 Clause 4.2 — impartiality requirement). Engagement fees are payable for the work performed regardless of certification outcome.
Engagement fees themselves — payable once the Certification Agreement is executed — start from the indicative figures published across the website: USD 2,000 onwards for Level 1, USD 4,000 onwards for Level 2, and USD 7,000 onwards for Level 3 (single-Module engagement, small organisation, single environment, single technology stack). Combined-module engagements and larger / more complex products are quoted on request. Full fee structure is at /process/fees.
Frequently Asked Questions
Common Questions Before Applying
Below are short, in-body answers to the questions prospective applicants ask most often during the application process. The full FAQ block covers a wider set of questions in greater depth.
Yes. Scoping conversation is part of the application process precisely because most applicants benefit from working through scope with Guardian rather than fully deciding it themselves first. What you should bring to the initial enquiry is a clear sense of the product, the driver, and the broad Module + Level direction; scoping refines this into the formal scope that goes onto the GSA-F-01.
No — one product per GSA-F-01. Where you have multiple products to certify, each is a distinct application. Where products share infrastructure (multi-tenant SaaS platforms, shared API estates), scoping conversation may identify efficiencies in evaluation that combined-module engagements can capture, but each certificate covers one product.
Your product is certified against the Guardian SecureApp™ scheme — anchored in OWASP ASVS (Modules A and B) or OWASP API Security Top 10 (Module C), at the chosen Level (1 Basic / 2 Advanced / 3 High-Risk Critical). Guardian, the certification body, is accredited under ISO/IEC 17065 by UAF — accreditation 52605385601. The chain reads: ‘Your product is certified by Guardian, against the Guardian SecureApp™ scheme; Guardian is ISO/IEC 17065-accredited by UAF.’ Saying a product is ‘17065-certified’ is technically incorrect — products are certified against schemes; certification bodies are accredited against 17065.
Rejection is communicated formally with the rationale. Where the rejection grounds are addressable, you may reapply once the addressing has been done — typically there is no waiting period imposed. Rejection is not recorded in the public directory (which only lists active certificates), and your application activity is confidential. Rejection is procedural, not a comment on the product’s security.
Submit a written withdrawal notice to your scoping contact at any time before signing the Certification Agreement. There is no withdrawal fee; any withdrawn application carries no record in the public directory. After Certification Agreement execution, withdrawal becomes termination — a different, contractually-defined process with potential fees for work performed up to the termination point.
Outcomes
Other Useful Steps Before Applying
Some prospective applicants reach the application page and conclude that they are not yet ready to formally apply — and that conclusion is sometimes correct. Below are useful steps that are typically appropriate before formal application, depending on the gap that delays readiness.
If You Are Uncertain About Module / Level Selection
Use the five-question decision framework on the Levels Hub at /levels. Then use the Module fit guidance on the Pillar at /certification/secureapp. If after those references you remain uncertain, an initial enquiry with Guardian (no charge, no commitment) is the next step — scoping conversation typically resolves uncertainty within a single discussion.
If Your Documentation Is Not Ready
Review the documentation checklist in Section 3.2 above. The most common gaps are: data flow diagrams (often not maintained as engineering artefacts; many teams have them only as verbal architecture), threat models (similarly), and current architecture diagrams (often out of date). Producing these before applying makes the engagement smoother. Guardian does not provide guidance on how to produce them (that would compromise our impartiality), but engineering teams typically know how — what is missing is usually time, not knowledge.
If You Want a Trial Run Before Certification
Consider a non-certification VAPT engagement — Guardian provides technical penetration testing as a stand-alone service (/services/vapt), separate from the certification scheme. VAPT is a private technical assessment without a certificate; many applicants use a VAPT engagement to identify and address security findings before applying for certification, reducing the risk of finding gaps during the certification engagement.
If You Need Internal Buy-In Before Applying
Compliance and procurement-driven certification often requires internal alignment — engineering buying into the timeline, finance approving the budget, legal reviewing the Certification Agreement template. The Indicative Quote (no-cost, valid 60 days) is engineered specifically to support this internal alignment phase: it is a binding-on-Guardian quote that you can use to drive internal approvals, with no commitment on your side until you formally submit GSA-F-01 and execute the Certification Agreement.
In all four cases, the application page itself is the right reference even if you are not yet ready to apply formally. When readiness comes, the next step is the same — initial enquiry, then scoping, then GSA-F-01.
Frequently Asked Questions
Common ISO/IEC 17065 Questions, Answered
Submission of GSA-F-01 (the application form) is non-binding. You may withdraw your application at any time before executing the Certification Agreement, with no fees payable. Binding obligation begins only when the Certification Agreement is signed by both parties. This non-binding nature is important applicant protection and is restated in the Certification Agreement itself.
The initial enquiry, scoping conversation, indicative quote, application form submission, application review, and Certification Agreement issuance are all no-charge. Engagement fees apply only after the Certification Agreement is executed. Indicative engagement fees start from USD 2,000 (Level 1), USD 4,000 (Level 2), USD 7,000 (Level 3) onwards. Final fees per the Certification Agreement, which reflects the Indicative Quote provided after scoping.
Required for all Levels: product description, architecture diagram, authentication / authorisation summary, hosting and integration details. Required for Levels 2 and 3: data flow diagram, threat model (recommended L2; mandatory L3). Optional but recommended: prior assessment evidence, change history, breach / incident history (where applicable), compliance context. Section 3.2 above has the complete checklist.
Typically 2–4 weeks for Level 1, 3–5 weeks for Level 2, and 4–6 weeks for Level 3 — depending substantially on applicant responsiveness during documentation gathering, GSA-F-01 submission, and Certification Agreement execution. Where applicant decisions are rapid, the 2–3 week range is achievable; where slower, 6–8 weeks is not unusual.
GSA-F-01 is the Guardian SecureApp™ Application Form — the formal record of a certification application. It captures applicant information, product identification, Module and Level selection, supporting documentation references, the impartiality declaration, and acknowledgements of non-binding status, fee handling, and confidentiality. It is provided through /apply or via the scoping contact.
Three possible outcomes: acceptance (the typical outcome — engagement proceeds to Certification Agreement issuance); request for clarification (specific points need to be augmented or clarified before final decision; resolved through brief follow-up); or rejection (rare; typically because proposed scope falls outside Guardian’s accreditation scope, or impartiality conflicts cannot be managed). Application review is procedural under ISO/IEC 17065 Clause 7.3 — it does not assess product security.
No — one product per GSA-F-01. Where you have multiple products to certify, each is a distinct application with its own application form, scoping, and Certification Agreement. Where products share infrastructure (multi-tenant SaaS, shared API estates), scoping may identify evaluation efficiencies that combined-module engagements can capture, but each certificate covers one product.
Generally no. Guardian SecureApp™ certifies released products at a specific version. Pre-release products can be the subject of a non-certification VAPT engagement (described at /services/vapt) — technical assessment without producing a certificate. Many applicants use pre-release VAPT followed by certification at release; this is a common pattern for products with regulatory deadlines.
It is the applicant’s declaration of any prior or current relationship with Guardian or with Guardian’s evaluators that might raise impartiality concerns — consulting engagements, employment relationships, financial interests, or other connections that could compromise (or appear to compromise) Guardian’s independence. Most applications have nothing to declare. Where there are declarations, Guardian’s impartiality review process determines whether the engagement can proceed and under what terms — per ISO/IEC 17065 Clause 4.2.
Limited negotiation is supported — primarily for jurisdictional clauses (governing law, dispute resolution venue) for clients in non-Indian jurisdictions, and for specific operational clauses where the standard terms genuinely do not fit the applicant’s context. The substantive structure (impartiality requirements, decision independence, fee disclosure, surveillance regime, mark usage) does not vary case-by-case — case-by-case variation would itself create impartiality risk. Standardisation of the agreement is itself an impartiality safeguard.
You may withdraw the application by written notice to your scoping contact at any time before executing the Certification Agreement. There is no withdrawal fee, and no record of the withdrawn application appears in the public directory. After Certification Agreement execution, withdrawal becomes contractual termination — different mechanics with potential fees for work performed up to the termination point.
Guardian helps you understand what is required and supports the scoping conversation that produces an accurate application — but Guardian does not assist with producing the application content itself (scope statement, architecture documentation, threat model, etc.). The applicant prepares the application content; Guardian reviews it. This is an impartiality boundary: a body that prepared the application could not impartially evaluate it. Where applicants need assistance with document preparation, that work is appropriate to engage with an independent consultant — not with Guardian.
Significant changes between application submission and kickoff (a major release, an architecture change, a new feature affecting security boundary) should be communicated to your scoping contact promptly. Guardian’s application review may need to be revisited, and the Certification Agreement scope may need to be revised. Minor changes — bug fixes, small feature additions that do not affect the security boundary — typically do not require formal revisitation. The line is judgment-based and is discussed at scoping.
The engagement fee is established by the Indicative Quote produced after scoping (Stage 2). Application review may refine the quote — for example, where supporting documentation reveals scope dimensions not surfaced during scoping. The refined quote is incorporated into the Certification Agreement at execution. The Certification Agreement fee is what applies during the engagement. Fees do not influence the certification decision (ISO/IEC 17065 Cl. 4.2).
At minimum: a principal contact (typically Compliance, Security, or Engineering leadership) who will own the engagement; an engineering point of contact who can provide architecture, data flow and authentication documentation; and a signing authority for the Certification Agreement. For Level 2 and 3 engagements, additional engineering contacts (e.g., backend engineering lead, security engineering lead, DevOps lead) are typically identified during the kickoff meeting. The principal contact remains the primary interface throughout.
The form is available at /apply on this website, or directly through your scoping contact after the initial enquiry. We recommend completing initial enquiry and scoping (no-cost, no-commitment) before submitting GSA-F-01, because scoping refines the Module + Level decision and the supporting documentation requirements that the application form captures. Submitting an application without prior scoping is supported but typically results in a request for clarification before acceptance.
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