India’s nodal cybersecurity agency — the Computer Emergency Response Team (CERT-In) — issued its Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0 on 25 July 2025. These guidelines, issued under Section 70B of the Information Technology Act 2000, are binding on all CERT-In empanelled auditing organisations and carry significant implications for every Indian enterprise that undergoes or commissions a cybersecurity audit.
This is the first time CERT-In has published a unified policy framework governing how cybersecurity audits must be conducted in India. It is not a minor update — it defines 26 audit engagement types, mandates specific audit principles, sets auditor qualification standards, and establishes new data handling, reporting, and quality control requirements.
If your organisation is due for a cybersecurity audit, or if you engage CERT-In empanelled auditors for VAPT, ISO 27001, or regulatory compliance work, these guidelines directly affect what you should expect and demand from your auditor.
India’s cybersecurity audit ecosystem has grown substantially over the past decade. CERT-In’s empanelled auditor list now contains over 230 organisations. As audit volumes have scaled — particularly for government, BFSI, and critical infrastructure — the need for consistent standards, quality controls, and accountability has become acute.
The guidelines address a specific concern: audits being conducted as compliance formalities rather than genuine security assessments. The document explicitly states that “the auditing process should be viewed as a tool for the continual process improvement of the auditee organisation’s security posture, rather than a mere formality for compliance.”
In practice, this means CERT-In is pushing back against tool-only assessments, checkbox auditing, and superficial engagements that produce certificates without finding real vulnerabilities.
Section 6 of the guidelines defines the scope of cybersecurity audits. This is the most practically important section for auditee organisations — it tells you what types of assessments fall under CERT-In’s framework. The 26 engagement types include:
This list matters for auditee organisations because it defines the universe of services a CERT-In empanelled auditor is authorised to provide. When you commission an audit, you should be specific about which engagement type you are procuring and verify the auditor’s declared competence for that type.
Section 7 establishes eight principles that all cybersecurity audits must follow. These are not aspirational — they define the minimum standard of professional conduct:
i. Independence — The auditor’s fee must not be tied to the outcome of the audit. An auditor who earns more for a “clean” result has a fundamental conflict of interest. The guidelines explicitly prohibit outcome-linked compensation structures.
ii. Objectivity — Auditors must form opinions based on evidence, not on client pressure or preferred outcomes.
iii. Integrity — Honest reporting, even when findings are uncomfortable for the client.
iv. Professional Skepticism — Auditors cannot simply accept client claims. They must verify.
v. Professional Judgement — Experience and domain knowledge must inform findings, not just tool output.
vi. Professional Care — The audit must meet or exceed professional standards for the engagement type.
vii. Confidentiality — All audit data must be protected from unauthorised disclosure, following CERT-In’s published Policy Guidelines for Handling Audit Related Data.
viii. Transparency and Accountability — Audit processes, methods, and conclusions must be clearly documented and communicated. Auditors are accountable for the credibility and reliability of their work.
The independence principle deserves particular attention for procurement teams. If your RFP or contract structure creates incentives for the auditor to produce a favourable result — through bonus payments, repeat business tied to clean reports, or relationship pressures — the guidelines now explicitly identify this as a violation of professional standards.
Section 8 specifies the frameworks auditors must apply. Two critical points stand out:
Tools alone are not sufficient. CERT-In explicitly states that “solely tools-based testing should be discouraged as tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure.”
OWASP Top 10 is not a complete standard. The guidelines state that “limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits.” Instead, audits must be based on comprehensive standards including:
For organisations commissioning audits, this creates a concrete test: ask your auditor which specific standard they are following for your engagement. “We follow OWASP Top 10” is now an insufficient answer.
Critical for Government and Ministry applications: Audits of critical applications/databases of Ministries, Departments, Secretariats, and government offices handling personal identifiable information (PII) must include verification against the “Comprehensive Audit Program Checklist — Cyber and Information Security Audit” comprising 282 mandatory control points as outlined in the MeitY Guidelines on Mandatory Features of Cybersecurity Architecture.
Section 9 outlines what CERT-In expects from auditee organisations — not just from auditors. This section is frequently overlooked but is operationally important.
Top Management Oversight (9.1): Senior management must review and approve the audit programme, scope, and remediation plans. The guidelines make explicit that “the responsibility for maintaining an efficient and robust cyber security posture ultimately rests with the auditee organisation, not the auditor.” Board members and CXOs cannot delegate accountability to the auditor.
Risk Acceptance and Exception Handling (9.2): Any exceptions to reported vulnerabilities must be authorised by the head of the organisation who owns the application. Risk treatment decisions — retain, avoid, transfer, or reduce — must be formally documented and signed off at the appropriate level.
Remediation and Follow-up (9.3): Vulnerabilities highlighted in audit reports must be patched by owners/developers at the earliest. Critically, follow-up audits must be included in the scope or RFP and conducted by the auditing organisation after closure of identified vulnerabilities. If your current audit contracts do not include a follow-up/retest provision, this is a gap to address.
Internal Monitoring (9.4): Organisations must conduct continuous internal audits and assessments. Auditee organisations must also ensure that “Secure by Design” principles and secure application development practices are mandatory requirements in their RFPs and tenders for application/software development. If your procurement team is not including secure development requirements in software RFPs, this is now a compliance gap.
Application Handling and Audit Artifacts (9.5): Application developers should avoid making code changes to audited applications after issuance of the audit certificate. Audit artifacts — hash values, versions, timestamps — must be captured and shared with the auditing organisation. These details must feature in the audit certificate and reports. Version control must be implemented so that audited assets can be backtracked.
Asset Management (9.6): Organisations must maintain an inventory of all authorised assets (hardware and software), implement patch management, secure configurations (blocking unused ports, changing default credentials), enforce least privilege, require MFA for all remote access to cyber infrastructure, and use only genuine licensed software.
Section 10 details auditor responsibilities, but auditee organisations can use these as a checklist for evaluating and managing auditors:
Audit team qualifications: All audit team members must have valid NDAs with their employer organisation. The auditing organisation may only deploy manpower declared to CERT-In in their Snapshot Information Form. Verify your auditor’s declared manpower before the engagement. Critically: freelancers, interns, freshers, moonlighters, third-party consultants, and employees serving notice periods must not be fielded. You have the right to verify the identity and employment status of everyone assigned to your audit.
Required competencies: Auditors must demonstrate adequate competency in: Security Technologies, Security Processes, Security Controls, Security Trends, Fact Collection, and Reporting.
Data handling: Audit-related data must be stored only on systems located in India. During the engagement, data must be kept in encrypted form on auditor laptops. After completion, all audit data must be wiped from auditor systems using forensic-grade deletion — and the auditing organisation must issue a certificate confirming permanent data deletion. Default data retention (if not specified in the contract) is 1 year from project completion.
Report signatures: Audit reports must be signed by three levels: (1) the auditors who conducted the audit, (2) a designated reviewer from mid-management who was not part of the audit team, and (3) the Head of the Auditing Organisation (Director, Partner, or CEO). If your audit report is not signed at all three levels, it does not meet the CERT-In standard.
CERT-In branding: Auditors are prohibited from using the CERT-In logo or describing themselves as being “from CERT-In” in any promotional material. The only permitted statement is: “This Organisation is empaneled by CERT-In for providing information Security Auditing Service.” If your auditor is claiming a stronger CERT-In affiliation than this, they are violating the guidelines.
Audit metadata submission: It is mandatory for empanelled auditing organisations to provide audit information to CERT-In within 5 days of completion of each audit. CERT-In reserves the right to join any audit team at any point to assess quality. CERT-In can also seek information about any project conducted during the empanelment period.
Section 12 provides guidance on auditor selection that auditee organisations should apply:
The guidelines also note that auditee organisations should provide feedback to CERT-In after every audit. Adverse feedback can trigger CERT-In’s Deter and Punish Framework against underperforming auditing organisations.
Based on the July 2025 guidelines, here is what organisations should review:
Audit scope: Are your audits covering all applicable engagement types for your infrastructure? Many organisations only commission VAPT but have significant exposure in areas like source code review, cloud security, endpoint security assessment, and log management audits.
Audit contracts: Do your contracts include a mandatory retest/follow-up provision? Are they for 2–3 years for critical applications? Do they specify data handling, deletion certification, and Indian data residency?
Remediation tracking: Is your organisation tracking and closing vulnerabilities from audit reports in a time-bound manner? Board-level review of audit findings and remediation status is now explicitly required.
Secure development: Are your software procurement RFPs including Secure by Design requirements? This is now an explicit CERT-In expectation for auditee organisations.
Internal audit capability: Do you have internal teams with the qualifications and skills to conduct continuous internal audits and assessments? If not, this is a gap requiring either capability building or a managed security services arrangement.
MFA for remote access: The guidelines explicitly state that Multi-Factor Authentication is mandatory for remote access to cyber infrastructure. If your organisation still has VPN or remote admin access without MFA, this is a documented compliance gap.
The CERT-In Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, July 2025) represent a significant maturation of India’s cybersecurity audit framework. For the first time, there is a single, authoritative document that defines what a cybersecurity audit in India must cover, how it must be conducted, and what both auditors and auditee organisations are responsible for.
The central message is clear: cybersecurity audits must produce genuine security improvements, not compliance certificates. Board-level accountability for security posture is not optional. And the standard of evidence, methodology, and reporting required from your auditor has been meaningfully raised.
For organisations planning their next audit cycle, the guidelines provide a useful checklist: scope coverage, auditor qualification verification, contract structure, remediation tracking, and internal monitoring. Starting this process now — rather than waiting until the next scheduled audit — is the responsible approach.
Crewtec helps Indian enterprises prepare for and manage cybersecurity audits — from gap assessment and ISO 27001 consulting to VAPT and regulatory compliance programmes. For a review of your current audit programme against the July 2025 CERT-In guidelines, contact our team.
Tags
Navigate to sections as you read.
Need Help?
Get personalised guidance on implementing strategies discussed in this article for your enterprise.
Book Free Consultation