NCIIPC and Critical Information Infrastructure protection — a practitioner reference

ControlForge free guide · 2026-05-24 · Reflects Section 70A of the Information Technology Act, 2000 and the IT (Information Security Practices and Procedures for Protected Systems) Rules, 2018

Quick reference

Applies to: any organisation whose computer resources have been declared as "Protected Systems" by gazette notification under Section 70A. As of 2026, declared Protected Systems include ICICI Bank, HDFC Bank, State Bank of India, UIDAI, NPCI, the Long Range Identification and Tracking (LRIT) ship-tracking system, several power-grid operators, oil & gas pipeline operators, telecom backbone operators, and various sensitive government systems. Sectors specifically identified as critical: power and energy, banking and finance, telecommunications, transportation, government, defence, public health, water, and strategic public sector enterprises.
Mandatory or voluntary: mandatory for declared Protected Systems; voluntary alignment for entities in critical sectors that may face future designation.
Year established: NCIIPC established by gazette notification on 16 January 2014 under Section 70A of the Information Technology Act, 2000 (as amended by the Information Technology (Amendment) Act, 2008). Operational guidance via the IT (Information Security Practices and Procedures for Protected Systems) Rules, 2018.
Issuing body: NCIIPC (National Critical Information Infrastructure Protection Centre), a unit of the National Technical Research Organisation (NTRO) under the Prime Minister's Office.
Penalties: declared Protected Systems are subject to the offences under Sections 65, 66, 70 of the IT Act for unauthorised access or attempts thereto, with penalties up to imprisonment of 10 years and fines. Non-compliance by the entity operating the Protected System surfaces through NCIIPC compliance audits and through inter-ministerial supervisory channels rather than monetary penalties directly.
ControlForge density: 35 controls curated covering NCIIPC's published guidelines and the 2018 Rules; cross-walked with RBI CSF / ITGRCA, SEBI CSCRF, CERT-In Direction 70B, and ISO/IEC 27001:2022.

What it is

NCIIPC is India's national nodal agency for the protection of Critical Information Infrastructure (CII) — computer resources whose incapacitation or destruction would have a debilitating impact on national security, economy, public health, or safety. Established in January 2014 under Section 70A of the IT Act, NCIIPC operates within the National Technical Research Organisation (NTRO), with the Director General of NCIIPC reporting through the NTRO chain to the Prime Minister's Office.

The legal foundation is the Information Technology (Amendment) Act, 2008, which inserted Section 70A authorising the Central Government to designate any computer resource that directly or indirectly affects the facility of CII as a "Protected System." A Protected System designation triggers:

Enhanced criminal penalties for unauthorised access (up to 10 years imprisonment under Section 70).
NCIIPC oversight authority including audit, advisories, and incident-response coordination.
Compliance with the IT (Information Security Practices and Procedures for Protected Systems) Rules, 2018 — the operational rules under Section 70A.
The Chief Information Security Officer (CISO) of the designated entity becomes accountable to the DG NCIIPC in addition to the entity's own corporate hierarchy.

The framework is declared, not opt-in. The Central Government, on the recommendation of sectoral ministries and NCIIPC, issues a gazette notification declaring specific computer resources of specific entities as Protected Systems. Once declared, the entity must implement the prescribed security framework and submit to NCIIPC oversight.

NCIIPC functions on a 24×7 basis providing: threat intelligence, situational awareness, alerts and advisories, vulnerability information, sector-specific guidance, incident response coordination, and training and awareness sessions for CII operators. It works with sectoral CERTs, CERT-In, and international partners.

A practical operational point: NCIIPC's role is complementary to, not a replacement for, CERT-In. CERT-In handles the general cyber-incident landscape; NCIIPC handles the specific subset of incidents affecting Protected Systems. An incident affecting a Protected System triggers reporting obligations to both NCIIPC and CERT-In under their respective frameworks.

Structure at a glance

The NCIIPC framework operates through:

Section 70 of the IT Act — declaration of any computer resource as a "Protected System" by gazette notification.
Section 70A of the IT Act — establishment of the National Nodal Agency (NCIIPC).
IT (NCIIPC and Manner of Performing Functions and Duties) Rules, 2013 — operational rules for NCIIPC itself.
IT (Information Security Practices and Procedures for Protected Systems) Rules, 2018 — operational security requirements for entities operating declared Protected Systems.
NCIIPC Guidelines — sector-specific guidance documents issued periodically.

The NCIIPC framework for Protected Systems organises required controls around:

