NCIIPC Critical Information Infrastructure Audit

Introduction: The NCIIPC Critical Information Infrastructure Audit

India's most consequential digital systems - the grids that keep the lights on, the payment rails that clear billions of rupees a day, the signalling that moves trains, and the platforms that run banks, telecom carriers and government service delivery - are increasingly targeted by nation-state actors, ransomware crews and hacktivist collectives. The National Critical Information Infrastructure Protection Centre (NCIIPC), the nodal agency constituted under Section 70A of the Information Technology Act, 2000, exists to protect these systems. The NCIIPC Critical Information Infrastructure (CII) Audit is the formal assurance mechanism by which an organisation demonstrates that its notified Critical Information Infrastructure meets NCIIPC's protection expectations.

This guide is written for two audiences at once. If you are the auditor or assessor - a CERT-In empanelled auditing organisation, an internal audit lead, or a third-party assessor - it gives you a control-by-control assessment map, evidence expectations, a scoring model and a defensible audit lifecycle. If you are the implementer - the CISO, the plant OT engineer, the SOC lead, or the product/architecture team of a designated Critical Sector entity - it tells you exactly what to build, what to document and how to prepare so the audit is a formality rather than a firefight. Throughout, we distinguish between what NCIIPC and CERT-In require, what is good practice, and what merely helps.

What is the NCIIPC CII Audit

Critical Information Infrastructure is defined in the IT Act as 'those computer resources, the incapacitation or destruction of which shall have a debilitating impact on national security, economy, public health or safety'. NCIIPC is the national nodal agency for CII protection and is administratively part of the National Technical Research Organisation (NTRO). A CII notification is a legal act: once the Central Government, on NCIIPC's recommendation, declares a computer resource to be 'protected system' under Section 70 of the IT Act, unauthorised access to it attracts enhanced penalties, and the operating entity inherits specific protection obligations.

The NCIIPC CII Audit is the assurance activity that verifies those obligations are met. It is not a single fixed checklist like a product certification; it is a risk-and-control assessment framed by NCIIPC's guidelines and delivered through the CERT-In empanelment audit ecosystem. In practice a CII audit blends several things: verification that the entity has correctly identified and notified its CII; assessment of the security controls protecting that CII against NCIIPC's guideline domains; validation of the organisation's incident detection, reporting and response capability (including the mandatory reporting of incidents to NCIIPC and CERT-In); and confirmation of governance, resilience and supply-chain controls. The output is an audit report with findings, risk ratings and a remediation roadmap, plus - increasingly - a maturity rating.

How it relates to the wider Indian assurance ecosystem

• NCIIPC sets CII-specific protection guidelines and evaluates cyber security posture of CII; it operates threat intelligence sharing, issues advisories, and runs the Responsible Vulnerability Disclosure Programme (RVDP) and the National Cyber Coordination effort for CII.
• CERT-In is the national CERT and issues the Cyber Security Directions of 28 April 2022 (incident reporting timelines, log retention, KYC/records), and empanels the auditing organisations that perform CII and other security audits.
• Sectoral regulators overlay their own mandates - RBI's cyber security framework and the SAR/CSITE guidance for banks and NBFCs, SEBI's CSCRF for market infrastructure institutions and intermediaries, IRDAI's information and cyber security guidelines for insurers, and CEA/DoT/TRAI directions for power and telecom.
• ISO/IEC 27001 and, for OT, IEC 62443 provide the international management-system and industrial-control baselines that a CII audit will often reference as evidence.

Who must comply

The obligation attaches to any organisation that owns or operates a computer resource notified as CII or declared a 'protected system'. NCIIPC identifies CII across the nation's Critical Sectors. The precise list evolves, but the recognised Critical Sectors are the anchor for scoping.

Who inside the organisation is accountable

• The organisation's Board and CEO carry ultimate accountability for protecting notified CII.
• A designated CISO must be appointed and, for notified entities, is the point of contact to NCIIPC and CERT-In.
• Each notified 'protected system' should have a named system owner and, per NCIIPC's model, the organisation appoints a Chief Information Security Officer and maintains a defined point of contact (nodal officer) for NCIIPC coordination.
• Managed service providers, OEMs and cloud providers operating in-scope infrastructure inherit contractual obligations flowed down from the notified entity.

Structure of the NCIIPC CII Audit

