How to use this industry guide
Use this guide to separate ordinary IT support from operational technology and critical infrastructure support. A software vendor supporting back-office utility billing is different from a contractor maintaining systems connected to generation, transmission, distribution, control centers, substations, or cyber assets that affect grid reliability.
What usually drives cybersecurity obligations in this sector
Electric-sector obligations are usually driven by system role and criticality. Contractors may support utility IT, OT, industrial control systems, energy management systems, physical security systems, communications, cloud monitoring, incident response, emergency planning, or government-owned energy facilities.
Where the work touches regulated electric infrastructure, contractors may see reliability, supply-chain, access-control, vulnerability-management, logging, personnel-risk, physical-security, and incident-reporting expectations. Federal contracts or grants may add FAR, DFARS, NIST, FISMA, CUI, CIRCIA-readiness, or agency-specific requirements.
Requirements to review for this sector
Review these areas first:
- FAR 52.204-21 for federal contract information.
- NIST SP 800-171 where energy-related CUI is handled on contractor systems.
- FISMA/NIST SP 800-53 where the contractor operates a government information system.
- Sector-specific electric reliability or grid cybersecurity requirements when the contractor supports regulated assets.
- CIRCIA-readiness if the organization may be a covered critical infrastructure entity once final rule obligations apply.
- Agency-specific requirements for DOE, DHS/CISA, DOD energy programs, federal facility operators, public utilities, or state/local energy customers.
- Supply-chain, remote-access, OT monitoring, vulnerability, and incident-reporting clauses.
Implementation focus areas
Electric-sector contractors should separate corporate IT risk from OT and grid-impacting risk. Implementation evidence should include asset inventories, remote-access controls, privileged-access records, network segmentation, vulnerability-management procedures, secure maintenance processes, incident escalation paths, supplier access controls, backup/recovery plans, change-management records, and documentation showing whether contractor personnel or systems can affect operational availability.
For OT support, practical compliance often depends on controlling maintenance pathways. Contractors should know who can connect, from where, using what credentials, through what logging, and under what customer approval process.
This page is an index. The actionable items are the requirements below.
Standards and frameworks commonly adopted
Energy
Energy producers, grid operators, and the bulk-electric and pipeline critical-infrastructure sector.
Adopts: NERC CIP— Bulk electric system assetsAdopts: NIST— Sector cyber risk management
Mapped requirements and controls
Data-Type / Sector-Specific Safeguards
Requirement
Protect Critical Energy/Electric Infrastructure Information in accordance with 18 CFR 388.113.
Plain-English explanation
Critical Energy/Electric Infrastructure Information is energy-sector information that could aid an attack on the grid. 18 CFR 388.113 sets FERC's rules for designating and releasing CEII. Energy contractors and their vendors should treat CEII as restricted and follow FERC's access process.
Implementation examples
View implementation examples
Protecting CEII:
- Identify documents that meet FERC's CEII definition and mark them accordingly.
- Restrict access to authorized requesters via FERC's CEII process.
- Apply need-to-know and secure storage controls.
- Coordinate with the asset owner before sharing CEII.
Required by
Requirement
Decontrol CUI When Safeguarding Is No Longer Required in accordance with 32 CFR 2002.18.
Plain-English explanation
CUI status is not permanent. 32 CFR 2002.18 lets the designating agency decontrol information when safeguarding is no longer required, and contractors should not keep treating decontrolled data as CUI. Decontrol is an agency decision — contractors follow it rather than make it.
Implementation examples
View implementation examples
Handling decontrol:
- Follow agency decontrol instructions and remove or update CUI markings accordingly.
- Note the decontrol decision and date in your records.
- Do not unilaterally decontrol CUI you received; confirm with the designating agency.
- Update access controls once data is decontrolled.
Required by
Requirement
Destroy CUI Using Approved Methods in accordance with 32 CFR 2002.14(f); NIST SP 800-88.
Plain-English explanation
CUI must be destroyed using methods that make it unreadable and irrecoverable. 32 CFR 2002.14(f) requires approved destruction, and NIST SP 800-88 provides the media-sanitization guidance the government relies on. Improper disposal is a common and avoidable cause of CUI loss.
Implementation examples
View implementation examples
Approved destruction practices:
- Cross-cut shred or pulp paper CUI to NSA/agency-approved standards.
- Sanitize digital media per NIST SP 800-88 (clear, purge, or destroy as appropriate).
- Use destruction logs or certificates of destruction for accountability.
- Include cloud and backup copies in your destruction process.
Required by
32 CFR 2002.16; CUI LDC Registry
Apply Limited Dissemination Controls and Lawful Government Purpose
DISSEM
Requirement
Apply Limited Dissemination Controls and Lawful Government Purpose in accordance with 32 CFR 2002.16; CUI LDC Registry.
Plain-English explanation
CUI may only be shared for a lawful government purpose, and Limited Dissemination Controls (LDCs) further restrict who may receive it. 32 CFR 2002.16 and the CUI Registry's LDC list govern which controls (e.g., NOFORN, FED ONLY) can be applied and how. Applying the wrong control — or ignoring one — is a disclosure risk.
Implementation examples
View implementation examples
Managing dissemination:
- Confirm a lawful government purpose before sharing CUI internally or externally.
- Apply only LDCs listed in the CUI Registry and only when authorized by the designating agency.
- Restrict distribution lists and shared drives to authorized recipients.
- Document dissemination decisions for CUI Specified categories.
Required by
DFARS 252.204-7012(m); proposed FAR CUI rule
Flow Down CUI Safeguarding Requirements to Subcontractors
FLOWDOWN
Requirement
Flow Down CUI Safeguarding Requirements to Subcontractors in accordance with DFARS 252.204-7012(m); proposed FAR CUI rule.
Plain-English explanation
CUI obligations do not stop at the prime — they flow down to subcontractors that will handle CUI. DFARS 252.204-7012(m) requires the clause be included in covered subcontracts, and the proposed FAR CUI rule would extend flowdown government-wide. Primes remain responsible for ensuring subs are covered.
Implementation examples
View implementation examples
Managing flowdown:
- Include the applicable CUI/safeguarding clause in subcontracts that involve CUI.
- Verify subcontractors' safeguarding posture (e.g., SPRS score, SSP) before sharing CUI.
- Track which subs receive CUI and under which categories.
- Require subs to report incidents up the chain.
Required by
EO 13556; 32 CFR Part 2002; NARA CUI Registry
Identify and Categorize CUI Using the CUI Registry
IDENTIFY
Requirement
Identify and Categorize CUI Using the CUI Registry in accordance with EO 13556; 32 CFR Part 2002; NARA CUI Registry.
Plain-English explanation
Before you can protect CUI you have to recognize it. The CUI program replaced dozens of agency-specific markings with one government-wide system, and the NARA CUI Registry is the authoritative list of what qualifies and under which category. Contractors should map where covered information lives and tag it to a Registry category.
Implementation examples
View implementation examples
Practical steps to identify and categorize CUI:
- Inventory systems, shares, and email that may hold government information and trace each to a contract or data flow.
- Match each information type to a NARA CUI Registry category (e.g., Controlled Technical Information, Privacy, Procurement).
- Confirm categorization with the contracting officer or data owner when a marking is ambiguous.
- Re-run the inventory when new contracts, tools, or data sources are added.
Required by
32 CFR 2002.20; CUI Marking Handbook
Apply CUI Markings (Banner, Portion, Category, and Limited Dissemination)
MARK
Requirement
Apply CUI Markings (Banner, Portion, Category, and Limited Dissemination) in accordance with 32 CFR 2002.20; CUI Marking Handbook.
Plain-English explanation
CUI must carry consistent markings so everyone who handles it knows the limits. The ISOO CUI Marking Handbook prescribes banner marks, portion marks, category designators, and limited-dissemination controls. Correct marking is what makes downstream safeguarding and dissemination rules enforceable.
Implementation examples
View implementation examples
Ways to apply CUI markings correctly:
- Add a CUI banner at the top (and bottom) of documents and a designation indicator identifying the source.
- Use category markings (e.g., CUI//SP-CTI) for CUI Specified.
- Apply portion marks where required and add Limited Dissemination Control markings (e.g., NOFORN, FED ONLY) when authorized.
- Configure templates, email footers, and DLP labels so markings are applied by default.
Required by
NIST SP 800-171 Rev 3; 32 CFR 2002.14(g)
Protect CUI on Nonfederal Systems per NIST SP 800-171
NIST171
Requirement
Protect CUI on Nonfederal Systems per NIST SP 800-171 in accordance with NIST SP 800-171 Rev 3; 32 CFR 2002.14(g).
Plain-English explanation
For CUI on nonfederal information systems, NIST SP 800-171 is the control set the government expects. Revision 3 (2024) reorganized the families and tightened several controls; DFARS 252.204-7012 and 32 CFR 2002.14(g) make it contractually and regulatorily binding for many contractors. A System Security Plan and POA&M are the core evidence artifacts.
Implementation examples
View implementation examples
Implementing NIST SP 800-171:
- Maintain a current System Security Plan (SSP) describing how each control is met.
- Track gaps in a Plan of Action & Milestones (POA&M) with owners and dates.
- Implement the access-control, MFA, logging, configuration, and incident-response families.
- Confirm which revision (Rev 2 vs Rev 3) your contract requires before scoping work.
Required by
Requirement
Protect Protected Critical Infrastructure Information in accordance with 6 CFR Part 29.
Plain-English explanation
Protected Critical Infrastructure Information is private-sector infrastructure information voluntarily shared with DHS under PCII protections. 6 CFR Part 29 limits its use and disclosure and requires trained, authorized users. PCII carries specific access and safeguarding obligations enforced by the PCII Program.
Implementation examples
View implementation examples
Handling PCII:
- Ensure only trained, authorized PCII users access the information.
- Store PCII per the PCII Program's safeguarding requirements.
- Do not disclose PCII outside authorized uses (e.g., not in FOIA releases).
- Mark PCII with the required cover sheet and statements.
Required by
Requirement
Protect Proprietary Business Information / Trade Secrets in accordance with 18 USC 1905; FOIA Exemption 4.
Plain-English explanation
Proprietary business information and trade secrets shared with or generated for the government are protected from improper disclosure. 18 USC 1905 (Trade Secrets Act) and FOIA Exemption 4 limit government release of confidential commercial information. Contractors should mark and segregate proprietary data.
Implementation examples
View implementation examples
Protecting proprietary information:
- Mark proprietary/trade-secret data with appropriate restrictive legends.
- Segregate it and limit access to a need-to-know basis.
- Assert confidentiality when submitting data the government might disclose.
- Track where proprietary data is shared and stored.
Required by
Requirement
Safeguard CUI at the 32 CFR 2002 Baseline in accordance with 32 CFR 2002.14.
Plain-English explanation
This is the baseline duty to protect CUI at rest, in transit, and in use. 32 CFR 2002.14 sets the floor for all CUI; for CUI on nonfederal systems that floor is implemented through NIST SP 800-171. Treat it as the minimum standard every CUI handler owes regardless of category.
Implementation examples
View implementation examples
Baseline safeguarding measures:
- Limit access to CUI to people with a lawful government purpose and a need to know.
- Encrypt CUI in transit and at rest using FIPS-validated cryptography.
- Control physical access to printed CUI and CUI media.
- Log access and review it; train staff on handling rules.
Required by
Requirement
Protect Nuclear Safeguards Information in accordance with 42 USC 2167; 10 CFR 73.21.
Plain-English explanation
Safeguards Information protects nuclear material and facilities from sabotage and theft. 42 USC 2167 and 10 CFR 73.21 impose strict access, marking, and protection requirements. SGI handling is tightly regulated by the NRC and DOE.
Implementation examples
View implementation examples
Protecting SGI:
- Limit SGI access to individuals with a need to know and required authorization.
- Mark, store, and transmit SGI per 10 CFR 73.21 protection requirements.
- Use approved physical and information-security controls.
- Report any SGI compromise to the NRC/appropriate authority.
Required by
Requirement
Apply Category-Specific (CUI Specified) Handling Controls in accordance with 32 CFR Part 2002 (CUI Specified).
Plain-English explanation
Some CUI categories are 'CUI Specified' — a law, regulation, or government-wide policy imposes handling controls beyond the CUI Basic baseline. 32 CFR Part 2002 directs you to the controlling authority for each Specified category. Always check whether a category is Basic or Specified before deciding how to handle it.
Implementation examples
View implementation examples
Handling CUI Specified:
- Identify the category's controlling law/regulation in the CUI Registry.
- Apply the category-specific dissemination and safeguarding rules, which may exceed the baseline.
- Mark Specified CUI with the correct category designator.
- Escalate questions to the contracting officer or the designating agency.
Required by
Requirement
Provide CUI Awareness Training to the Workforce in accordance with 32 CFR 2002.30.
Plain-English explanation
People are the front line of CUI protection, so the program expects workforce awareness training. 32 CFR 2002.30 contemplates training on identifying, marking, handling, and reporting CUI. Document that staff who touch CUI have completed it.
Implementation examples
View implementation examples
Building a CUI training program:
- Deliver role-based training before staff are granted CUI access and at least annually.
- Cover identification, marking, dissemination limits, incident reporting, and destruction.
- Track completion and retain records as evidence.
- Refresh content when CUI policies or contract requirements change.
Required by
Requirement
Protect Unclassified Controlled Nuclear Information in accordance with 42 USC 2168; 10 CFR Part 1017.
Plain-English explanation
Unclassified Controlled Nuclear Information is unclassified information about nuclear facilities/material whose disclosure could harm security. 42 USC 2168 and 10 CFR Part 1017 govern its identification and protection (DOE program). UCNI determinations are made by authorized reviewers.
Implementation examples
View implementation examples
Handling UCNI:
- Have authorized officials make UCNI determinations and apply markings.
- Restrict access to those with a need to know.
- Protect UCNI in storage and transmission per 10 CFR Part 1017.
- Destroy UCNI by approved methods.
Required by
Requirement
A responsible entity for Bulk Electric System (BES) Cyber Systems must comply with the mandatory NERC Critical Infrastructure Protection (CIP) standards — including asset categorization (CIP-002), security management controls, personnel and training, electronic and physical security perimeters, system security management, incident reporting, recovery, configuration and vulnerability management, and supply-chain risk management (CIP-013) — for the applicable assets it owns or operates.
Plain-English explanation
For the electric grid, NERC CIP is mandatory and enforceable law, with financial penalties. If you own, operate, or supply BES Cyber Systems, the CIP family governs them, and CIP-013 specifically pushes security obligations onto your supply chain and vendors.
Implementation examples
View implementation examples
Examples of meeting this requirement:
- Categorize BES Cyber Systems (High/Medium/Low) per CIP-002 and scope controls accordingly.
- Implement electronic/physical security perimeters and personnel risk assessments.
- Build a CIP-013 supply-chain risk-management plan and flow vendor security terms into procurements.
Required by
External Notification & Reporting
Requirement
Report Loss or Compromise of CUI in accordance with 32 CFR 2002; agency incident-reporting policy.
Plain-English explanation
Loss or compromise of CUI must be reported, often on tight timelines. 32 CFR Part 2002 and agency/contract incident-reporting policy (and DFARS 7012's 72-hour rule for DoD) govern when and to whom. Build the reporting path before an incident, not during one.
Implementation examples
View implementation examples
Incident-reporting readiness:
- Maintain an incident-response plan with defined roles and reporting timelines.
- Know the reporting channel (e.g., DIBNet for DoD) and required contract notifications.
- Preserve images and affected media for the period the contract requires.
- Run tabletop exercises so the team can meet the deadline.
Required by
Use Find My Requirements to narrow this list
This industry guide shows requirements that commonly arise in this sector. Find My Requirements lets you filter by contract type, agency customer, data categories, and selected jurisdictions to produce a tailored list for your specific situation.
Start Find My Requirements →