CERT-In Comprehensive Cyber Security Audit

Introduction: The CERT-In Comprehensive Cyber Security Audit

The Indian Computer Emergency Response Team (CERT-In), operating under the Ministry of Electronics and Information Technology (MeitY), is the national nodal agency for responding to computer security incidents under Section 70B of the Information Technology Act, 2000. A CERT-In Comprehensive Cyber Security Audit is a structured, evidence-driven assessment of an organisation's information technology infrastructure, applications, networks, cloud environments and processes against recognised security baselines, conducted by an auditing organisation empanelled by CERT-In. It is not merely a vulnerability scan; it is a holistic examination of technical controls, governance, incident readiness and regulatory conformance that produces an auditor's opinion and a prioritised remediation roadmap.

This guide is written for two audiences simultaneously. For the auditor, it lays out the assessment methodology, the control-by-control verification steps, and the specific evidence to demand and inspect. For the implementer, it explains what to build, harden and document so that an audit passes on the first attempt. Throughout, we anchor the guidance to the real CERT-In instruments that give the audit its authority: the CERT-In Directions dated 28 April 2022 issued under Section 70B(6), the Guidelines on Information Security Practices for Government Entities (2023), the CERT-In empanelment framework for security auditing organisations, and the sector-specific mandates issued by the RBI, SEBI, UIDAI, NPCI, PFRDA and IFSCA that require CERT-In-empanelled audits.

What is the CERT-In Audit Policy

The 'CERT-In Audit Policy' is the collective framework of directions, guidelines, empanelment rules and audit methodology under which cyber security audits are commissioned and delivered in India when CERT-In empanelment is required. It has four interlocking layers.

