On 25 July 2025 CERT-In published its Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0) — the first time India's national cyber agency has set out, end to end, how an empanelled cyber security audit must actually be scoped, conducted, scored and reported. If you are a CISO who commissions VAPT, an auditee preparing for a regulatory inspection, or a CERT-In empanelled auditor, this document now defines the floor you are measured against. Here is our section-by-section analysis, with the official PDF to download.
The guidelines are issued under CERT-In's statutory authority — Section 70B of the Information Technology Act, 2000 and Rule 9 of the CERT-In Rules, 2013 — and run to 20 sections covering applicability, definitions, scope of engagements, basic principles, applicable standards, auditee and auditor responsibilities, auditor selection, audit planning, performance, reporting, evidence and the consequences of non-compliance. They are binding context for the empanelment relationship: failure to follow them carries punitive action under Section 70B(7) and the terms of empanelment. Our reading below is sourced directly from the published document; the framing is ours, the requirements are CERT-In's.
Read the source document yourself — the Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0 dated 25 July 2025, published by CERT-In / MeitY. This link opens the official PDF hosted on cert-in.org.in.
What the guidelines are — and who they bind
The document has a deliberately dual audience. It tells auditee organisations how to prepare for an audit, understand the requirements and close deficiencies; and it gives CERT-In empanelled auditing organisations a structured framework to conduct rigorous, fair and transparent audits. Applicability is explicit on both sides.
- CERT-In empanelled auditing organisations — the firms empanelled to perform vulnerability assessment and penetration testing of systems, networks and applications across government and other sectors, who must deliver in accordance with their commercial contract and the conditions of empanelment.
- Auditee organisations — any public- or private-sector entity that owns or operates the systems being assessed, whether they are required to be audited or are seeking to evaluate their posture, identify vulnerabilities and demonstrate regulatory compliance.
The biggest shift: OWASP Top 10 is no longer a 'standard'
The single most consequential change for buyers of audit services is in Section 8. CERT-In states plainly that limited lists such as the OWASP Top 10 and SANS Top 25 must not be treated as standards or references for an audit. A test that simply walks the Top 10 and produces a clean certificate no longer satisfies the guideline. Instead, audits must discover all known vulnerabilities against comprehensive frameworks.
- ISO/IEC standards and CERT-In's own 'Cyber Security Audit Baseline Requirements'.
- CSA Cloud Controls Matrix (CCM) for cloud security.
- OSSTMM3 (Open Source Security Testing Methodology Manual).
- OWASP Web Security Testing Guide (WSTG) for web apps, Application Security Verification Standard (ASVS) for control verification, and the Mobile Security Testing Guide (MSTG) for mobile apps.
- OWASP DevSecOps Maturity Model for CI/CD pipeline security, plus all applicable regulatory directions issued from time to time by CERT-In and sector regulators.
Reporting: CVSS and EPSS are both mandatory now
Section 16 reshapes the audit report itself. Every observation must be scored on two axes, not one: CVSS for technical severity and EPSS (the Exploit Prediction Scoring System) for the likelihood of real-world exploitation. Severity alone is no longer enough — the report has to tell the board how likely a flaw is to actually be weaponised. On top of the scores, every reported vulnerability must be mapped to a CWE (Common Weakness Enumeration) and a CVE (Common Vulnerabilities and Exposures) identifier.
| Requirement | Detail |
|---|---|
| Dual scoring | CVSS for severity AND EPSS for exploitation likelihood on every observation |
| Standardised mapping | Every finding mapped to a CWE and a CVE number |
| Executive summary | Board-level summary translating technical findings into business risk |
| Live notification | Critical / high findings reported to the auditee as-and-when found, not just at the end |
| Sign-off | Audit certificate signed by both the Lead Auditor and the Head of the Auditing Organisation (Director / Partner / CEO) |
| Closure & follow-up | Final report issued only after vulnerabilities are closed and a follow-up audit confirms it — on production, not staging |
What a compliant CERT-In audit report must now carry (Section 16)
Final reports are for production — and follow-up is built in
A subtle but important rule: the final audit report is to be issued only after vulnerabilities are closed and a follow-up audit has verified that closure on the application as hosted in the production environment. If the audit scope was limited to a staging platform, the report must explicitly say so. This kills the common pattern of certifying a staging build that never matches what is actually exposed to the internet.
Data handling: NDAs, no overseas transfer, 5-day CERT-In reporting
The guidelines tighten the chain of custody around audit data considerably, which matters to any organisation worried about where its findings end up.
- A formal NDA must be signed before work starts, and auditors are ethically bound to confidentiality regardless of whether an NDA exists.
- Auditee data must not be shared with or disclosed to any overseas entity or partner unless the auditee authorises it in writing — disclosures mandated by law or to CERT-In are the exception.
- Reports must be delivered only to a named Point of Contact, over secure channels (passwords, encryption), from official email IDs.
- Crucially, auditing organisations must inform the auditee before work begins that audit metadata and the audit reports will be shared with CERT-In within five days of audit completion.
The 282-control-point checklist for critical government PII systems
For audits of critical applications, databases or platforms of Ministries, Departments, Secretariats and Offices that handle sensitive personally identifiable information, the guidelines make the 'Comprehensive Audit Program Checklist – Cyber and Information Security Audit' — 282 control points, drawn from the MeitY Guidelines on Mandatory Features of Cybersecurity Architecture — the default mandatory scope. If you operate or audit a government PII system, that 282-point checklist is now your baseline coverage, not an optional add-on.
Insecure apps should not be audited at all
One provision will surprise a lot of teams: an application developed without secure design and development practices should not be accepted for assessment or audit. Where an auditor finds this, they must inform the auditee in writing — with a copy marked to CERT-In. The expectation is that auditees adopt the practices in CERT-In's 'Guidelines for Secure Application Design, Development, Implementation & Operations' before they ever book a pen test. Audit is positioned as verification of a secure SDLC, not a substitute for one.
What happens to auditors who fall short
Section 19 sets out a graded 'Deter & Punishment matrix' for empanelled auditors whose work is inadequate or who breach the guidelines. For auditees, this is a quality signal: it tells you what a serious regulator will do to a firm that ships a weak report — and therefore what to look for when you select one.
| Action | Triggered by (indicative) |
|---|---|
| Move to watch list (warning + written commitment) | Inadequate closure of non-compliances, weak sampling, minor terms violations, first instance of non-compliance to the data-collection framework |
| Suspension | Adverse auditee feedback on technical competency, repeated failures in planning or coverage, issues appearing soon after an audit, major terms violations |
| Withdrawal of empanelment / de-empanelment | Auditing malpractices, substandard services, failure to cover scope — actioned per GFR rules |
| Penal & legal action | Breach of trust, digital break-in, damage or attempted damage to auditee interests and infrastructure |
CERT-In's graded consequences for non-compliant auditors (Section 19)
What auditees should do in the next 30 / 60 / 90 days
- Re-read your last audit report against Section 16: does it carry both CVSS and EPSS, CWE and CVE mappings, and a board-level executive summary? If not, your next one should.
- Stop accepting OWASP-Top-10-only or scanner-only 'VAPT'. Ask your auditor in writing which comprehensive frameworks (ISO/IEC, CERT-In Baseline, OWASP WSTG/ASVS/MSTG, OSSTMM3, CSA CCM, DevSecOps Maturity Model) they test against.
- Update your engagement letters and data-handling policy to pre-authorise the auditor's mandatory CERT-In metadata/report sharing within five days of completion, and to prohibit overseas transfer of audit data without written consent.
- If you run a critical government PII system, map your scope to the 282-control-point Comprehensive Audit Program Checklist before the next cycle.
- Adopt CERT-In's secure application design and development guidelines in your SDLC — an app that cannot show secure-by-design practice may be refused for audit.
- Insist that the final report follows closure and a follow-up audit on production, and that critical/high findings are escalated to you live during the engagement, not buried in the deliverable.
How Macksofy helps
As a CERT-In empanelled auditor, Macksofy already runs to this standard: manual, methodology-driven VAPT mapped to ISO/IEC, OWASP WSTG/ASVS/MSTG, OSSTMM3 and CERT-In's Baseline Requirements rather than a scanner pass; reports carrying CVSS and EPSS scoring with CWE/CVE mapping and a board-ready executive summary; secure, named-PoC delivery; and follow-up audits that verify closure on production. See /services/vapt for the assessment scope, /audit/cert-in-empanelled-audit for an empanelled-format engagement, /services/web-application-security and /services/mobile-application-security for app-layer testing aligned to the OWASP guides, and /services/cloud-security for CSA CCM-based cloud audits. If you want a second opinion on whether your last report would survive these guidelines, we will review it.