Governance — Board approval, CISO role, organisational structure, policy framework.
Risk assessment — periodic risk assessment, threat modelling, risk register.
Information security management — policies, procedures, awareness, training.
Access control — identity management, authentication (MFA), authorisation, access reviews.
Network security — segmentation, monitoring, intrusion detection.
Application security — secure SDLC, vulnerability management, security testing.
Cryptography and data protection — encryption standards, key management.
Physical security — facility access controls, environmental.
Operations security — change management, configuration management, patch management, log management.
Supplier management — third-party risk, contractual security obligations.
Incident management — detection, response, recovery, reporting to NCIIPC.
Business continuity — BCP, DR, resilience testing.
Audit and assurance — periodic security audit, NCIIPC inspection authority.

NCIIPC has identified the following sectors as critical: power and energy; banking and finance; telecommunications; transportation (air, surface, rail, water); defence; space; law enforcement / security / intelligence; sensitive government organisations; public health; water supply; critical manufacturing; e-governance.

Who must comply

The NCIIPC compliance framework applies to entities operating declared Protected Systems. The mechanism is government declaration by gazette notification under Section 70A on the recommendation of sectoral ministries (MeitY, Finance, Power, Petroleum, Transport, Defence, Health, etc.) and NCIIPC.

Publicly known Protected System declarations (illustrative — the full list is maintained by NCIIPC):

Banking and Finance: ICICI Bank, HDFC Bank, State Bank of India, and other systemically important banks' core banking and online banking systems; National Payments Corporation of India (NPCI) for the UPI, IMPS, and other national payment rails.
Identity: Unique Identification Authority of India (UIDAI) for the Aadhaar platform.
Energy: Several power grid operators and transmission systems; oil & gas pipeline operators.
Transportation: Long Range Identification and Tracking (LRIT) for ships; selected railway systems.
Government: Various Ministry computer resources deemed critical.

Entities operating in critical sectors but not yet declared are not bound by Section 70A obligations but typically align voluntarily with NCIIPC guidelines for two reasons: (a) declaration may follow at any time and the runway to compliance is short, (b) NCIIPC guidelines are increasingly the de facto baseline for sectoral cybersecurity expectations regardless of formal declaration.

A practical scoping question: when an entity is declared, which specific systems are the Protected Systems. The gazette notification specifies the computer resources; not every system the entity operates is automatically a Protected System. Scope discipline matters: the obligations apply at the declared-system scope, and over-application creates unnecessary compliance load.

Core obligations

Walking the major obligations for entities operating declared Protected Systems.

Governance and CISO accountability. Board-approved Information Security Policy for the Protected System, reviewed annually; CISO of the entity is accountable to DG NCIIPC in addition to the entity's corporate hierarchy; documented organisational structure showing responsibilities for the Protected System's security. Maps into ControlForge clusters cl-policy, cl-roles-responsibilities, and cl-it-governance-board.

Risk assessment. Periodic comprehensive risk assessment covering threats, vulnerabilities, impacts, and likelihood; risk register maintained and reviewed; risk treatment decisions documented. Maps into cl-risk-assessment and cl-risk-management.

Asset management and information classification. Comprehensive inventory of all hardware, software, data, and personnel associated with the Protected System; classification of information assets by sensitivity; ownership clearly assigned; lifecycle management documented. Maps into cl-asset-inventory and cl-data-classification.

Access control. Strong authentication including multi-factor authentication for all privileged access to the Protected System; role-based access; periodic access reviews; privileged access management with session recording; documented joiner-mover-leaver procedures; visitor and contractor access controls. Maps into cl-access-rights, cl-multi-factor-authentication, and cl-joiner-mover-leaver.

Network security and segmentation. Network architecture documented; segmentation between the Protected System and other networks; perimeter and internal monitoring; intrusion detection and prevention; DDoS mitigation for internet-facing components; secure remote access. Maps into cl-network-protection and cl-network-segmentation.

Application security and secure development. Secure SDLC for applications associated with the Protected System; vulnerability identification and remediation with documented SLA; security testing including penetration testing by CERT-In empanelled firms; manual testing required, not just automated scanning. Maps into cl-secure-development, cl-vuln-identification, and cl-vapt-cycle.

Cryptography and data protection. Approved cryptographic algorithms and key lengths; TLS 1.2 minimum for transit; encryption at rest for sensitive data; hardware security modules (HSMs) for high-value keys; documented key management. Maps into cl-cryptography and cl-encryption.

Physical and environmental security. Physical access controls for facilities hosting the Protected System; environmental protection (power, cooling, fire suppression, water damage); equipment maintenance procedures; secure disposal of media. Maps into cl-physical-security.

