Comprehensive Cyber Security Audit Policy Guidelines:

The Indian Computer Emergency Response Team (CERT-In), Ministry of Electronics and Information Technology, Government of India, has issued “Comprehensive Cyber Security Audit Policy Guidelines “ (Guidelines) for cybersecurity audits. These guidelines outline the roles and responsibilities of both auditing and auditee organisations, emphasising independence, objectivity, and ethical conduct throughout the audit process. The document details th¯e scope of various cybersecurity assessments, including compliance and risk evaluations, as well as highly specialised testing such as blockchain and AI system audits. It also covers planning, execution, reporting, and data handling protocols for audits, ensuring quality control, accountability, and continuous improvement in national cybersecurity posture.

Introduction and Objectives

These guidelines are issued CERT-In under the authority of Section 70B of the Information Technology (IT) Act, 2000. Their primary objective is to provide a “structured and standardized framework for conducting cyber security audits within organizations,” aiming to ensure “consistency in audit quality, evaluation criteria, and reporting.” The document serves a dual purpose:

• For Auditees: To “assist organizations being audited (auditees) in preparing for audits, understanding requirements, and addressing deficiencies.” This helps them proactively improve their security practices and align with industry standards.
• For Auditing Organisations: To provide a “structured framework to conduct rigorous, fair, and transparent cyber security audits,” outlining responsibilities, methodologies, and best practices.

The success of cyber security audits hinges on “collaborative efforts of both the organization being audited and the auditing entity,” fostering “mutual responsibility and driving meaningful enhancements in security, risk mitigation, and regulatory adherence.”

Applicability

These guidelines are applicable to two main entities:

• CERT-In Empanelled Auditing Organisations: These are organisations empanelled by CERT-In to conduct information security audits, including vulnerability assessments and penetration testing, for both government and other sectors.
• Auditee Organisations: Public and private sector organisations that are required to or seek to evaluate their cyber security posture, identify vulnerabilities, assess risks, and ensure compliance.

Core Principles of Cyber Security Audits

The effectiveness of an audit relies on adherence to fundamental principles that ensure thoroughness, unbiased conduct, and quality:

• Independence: Auditors must be “free from bias, conflict of interest, and external influence.” Critically, “payments to the auditing organization should not be contingent upon the outcome of the audit.” Any pressure from the auditee that compromises independence must be “promptly escalated to CERT-In.”
• Objectivity: Auditors must maintain “impartiality and fairness” and avoid situations that could impair unbiased judgments, such as accepting gifts or favours. Findings must be “supported by verifiable evidence.”
• Integrity: Auditors must act “honestly and with strong ethical principles,” providing “clear, accurate, and truthful reports.”
• Professional Skepticism: Auditors should “critically assess information, question assumptions, and seek supporting evidence to identify gaps, inaccuracies, or risks.”
• Professional Judgment: Decisions should be “informed” by experience, evidence, and contextual understanding.
• Professional Care: Audits must be performed with “diligence, competence, and attention to detail,” staying updated with threats and following standards.
• Confidentiality: Auditors must “protect the privacy and integrity of the information” accessed during the audit.
• Transparency and Accountability: Audit processes, methods, and conclusions must be “clearly documented and communicated.”

Scope of Engagements Covered

The guidelines cover a broad range of cyber security audits and assessments. Auditees are expected to undergo a comprehensive audit of their Information and Communication Technology (ICT) systems “at least once a year.” Key types of engagements include, but are not limited to:

• Compliance Audits: Ensuring adherence to standards, regulations, and policies.
• Risk Assessments: Identifying and evaluating risks from cyber threats.
• Vulnerability Assessments & Penetration Testing: Identifying and exploiting potential vulnerabilities.
• Network Infrastructure Audits: Reviewing hardware, software, configurations, and controls.
• Operational Audits: Assessing efficiency and effectiveness of security operations.
• Application Security Testing: Including web, mobile, and API applications, often involving DAST and SAST for critical applications.
• Source Code Review: Identifying vulnerabilities and coding errors.
• Red Team Assessments: Simulating real-world attacks.
• Cloud Security Testing: Evaluating cloud-based systems.
• Industrial Control Systems (ICS)/Operational Technology (OT) Security Testing: Specific to critical industrial processes.
• IoT/IIoT Security Testing: Assessing connected devices.
• AI System Audits: Evaluating security, ethics, transparency, and data integrity of AI systems.
• Vendor Risk Management Audits: Assessing third-party cybersecurity practices.
• Blockchain Security Audit: Assessing blockchain systems, smart contracts, and infrastructure.
• SBOM/QBOM/AIBOM Auditing: Ensuring transparency, traceability, and integrity of software, quantum, and AI system components.

