STQC IT Testing & Certification

Introduction to STQC IT Testing and Certification

STQC (Standardisation Testing and Quality Certification) is the assurance and conformity-assessment arm of the Ministry of Electronics and Information Technology (MeitY), Government of India. For any organisation building products, delivering IT-enabled services to the government, operating data centres, hosting e-Governance workloads, or seeking recognition of an information-security or product-testing regime under Indian public procurement, an STQC certificate is frequently the mandated proof of trust. Unlike a self-declaration, an STQC certificate is issued by an accredited Government of India laboratory and, in most schemes, is underpinned by international mutual-recognition arrangements (such as the CCRA for Common Criteria) so that the certificate carries weight both within India and abroad.

This guide is written for two audiences at once. For the assessor, auditor or QSA it enumerates every domain, family, requirement and evaluation activity so that a gap assessment can be performed against real, verifiable criteria. For the implementer, developer and product-management team it explains the certification lifecycle, the evidence you must generate at each phase, and the maturity/assurance levels you are expected to attain. STQC is not a single monolithic standard; it is a family of schemes, and choosing the correct scheme for your product or service is the single most important scoping decision.

What is STQC IT Testing and Certification

STQC operates a nationwide network of laboratories and centres that provide testing, calibration and certification services across electronics and IT. Within the IT and information-security space, STQC administers several distinct but complementary schemes. The most prominent is the Indian Common Criteria Certification Scheme (IC3S), through which STQC acts as the national Certification Body for evaluating the security functionality of IT products against ISO/IEC 15408. STQC also runs cryptographic module testing aligned to FIPS 140-2/140-3, an information-security-management-system certification scheme aligned to ISO/IEC 27001, website and application quality certification against the Guidelines for Indian Government Websites (GIGW) and WCAG accessibility, biometric device certification (for example for Aadhaar-authentication devices under UIDAI's L0/L1 requirements), electronic-hardware and product testing, and audit/empanelment services for e-Governance applications.

The unifying idea across all STQC schemes is independent, laboratory-based conformity assessment: a candidate product, system or management regime is evaluated by an accredited body against a defined set of criteria, evidence is examined and independently tested, and a certificate is issued at a stated assurance or conformance level with a defined scope of validity. STQC laboratories are themselves accredited (for example to ISO/IEC 17025 for testing and calibration, and ISO/IEC 17065/17021 for product and management-system certification), which is what gives the certificate its legal and commercial standing in Indian public procurement.

The principal STQC IT schemes at a glance

Who must comply with STQC

STQC certification is sometimes a legal or contractual mandate and sometimes a strong commercial differentiator. The obligation flows from the procurement rules of the buying entity (typically a government department, PSU or regulated operator) rather than from a single horizontal law, so the applicable scheme depends on what you are selling and to whom.

Structure of STQC (schemes, domains and control families)

Because STQC is a family of schemes, its 'structure' is best understood as the internal control structure of each scheme plus the common conformity-assessment machinery that binds them. The table below decomposes the two flagship IT-security schemes (IC3S/Common Criteria and FIPS 140-3) plus the ISMS scheme into their constituent domains/families/requirement areas, because these are the areas an assessor will actually walk through.

The Common Criteria assurance stack (SFR and SAR classes)

Within IC3S, a product (the Target of Evaluation, or TOE) is described by a Security Target (ST) that states which Security Functional Requirements it satisfies and which Evaluation Assurance Level of Security Assurance Requirements it claims. The functional classes cover audit (FAU), communication/non-repudiation (FCO), cryptographic support (FCS), user data protection (FDP), identification and authentication (FIA), security management (FMT), privacy (FPR), protection of the TSF (FPT), resource utilisation (FRU), TOE access (FTA) and trusted path/channels (FTP). The assurance classes cover development (ADV), guidance documents (AGD), life-cycle support (ALC), security-target evaluation (ASE), tests (ATE) and vulnerability assessment (AVA).

Master assessment checklist

This is the core of the guide. Each h3 below is a control group; each table lists, for the requirements in that group, exactly what an assessor must verify and the typical evidence an implementer must produce. No domain, family or requirement area is skipped. The checklist is organised first by the Common Criteria functional and assurance classes (the deepest and most examinable scheme), then by FIPS 140-3 areas, then by ISMS themes, then GIGW/accessibility, then biometric device criteria.

FAU - Security Audit (CC functional class)

FCO - Communication (non-repudiation)

FCS - Cryptographic Support

FDP - User Data Protection

FIA - Identification and Authentication

FMT - Security Management

FPR - Privacy

FPT - Protection of the TSF

FRU - Resource Utilisation

FTA - TOE Access

FTP - Trusted Path/Channels

ADV - Development (CC assurance class)

AGD - Guidance Documents

ALC - Life-cycle Support

ASE - Security Target Evaluation

ATE - Tests

AVA - Vulnerability Assessment

FIPS 140-3 cryptographic module security areas

ISMS (ISO/IEC 27001) management-system clauses

ISMS Annex A control themes (ISO/IEC 27001:2022)

Website Quality and GIGW / WCAG 2.1 accessibility

Biometric device certification (UIDAI L0/L1)

Scoping the certification

Scoping determines cost, timeline and the very meaning of your certificate, and a mistake here is expensive to unwind. The first decision is which scheme applies; a cryptographic library should target FIPS 140-3, a security appliance IC3S, a hosting operation ISMS, and a citizen-facing portal GIGW. Within a scheme the scope is defined precisely: for IC3S the Target of Evaluation (TOE) boundary must state exactly which product versions, modules, interfaces and hardware/software environment are included, because anything outside the boundary is uncertified. For FIPS the cryptographic boundary must be drawn around the module, and the operational environment classified as non-modifiable, limited or modifiable. For ISMS the scope statement fixes the sites, services, business units and information assets covered by the Statement of Applicability.

• Identify the mandate: read the tender/RFP or regulatory requirement to see which scheme and which level (e.g. EAL2, FIPS Level 3) is demanded.
• Draw the boundary precisely: TOE/cryptographic/ISMS scope must be unambiguous and version-locked.
• Fix the security problem: threats, assumptions and organisational policies the certificate will address.
• Decide the assurance/security level to claim, balancing cost against the buyer's requirement.
• Confirm any Protection Profile the product must conform to (some sectors mandate a specific PP).
• Enumerate the operational environment and dependencies that the certificate assumes.

Implementation approach (phased)

An STQC engagement runs most smoothly as a staged programme. The phases below use IC3S/Common Criteria as the running example (the most document-intensive scheme); the same shape applies to FIPS and ISMS with scheme-specific artefacts substituted.

Phase 1 - Readiness and scheme selection

• Activities: confirm applicable scheme and level; perform a gap assessment against the target criteria; draft the TOE/scope boundary.
• Deliverables: scheme-selection memo, gap-assessment report, high-level scope statement and project plan.

Phase 2 - Security Target / documentation build

• Activities: author the Security Target (or SoA/module spec); map claims to SFRs/controls; establish CM, SDLC and delivery procedures.
• Deliverables: Security Target (ASE) or Statement of Applicability, CM plan, life-cycle documentation, guidance manuals (AGD).

Phase 3 - Engineering hardening and evidence generation

• Activities: implement/remediate controls; produce design (ADV) and test (ATE) evidence; run internal VAPT and self-tests.
• Deliverables: architecture and design documents, test plans and results, vulnerability-remediation records, secure-config baseline.

Phase 4 - Laboratory evaluation / audit

• Activities: engage the accredited lab (CCTL for IC3S); submit evidence; support evaluator testing, penetration testing and observation reports.
• Deliverables: evaluation-input package, evaluator observation-report responses, corrected artefacts, evaluation test evidence.

Phase 5 - Certification and surveillance

• Activities: STQC Certification Body reviews the Evaluation Technical Report and issues the certificate; establish assurance-continuity/maintenance and surveillance where applicable.
• Deliverables: certificate and certification report, maintenance/assurance-continuity plan, surveillance-audit schedule and re-certification roadmap.

Assurance / capability levels (scoring model)

Each STQC scheme expresses rigour through a graded level scale. The table maps the level scales of the flagship schemes so implementers can choose a target and assessors can calibrate depth.

Assessment and audit approach

1. Application and scoping: submit the certification application to STQC, agree the scheme, level and boundary.
2. Evidence submission: deliver the Security Target/SoA and supporting design, life-cycle and guidance evidence to the accredited laboratory.
3. Evaluation planning: the lab produces an evaluation work-plan mapping each requirement to evaluation activities.
4. Documentary evaluation: evaluators examine each SFR/SAR (or clause/control) and raise observation reports on deficiencies.
5. Independent testing: evaluators reproduce vendor tests and design their own functional and penetration tests.
6. Vulnerability assessment: evaluators rate residual vulnerabilities against the attack potential defined for the claimed level.
7. Observation-report resolution: the vendor remediates and resubmits until all findings are closed.
8. Evaluation Technical Report: the lab compiles the ETR and a verdict per requirement.
9. Certification decision: the STQC Certification Body reviews the ETR and issues (or withholds) the certificate and certification report.
10. Surveillance / assurance continuity: maintenance, re-evaluation of changes and periodic surveillance sustain the certificate's validity.

Evidence request list

• Governance: scheme-selection memo, certification application, project plan, scope/boundary statement.
• Security definition: Security Target or Statement of Applicability, Protection Profile conformance claims, risk register.
• Design: security-architecture (ADV_ARC), functional specification (ADV_FSP), TOE design (ADV_TDS), implementation representation for EAL4+.
• Life-cycle: configuration-management plan and item list, secure-delivery procedure, development-site security controls, flaw-remediation process, SDLC model.
• Guidance: operational user guidance and preparative install procedures, secure-configuration baseline.
• Testing: test plans, procedures and results, coverage and depth analyses, self-test and known-answer-test logs.
• Cryptography: algorithm inventory, key-lifecycle and zeroisation evidence, entropy/DRBG assessment, CAVP/CMVP references.
• Vulnerability: internal and evaluator VAPT reports, residual-vulnerability list, patch SLAs.
• ISMS operations: policies, training records, internal-audit reports, management-review minutes, CAPA log.
• Web/accessibility: WCAG audit, VAPT report, HTTPS/privacy configuration, content-ownership metadata.

Roles and responsibilities

KPIs to track

• Percentage of SFRs/SARs (or Annex A controls) with complete, lab-ready evidence.
• Number of open observation reports from the laboratory and mean time to resolution.
• Residual vulnerabilities by severity and closure rate against the attack-potential threshold.
• Documentation coverage ratio (design/guidance/life-cycle artefacts complete versus required).
• Test coverage and depth against TSF interfaces and subsystems.
• Elapsed time per phase versus plan (readiness, ST build, evaluation, certification).
• Self-test and known-answer-test pass rate for cryptographic modules.
• Days to re-certification / next surveillance and assurance-continuity actions raised per change.

Readiness checklist

• Correct STQC scheme and target level confirmed against the mandate or RFP.
• TOE / cryptographic / ISMS boundary drawn and version-locked.
• Security Target or Statement of Applicability drafted and internally reviewed.
• All applicable SFRs/controls mapped to implemented functions with traceability.
• Design, life-cycle, guidance and test evidence assembled to the claimed level.
• Internal VAPT completed and high/medium findings remediated.
• Cryptographic self-tests and key-zeroisation verified.
• Accredited laboratory / CCTL engaged and evaluation work-plan agreed.
• Flaw-remediation, CM and secure-delivery procedures operational.
• Surveillance / assurance-continuity plan defined for post-certification.

Common gaps

• Ambiguous or over-broad TOE boundary that pulls uncertified components into scope.
• Security Target claims not traceable to actual implemented functions (weak ASE_TSS).
• Missing or thin life-cycle evidence: no formal CM item list or secure-delivery procedure.
• Insufficient test coverage/depth for the claimed EAL (ATE_COV/DPT shortfalls).
• Cryptography using non-approved algorithms or lacking documented key zeroisation.
• No trusted-time source or self-test evidence for TSF protection (FPT_STM/FPT_TST).
• ISMS Statement of Applicability with unjustified control exclusions.
• Accessibility failures (poor contrast, missing alt-text, keyboard traps) in GIGW/WCAG scope.
• Residual vulnerabilities not rated against the correct attack potential for the level.
• No assurance-continuity plan, so a routine product update invalidates the certificate.

STQC mapped to other frameworks

Frequently asked questions

Need help with STQC?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.