Guide

NIS2 and NERC CIP Audit-Readiness Guide

Most OT security teams know which framework they answer to. What they lack is a clear picture of what an auditor will actually ask for, how much lead time evidence collection requires, and where scoping decisions create liability. This guide covers both NERC CIP and NIS2 in parallel, including evidence requirements, incident reporting workflows, asset categorization, and the failure patterns that show up most often in enforcement actions. Use the framework filter to highlight content relevant to your situation.

Contents

Which framework applies to you
Evidence collection
Incident reporting timelines
Asset categorization and scoping
Common audit failures
What to keep current and how often

NERC CIP-015 effective

Jul 2026

Internal network security monitoring

NIS2 enforcement

Oct 2024

EU member state transposition deadline

NIS2 early warning

24 hrs

From awareness of significant incident

Dimmed content still applies — use the filter for faster scanning

Which framework applies to you

Scope assumptions can sink a compliance program before it has even begun. Organizations assume they fall under one framework, build their program around it, and discover the error during registration or, worse, during an enforcement inquiry.

🇺🇸 NERC CIP

NERC CIP scope applies to owners, operators, and users of the Bulk Electric System as defined by NERC's Statement of Compliance Registry Criteria. Scope is determined by your registration category — Generator Owner, Transmission Owner, Distribution Provider, and similar — and by whether your assets meet the BES Cyber System definition: cyber assets that, if compromised, could impact the reliable operation of the BES within 15 minutes.

🇪🇺 NIS2

NIS2 scope applies to medium and large organizations operating in sectors the directive classifies as essential or important, including energy, water, transport, manufacturing, and digital infrastructure, among others. Review Annex I and II of the directive to confirm your classification.

Size thresholds: medium entities have 50 or more employees or annual turnover above EUR 10 million. Large entities have 250 or more employees or turnover above EUR 50 million. Member states may extend scope to smaller organizations in critical sectors.

Organizations subject to both frameworks exist, including European energy utilities with US operations and multinationals with assets in both jurisdictions. In those cases, the evidence collection and incident reporting requirements do not map cleanly onto each other, and the internal workflows need to be designed with both in mind from the start.

Evidence collection

The underlying methodology is the same regardless of framework: maintain a current, accurate record of what you have, how it is configured, who can access it, and what has happened to it. The difference is in the specific artifacts each framework requires, the formats auditors expect, and the retention periods that apply.

The four evidence categories every OT audit requires

Category	What it covers
Asset inventory	What is on your OT network, how it is classified, and when the inventory was last validated
Configuration records	Baseline configurations, change history, patch status, and deviation documentation
Access logs	Who has access to what, how access is granted and revoked, and privileged access records
Incident documentation	Detection records, response actions, timeline reconstruction, and post-incident analysis

🇺🇸 NERC CIP evidence requirements

Standard	Evidence item	Format	Retention
CIP-002	BES Cyber System inventory with impact ratings	Structured list, approved format	3 years
CIP-003	Cybersecurity policies, board or senior manager approval	Signed policy documents	3 years
CIP-005	Electronic Security Perimeter documentation, access control lists	Network diagrams + ACL exports	3 years
CIP-006	Physical Security Plan, visitor logs, access records	Plan document + logs	3 years
CIP-007	Patch management records, port and service documentation	Patch log, system hardening records	3 years
CIP-008	Incident response plan, test records, actual incident records	Plan + test documentation	3 years
CIP-010	Configuration baselines, change management records, vulnerability assessments	Baseline snapshots + change log	3 years
CIP-013	Supply chain risk management plan, vendor risk assessments	Plan + vendor documentation	3 years
CIP-015	Internal network security monitoring implementation evidence	Architecture documentation + log records	3 years

🇪🇺 NIS2 evidence requirements