Applicable Standards and Frameworks

Auditors must utilise industry-standard methodologies and best practices, discouraging “solely tools-based testing” due to its limitations.

• Discouraged Lists: Limited lists like OWASP Top 10 and SANS Top 25 are not to be considered as comprehensive standards for audits.
• Required Frameworks: Audits must include discovery of all known vulnerabilities based on comprehensive standards/frameworks such as:
  o ISO/IEC
  o Cyber Security Audit Baseline Requirements (published by CERT-In)
  o CSA Cloud Controls Matrix (CCM) for Cloud Security
  o Open Source Security Testing Methodology Manual (OSSTMM3)
  o OWASP Web Security Testing Guide, ASVS, MSTG, DevSecOps Maturity Model
• Regulatory Compliance: Guidelines and directions issued by CERT-In and other regulators must be included in the audit scope by default. For critical applications with Sensitive Personal Identifiable Information (PII) data, compliance with the “Comprehensive Audit Program Checklist – Cyber and Information Security Audit” (282 control points) is mandatory.
• Vulnerability Classification: Auditors are required to implement both CVSS (Common Vulnerability Scoring System) for severity (0.0 to 10.0) and EPSS (Exploit Prediction Scoring System) for likelihood of real-world exploitation (0 to 100%) in their reports. Every reported observation/vulnerability must also be mapped with CWE (Common Weakness Enumeration) and CVE (Common Vulnerabilities and Exposures) numbers.

Audits should be viewed as a “tool for the continual process improvement of the auditee organization’s security posture, rather than a mere formality for compliance,” adopting a “risk-based and domain-specific approach.”

Auditee Responsibilities

Auditee organisations bear the ultimate responsibility for their cyber security posture and active engagement in the audit process:

• Governance and Oversight: Top management must “review & approve the audit program, scope and remedial measures.” The frequency and broad scope of audits should be included in annual reports (excluding confidential details).
• Risk Acceptance and Exception Handling: The head of the auditee organisation must authorise and accept “risk treatment techniques” for reported vulnerabilities and any exceptions.
• Remediation and Follow-up: Auditees are responsible for “implementing the recommended actions to improve security and mitigate risks” and for “patching and correction of vulnerabilities.” Follow-up audits by the auditing organisation are required after vulnerability closure.
• Internal Monitoring and Development: Auditees should conduct continuous internal audits and ensure “Secure by Design” principles are mandatory in RFPs for software development.
• Application Handling and Audit Artefacts: Auditees should capture audit-related artefacts (hash values, versions, timestamps) to be featured in reports. Version control and change management are essential.
• Asset Management and Infrastructure Security: The auditee is solely responsible for the “complete audit process of the information infrastructure,” including defining scope and selecting the auditor (unless specifically mandated otherwise). Key responsibilities include:
  o Maintaining and monitoring asset inventory.
  o Implementing proper patch management.
  o Ensuring secure configuration of assets (e.g., blocking unused ports, changing default credentials).
  o Implementing the “principle of least privilege.”
  o Restricting and securing remote access with MFA.
  o Using genuine and updated software, and secure protocols.
• Onboarding and Exit Conferences: Auditees should participate in presentations by the auditing organisation during onboarding (scope, methodology, timelines) and exit (key findings, overall security posture, risks).

Auditor Responsibilities

Auditing organisations have distinct responsibilities ensuring the quality, ethics, and reporting of audits:

• Role and Accountability: The auditor’s role is to “evaluate the effectiveness of these measures, verify compliance… and provide recommendations for improvement.” They are not responsible for directly managing or maintaining the auditee’s security measures.
• Personnel Conduct and Competency: Audit personnel must:
  o Adhere to information classification, confidentiality, security, and privacy requirements.
  o Have a valid Non-Disclosure Agreement (NDA) with their employer, and potentially with the auditee.
  o Understand and avoid conflicts of interest.
  o Possess experience, maturity, and adequate competency in security technologies, processes, controls, trends, fact collection, and reporting.
  o Only deploy manpower declared to CERT-In.