NCIIPC's protection guidelines are organised into control domains that together cover governance, technical protection, detection, response and resilience. The audit assesses each domain. The table below sets out the domain structure used to frame a CII audit; the exact numbering follows the current NCIIPC guidelines, but the families below reflect their substance and are the practical basis for the master checklist in the next section.

Master assessment checklist

This is the operational heart of the audit. Each control family below has a short intent statement, an evidence-oriented verification table, and specific notes for OT/ICS where relevant. Auditors should treat 'What to verify' as the assertion and 'Typical evidence' as the artefacts that substantiate it. Implementers should read the same tables as a build-and-document specification. No family is optional; where a family is not applicable to a given notified system, that non-applicability must itself be documented and justified.

D1 - Governance & Risk Management

Intent: leadership has established a CII protection programme with clear ownership, an approved policy set, and a living risk assessment tied to the notified systems.

D2 - Identification & Classification of CII

Intent: the organisation has correctly identified which of its assets constitute CII, mapped interdependencies, and completed notification. Mis-scoping here invalidates everything downstream.

D3 - Access Control & Identity

Intent: access to CII is least-privilege, strongly authenticated, individually accountable, and privileged access is tightly governed.

D4 - Network Security & Architecture

Intent: the network is segmented so that a compromise cannot spread freely into CII, IT and OT are separated, and boundaries are actively defended. This domain carries special weight for OT-heavy sectors.

D5 - Application & Data Security

Intent: software touching CII is built and maintained securely, and sensitive data is classified, encrypted and protected against exfiltration.

D6 - Endpoint, Server & OT/ICS Security

Intent: hosts - IT servers, workstations, and industrial devices (PLC/RTU/DCS/HMI) - are hardened, patched (or compensated), and protected against malware, recognising that OT patching windows are constrained.

D7 - Security Monitoring & Threat Detection

Intent: security-relevant events from CII are collected, retained and analysed; detection use-cases are tuned to CII threats; and the organisation consumes NCIIPC threat intelligence and participates in the RVDP.

D8 - Incident Management & Reporting

Intent: the organisation can detect, contain, eradicate and recover from incidents, preserve evidence, and meet mandatory reporting duties to NCIIPC and CERT-In within prescribed timelines.

D9 - Business Continuity & Resilience

Intent: CII availability is protected through resilient design, tested backups, and a cyber crisis management plan; recovery objectives are defined and validated.

D10 - Supply Chain & Third-Party Security

Intent: OEMs, MSPs, cloud providers and other vendors touching CII are assessed, contractually bound, and monitored; software provenance is understood.

D11 - Physical & Environmental Security

Intent: facilities housing CII - data centres, control rooms, substations, plant floors - are physically protected and environmentally controlled.

D12 - Awareness, Training & Personnel Security

Intent: people who operate and protect CII are vetted, trained for their role, and the insider-threat risk is managed.

Scoping the audit

Correct scoping is the single biggest determinant of a useful CII audit. The scope is anchored on the notified CII, then expanded to every system that can affect the confidentiality, integrity or availability of that CII.

1. Confirm the notification: obtain the Section 70 'protected system' notification(s) and the NCIIPC identification correspondence to fix the authoritative list of CII assets.
2. Draw the boundary: include the CII itself plus all directly connected and supporting systems (identity providers, jump hosts, backup infrastructure, monitoring, network devices, engineering stations).
3. Map interdependencies: add upstream/downstream dependencies and shared services that, if compromised, cascade into CII.
4. Include OT and IT: for cyber-physical sectors, explicitly bring control systems (PLC/RTU/DCS/HMI/SCADA) and the IT/OT boundary into scope.
5. Include third parties: bring in MSPs, cloud tenancies and OEM remote-access paths that touch in-scope systems.
6. Document exclusions: any exclusion must be justified in writing and agreed with the audit sponsor; unjustified narrowing is itself a finding.
7. Fix the assessment period: define the time window for evidence (typically the preceding 12 months for recurring controls).

Implementation approach

For implementers preparing a notified system, a phased programme de-risks the audit and spreads effort over a realistic horizon. Each phase below lists activities and the deliverables an auditor will later expect to see.

Phase 1 - Identify & Govern (Weeks 0-6)

