GUARDIAN SECUREAPP™ CERTIFICATION SCHEME
Guardian SecureApp™ — Third-Party Product Certification for Application Security
An ISO/IEC 17065-accredited certification scheme that independently certifies the cybersecurity of web applications, SaaS / multi-tenant platforms and APIs / microservices — against OWASP ASVS, OWASP Top 10 and OWASP API Security Top 10, at three assurance levels. Operated by Guardian Assessment Pvt. Ltd., accredited by UAF.
Scheme Overview
A Single Accredited Scheme. Three Product Categories. Three Assurance Levels.
Guardian SecureApp™ is a third-party product certification scheme that independently certifies the cybersecurity of three categories of software product: web applications, SaaS / multi-tenant platforms, and APIs / microservices. The scheme is operated by Guardian Assessment Pvt. Ltd., a Conformity Assessment Body accredited by United Accreditation Foundation (UAF) under ISO/IEC 17065:2012 — the international standard for bodies certifying products, processes and services. The accreditation number is 52605385601, the IAF Scope Code is 33 (Information Technology), and the accreditation is valid from 06 May 2026 to 05 May 2030.
Under the scheme, certification is offered through three modules — Module A for web applications, Module B for SaaS / multi-tenant platforms, and Module C for APIs / microservices — and at three assurance levels: Level 1 (Basic), Level 2 (Advanced), and Level 3 (High-Risk / Critical). A single certificate may cover one module or any combination of modules, evaluated at the assurance level appropriate to the product’s risk.
Two layers of standards anchor the scheme. The first is technical: evaluation is conducted against OWASP standards — the Application Security Verification Standard (ASVS), the OWASP Top 10, and (for Module C) the OWASP API Security Top 10. These standards are the international common language of application security and are recognised by virtually every mature security programme worldwide. The second layer is procedural: how Guardian conducts evaluations, takes certification decisions, manages impartiality, handles complaints and surveils certified products is governed by ISO/IEC 17065, supplemented by UAF-CAB-PrCB, UAF-GEN-CAB-01, UAF-GEN-CAB-02, IAF MD 4:2025 and IAF MD 12:2023. Procedural conformance is itself audited annually by UAF. The scheme is documented in GSA-PR-01 — the Guardian SecureApp™ Product Certification Scheme — which translates the technical and procedural requirements into the rules under which certificates are issued, surveilled, suspended, withdrawn, and recertified. A public summary of GSA-PR-01 is available for download. The full scheme document is held under accreditation control and shared with applicants on contracted engagement.
What Gets Certified
We Certify the Product, Not the Company
A Guardian SecureApp™ certificate is product-specific. It is issued for a named software product, at a named version (or a named version range), against a defined functional and security boundary, evaluated under one or more named modules at a named assurance level. The certificate makes a statement about that product, not about the company that owns it. A single company can hold multiple Guardian SecureApp™ certificates for different products, at different levels, under different combinations of modules — and this is the normal pattern, not the exception.
This product-level granularity is deliberate and matters for three reasons. First, security posture is product-specific: a company’s flagship product may have institutional engineering investment that justifies Level 3 evaluation, while an internal admin tool justifies only Level 1. A company-level certificate would either over-certify the second product or under-certify the first. Second, the meaning of the certificate is unambiguous to any reader: there is no ambiguity about what was evaluated. Third, regulatory and procurement requirements usually attach to specific products in scope of a specific contract or licensure — a product-level certificate maps directly onto how those requirements are written. The scope of each certificate is defined precisely in the Scope Statement that accompanies the certificate. The Scope Statement names: the product and version; the modules evaluated; the assurance level; the functional boundary (the components, features and integrations included in evaluation); the security boundary (the controls evaluated); the deployment environment evaluated; and any explicit exclusions. The Scope Statement is part of the certification record and is available to anyone querying the public directory.
The Three Modules
Three Product Categories Covered Under One Accredited Scope
Module A — Web Application Security
Module A applies to web applications: single-page applications, server-rendered web apps, customer-facing portals, internal business tools, content portals, transactional websites, and any browser-accessible product where the security posture of the application itself is the primary assurance question.
Evaluation under Module A is conducted against the OWASP Application Security Verification Standard (ASVS), with depth varying by assurance level. The ASVS organises application security controls across fourteen control families (V1–V14): architecture, design and threat modelling; authentication; session management; access control; validation, sanitisation and encoding; stored cryptography; error handling and logging; data protection; communications; malicious code; business logic; files and resources; API and web service interfaces; and configuration. Module A also references the OWASP Top 10 — the most critical web application security risks — as a prioritised risk framework alongside ASVS.
A Module A certificate confirms that the named web application, at the named version, has been evaluated against ASVS at the named assurance level and meets the certification criteria. Module A is the right module when your product surface is a web application and your customers, regulators or procurement teams are asking whether that application meets recognised application security controls.
Detailed scope, evaluation methodology and indicative timelines are at /certification/web-application-security.
Module B — SaaS / Multi-Tenant Platform Security
Module B applies to multi-tenant SaaS platforms — products where multiple customer organisations share a single application instance, with logical isolation between their data, identities, configurations and workloads. Module B extends Module A and adds tenant-aware evaluation of identity federation, authorisation boundaries, key management, data segregation, subscription lifecycle, audit logging across tenants, platform operations and the provider-customer security responsibility model (the so-called shared responsibility model, in cloud-native architectures).
Module B is the right module when your customers are asking how you guarantee that their data cannot be reached, modified, observed or aggregated by another customer of the same platform — a question that traditional web application security testing (Module A alone) does not directly answer. SaaS providers serving regulated buyers (banks, hospitals, government agencies, large enterprises) are often pushed into Module B by procurement requirements that explicitly call for evidence of tenant isolation.
A Module B certificate confirms the multi-tenant platform’s security posture, including the tenant-isolation architecture and the controls that maintain it. Detailed scope at /certification/saas-security.
Module C — API / Microservices Security
Module C applies to APIs and microservices — REST, GraphQL, gRPC, event-driven, and other machine-to-machine interfaces. Evaluation is anchored in the OWASP API Security Top 10, the prioritised framework specifically engineered for API risks, and addresses Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization (which subsumes BFLA and Excessive Data Exposure), Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.
Module C is the right module when your product surface is an API — public, partner-facing, or internal — and where the security of integration points and data exposure is the assurance question your customers, regulators or partners are asking. API-only products (developer platforms, embedded service providers, fintech rails, ML/AI inference APIs) are natural Module C candidates.
A Module C certificate confirms the API’s security posture against the OWASP API Security Top 10, at the named assurance level, with explicit listing of certified endpoints and API versions in scope. Detailed scope at /certification/api-security.
Assurance Levels
Choose the Assurance Level That Matches Your Product’s Risk
The assurance level you select determines the depth of evaluation, the rigour of testing, the breadth of source code review (where applicable), the frequency of surveillance, and ultimately the strength of the assurance signal the certificate carries. Level selection is a business decision that should follow your risk assessment, your regulatory drivers, your customer expectations and your competitive positioning. Where a regulator names a level, the choice is made for you. Where it does not, scoping discussion will help map your product’s risk profile to a proportionate level.
| Attribute | Level 1 — Basic | Level 2 — Advanced | Level 3 — High-Risk / Critical |
|---|---|---|---|
Mapped ASVS Level | ASVS Level 1. | ASVS Level 2. | ASVS Level 3. |
Testing Depth | Automated scanning plus targeted manual verification. | Automated, manual, business-logic, and threat-model-driven testing. | Comprehensive manual, threat-led, abuse-case, and adversarial testing. |
Source Code Review | Not mandatory. | Sample-based review on critical components. | Comprehensive review of the in-scope codebase. |
Architecture Review | High-level review. | Detailed review including data flow. | Threat-modelled architecture review. |
Surveillance Frequency | Annual. | Annual plus change-driven review. | Semi-annual plus change-driven review. |
Re-evaluation on Major Release | Notification only. | Targeted re-evaluation. | Mandatory re-evaluation. |
Indicative Starting Fee* | USD 2,000 onwards | USD 4,000 onwards | USD 7,000 onwards |
Typical Timeline | 4-7 weeks. | 6-10 weeks. | 10-16 weeks. |
Typical Use Case | Internal tools, low-risk public sites, and content portals. | E-commerce, customer-facing SaaS, and healthcare portals. | Net-banking, UPI / payment apps, EHR, and trading platforms. |
*Indicative starting fees are for small organisations certifying a single, low-complexity product on a single technology stack in a single environment, under a single Module. Fees do not influence the certification decision (ISO/IEC 17065 Clause 4.2 — impartiality requirement).
Detailed level pages, including scheme-specific testing depth and surveillance rules, are at /levels/level-1-basic, /levels/level-2-advanced and /levels/level-3-critical. A side-by-side comparison is at /levels.
Standards
The Open, Internationally Recognised Standards Behind Every Decision
A certification is only as credible as the standards it is built on. Guardian SecureApp™ is anchored in two layers of internationally recognised standards: a technical layer that defines what is evaluated, and a procedural layer that defines how the certification is issued. The technical layer is open and free to read; the procedural layer is published by ISO and IAF and operationalised by UAF. There is no proprietary methodology — every reader can verify what we evaluate against and how we evaluate.
| Standard / Document | Role in the Scheme |
|---|---|
OWASP Application Security Verification Standard (ASVS) | The principal technical normative document for Modules A and B. Defines 14 control families and 3 verification levels. Open standard maintained by OWASP Foundation. Detailed at /standards/owasp-asvs. |
OWASP Top 10 | Prioritised risk framework used alongside ASVS for Modules A and B. Highlights the most critical web application security risks. Detailed at /standards/owasp-top-10. |
OWASP API Security Top 10 | The principal technical normative document for Module C. Detailed at /standards/owasp-api-top-10. |
ISO/IEC 17065:2012 | The international standard governing how Guardian operates as a Product Certification Body. Defines impartiality, evaluation-decision separation, complaints and appeals, public information, and management system requirements. Detailed at /standards/iso-17065. |
UAF-CAB-PrCB · UAF-GEN-CAB-01 · UAF-GEN-CAB-02 | UAF accreditation requirements applicable to Product Certification Bodies, plus general accreditation requirements and conditions for use of the UAF symbol. |
IAF MD 4:2025 | Governs the use of ICT remote methods in conformity assessment. Most Guardian evaluation activities can be conducted remotely under IAF MD 4:2025. |
IAF MD 12:2023 | Governs CABs operating in multiple countries, relevant for Guardian engagements involving applicants outside India. |
GSA-PR-01 | The Guardian SecureApp™ Product Certification Scheme document. It translates the technical and procedural standards above into the operating rules of the scheme. Public summary downloadable. |
Levels
From Application to Certificate to Renewal — the Full Cycle
The Guardian SecureApp™ certification lifecycle is structured into seven defined stages, with surveillance and recertification activities continuing through the certification cycle. Each stage has documented inputs, activities and outputs, recorded against the certification file. The full lifecycle is documented in GSA-PR-01.
Application
The applicant submits the Application Form GSA-F-01 with supporting documentation: product description, architecture diagram, data flow diagram, threat model where available, authentication and authorisation summary, hosting and integration details, and prior security assessment evidence if any. The application identifies the modules and assurance level requested.
Application Review
Guardian reviews the application against ISO/IEC 17065 Clause 7.3, confirming our ability to perform certification, including scope match and resource availability, the absence of impartiality conflicts, consultancy involvement screening, financial dependence check, evaluator conflicts, and the completeness of the submitted documentation.
Acceptance, request for clarification, or rejection with documented reasons. On acceptance, the Certification Agreement is executed.
Documentation Review
Evaluators conduct a documentation review of architecture, threat models, data flow diagrams, prior assessment evidence, and change history. Documentation findings, including gaps in security architecture, untested assumptions, and missing controls, are reported to the applicant. Stage 1 outputs include a Documentation Review Report and a refined Stage 2 evaluation plan, scoped to the product as it actually is rather than as initially described.
Technical Evaluation
Stage 2 is the core technical evaluation, with depth and methodology dictated by the assurance level. Activities include:
- Vulnerability assessment and penetration testing (VAPT)
- Configuration and source code review, sample-based at Level 2 and comprehensive at Level 3
- Business-logic, abuse-case, and threat-led testing
* Evaluation may be conducted on-site or remotely under IAF MD 4:2025; most engagements are remote.
Findings and Closure
Findings are issued with severity ratings referenced to the relevant OWASP control where applicable, and accompanied by sufficient detail for the applicant’s engineering team to scope remediation.
Critical and High findings must be addressed for certification to be granted; Medium and Low findings may be accepted with documented compensating controls or risk acceptance, subject to scheme rules and Decision Authority approval.
Guardian re-verifies corrective actions; one round of re-verification is included in the engagement. Additional rounds, if required, are billed separately.
Evaluation Report & Decision
On closure of in-scope findings, the evaluation team prepares an Evaluation Report summarising scope, methodology, activities, findings, corrective actions, and a recommendation.
The Report is submitted to the Certification Decision Authority, independent of evaluation personnel per ISO/IEC 17065 Clause 7.6, who takes one of three decisions:
Certificate & Public Listing
Granted certificates are issued bearing the certificate number, applicant name, product name, version, modules certified, assurance level, scope statement, issue date, and validity period. The certificate is signed by an authorised Guardian signatory.
The certified product is added to the Public Directory of Certified Products at /directory, where any party can independently verify it.
Validity
How Certification Stays Current — and What Causes It to Lose Validity
A Guardian SecureApp™ certificate is not a one-off event — it is a continuing assurance instrument that is maintained, re-evaluated, and (where appropriate) suspended or withdrawn through the certification cycle. Four mechanisms govern this:
Surveillance
Surveillance is the periodic, scheduled re-evaluation activity that confirms a certified product continues to meet certification criteria. Frequency is level-dependent: annual at Level 1 and Level 2, semi-annual at Level 3. Surveillance is lighter than initial certification but rigorous enough to detect drift, regression, or material changes that affect certification status. Surveillance failure may result in suspension.
Change-Driven Re-Evaluation
Significant changes to the product — major releases, architecture changes, new authentication methods, breach incidents — trigger re-evaluation activity outside the scheduled surveillance cycle. The Certification Agreement requires the certified client to notify Guardian of significant changes; the Decision Authority assesses whether the change requires a Stage 2 re-evaluation or can be addressed through routine surveillance. At Level 3, mandatory re-evaluation on major releases is the default.
Recertification
Recertification is required before expiry of the certification cycle (typically every 3 years from initial issue, subject to scheme rules and any UAF-driven changes). Recertification is a comprehensive re-evaluation against the current version of the scheme criteria — including any updates to OWASP standards or the GSA-PR-01 scheme document adopted by Guardian since initial certification. Material changes to the standards are communicated to certified clients with appropriate transition guidance.
Suspension, Withdrawal and Reduction of Scope
Where a certified client fails to comply with scheme requirements — fails surveillance, breaches the Certification Agreement, misuses the certification mark, fails to notify of significant changes, fails to address corrective actions — Guardian may take one of three actions:
- Suspension — temporary loss of validity. Suspended certificates remain in the directory but are visibly listed as ‘suspended’, with the date and reason. Suspension is time-bounded (typically 90 days); failure to address the cause within the suspension period may result in withdrawal.
- Withdrawal — permanent loss of certification. The client must immediately cease all use of the certification mark and any references to certification. Withdrawn certificates are listed publicly at /directory.
- Reduction of Scope — specific modules, features or product versions are removed from the certificate, with a revised certificate issued reflecting the reduced scope.
All such actions are reflected in the Public Directory in real time and are themselves subject to appeal under our Complaints & Appeals procedure.
Certification Mark
The Guardian SecureApp™ Mark — Where, How and Within What Limits
Certified clients are licensed to use the Guardian SecureApp™ certification mark in accordance with our Use of Mark Policy and UAF-GEN-CAB-02 (Conditions for the Use of UAF Accreditation Symbol). The mark may be displayed on the certified product’s about page, marketing collateral, RFP responses, sales proposals, packaging and across digital channels — but only in respect of the certified product, version and scope. The Use of Mark Policy specifies the visual specification, the placement rules, the disclaimers required, and the prohibitions.
Misuse of the mark — for example, displaying it on an uncertified product, an uncertified version, beyond the certified scope, or in a manner that misrepresents the meaning of the certification — may result in formal notice, suspension of the certificate, public correction, and (in serious or persistent cases) withdrawal of certification. Misuse is also a breach of UAF-GEN-CAB-02 and may attract UAF action against Guardian if unaddressed.
Full Mark Usage Policy at /marks-policy.
Verification
Every Certificate, Verifiable by Anyone
ISO/IEC 17065 Clause 4.6 requires the certification body to make defined facts about each issued certificate publicly available. We meet this requirement through the Public Directory of Certified Products at /directory, searchable by certificate number, product name, or applicant name. The directory shows current valid certificates as well as suspended and withdrawn certificates, with the date and reason for status changes.
Every entry in the directory shows: certificate number; applicant legal name; product name and certified version (or version range); modules certified; assurance level; scope statement (summarised); issue date; validity period; and current status. The directory is the authoritative public source for the status of any Guardian SecureApp™ certificate; if a status claim made elsewhere does not match the directory, the directory prevails.
Independent verification at the accreditation level is at https://www.uafaccreditation.org/ (accreditation number 52605385601). For the IAF MLA scope by accreditation type, verification is at www.iaf.nu.
Why Choose Us
What a Guardian SecureApp™ Certificate Says About Your Product
Five attributes distinguish a Guardian SecureApp™ certificate from less rigorous forms of assurance:
Independence by structure
Guardian provides no consultancy, no implementation, no remediation, no training-to-pass — for any client, ever. Evaluators with prior consultancy involvement are barred for two years. Decision-makers are independent of evaluation personnel. Our impartiality is structurally enforced and audited annually by UAF, not merely declared.
Globally recognised technical methodology
OWASP standards are the international common language of application security. Anyone competent in the field — your engineers, your customers’ security teams, your regulators, your auditors — can interpret the meaning of a Guardian SecureApp™ certificate without translation.
Procedurally accredited issuance
ISO/IEC 17065-accredited issuance means the procedure that led to your certificate has itself been audited. UAF surveillance, witness assessments, and the public accreditation register make this auditable end-to-end.
Modular and proportionate
Three modules and three levels mean you certify only what you need, at the depth your risk demands. There is no all-or-nothing certification gate. You can start at Level 1 for a low-risk product, certify a higher-risk product at Level 2 or 3, and add modules to existing certificates as your product surface grows.
Public verifiability
Every certificate is independently verifiable by anyone, anytime, without our involvement — through the public directory and the underlying UAF accreditation register. Public verifiability is the difference between an assurance instrument that scales across customer bases, regulatory submissions and procurement processes, and a private document that does not.
Pricing
Tentative Starting Fees for Small Organizations
Guardian publishes indicative starting fees because transparency is a market expectation and because pricing should be a business filter, not a guessing game. The figures below apply when the applicant is a small organisation certifying a single, low-complexity product on a single technology stack in a single environment, under a single Guardian SecureApp™ Module. Final fees depend on scope, technology, modules, level, evaluation man-days and complexity. A formal quotation is provided on request and is valid for 30 days.
Level 1
Basic
$2,000
onwards
Indicative Starting Fee *
Typical Timeline
4–7 weeks
For Internal tools, low-risk public sites
Level 2
Advanced
$4,000
onwards
Indicative Starting Fee *
Typical Timeline
7–11 weeks
For Customer-facing apps with PII / payments
Level 3
High-Risk / Critical
$7,000
onwards
Indicative Starting Fee *
Typical Timeline
11–16 weeks
For Banking, healthcare, critical infrastructure
*Indicative starting fees are exclusive of applicable taxes (e.g., GST in India), and are payable for the work performed regardless of certification outcome. Travel and out-of-pocket expenses for on-site evaluations (where required) are billed at actuals with prior approval. Surveillance and recertification fees are billed separately. Fees do not influence the certification decision (ISO/IEC 17065 Clause 4.2 — impartiality requirement).
Full fee structure, basis of fees, payment terms and impartiality disclosure at /process/fees. Quotations on request at /quote.
Frequently Asked Questions
Common Questions, Answered
The product. Each certificate is issued for a specific product name, version (or version range), module(s) and assurance level. A single company may hold multiple certificates for different products, or different levels for different products. This product-level granularity is deliberate: it lets you certify only what needs certification, at the level proportionate to its risk.
Guardian SecureApp™ is a voluntary certification scheme. However, customers, regulators, partners and procurement teams increasingly require independent third-party evidence of application security, and an accredited certificate satisfies that requirement in a standardised, verifiable way. In practice, voluntary today often means contractually expected tomorrow.
Match the level to your product’s risk. Level 1 for low-risk internal tools and public information sites; Level 2 for customer-facing products handling personal data, transactions or sensitive workflows; Level 3 for products handling financial transactions, regulated data, or that are part of critical infrastructure. Where a regulator or major customer specifies a level, that decision is made for you. Otherwise, our scoping discussion will help map your product’s risk profile to a proportionate level — neither over-investing nor under-investing.
Yes. Each product is certified independently. You can certify only your API (Module C) at Level 2 today, and add a Web application certification (Module A) for a different product later — they are separate certificates. You can also combine modules on a single certificate when it makes sense (a SaaS platform with public APIs is naturally Modules B and C together).
Certificates are issued for a defined cycle (typically 3 years), subject to successful surveillance during the cycle. Recertification is required before expiry. Significant changes to the certified product trigger surveillance or re-evaluation activity outside the scheduled cycle.
Significant changes (architecture, security controls, new features that change the threat model, new authentication methods, breach incidents) require notification to Guardian and may trigger evaluation activities. Minor releases that do not affect the certification scope can typically be covered by routine surveillance. The exact rules are documented in the Certification Agreement and GSA-PR-01. At Level 3, mandatory re-evaluation on major releases is the default.
Findings are issued with severity ratings. Critical and High findings must be addressed for certification to be granted. The applicant is given a defined period to address findings and Guardian re-verifies corrective actions; one round of re-verification is included. If the product cannot meet the criteria, the certification is not issued. Guardian does not provide remediation advice — addressing findings is the applicant’s responsibility, with their own resources or any third party they engage.
Yes. Any applicant or certified client may file an appeal under our Complaints & Appeals procedure. Appeals are heard by an independent Appeals Panel separate from the original decision-makers. Process and timelines documented at /complaints-appeals.
OWASP ASVS is the principal technical normative document for Modules A and B. OWASP Top 10 is a prioritised risk framework used alongside ASVS. OWASP API Security Top 10 is the principal technical normative document for Module C. ISO/IEC 17065 governs the certification process itself, not the technical content. GSA-PR-01 (the scheme document) translates these into operational rules.
Evaluation activities may be conducted remotely (using ICT) where appropriate, in accordance with IAF MD 4:2025. The decision is risk-based and depends on the level, the nature of the product, and the activities required. Most engagements are conducted remotely; some Level 3 engagements may benefit from limited on-site presence, determined at scoping.
ISO/IEC 27001 certifies an organisation’s Information Security Management System (ISMS) — how the organisation governs information security. Guardian SecureApp™ certifies a specific software product’s security posture. They are complementary, not substitutes: an ISO 27001-certified organisation can still ship a vulnerable product, and a Guardian SecureApp™-certified product can be developed by an organisation that is not 27001-certified. Mature buyers increasingly ask for both.
Yes. Vulnerability Assessment and Penetration Testing (VAPT) is conducted as part of the technical evaluation, with depth varying by assurance level. VAPT can also be commissioned as a stand-alone engagement from Guardian, independent of certification — but stand-alone VAPT delivers a findings report only and is not equivalent to certification.
Yes — for the certified product, in accordance with our Use of Mark Policy and UAF-GEN-CAB-02. The mark may be displayed on the product’s about page, marketing collateral, RFP responses, sales proposals, packaging and across digital channels, but only in respect of the certified product, version and scope. Misuse may result in suspension or withdrawal.
Every Guardian SecureApp™ certificate is publicly listed at /directory, searchable by certificate number, product name or applicant name. The directory shows current valid certificates as well as suspended and withdrawn certificates. Public listing of certificate facts is required by ISO/IEC 17065 Clause 4.6.
GSA-PR-01 is the Guardian SecureApp™ Product Certification Scheme document. It is the normative scheme document that defines the rules under which certificates are issued, surveilled, suspended, withdrawn and recertified. It translates the technical standards (OWASP ASVS, OWASP Top 10, OWASP API Top 10) and the procedural standards (ISO/IEC 17065, UAF and IAF mandatory documents) into the operating rules of Guardian SecureApp™. A public summary is downloadable from our /accreditation page.
The indicative starting fee for an assurance level covers application review, Stage 1 documentation review, Stage 2 technical evaluation appropriate to the level (VAPT, configuration review, source code review per level), one round of findings re-verification, the certification decision, initial certificate issuance, and listing in the public directory. Annual surveillance, recertification, additional re-verification rounds, scope changes and additional modules are billed separately. Full fee structure at /process/fees.
Indicative starting fees for small organisations are USD 2,000 (Level 1), USD 4,000 (Level 2), and USD 7,000 (Level 3) — designed to make accredited certification accessible to startups and growth-stage companies. Final fees depend on scope and complexity; quotation is on request. We work routinely with companies of all sizes.
CERT-In empanelment is a separate accreditation under the Government of India for specific information security audit purposes. Guardian SecureApp™ is a third-party product certification under ISO/IEC 17065 — a different mechanism with different applications. They are complementary and are not substitutes for one another. Where a regulatory mandate specifies CERT-In empanelment, that requirement is what applies; where the requirement is for accredited third-party product certification, Guardian SecureApp™ applies. Discuss your specific regulatory driver during scoping.
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