• Handling Audit Related Data: Audit data must be treated as confidential, stored securely (preferably encrypted on laptops during engagement), and located only on systems in India. Data must be “wiped from auditor’s laptop after completion of the project,” with a certificate issued to the auditee. Audit reports may be retained with safeguards but should not include other auditee data. Data retention periods are specified.
• Reporting: Audit reports must be “clear, precise and comprehensive,” including scope, duration, methodologies, tools, findings, prioritisation, and details of manpower involved. Reports must be signed by the auditors, reviewed by a designated reviewer (not part of the audit team), and authorised by the Head of the Auditing Organisation, with the audit certificate signed by the Lead Auditor and Head.
• Awareness, Training, and Outreach: Auditing organisations should conduct in-person sessions for clients on audit awareness and maintain a professional relationship to keep auditees updated on security developments.
• CERT-In Affiliation and Branding: Auditors must not use the CERT-In logo or imply CERT-In is part of their contract without prior written permission. They can only state: “This Organization is empaneled by CERT-In for providing information Security Auditing Service.”
• Sharing Audit Report and Metadata: It is mandatory for auditing organisations to provide audit information to CERT-In “within 5 days of completion of audit.” This data will be kept confidential by CERT-In.

Planning the Audit

Effective planning is crucial for both parties:

Guidelines for Auditee Organisations:

• Defining Scope: Auditees must define a “complete and comprehensive scope,” including all cyber infrastructure components (systems, applications, networks, OT/ICS, cloud, APIs, databases, code review, data security, incident response capabilities). The scope must be derived from a consolidated and updated asset inventory, vetted by the internal audit team and CISO, and include third-party/vendor risk assessments.
• Audit Frequency and Trigger Conditions: Audits should be conducted “at least once in a year,” with increased frequency based on criticality. “Major changes” (high-risk, impactful to security) to systems or applications must undergo a cyber security audit before implementation.
• Critical Assets: Critical databases and applications must be identified and included in the scope. For critical applications, DAST and SAST are required.
• Audit Team and Stakeholder Coordination: A technical point of contact team should be assigned by the auditee to assist and monitor the audit.
• Handling Hosted/Third-Party Infrastructure: Responsibility for auditing owned components lies with the owner; for website content hosted elsewhere, the content owner is responsible for auditing their data/software.
• Secure Handling of Reports and Data: A clear mechanism for secure storage and destruction of reports and data by the auditing organisation must be in place.
• Contracts, Agreements, and Governance: Contracts must clearly identify audit criteria, scope, plan, tasks, documentation, support, reporting requirements, and revalidation clauses. A Non-Disclosure Agreement (NDA) is mandatory. Escalation matrices must be defined.

Guidelines for Auditing Organisations:

• Legal and Confidentiality: Ensure NDA is signed and maintain confidentiality. Inform auditees about mandatory sharing of metadata/reports with CERT-In.
• Audit Team and Tool Authorisation: Share audit team details and procure documented approval. Provide a list of tools to be installed, confirming no IPR or license violations. Tools must be tested in a controlled environment and results approved by the auditee. Written approvals are needed for penetration tests and tool installation in the auditee’s presence.
• Scope and Objectives: Clearly communicate the type of audit, report format, standards, assets covered, data handling, timelines, and the requirement to share data with CERT-In. Advise auditees to base scope on a centralised, updated asset inventory. Explicitly mention version-specific details for applications in reports.
• Stakeholder Communication: Eliminate the “expectation gap” by clearly explaining the audit process and deliverables. Communicate any exemptions, limitations, or constraints.
• Report Handling and Distribution: Obtain official email IDs and mobile numbers for secure, password-protected report distribution to designated contacts only.
• Risk Escalation: A well-defined escalation matrix must be shared with relevant authorities.
• Remote/High-Risk Tests: Disclose auditor identity and obtain formal written permission for remote testing. Obtain specific written permissions for DoS/DDoS, process testing, or social engineering. Notify auditee of any changes, high-risk findings, or testing issues, and provide progress updates.

Performance of the Audit