Operations security. Change management with documented impact assessment and approval; configuration management with baselines; patch management with documented SLA; comprehensive logging and log retention; time synchronisation; backup with periodic restoration testing. Maps into cl-change-management, cl-configuration-management, cl-patching, cl-logging, and cl-backup.

Supplier and third-party management. Documented vendor risk assessment for all third parties with access to or impact on the Protected System; contractual security obligations including incident notification, audit rights, sub-contractor controls; ongoing oversight; particular scrutiny on cloud, managed-service, and IT outsourcing arrangements. Maps into cl-supplier-policy and cl-supply-chain-risk.

Incident management. Documented incident response procedure with classification, escalation, containment, recovery, and post-incident review; tested via tabletop exercise at least annually; incident notification to NCIIPC for any incident affecting the Protected System; parallel notification to CERT-In within 6 hours under Direction 70B; sectoral regulator notifications (RBI / SEBI / IRDAI) where applicable. Maps into cl-incident-response-execution, cl-ir-plan-prep, and cl-incident-reporting-external.

Business continuity and disaster recovery. Documented BCP and DR plans for the Protected System with defined RTO and RPO; annual testing including cyber-specific scenarios (ransomware, destructive attack); alternate-site capability; communication during disruption. Maps into cl-bcp-ict-readiness and cl-cyber-rehearsal.

Audit and inspection. Periodic security audit of the Protected System by a CERT-In empanelled firm; audit report submitted to NCIIPC; NCIIPC inspection authority including the right to inspect the Protected System, review documentation, and require remediation. Maps into cl-mandatory-audit and cl-internal-audit.

Training and awareness. Annual security awareness for all personnel with access to the Protected System; role-based training for IT and security personnel; specific awareness on the Protected System designation and its implications. Maps into cl-awareness.

How auditors test it

Three audit and inspection patterns:

NCIIPC inspection under the IT Rules 2018. NCIIPC has direct inspection authority over Protected Systems and exercises it through periodic on-site reviews, follow-up on advisories, and incident-driven investigations. Inspection scope covers the full control framework; NCIIPC inspectors are typically NTRO personnel with deep technical expertise.

Periodic external security audit by CERT-In empanelled firms. Mandated by the IT Rules 2018; report submitted to NCIIPC. Scope is the full Protected System with sampling proportionate to system criticality. Findings tracked through documented closure.

Sectoral regulator audit that overlaps. A bank's NPCI / core banking system is a Protected System; the bank also faces RBI ITGRCA / CSF audits. The audits run in parallel; evidence overlaps but each audit has its own scope and reporting line.

Evidence patterns at an NCIIPC inspection:

Gazette notification declaring the Protected System (the foundational document).
Board-approved Information Security Policy for the Protected System.
CISO appointment letter and documented accountability to DG NCIIPC.
Risk assessment register with periodic review evidence.
Asset inventory and classification.
VAPT reports with CERT-In empanelment proof and manual testing depth.
BCP/DR test reports including cyber scenarios.
Incident records and NCIIPC / CERT-In submission evidence.
Vendor risk assessment files for critical third parties.
External audit reports with closure tracking.

Common findings in NCIIPC inspections: - Scope of declaration not clearly understood — controls applied too narrowly or too broadly. - VAPT depth insufficient — automated scanning without manual penetration testing. - Third-party / cloud assessment shallow — vendor SOC 2 accepted without entity-specific configuration review. - Incident response procedures not tested against ransomware or destructive-attack scenarios. - CISO accountability to DG NCIIPC documented in policy but not exercised operationally (e.g. quarterly status reports to NCIIPC not happening).

How it relates to other frameworks

NCIIPC sits at the national-security layer of India's cybersecurity stack. It interacts with:

CERT-In Direction 70B: 6-hour incident reporting applies in parallel; CERT-In is the general cyber-incident handler, NCIIPC is the Protected-Systems-specific handler.
RBI CSF / ITGRCA: for banking Protected Systems (which are common given the financial-sector criticality designation), RBI obligations layer on top of NCIIPC obligations.
SEBI CSCRF: for capital-markets Protected Systems.
IRDAI Information and Cyber Security Guidelines 2023: for insurance-sector Protected Systems.
DPDPA 2023 + Rules 2025: from May 2027, where personal data is involved in the Protected System, DPBI breach notification applies in addition.
IT (Reasonable Security Practices) Rules 2011 (Section 43A): in force until May 2027 alongside DPDPA's runway.
ISO/IEC 27001:2022: many Protected Systems' operators hold ISO 27001 certification; the certification reduces NCIIPC audit friction but does not substitute for NCIIPC compliance.
NIST SP 800-53 Rev 5 / 800-171: useful as reference control catalogues for the operational layer.
MeitY guidelines on critical infrastructure: complementary general-government cybersecurity guidance.