Evidence item	Format	Retention	Audit trigger
Asset register covering network and information systems	Structured inventory, any format	Duration of classification	Supervisory inspection or incident
Risk management measures documentation	Policy + implementation evidence	2 years minimum	Supervisory inspection
Supply chain security assessments	Vendor risk records, contractual security clauses	Duration of vendor relationship	Incident involving third party
Incident records	Timeline, impact assessment, response log	2 years	Any reported incident
Business continuity and crisis management plans	Current approved version + test records	Current version always available	Supervisory inspection
Cybersecurity training records	Attendance, content, frequency	2 years	Supervisory inspection
Multi-factor authentication evidence	Policy + system configuration evidence	Current configuration always available	Supervisory inspection

Building an evidence collection calendar

Evidence gaps discovered during an audit cannot be reconstructed retroactively. The only reliable approach is continuous collection with scheduled validation cycles.

Minimum cadence:

Asset inventory: validated quarterly, full review annually
Configuration baselines: updated within 30 days of any change
Access reviews: quarterly for privileged access, annually for all other access
Policy reviews: annually, with approval documented
Incident records: maintained in real time, reviewed 30 days post-incident

Assign ownership. Evidence that belongs to everyone gets collected by no one. Each evidence category needs a named owner, a collection method, and a storage location that auditors can access on request.

Incident reporting timelines

The timelines are tight, the definitions are ambiguous, and the operational pressure during an active incident works against careful documentation. Build the workflow before you need it.

🇺🇸 NERC CIP incident reporting workflow

NERC CIP incident reporting runs on two parallel tracks: mandatory reporting under CIP-008 to E-ISAC, and Department of Energy reporting via Form OE-417. These are separate obligations with different triggers.

Report	Trigger	Deadline	Recipient
E-ISAC incident report	Incident affecting or potentially affecting BES reliability	Within 1 hour for imminent threat; as soon as practicable otherwise	E-ISAC
DOE OE-417	Physical attack, cyber event, or suspicious activity affecting electric system	Within 6 hours for major interruptions; 24 hours for others	DOE Office of Electricity
CIP-008 internal record	Any Cyber Security Incident that activates the incident response plan	Real-time documentation, retained 3 years	Internal, available to auditors

CIP-008 requires a documented incident response plan and evidence that it was activated and followed. The plan must be tested at least once every 15 months. Test records are audit evidence.

🇪🇺 NIS2 incident reporting workflow

NIS2 requires a three-stage reporting process for significant incidents. A significant incident is one that causes or could cause severe operational disruption or financial loss, or that affects other persons by causing considerable material or non-material damage.

Stage	Deadline	Recipient	Content required
Early warning	24 hours from awareness	National CSIRT or competent authority	Indication that a significant incident has occurred. Whether suspected malicious. Cross-border impact if known.
Incident notification	72 hours from awareness	National CSIRT or competent authority	Initial assessment of severity and impact. Indicators of compromise if available. Update on early warning.
Final report	1 month from incident notification	National CSIRT or competent authority	Detailed description, severity, impact, root cause, cross-border impact, mitigation measures taken.

"Awareness" means the moment a designated person in your organization has reasonable grounds to believe a significant incident has occurred. Document when awareness was established and by whom. This timestamp anchors all three deadlines.

Operational workflow for the 24-hour window:

01Incident detected and escalated to designated security contact
02Initial severity assessment against significance thresholds
03Decision: significant or not significant, documented with rationale
04If significant: early warning submitted, internal incident record opened
05Parallel: legal and communications notified

The 72-hour notification requires more detail but arrives before your investigation is complete. Submit what you have. Regulators understand that incident investigations take time. What they do not accept is silence.

Building the internal escalation workflow

Both frameworks require that the right people are notified quickly and that decisions are documented. The escalation workflow is the operational layer that makes reporting possible under pressure.

Minimum workflow elements:

Named incident coordinator with backup designation
Severity classification criteria written down in advance
Regulatory reporting thresholds defined in plain language, not by reference to the framework text
Pre-drafted notification templates for each reporting stage
A single incident log that captures timestamps, decisions, and actions in real time
Legal and communications on the notification chain from the first escalation

