NERC CIP-007 Systems Security Management: Requirements and Compliance Guide for 2026
NERC CIP-007 establishes the technical and operational controls used to protect critical Bulk Electric System cyber environments from compromise. It covers system hardening, patch management, malicious-code protection, security monitoring, and user-access controls.
What Is NERC CIP-007?
NERC CIP-007 is the Critical Infrastructure Protection standard for Systems Security Management. Its purpose is to establish technical, operational, and procedural requirements that protect applicable Bulk Electric System, or BES, Cyber Systems against compromise that could cause misoperation or instability in the Bulk Electric System.
The standard focuses on five main areas:
- System hardening and unnecessary ports
- Cybersecurity patch management
- Malicious-code prevention
- Security event monitoring
- System access controls
Together, these requirements address common entry points for cyberattacks, including exposed services, unpatched vulnerabilities, malware, weak authentication, unmanaged accounts, and security events that remain undetected.
Compliance requires more than deploying security tools. Entities must maintain documented processes and evidence showing that those processes are consistently followed.
- Unnecessary ports and services must be restricted.
- Security patches require 35-day evaluations.
- Malware controls must detect and address threats.
- Security events must be logged and reviewed.
- User accounts require controlled authentication.
- Compliance evidence must remain audit-ready.
What Is NERC CIP-007?
NERC CIP-007 is the Critical Infrastructure Protection standard for Systems Security Management. Its purpose is to establish technical, operational, and procedural requirements that protect applicable Bulk Electric System, or BES, Cyber Systems against compromise that could cause misoperation or instability in the Bulk Electric System.
The standard focuses on five main areas:
- System hardening and unnecessary ports
- Cybersecurity patch management
- Malicious-code prevention
- Security event monitoring
- System access controls
Together, these requirements address common entry points for cyberattacks, including exposed services, unpatched vulnerabilities, malware, weak authentication, unmanaged accounts, and security events that remain undetected.
Quick answer: NERC CIP-007 requires responsible entities to secure applicable BES Cyber Systems by limiting unnecessary ports and services, managing security patches, preventing malicious code, monitoring security events, and controlling system access.
Compliance requires more than deploying security tools. Entities must maintain documented processes and evidence showing that those processes are consistently followed.
Which Version of NERC CIP-007 Applies in 2026?
As of July 2026, CIP-007-6 remains the mandatory version subject to enforcement. The revised CIP-007-7.1 becomes effective in the United States on October 1, 2026, when it will replace CIP-007-6.
CIP-007-7.1 preserves the standard’s five core control areas but updates terminology, expands applicability to Shared Cyber Infrastructure, and introduces specific protections for virtualized environments.
Organizations publishing or using this guide after October 1, 2026, should apply the CIP-007-7.1 requirements. Until then, compliance assessments should remain based on CIP-007-6 while implementation teams complete their transition work.
NERC CIP-007 Requirements at a Glance
| Requirement | Control area | Main obligation |
|---|---|---|
| R1 | Ports, services and system hardening | Restrict unnecessary logical and physical access points |
| R2 | Security patch management | Track, evaluate and address applicable security patches |
| R3 | Malicious-code prevention | Deter, detect, prevent and mitigate malicious code |
| R4 | Security event monitoring | Log, alert, retain and review security events |
| R5 | System access controls | Control authentication, accounts and passwords |
The applicable assets vary by requirement part. Depending on the system’s impact rating, location, and connectivity, the scope can include high- and medium-impact BES Cyber Systems and associated Electronic Access Control or Monitoring Systems, Physical Access Control Systems, and Protected Cyber Assets.
That distinction matters because not every requirement part applies to every asset in exactly the same way. Entities should map each requirement to its specific applicable systems rather than treating CIP-007 as one universal technical checklist.
NERC CIP-007 R1: Ports, Services and System Hardening
Requirement R1 of CIP-007-6 is titled Ports and Services. It requires documented processes for controlling logical network-accessible ports and protecting unnecessary physical input and output ports.
Restrict unnecessary logical ports
Where technically feasible, entities must enable only the logical network-accessible ports that they have determined are needed. This can include individual ports, port ranges, and services that depend on dynamic ports.
When a device does not provide a method for disabling or restricting its logical ports, its open ports may be treated as needed under the standard. However, the entity should still document the device limitation, its purpose, and any compensating protection.
Evidence may include:
- Approved port and service inventories
- Business or operational justifications
- Device configuration files
- Host firewall rules
- Network scan results
- Command-line output showing listening ports
- Change records for newly enabled services
CIP-007-6 specifically expects the entity to identify the need for enabled ports rather than merely recording that they are open.
A port inventory without ownership or justification can quickly become outdated. A stronger process connects each port or service to an asset, system owner, business purpose, approval, configuration baseline, and last review date.
Protect unnecessary physical ports
Entities must also protect against the use of unnecessary physical input and output ports used for network connectivity, console commands, or removable media.
Examples include:
- USB ports
- Serial ports
- Console interfaces
- Unused network interfaces
- Removable-media connections
- Maintenance interfaces
Controls may be logical or physical. An entity could disable a port through configuration, apply a port lock, restrict the interface through system settings, or use documented signage where appropriate.
The control should be selected according to the device’s capability and operational purpose. A port that must remain available for emergency maintenance may require a controlled authorization process rather than permanent disabling.
What changes under CIP-007-7.1?
CIP-007-7.1 renames R1 as System Hardening. It requires entities to disable or prevent unneeded routable-protocol network accessibility according to system capability.
It also introduces a virtualization-focused requirement for certain Shared Cyber Infrastructure. Entities must mitigate CPU or memory vulnerabilities by preventing covered virtual cyber assets from sharing CPU and memory resources with virtual cyber assets that are outside the applicable medium- or high-impact environment. Examples include virtualization affinity rules or hardware partitioning.
NERC CIP-007 R2: Security Patch Management
Patch management is one of the most time-sensitive parts of NERC CIP-007. The standard requires a repeatable process for tracking, evaluating, installing, or mitigating cybersecurity patches for applicable cyber assets.
R2.1: Identify and track patch sources
The entity must identify the sources it monitors for cybersecurity patch releases. These sources may include:
- Equipment manufacturers
- Operating-system vendors
- Application vendors
- Security-product vendors
- Approved third-party support providers
- Vendor notification portals
The process should cover applicable assets that can be updated and for which a patching source exists.
A complete patch-source register should connect each product or asset class with its vendor, supported version, notification source, internal owner, and monitoring method.
R2.2: Evaluate patches every 35 calendar days
At least once every 35 calendar days, the entity must evaluate applicable security patches released since its previous evaluation.
This does not mean every patch must be installed within 35 days of release. It means the entity must perform and document an applicability evaluation within the required cycle.
The evaluation should address questions such as:
- Does the patch apply to an in-scope product or version?
- Is the affected component installed or enabled?
- Does the vulnerability affect the entity’s configuration?
- Can the patch be tested without creating operational risk?
- Is vendor support or outage coordination required?
- Are temporary mitigations available?
Recording only “applicable” or “not applicable” may not provide enough context. A short technical rationale can make the decision more defensible.
R2.3: Apply the patch or create a mitigation plan
For patches identified as applicable, the entity must act within 35 calendar days after completing the evaluation.
The organization must generally:
- Apply the patch;
- Create a dated mitigation plan; or
- Revise an existing mitigation plan.
A mitigation plan may be necessary when immediate installation could affect reliability, require extended testing, depend on an outage, or conflict with vendor support conditions.
The plan should identify the vulnerability, affected systems, temporary controls, accountable owner, planned actions, milestones, and completion date.
R2.4: Implement mitigation plans
Once a mitigation plan is created, it must be implemented within the timeframe stated in the plan. A revision or extension should be properly documented and approved by the CIP Senior Manager or delegate when required.
Open-ended plans such as “patch during a future maintenance window” are difficult to defend. The plan should contain a specific date or measurable completion milestone.
Common patch-management evidence
Maintain:
- Asset and software inventories
- Approved patch-source lists
- Vendor notices
- 35-day evaluation records
- Applicability decisions
- Testing results
- Change approvals
- Installation records
- Mitigation plans
- Plan-extension approvals
- Closure evidence
The strongest evidence package links the original vendor notice to the affected asset, evaluation, remediation decision, implementation record, and final status.
NERC CIP-007 R3: Malicious-Code Prevention
Requirement R3 requires entities to deploy methods that deter, detect, or prevent malicious code on applicable systems. It also requires processes for responding when malicious code is detected.
The standard does not prescribe one specific product. Depending on system capability and risk, controls can include:
- Antivirus or antimalware tools
- Application allowlisting
- System hardening
- Endpoint detection controls
- Restricted execution policies
- File-integrity monitoring
- Network-based detection
- Administrative procedures
CIP-007 recognizes that some operational technology cannot support conventional endpoint-security software. Alternative methods can be used when they meet the requirement and are properly implemented.
Mitigate detected malicious code
Detection alone is insufficient. Entities must have a process for mitigating the threat when malicious code is identified.
The process should address:
- Alert validation
- Incident escalation
- Isolation decisions
- Operational coordination
- Evidence preservation
- Malware removal
- Recovery activities
- Documentation
- Post-event review
This procedure should align with the organization’s CIP-008 incident response plan so that malware events are escalated consistently.
Update signatures or patterns
When the selected malicious-code protection method uses signatures or patterns, the entity must have a process for testing and installing updates.
Evidence can include signature-update policies, testing records, deployment reports, version information, exception records, and alert-response documentation.
NERC CIP-007 R4: Security Event Monitoring
Security event monitoring helps entities identify suspicious activity and investigate incidents after they occur.
R4.1: Log required security events
Applicable systems must log security events, according to system capability, including at least:
- Successful login attempts
- Failed access attempts
- Failed login attempts
- Detected malicious code
The entity should know which assets can generate these events, which log sources are enabled, where the records are sent, and whether the configured timestamps are reliable.
A logging policy alone does not prove implementation. Evidence should demonstrate that the system was configured to generate and retain the required events.
R4.2: Generate security alerts
Applicable systems must generate alerts for events the entity determines require notification. At a minimum, this includes detected malicious code and failures of required event logging.
The alert workflow should identify:
- Events requiring alerts
- Detection method
- Alert destination
- Responsible recipient
- Escalation deadline
- Required response
- Evidence of investigation and closure
An alert that is generated but never reviewed does little to reduce risk.
R4.3: Retain logs for at least 90 days
For the systems identified in the requirement, applicable event logs must be retained for at least the last 90 consecutive calendar days, where technically feasible and except under qualifying CIP Exceptional Circumstances.
Entities should confirm that retention settings apply to the original or centralized record and that storage limitations, system restarts, or failed transfers do not silently shorten the retention period.
R4.4: Review logs every 15 calendar days
For applicable high-impact systems, a summarization or sampling of logged events must be reviewed at intervals no greater than 15 calendar days to identify previously undetected Cyber Security Incidents.
The process should define:
- Which logs are included
- How the sample is selected
- What patterns reviewers evaluate
- Who performs the review
- How findings are documented
- When findings are escalated
- How completion is tracked
A date showing that “logs were reviewed” may not be enough. Evidence should also describe the review method and document any findings.
NERC CIP-007 R5: System Access Controls
Requirement R5 addresses authentication, default accounts, shared accounts, passwords, and unsuccessful login attempts.
Enforce interactive authentication
Where technically feasible, applicable systems must enforce authentication for interactive user access.
Evidence may include system settings, authentication architecture, access procedures, screenshots, or configuration reports.
Inventory default and generic accounts
Entities must identify known enabled default or other generic account types. The inventory may be maintained by system, system group, location, or asset type.
The inventory should identify:
- Account name or type
- Associated system
- Business purpose
- Status
- Owner
- Access restrictions
- Credential-management method
- Last review date
Identify users of shared accounts
For covered shared accounts, the entity must identify the individuals who are authorized to use each account.
Shared access should not become anonymous access. Where individual accounts are not technically possible, procedures should preserve accountability through approvals, credential controls, access logs, or session records.
Change known default passwords
Known default passwords must be changed according to the cyber asset’s capability. Evidence may include implementation procedures, configuration records, commissioning checklists, or vendor documentation showing that a device receives a unique factory-generated credential.
Enforce password controls
For password-only interactive authentication, CIP-007-6 requires password parameters based on the system’s capability. These include a minimum length of eight characters, or the maximum supported length when lower, and a minimum level of complexity using three character types, or the maximum complexity supported.
Where technically feasible, password changes must also be enforced, or users must be obligated to change passwords, at least once every 15 calendar months.
For certain systems, entities must either limit unsuccessful authentication attempts or generate an alert after a defined threshold is reached.
These are minimum regulatory controls. An entity may apply stronger authentication policies where operational technology and vendor support allow it.
Start your 21-day free trial and experience how VComply helps you with your policy management and compliance maturity.
How to Build an Audit-Ready CIP-007 Program
1. Establish the system inventory
Start with a reliable inventory of applicable BES Cyber Systems and associated assets.
Record:
- Asset name and identifier
- Location
- Impact classification
- Asset type
- Operating system and firmware
- Software versions
- Connectivity
- System owner
- Patch source
- Logging capability
- Authentication capability
An incomplete inventory affects every CIP-007 requirement that follows.
2. Build a requirement-to-asset matrix
Map each part of R1 through R5 to the systems it applies to.
This prevents teams from applying controls too broadly or missing systems with special applicability conditions, such as medium-impact BES Cyber Systems at Control Centers or systems with External Routable Connectivity.
3. Assign control ownership
Each recurring activity should have an accountable owner.
Examples include:
- Port reviews
- Patch-source monitoring
- 35-day patch evaluations
- Mitigation-plan approvals
- Malware-signature updates
- Log-retention checks
- 15-day event reviews
- Account inventories
- Password-control verification
The owner should be responsible for both completing the activity and retaining evidence.
4. Track recurring deadlines
CIP-007 includes several distinct timeframes:
- Patch evaluation every 35 calendar days
- Action within 35 days after applicable-patch evaluation
- Log retention for at least 90 consecutive days
- Event review at intervals no greater than 15 days
- Password changes at least once every 15 calendar months, where applicable
These deadlines should be tracked from actual completion dates rather than assumed calendar periods.
5. Connect evidence to each control
Every compliance record should answer:
- What was required?
- Which system was affected?
- Who performed the activity?
- When was it completed?
- What result was reached?
- Were exceptions identified?
- Was follow-up completed?
- Who approved the decision?
This makes evidence easier to retrieve and reduces the risk of an undocumented gap.
Common NERC CIP-007 Compliance Gaps
Incomplete port inventories
Teams may scan systems but fail to document why each enabled service is necessary.
Missed 35-day patch evaluations
Patch releases are monitored, but reviews are not completed or documented within the required period.
Weak mitigation plans
Plans lack owners, target dates, milestones, temporary controls, or senior-manager approval for extensions.
Unsupported malware controls
The entity states that antivirus is not supported but does not document an alternative method for deterring, detecting, or preventing malicious code.
Logging without monitoring
Systems generate logs, but required alerts, reviews, or evidence of follow-up are missing.
Retention failures
Central logging is configured for 90 days, but individual devices stop forwarding logs or storage limits remove events early.
Unmanaged generic accounts
Generic accounts appear in system configurations but not in the approved account inventory.
Shared accounts without traceability
The organization knows an account is shared but cannot identify every authorized user.
Evidence scattered across systems
Policies, tickets, spreadsheets, screenshots, emails, and logs remain disconnected, making it difficult to reconstruct the compliance history.
Preparing for CIP-007-7.1
The October 1, 2026 effective date makes transition planning a current priority.
Entities should:
- Identify Shared Cyber Infrastructure supporting applicable systems.
- Inventory virtual cyber assets and their host infrastructure.
- Review CPU and memory-sharing configurations.
- Establish virtualization affinity or partitioning controls.
- Extend patch, malware, logging, and access processes to newly applicable infrastructure.
- Update terminology and system inventories.
- Revise procedures and evidence templates.
- Test the new control scope before the effective date.
CIP-007-7.1 does not remove the need for existing patching, malware protection, monitoring, and access-management processes. It extends these controls into infrastructure that may support multiple virtualized workloads.
NERC CIP-007 Compliance Checklist
- Applicable systems are accurately inventoried.
- Each requirement is mapped to the correct assets.
- Necessary logical ports and services are documented.
- Unnecessary physical ports are protected.
- Approved patch sources are recorded.
- Patch evaluations occur every 35 days.
- Applicable patches are addressed within the required period.
- Mitigation plans include dates and owners.
- Malicious-code controls reflect system capabilities.
- Signature and pattern updates are tested and installed.
- Required security events are logged.
- Malware and logging failures generate alerts.
- Applicable logs are retained for at least 90 days.
- Required event reviews occur within 15 days.
- Interactive access requires authentication.
- Default and generic accounts are inventoried.
- Shared-account users are identifiable.
- Default passwords are changed.
- Password requirements are enforced.
- Failed authentication attempts are limited or alerted.
- CIP-007 evidence is retained and searchable.
CIP-007-6 requires entities to retain evidence for each requirement for three calendar years unless directed to retain it longer. Evidence related to a noncompliance must be retained until mitigation is completed and approved or until the standard retention period ends, whichever is longer.
Frequently Asked Questions (FAQs)
What does NERC CIP-007 cover?
NERC CIP-007 covers systems security management for applicable BES Cyber Systems. Its requirements address ports and services, security patch management, malicious-code prevention, security event monitoring, and system access controls.
What is the purpose of NERC CIP-007?
Its purpose is to protect BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System.
How often must security patches be evaluated?
Security patches released by the entity’s documented sources must be evaluated for applicability at least once every 35 calendar days.
Does every applicable patch have to be installed?
Not necessarily. Within 35 days of completing the applicability evaluation, the entity may apply the patch or create or revise a dated mitigation plan. The mitigation plan must then be implemented within its documented timeframe.
How long must CIP-007 logs be retained?
Applicable security event logs must be retained for at least the last 90 consecutive calendar days, according to the specific systems, capabilities, and exceptions identified by the standard.
How often must security events be reviewed?
For applicable high-impact systems, a summarization or sampling of logged events must be reviewed at intervals no greater than 15 calendar days.
Does CIP-007 require antivirus?
It requires methods to deter, detect, or prevent malicious code, but it does not require one specific antivirus product. An entity may use antivirus, application allowlisting, system hardening, policies, or other suitable controls based on system capability.
What is changing in CIP-007-7.1?
CIP-007-7.1 updates the system-hardening language, adds Shared Cyber Infrastructure to applicable parts, and introduces controls intended to prevent covered virtual assets from sharing CPU and memory resources with out-of-scope virtual assets.