A practical observation: organisations operating Protected Systems typically face the highest cumulative regulatory cyber-compliance load in India, often satisfying NCIIPC + sectoral regulator + CERT-In + DPDPA + ISO 27001 + sector-specific frameworks (e.g. PCI DSS for banks). Coordinated programme architecture is essential to avoid duplicative effort.

Common pitfalls

Five recurring failure patterns:

Scope of "Protected System" misinterpreted. The gazette notification declares specific computer resources; the operating entity may apply Protected System controls to a wider or narrower scope than declared. Fix: explicit scope statement based on the gazette text; reviewed with NCIIPC if ambiguity exists; documented and dated.
CISO accountability to DG NCIIPC documented but not exercised. The IT Rules 2018 make the CISO accountable to DG NCIIPC; in practice this requires periodic reporting and incident-driven engagement. Some entities document the accountability in policy but never operationalise it. Fix: scheduled periodic engagement with NCIIPC; documented CISO reports to DG NCIIPC; incident notification path tested.
NCIIPC advisories not actioned. NCIIPC issues alerts and advisories; entities are expected to evaluate and action them within reasonable timelines. Audit reveals advisories sitting unactioned. Fix: documented advisory triage process; SLA for evaluation and remediation; status tracked at the security committee.
VAPT depth insufficient for Protected System criticality. Automated scanning satisfies general expectations; Protected Systems warrant deeper manual penetration testing including red-team engagements. Fix: VAPT methodology calibrated to Protected System criticality; manual testing depth documented; periodic red-team exercise for highest-criticality systems.
Supply chain risk inadequately addressed. Critical infrastructure compromises through supply chain (vendor product, managed-service provider, software supply chain) have driven significant incidents internationally. NCIIPC has emphasised supply chain risk; entity programmes often haven't caught up. Fix: structured supply chain risk management; SBOM (software bill of materials) for critical applications; supplier-incident notification flowback.

Two further patterns worth flagging:

Parallel reporting paths confused. An incident affecting a Protected System triggers NCIIPC notification + CERT-In 70B (6-hour) + sectoral regulator (e.g. RBI 6-hour CIMS) + (from May 2027) DPBI 72-hour. Each has its own format and timing. Some entities have prioritised one path while missing others. Fix: pre-staged multi-regulator notification matrix; named owners per path; coordinated submission discipline.
Post-declaration runway underestimated. New Protected System declarations typically allow 6–12 months for compliance; entities sometimes treat declaration as a low-priority compliance event and find themselves under inspection without the controls being in place. Fix: contingent compliance plan for likely-declaration scenarios; immediate compliance build on declaration.

Sectoral examples and lessons. Three illustrative patterns from publicly known Protected System operators inform practical implementation:

NPCI (the operator of UPI, IMPS, AePS, and other national payment rails) was an early Protected System declaration; it operates with NCIIPC oversight in addition to RBI supervision. The operational lesson: dual-regulator oversight requires explicit coordination, with NCIIPC engagement on national-security-relevant aspects of incidents (e.g., suspected state-actor involvement) and RBI engagement on payment-system-stability aspects.
UIDAI (Aadhaar) operates with the most-comprehensive Protected System compliance regime: hardware-based identity processing, comprehensive logging, biometric-data-specific encryption, and continuous NCIIPC engagement. The complexity scales with the sensitivity of the data the system processes.
Bank core systems (the major commercial banks' core banking platforms have been declared Protected Systems) face the layered NCIIPC + RBI ITGRCA + RBI CSF stack. The integration challenge is reconciling reporting calendars and audit cycles across NCIIPC and RBI; coordinated planning at the CISO level is the standard approach.

When to use this framework

NCIIPC compliance is mandatory only for declared Protected Systems. Voluntary alignment is appropriate when:

Operating in a critical sector where future declaration is plausible.
Operating systemically important infrastructure whose disruption would have broad consequences.
Pursuing sectoral procurement where critical-infrastructure-aligned cyber posture is expected (defence, energy, large government contracts).

For non-Protected-System entities, NCIIPC guidelines serve as a useful reference for mature cyber programmes oriented toward national-security-grade resilience. The framework is more demanding than general commercial frameworks (ISO 27001, SOC 2) on threat modelling, supply chain, and resilience testing — which is appropriate to its purpose.

Indian organisations not yet declared but in critical sectors should maintain awareness of NCIIPC's annual sectoral guidance updates and follow major advisories. The framework evolves and the bar tightens; gaps that widen between voluntary posture and the formal framework become more expensive to close at declaration time.