The threshold question both frameworks leave ambiguous is what constitutes a "significant" or "reportable" incident. Do not leave this to judgment during an active incident. Write your thresholds down, have legal review them, and document the rationale. When an auditor asks why you did or did not report a specific incident, the answer is your pre-defined threshold criteria, not a post-hoc explanation.

Asset categorization and scoping

Scoping is where audits are won or lost. Over-scope and you apply security controls to assets that do not require them, diverting resources from higher-risk systems. Under-scope and you create compliance gaps that auditors find, or worse, that attackers exploit.

The categorization methodology

The approach is the same regardless of framework: work from function to consequence to connectivity.

Function What does this asset do? Control, monitor, safety, historian, network infrastructure, remote access.
Consequence What happens to the physical process if this asset is compromised or unavailable? What is the blast radius?
Connectivity What can reach this asset, and what can this asset reach? Connectivity determines attack surface and compliance boundary.

🇺🇸 NERC CIP asset scoping

NERC CIP uses a defined impact rating methodology. CIP-002 Attachment 1 specifies the criteria for High, Medium, and Low impact ratings.

Impact level	General criteria	Implication
High	Generation above 1,500 MW, certain transmission facilities, control centers	Full CIP requirements apply across all standards
Medium	Generation 300–1,500 MW, certain transmission elements, EMS/SCADA	Most CIP standards apply, some with modified requirements
Low	BES Cyber Systems not meeting High or Medium criteria	CIP-003-8 only, plus organizational policy requirements

🇪🇺 NIS2 asset scoping

NIS2 does not define asset impact tiers the way NERC CIP does. The obligation is to apply appropriate and proportionate security measures based on risk. In practice, your risk assessment methodology defines your scoping, and that methodology becomes audit evidence.

Essential entity classification carries higher supervisory scrutiny and stricter requirements. Important entities face lighter obligations but are not exempt from enforcement. If your organization is on the boundary between classifications, document the classification decision and the criteria applied.

Sector-specific scoping notes:

Energy sector: OT networks controlling generation, transmission, or distribution assets are in scope. Building management systems that do not connect to operational networks are generally out of scope.
Manufacturing: NIS2 scope for manufacturing applies to specific subsectors. Review Annex I and II of the directive against your primary activity code.
Supply chain: NIS2 requires security measures for suppliers and service providers. This extends scoping beyond your own perimeter.

Assets that are commonly miscategorized

Historian servers Often treated as IT assets. If the historian receives data directly from Level 1/2 control systems and a compromise could affect BES operations, it is likely in scope.
Remote access infrastructure Jump servers, VPN concentrators, and vendor access systems are in scope if they provide electronic access to BES Cyber Systems or OT networks in scope under NIS2.
Protective relays Often overlooked in initial inventories. If they meet the BES Cyber Asset definition, they require full CIP controls.
Engineering workstations Portable or fixed workstations used to configure BES Cyber Systems are Electronic Access Control or Monitoring Systems (EACMS) and carry their own requirements.

Companion tool

Asset Scoping Decision Tool

Walk through the categorization decision for individual assets. Produces a classification with the criteria applied, ready to include in your audit documentation.

Open the tool

Common audit failures

Three structural failure modes appear across both frameworks regardless of organization size or program maturity.

Evidence gaps

The program exists on paper. Controls are in place. But when the auditor asks for evidence that a specific control was operating on a specific date, the records do not exist, cannot be located, or contradict the policy documentation. Evidence collection is an operational discipline, not an annual exercise.

Scope errors

Assets that should be in scope are not. This is discovered either during an audit, when the auditor identifies assets that meet the classification criteria and asks why they are absent from the inventory, or after an incident, when the gap in controls becomes apparent. Scope errors compound over time as new assets are added without a classification process.