• Activities: appoint CISO and NCIIPC nodal officer; confirm CII notification status; establish the CII asset inventory and criticality rating; approve the security policy set; stand up the risk register.
• Deliverables: CII inventory with criticality tiers; approved policy suite; RACI and appointment letters; initial risk assessment; compliance obligation map (IT Act, CERT-In directions, sector regulator).

Phase 2 - Assess & Prioritise (Weeks 4-12)

• Activities: run a gap assessment against the D1-D12 domains; conduct VAPT and OT/ICS security assessment; map interdependencies and single points of failure; rate residual risk.
• Deliverables: gap-assessment report with domain scoring; VAPT and OT assessment reports; interdependency diagrams; prioritised remediation roadmap with owners and dates.

Phase 3 - Remediate & Harden (Weeks 8-24)

• Activities: implement segmentation and IT/OT separation; deploy MFA and PAM; harden hosts and controllers; stand up or tune the SIEM/SOC; close high-risk VAPT findings; formalise IR and BCP/DR.
• Deliverables: updated architecture with zones/conduits; PAM and MFA rollout evidence; hardening compliance reports; SIEM use-case catalogue; IR plan and playbooks; BCP/DR and CCMP.

Phase 4 - Operationalise & Report (Weeks 20-32)

• Activities: establish continuous monitoring; ingest NCIIPC advisories; run drills (IR tabletop, DR failover, phishing); configure CERT-In-compliant logging, NTP and 6-hour incident reporting workflow; deliver role-based training.
• Deliverables: monitoring dashboards and KPIs; drill reports; advisory-action tracker; incident-reporting SOP with test submissions; training completion records.

Phase 5 - Audit & Improve (Ongoing)

• Activities: engage a CERT-In empanelled auditor for the formal CII audit; remediate findings; re-audit high-risk items; feed lessons into the risk register; sustain the programme through periodic reviews and re-audits.
• Deliverables: audit report and management response; corrective-action plan with closure evidence; annual re-assessment schedule; continuous-improvement records.

Maturity and capability scoring model

NCIIPC evaluates the cyber security posture of CII and increasingly frames results in maturity terms. A five-level maturity scale gives both auditor and implementer a common language for rating each domain and setting improvement targets. Ratings should be assigned per domain (D1-D12) and rolled up to an overall posture.

Findings within the audit should additionally carry a risk rating so that remediation can be prioritised independently of maturity.

Assessment and audit approach

A defensible CII audit follows a structured lifecycle. The steps below are what a CERT-In empanelled audit team should execute and what an internal team should mirror when self-assessing.

1. Engagement & scoping: agree scope against the notified CII, confirm the assessment period, and issue the audit plan and evidence-request list.
2. Documentation review: examine policies, inventories, risk assessments, architecture and prior audit reports to build the control expectation baseline.
3. Design assessment: for each D1-D12 control family, evaluate whether the control is designed to meet the objective.
4. Operating-effectiveness testing: sample records over the assessment period to confirm controls operate as designed (access recertifications, patch cycles, incident reports, drills).
5. Technical validation: perform or review VAPT, configuration reviews, and OT/ICS assessments; validate segmentation and monitoring empirically, not just on paper.
6. Interviews & walkthroughs: interview the CISO, SOC, OT engineers and asset owners; walk through incident and recovery procedures.
7. Findings & rating: record findings with maturity and risk ratings, root cause and recommended remediation.
8. Reporting: deliver a draft report, hold a closing meeting, incorporate management responses, and issue the final signed report.
9. Remediation & re-test: track corrective actions to closure and re-test critical/high findings before sign-off.
10. Regulatory interface: support submission of results to NCIIPC and the relevant sectoral regulator where required, and schedule the next re-audit.

Evidence request list

The following categorised list is the evidence pack an auditor will request and an implementer should assemble in advance.