• Legal basis: Section 70B of the IT Act, 2000 empowers CERT-In to call for information, issue directions, and require audits. The IT (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013 operationalise this.
• Binding directions: The CERT-In Directions of 28 April 2022 mandate 180-day log retention within Indian jurisdiction, synchronisation of all ICT system clocks to NPL/NIC NTP servers, mandatory reporting of 20 categories of cyber incidents within 6 hours of noticing, KYC and record-keeping for data centres/VPS/cloud/VPN providers, and specific record-keeping for virtual asset service providers.
• Guidelines: The CERT-In Guidelines on Information Security Practices for Government Entities (June 2023) provide baseline controls across governance, network, application, cloud, endpoint, identity, data and third-party security, and are widely used as the audit baseline for public-sector and CII-adjacent entities.
• Empanelment and methodology: CERT-In maintains a panel of empanelled Information Security Auditing Organisations. An audit under this policy follows a defined lifecycle - scoping, information gathering, vulnerability assessment, penetration testing, configuration and process review, reporting, and re-audit/closure verification.

An audit conducted under this policy typically covers vulnerability assessment and penetration testing (VAPT) of externally and internally exposed assets, secure configuration review, source code and application security review, cloud security posture review, network architecture review, and a governance/process review mapped to the directions and any applicable sectoral circular. The deliverable is a signed audit report with a risk-rated findings register, evidence annexures, and a closure/re-audit certificate once high and critical findings are remediated.

Who must comply

CERT-In-empanelled cyber security audits are mandatory or strongly expected for a broad set of organisations, driven either by the CERT-In directions directly or by sector regulators who cite CERT-In empanelment in their own circulars.

Structure of the CERT-In Audit Policy

For audit execution, the framework is best expressed as a set of control domains, each decomposed into control families and individual verifiable controls. The table below sets out the domain structure CyberSigma uses to organise a CERT-In-empanelled comprehensive audit; it aligns the CERT-In directions and government guidelines with the technical assessment areas an empanelled auditor must cover.

Master assessment checklist

This is the operational core of the audit. Each domain is expanded below into a control group with a table of what the auditor must verify and the typical evidence that satisfies each control. Implementers should treat the 'What to verify' column as their build-and-document requirement, and the 'Typical evidence' column as their evidence register. No domain is omitted.

D1 - Governance, Risk & Compliance

D2 - Incident Response & Reporting

D3 - Logging, Monitoring & Time Synchronisation

D4 - Identity & Access Management

D5 - Network Security

D6 - Endpoint & Server Hardening

D7 - Application Security

D8 - Vulnerability Assessment & Penetration Testing

D9 - Data Security & Cryptography

D10 - Cloud & Virtualisation Security

D11 - Third-Party & Supply Chain Security

D12 - Business Continuity & Resilience

D13 - Physical & Environmental Security

D14 - Awareness & Human Factors

Scoping the CERT-In audit

Correct scoping determines the validity of the audit opinion. A scope that omits an internet-facing asset or a sensitive data flow renders the certificate misleading and, for regulated entities, non-compliant. Scoping must be documented, signed off by the auditee's management, and reflected in the audit report.

• Enumerate all in-scope assets: public IP ranges and domains, internal networks, applications and APIs, cloud accounts and regions, databases, endpoints, and OT/ICS where applicable.
• Identify sensitive data flows and their storage locations to confirm data localisation and 180-day log retention within India.
• Confirm regulatory drivers (RBI, SEBI, UIDAI, NPCI, PFRDA, IFSCA) as each imposes specific scope items - for example switch/host security for NPCI or the Aadhaar Data Vault for UIDAI.
• Define testing windows, rules of engagement, escalation contacts, and out-of-scope exclusions with written justification.
• Distinguish grey-box (credentialed) versus black-box testing per asset; regulated audits usually require authenticated testing for internal assets.
• Agree the certification threshold: which severity levels (critical/high) must be closed and re-tested before the audit certificate is issued.

Implementation approach

CyberSigma delivers CERT-In readiness and audit as a phased engagement so that implementers can remediate ahead of the formal empanelled audit and pass on first submission.

Phase 1 - Discovery & Gap Assessment

• Activities: asset discovery, documentation review, control-mapping workshops against CERT-In directions and applicable sectoral circulars, and a lightweight VA baseline.
• Deliverables: scoping document, control gap register with severity, applicability matrix, and a prioritised remediation roadmap.

Phase 2 - Remediation & Hardening

• Activities: implement/document policies, enable 180-day log retention in India, enforce NPL/NIC NTP, deploy MFA and PAM, harden configurations, fix critical/high vulnerabilities, and stand up the incident-reporting workflow.
• Deliverables: hardened baselines, updated policy set, evidence pack, and a defect burndown showing closure of critical/high items.

Phase 3 - Formal Audit (VAPT + Review)

• Activities: empanelled-auditor VAPT (external and internal), secure-configuration review, source-code/application review, cloud posture review, and process/governance review with interviews.
• Deliverables: draft audit report with risk-rated findings register and evidence annexures.

Phase 4 - Closure, Re-test & Certification

• Activities: remediate residual findings, submit fix evidence, and undergo re-test of high/critical items.
• Deliverables: signed audit closure/re-audit certificate suitable for submission to CERT-In or the sector regulator, plus a continuous-monitoring plan.

Phase 5 - Sustain & Continuous Assurance

• Activities: periodic VA scans, quarterly access reviews, drill exercises, and monitoring of CERT-In advisories/vulnerability notes.
• Deliverables: recurring assurance dashboard, updated risk register, and readiness for the next audit cycle.

Maturity and capability model

CyberSigma rates each control domain on a five-level capability scale so that management can see where they stand and target investment. Regulated entities are generally expected to operate at Level 3 (Defined) or above across all domains, with Level 4+ for critical financial-sector functions.

Assessment and audit approach

The empanelled audit follows a disciplined, repeatable lifecycle. The steps below are the sequence CyberSigma executes and that an auditor should expect.

1. Initiation and scoping: agree assets, rules of engagement, escalation paths and certification threshold; obtain signed authorisation for testing.
2. Information gathering: collect policies, network diagrams, asset inventory, prior audit reports and access to test environments.
3. Vulnerability assessment: run authenticated and unauthenticated scans across in-scope assets and de-duplicate/validate results.
4. Penetration testing: manually validate exploitability, chain vulnerabilities, and demonstrate business impact with proof-of-concept.
5. Configuration and secure-baseline review: benchmark servers, network devices, databases and cloud against CIS/vendor standards.
6. Application and source-code review: perform SAST/DAST and manual review against OWASP ASVS/Top 10 and API security best practice.
7. Process and governance review: interview stakeholders and inspect evidence for GRC, IR, logging, IAM, BCP and third-party controls.
8. Risk rating and reporting: assign CVSS-based severities, contextualise to business risk, and produce the draft findings register.
9. Remediation support and re-test: verify closure of critical/high findings and update statuses.
10. Certification and closure: issue the signed audit certificate and submit to CERT-In or the relevant regulator; agree the next-cycle plan.

Evidence request list

The following categorised list is the evidence the audit team will request. Implementers should assemble these into an indexed evidence pack before the audit begins.

• Governance: information security policy, risk register, asset inventory, org chart/RACI, CISO appointment, exception register, compliance calendar.
• Incident response: IR plan, reportable-incident taxonomy, 6-hour reporting SOP, CERT-In acknowledgements, playbooks, tabletop records.
• Logging & time: log retention policy, storage-location attestation (India), SIEM source inventory, NTP configuration to NPL/NIC.
• Identity & access: MFA/PAM configuration, RBAC matrix, JML tickets, access-recertification sign-offs, KYC records where applicable.
• Network & endpoint: network diagrams, firewall rule base and review, IPS/IDS config, EDR coverage, patch-compliance reports, hardening scans.
• Application & cloud: SDLC policy, SAST/DAST/PT reports, SBOM/SCA output, CSPM findings, cloud IAM and logging config.
• Data & crypto: classification policy, encryption/TLS evidence, key-management records, DLP reports, data-localisation attestations.
• Continuity: BCP/DR plans, BIA, backup job logs, restore-test and DR-drill reports, ransomware recovery runbook.
• Third-party: vendor assessments, contracts/DPAs, KYC and retention records, sub-processor lists.
• Physical: data-centre access logs, CCTV retention, environmental certificates, media-disposal records, provider SOC 2/ISO certificates.
• Awareness: training completion records, phishing-simulation results, signed acceptable-use acknowledgements.
• Prior assurance: previous audit/VAPT reports, closure certificates, and remediation trackers.

Roles and responsibilities

KPIs to track

• Mean time to report incidents to CERT-In (target: well under the 6-hour mandate).
• Percentage of ICT systems with 180-day logging enabled and stored in India.
• Percentage of systems synchronised to NPL/NIC NTP with drift within tolerance.
• Critical/high vulnerability remediation SLA adherence and open-finding ageing.
• MFA and privileged-access coverage across in-scope accounts.
• Patch compliance percentage by severity within defined SLAs.
• Phishing-simulation click rate and report rate trends.
• Backup restore-test success rate and DR-drill RTO achievement.
• Access-recertification completion rate per cycle.
• Percentage of critical vendors with current security assessments and contract clauses.
• Audit findings closed before certification versus carried forward.
• Time from finding to closure verification (re-test cycle time).

Readiness checklist

• Scope document signed off by management with all internet-facing and internal assets enumerated
• Information security policy approved, current and communicated
• CERT-In point of contact nominated and incident-reporting SOP tested against the 6-hour rule
• Logs enabled with 180-day retention stored within Indian jurisdiction
• All clocks synchronised to NPL/NIC NTP servers
• MFA enforced on remote, privileged and administrative access
• Privileged access vaulted and access recertification completed
• Critical and high vulnerabilities from prior scans remediated or in a tracked plan
• Secure configuration baselines applied and validated by benchmark scan
• Application security testing completed against OWASP ASVS/Top 10 with fixes
• Cloud posture reviewed with no public data exposure and least-privilege IAM
• Backups verified by restore test and DR drill conducted with RTO/RPO evidence
• Vendor KYC and 5-year retention records maintained for infra providers
• Evidence pack assembled, indexed and mapped to the applicable sectoral circular
• Awareness training and phishing simulation completed with metrics captured

Common gaps

• Logs retained for less than 180 days or stored outside India, breaching the CERT-In directions.
• System clocks not synchronised to NPL/NIC, undermining incident correlation and forensic timelines.
• No tested capability to report incidents within 6 hours; reliance on undocumented ad hoc escalation.
• MFA absent on VPN, cloud console or privileged accounts; long-lived cloud access keys in use.
• Firewall rule base containing any-any rules and unreviewed legacy exceptions.
• Publicly exposed storage buckets, databases or management interfaces discovered during external testing.
• Hard-coded secrets in source code and no SBOM or SCA scanning for vulnerable dependencies.
• Backups not immutable/offline, leaving the organisation exposed to ransomware encryption of backups.
• Critical/high vulnerabilities left open past SLA with no risk-accepted exception record.
• Vendor contracts lacking security, audit-right, breach-notification and data-localisation clauses.
• Access reviews and de-provisioning not performed, leaving orphan and dormant privileged accounts.
• Audit conducted by a non-empanelled provider, which regulators may reject.

CERT-In Audit Policy mapped to other frameworks

CERT-In audit domains map closely to major standards and sectoral frameworks, allowing organisations to reuse evidence across multiple compliance programmes.

Frequently asked questions

Need help with CERT-In Audit Policy?

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