Process documentation that does not match practice

The incident response plan says the CISO is notified within one hour. In practice, the CISO finds out the next morning. The patch management policy says critical patches are applied within 35 days. The patch log shows a six-month backlog. Auditors test whether documentation reflects reality. When it does not, the violation is the gap between the two, not the underlying practice.

🇺🇸 NERC CIP violation patterns

NERC publishes violation data. The standards with the highest sustained violation rates:

Standard	Common violation	Why it recurs
CIP-007	Ports and services not documented or disabled; patch timelines exceeded	Legacy assets with no patch path; configuration management gaps
CIP-010	Configuration baselines not maintained after changes; vulnerability assessments overdue	Change management process not integrated with compliance workflow
CIP-005	ESP boundary not accurately documented; access control list not current	Network changes not reflected in compliance documentation
CIP-003	Policy not approved at required level; low-impact asset obligations not met	Governance gap; low-impact assets deprioritized

Penalties under NERC CIP can reach USD 1 million per violation per day. Most penalties are significantly lower, but the exposure is real and the violation record is public.

🇪🇺 NIS2 enforcement patterns

NIS2 enforcement is in its early stages, but national competent authorities have signaled consistent focus areas:

Incomplete risk assessments that do not address supply chain risk
Incident reporting failures, particularly the 24-hour early warning window
Missing or untested business continuity plans
No documented governance structure for cybersecurity at board level

Maximum fine for essential entities: EUR 10 million or 2% of global annual turnover, whichever is higher. For important entities: EUR 7 million or 1.4% of global turnover.

Pre-audit gap assessment

Run this before every audit cycle:

01Pull your current asset inventory. Verify it against a network scan. Reconcile discrepancies before the auditor does.
02For each evidence requirement, confirm the record exists, is current, and matches the relevant policy or control.
03Walk through your incident response plan. Check whether the named contacts, escalation paths, and reporting thresholds reflect current organizational reality.
04Review the most recent NERC violation notices or NIS2 enforcement actions for your sector. Check whether the cited gaps exist in your program.
05Document the gap assessment and what was done to address each finding. The assessment itself is evidence of a functioning compliance program.

What to keep current and how often

Compliance programs decay as regulations change, organizations change, and evidence collection lapses. The maintenance obligation is ongoing.

Artifact	Update trigger	Minimum frequency	Owner role
Asset inventory	Any new asset, decommission, or network change	Quarterly validation, annual full review	OT security lead
BES Cyber System / NIS2 asset classification	Inventory change, regulatory update	With each inventory update	Compliance lead
Configuration baselines	Any configuration change	Within 30 days of change	System owner
Access control lists	Any personnel change, role change, or network change	Within 24 hours of change	Identity/access owner
Incident response plan	Organizational change, post-incident review, regulatory update	Annually, plus after any activation	Security operations lead
Policy documents	Regulatory update, organizational change	Annually, with documented approval	CISO or equivalent
Vendor / supply chain assessments	Contract renewal, vendor security incident, regulatory update	Annually per active vendor	Procurement / security joint
Evidence package completeness check	Pre-audit, post-incident	Quarterly	Compliance lead

🇺🇸 NERC regulatory watch

NERC standards development is public. Monitor:

NERC Standards Development activity for standards under revision
FERC rulemaking notices that direct NERC to develop new or modified standards
NERC's violation notice database for emerging enforcement patterns

🇪🇺 NIS2 regulatory watch

NIS2 implementation varies by member state. The directive sets minimum requirements; national law sets the specific obligations, fines, and supervisory authority. Monitor:

ENISA for guidance documents and incident reporting templates
Your national competent authority for sector-specific guidance
EUR-Lex for implementing acts and delegated regulations

When your organization crosses a NIS2 size threshold or registers in a new NERC category, the compliance obligations change immediately. Build a trigger into your annual review process that checks whether your registration status or entity classification has changed.