• Governance: security policy suite; board/management approval minutes; CISO and nodal-officer appointments; risk methodology and register; management review records.
• Scope & assets: CII asset inventory with criticality; Section 70 notification; interdependency and data-flow diagrams; network architecture with zones/conduits.
• Access & identity: IAM records; joiner/mover/leaver tickets; access recertification campaigns; PAM policy and session logs; MFA configuration; remote/vendor access logs.
• Network & infrastructure: firewall rule-base exports and review reports; IT/OT segmentation design; wireless survey; egress-filtering config; IDS/IPS placement.
• Application & data: SSDLC policy; VAPT and SAST/DAST reports with remediation trackers; data classification policy; crypto standard and TLS/KMS/HSM evidence; DLP alerts.
• Endpoint & OT: hardening baselines and compliance scans; patch reports and OT compensating controls; EDR coverage; application-whitelisting config; PLC/controller backups and change records; EoL inventory.
• Monitoring & detection: SIEM source inventory and log-coverage matrix; retention config (180-day); NTP config; use-case catalogue; NCIIPC advisory-action tracker; RVDP records.
• Incident & continuity: IR plan and playbooks; sample CERT-In/NCIIPC incident submissions and acknowledgements; forensic and chain-of-custody procedures; incident register and RCAs; BCP/DR and CCMP; backup and DR drill reports.
• Supply chain: vendor register and risk ratings; contracts with security and flow-down clauses; vendor assessments; SBOMs; cloud data-residency evidence.
• Physical & people: physical access logs; CCTV coverage; environmental test records; BGV records; training completion; phishing-simulation results; signed acceptable-use/confidentiality agreements.

Roles and responsibilities

KPIs to track

• Percentage of notified CII assets with complete, current inventory and criticality rating.
• MFA and PAM coverage across privileged and remote CII access (target 100%).
• Mean time to detect and mean time to respond for CII-affecting incidents.
• Percentage of CERT-In-reportable incidents reported within the 6-hour window.
• Patch/vulnerability SLA adherence for critical and high findings (IT and OT separately).
• Percentage of high/critical VAPT findings remediated within SLA.
• Log-coverage ratio (in-scope sources logging to SIEM) and retention compliance (180-day).
• Backup restore-test success rate and DR RTO/RPO achievement.
• NCIIPC advisory action-closure rate and time-to-action.
• Access-recertification completion rate per cycle.
• Security-training completion and phishing-simulation failure trend.
• Vendor assessment coverage and overdue re-assessment count.
• Domain maturity scores (D1-D12) trend over successive assessments.

Readiness checklist

• CISO and NCIIPC nodal officer are formally appointed with documented authority
• CII assets are inventoried, criticality-rated and Section 70 notification is on file
• Board-approved security policy suite covers CII explicitly
• Risk assessment covers all notified CII with treatment plans and accepted-risk records
• IT and OT networks are segmented with a controlled boundary/DMZ
• MFA protects all administrative and remote CII access; PAM governs privileged access
• Hosts and controllers are hardened to a baseline with drift detection
• Patch/vulnerability management operates with risk-based SLAs for IT and OT
• SIEM ingests in-scope logs with 180-day retention and NIC/NPL-referenced NTP
• NCIIPC advisories and threat feeds are ingested and actioned
• IR plan, playbooks and a tested 6-hour CERT-In reporting workflow are in place
• BCP/DR and a Cyber Crisis Management Plan exist and are exercised
• Backups are immutable/offline and restore-tested
• Third parties touching CII are assessed and contractually bound with flow-downs
• Physical, environmental and personnel (BGV, training) controls are evidenced
• Prior audit findings are remediated with closure evidence

Common gaps

• Under-scoped CII: only the flagship application is treated as CII while the identity, backup and monitoring plane that can compromise it is excluded.
• Flat networks and porous IT/OT boundaries: segmentation exists on the diagram but not in the firewall rule-base; engineering stations dual-homed to corporate IT.
• Weak privileged access: shared admin and vendor accounts, no PAM, MFA absent on remote OT access paths.
• Logging blind spots: OT and network devices not logging to the SIEM, retention below 180 days, or NTP not referenced to approved sources.
• Reporting gaps: no tested workflow to meet the CERT-In 6-hour incident reporting duty or to notify NCIIPC.
• OT patching paralysis: unsupported controllers with neither patches nor documented compensating controls or isolation.
• Untested resilience: BCP/DR and CCMP documents exist but have never been exercised; backups never restore-tested.
• Supply-chain blind spots: MSP/OEM remote access uncontrolled, no flow-down clauses, no SBOM or software-integrity verification.
• Advisory drift: NCIIPC advisories received but not tracked to closure.
• Stale inventory: CII inventory and interdependency maps not updated after major change, invalidating the risk picture.

NCIIPC CII mapped to other frameworks

CII audit domains align closely with mainstream frameworks, which lets an organisation reuse evidence and integrate assurance. The mapping below is indicative, not one-to-one; use it to build a shared control library.

Frequently asked questions

Need help with NCIIPC CII?

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