• Auditee Preparation: Limit notification of the audit to key personnel to prevent temporary security measure increases. Avoid unusual or major network changes during the audit.
• Access Management: Provide only temporary, privileged access (credentials, tokens) and ensure immediate revocation upon completion.
• Auditee Monitoring: Track audit execution and adherence to timelines.
• Auditor Pre-Audit: Hold pre-audit discussions to eliminate ambiguities and ensure alignment. Assign personnel with appropriate domain expertise. Revalidate previous observations and record unresolved issues as repeat observations. Verify compliance with CERT-In directions on information security practices.
• Secure and Ethical Testing: Immediately report “high-risk vulnerabilities” (e.g., discovered breaches) to auditee and CERT-In. Obtain explicit written permission for DoS/DDoS testing. Conduct social engineering and process testing ethically, targeting only explicitly agreed-upon employee groups, and avoiding external entities without specific written consent. Conduct passive testing in critical environments to avoid disruption.
• Testing Environment: Clearly specify the environment (Test, Development, UAT, Pre-Production, or Production) where the application was tested. Obtain application hash values and version numbers.
• Quality and Confidentiality: Adhere to timelines. Effectively manage auditee data security and confidentiality with defined procedures. Implement a “maker-checker concept” with a separate verification team.
• Incident Management: Have an Incident Management Policy and escalation matrix, shared with the auditee.
• Review and Coordination: Conduct regular meetings with auditee SPOCs to review progress.

Forming an Opinion, Conclusion, and Reporting

• Report Structure: Audit report format should be mutually agreed upon. Reports must be clear, precise, and comprehensive, including all details of the audit process, scope, duration, methodologies, tools, findings, prioritisation, sampling, manpower, exemptions, and limitations. All assets in scope must be mentioned. Report versions must be maintained.
• Signatures: Reports and certificates must be signed by the auditors who conducted the audit, reviewed by a designated mid-management reviewer (not part of the audit team), and authorised by the Head of the Auditing Organisation.
• Executive Summary and Risk Categorisation: The report must include an executive summary for top management, translating technical findings into business risks and assessing overall security posture. Vulnerabilities must be categorised using both CVSS for severity and EPSS for likelihood of exploitation and mapped to CWE and CVE numbers.
• Remediation and Follow-up: Suggested remedies must be practical. Critical/high vulnerabilities must be notified immediately during the audit. Reports should mention timelines for vulnerability closure. Final audit reports are issued after the closure of vulnerabilities and follow-up audits, particularly for applications hosted in production environments.
• Report Delivery: Use only official email IDs for sharing reports and related data, using secure methods (passwords, encryption) and communicating only to specified PoCs. All communication channels must be end-to-end confidential.
• Data Handling and Disclosure: Sharing auditee-related data requires prior consent, except for disclosures mandated by law or Indian regulatory bodies (e.g., CERT-In). Data should not be shared with overseas entities without specific written authorisation. Auditing organisations must inform the auditee and take action if client audit data is leaked.

Consequences of Non-Compliance

CERT-In has a “Deter and Punish Framework” for non-compliance, poor quality audits, or violations of guidelines/empanelment terms. Graded actions include:

• Move to watch list with warning & written commitment: For inadequate closure of non-compliances, lack of relation between noting and issues, inadequate sample details, minor impact violations of T&Cs, missing up to 2 vulnerabilities, first instance of conflict with auditee or non-compliance to data collection framework.
• Suspension: For adverse feedback (technical competency, auditor attributes), repeated failures in planning/coverage, issues appearing soon after audit, major impact violations of T&Cs, multiple adverse reports of missing vulnerabilities, or multiple non-compliance instances for data collection. Suspension can be revoked upon satisfactory corrective action.
• Withdrawal of Empanelment: For auditing malpractices, substandard services, or failure to cover scope of work, leading to actions as per GFR and Department of Expenditure O.M.
• Penal & Legal Actions: For breach of trust, digital break-ins, damage or attempts to damage auditee interests/infrastructure, as per applicable laws.

Conclusion and Feedback Mechanism

The guidelines aim to provide a “structured, standardized, and practical framework for conducting cyber security audits” to “strengthen the overall cyber resilience of the ecosystem.” CERT-In encourages “collaborative and iterative approach” and invites feedback from both auditing and auditee organisations to ensure the framework “remains practical, relevant, and aligned with evolving technological and threat landscapes.”