What to outsource for NERC CIP compliance and what to keep

A registered entity keeps accountability for every CIP requirement that applies to it, while contractors and vendors can run defined technical tasks and prepare evidence. The entity, not the contractor, answers to the Compliance Enforcement Authority for every CIP requirement. Outside parties can patch, monitor, back up, test and document, but they cannot take over the obligation itself. The practical question is therefore not whether to outsource, but which tasks can move and which decisions must stay in-house.

The split depends on three things: the impact rating from CIP-002, the systems in scope for each requirement, and the delegation records kept under CIP-003-9. Under R1, the CIP Senior Manager approves cyber security policies at least every 15 calendar months, and under R4 any delegation of authority must be documented with the delegate's name or title, the specific actions delegated and the date, approved by the CIP Senior Manager and updated within 30 days of any change. A contractor performing a task without a recorded delegation is a gap an auditor will notice. Recurring technical work such as patch evaluations every 35 calendar days under CIP-007-6 R2 or baseline monitoring every 35 days for high impact systems under CIP-010-4 R2 is usually the first candidate for an outside team, provided the entity reviews the output on schedule.

Outside personnel with access to BES Cyber Systems or BES Cyber System Information fall under the entity's personnel rules. Under CIP-004-7 Part 3.4, the entity must verify that personnel risk assessments performed by contractors or service vendors meet Parts 3.1 to 3.3, so the entity should ask each vendor for its criteria and records before granting access. Before signing, confirm with counsel and the CIP Senior Manager which tasks are delegated, who verifies outputs, and how evidence will be handed over. NERC's cloud guidance on BES Cyber System Information makes the same point: shared responsibility with a provider does not transfer compliance responsibility, so the entity must still demonstrate compliance under CIP-004-7 and CIP-011-3.

Which NERC CIP responsibilities stay with the registered entity

Contractors can build, configure, test and document much of a NERC CIP program, but several decisions stay with the registered entity. The cards below cover the decisions that name accountable people, approve policy and delegations, accept risk, and protect BES Cyber System Information. Each is a decision a contractor can inform but cannot make on the entity's behalf.

Naming the CIP Senior Manager

The registered entity must name one individual as its CIP Senior Manager, and that person carries overall accountability for CIP compliance. A contractor can draft the role description and reporting lines, but it cannot be the person the Compliance Enforcement Authority holds responsible. Check that the named individual is an employee with the authority to approve policy and resources, and that the name is documented and updated when the person changes.

Approving policies every 15 months

The CIP Senior Manager must approve the cyber security policies at least every 15 calendar months. A partner can prepare the policy drafts, map them to the applicable requirements and track the review date, but the approval is the entity's act. Ask the partner to deliver a policy register with owners, last approval dates and next review dates so the approver can sign off on a current set.

Approving the delegation record

Where the CIP Senior Manager delegates authority to others, the delegation must be documented with the delegate's name or title, the specific actions delegated and the date, and approved by the CIP Senior Manager. A contractor may maintain the register, but it cannot grant authority to itself or its staff. Confirm that every delegation traces back to an entity employee who signed it, and that the record is updated within 30 days of any change.

Owning the risk decisions

Each control involves a judgment about risk, such as whether a compensating measure is acceptable, which systems are in practice affected by a change or whether a vendor's remediation is sufficient. Partners can analyze options and recommend an approach, but the entity owns the risk acceptance and the consequences. Ask for written options with their risks stated, and keep a record of who accepted each risk and on what basis.

Answering for BES Cyber System Information

BES Cyber System Information (BCSI) is the information the entity must identify and protect, including when it is stored off premises or with a cloud provider. NERC guidance states that a cloud or contractor arrangement does not transfer compliance responsibility, so the entity remains the data owner accountable for the controls. Confirm who holds access to BCSI repositories, how that access is reviewed, and how the entity can demonstrate the controls to an auditor.

How CIP-003-9 delegations let outside staff act for the entity

An outside firm can act for a registered entity under CIP-003-9 only if the entity has recorded that delegation. Requirement R4 asks for a documented process for delegating authority, unless no delegations are used. Each delegation record names the delegate by name or title, lists the specific actions delegated and the date, and carries the CIP Senior Manager's approval. The record must be updated within 30 calendar days of any change. A consultant who runs a vulnerability scan or drafts a change ticket without a matching entry is acting without documented authority, which is a gap an auditor will test.

Delegation transfers authority to act, not accountability. The CIP Senior Manager stays responsible for the program even when a contractor performs a task, and the entity remains answerable for the work product, its timeliness and its evidence. Keep delegation entries narrow enough to match the work. A line that delegates 'all CIP-007 activities' to an integrator is hard to defend, while a line that names the firm, the specific patch evaluation or log review tasks, the systems in scope and the start date gives an assessor something to verify against the tickets and logs the firm produces.

Before any engagement starts, the entity should confirm the current wording of R4 and its parts against the standard itself, since the requirement text is the authority and this summary is not a substitute for it. Then ask the CIP Senior Manager to approve the delegation entry and check that the change-tracking process will catch later scope changes, such as a new firm, an added system or a delegated task moved to another person. Those updates must reach the record within the 30-day window.

Which recurring technical tasks partners commonly run

Several high-frequency technical obligations sit on a 35-calendar-day cycle. Under CIP-007-6 R2, security patches must be evaluated for applicability on that cadence, and CIP-010-4 R2 requires baseline configuration monitoring every 35 days for high impact BES Cyber Systems. A partner can build the collection tooling, run the scans and compile the raw output that feeds these reviews.

Patch source tracking: A partner can configure feeds from the vendors in scope and record each evaluation date, but the entity decides applicability and any mitigation plan.
Baseline comparison runs: A partner can schedule configuration collection and diff reports against approved baselines, while the entity reviews deviations and records the outcome.
Change ticket reconciliation: A partner can match detected changes to authorized change tickets so exceptions are visible.
Sign-off records: The entity's designated reviewer signs each cycle, and the signed record is kept with the scan output.
Evidence retention: The entity keeps dated patch evaluations, baseline reports and approvals for the audit period.

Confirm with your Regional Entity which records it expects for each 35-day cycle and whether your tooling produces them in that form.

Why a third party does not take compliance responsibility with it

Splitting security duties with a cloud or service provider does not move the compliance obligation to that provider. NERC's implementation guidance on cloud solutions for BES Cyber System Information (BCSI), issued by the RSTC in June 2023 for CIP-004-7 R6 and CIP-011-3 R1, makes this point directly. The Responsible Entity remains the data owner, must apply the required controls even where the data sits at a third party, and must be able to demonstrate compliance with CIP-004-7 and CIP-011-3 during an audit. A provider's shared responsibility model can describe who operates which layer, but it does not answer the auditor's question about who is accountable.

For the CIP Senior Manager and the contract owner, this means the split of duties has to be written down in two places: the contract and the evidence request process. The contract should name which controls the provider performs, what logs, reports or attestations it delivers and how often, how the entity can verify them, and how access to BCSI is granted and revoked at the provider. The evidence request process should then ask for that material on a schedule, store it under the entity's own retention rules, and tie each item back to the requirement it supports. Where a provider's standard terms do not give the entity this visibility, that gap is the risk to plan for before a Regional Entity audit notice arrives.

Before relying on any cloud or hosted arrangement for BCSI, confirm the current scope, wording and expectations directly in the RSTC guidance and the current CIP-004-7 and CIP-011-3 standard text, and check them with your Regional Entity if the arrangement is unusual. The guidance is the natural starting point for the contract review, and the questions it raises should be answered in writing by the entity and its provider before the arrangement goes live.

Personnel and access rules that apply to outside staff

Outside staff who reach BES Cyber Systems, their electronic access or their BES Cyber System Information fall under the same CIP-004-7 personnel rules as employees. The registered entity keeps the duty to train, screen, authorize and revoke access, and it must be able to show that each contractor met those steps before access was granted.

Training before access is granted

Part 2.2 requires that contractor staff complete the required CIP training before they receive authorized electronic access or authorized unescorted physical access. The only relief is during CIP Exceptional Circumstances, which the entity must define and handle under its own procedure. Check that your vendor's onboarding record shows a completion date earlier than the access grant date, because an auditor will compare the two.

Personnel risk assessment criteria

Part 3.3 requires criteria or a process for evaluating the results of criminal history records checks. The entity decides what results disqualify a person or trigger further review, and it must apply that process consistently to contractors and employees. Ask your vendor which criteria it applies and whether they match the ones in your own program.

Verifying vendor personnel risk assessments

Part 3.4 requires a process to verify that personnel risk assessments performed by contractors or service vendors meet Parts 3.1 to 3.3. Relying on a vendor's written statement is not enough on its own, so the entity should define what evidence it accepts, such as a sample of screening records or an attestation tied to the same criteria. Build this check into the contract so the vendor agrees to provide it before staff start.

Quarterly access authorization checks

The entity must review authorized access for contractors on a quarterly cycle, confirming that each person still needs the access granted to them. The entity owns this review even when a vendor manages its own roster. Schedule the review against your access list rather than the vendor's staffing list, since staff can leave a project while their credentials remain active.

Access revocation on contractor exit

When a contractor no longer needs access, the entity must revoke it within the timeframe set in its CIP-004-7 access revocation process. Revocation covers electronic accounts, physical credentials, and access to stored BES Cyber System Information. Ask vendors to notify you promptly when staff roll off, and reconcile their departures against your revocation records at each quarterly review.

How to set the split before signing a contract

This sequence turns a vague request for help into a written allocation of every applicable CIP requirement, so the registered entity knows who owns each control, what evidence each party delivers and what it can present to a Regional Entity auditor. The outputs are documents and records the entity keeps and presents itself, since no external party issues a CIP certificate.

Confirm categorization under CIP-002-5.1a
The registered entity, with its CIP Senior Manager, lists its BES Cyber Systems and rates each as high, medium or low impact using the bright-line criteria in Attachment 1 of CIP-002-5.1a. This rating decides which requirements apply, so a partner should not scope a single control until the entity has signed off on the categorization. The check is complete when the entity holds a dated categorization record that names each system, its impact rating and the Applicable Systems it falls under, approved by the CIP Senior Manager.
Name the CIP Senior Manager and delegations
The entity names its CIP Senior Manager and records any delegation of authority under CIP-003-9 R4, including the delegate's name or title, the specific actions delegated and the date. Only the entity can make these appointments, and an outside firm cannot hold the role. The step is done when the delegation register is approved by the CIP Senior Manager and the entity knows which decisions remain with its own staff.
Map each requirement to an owner
Work through every applicable requirement and assign one accountable owner: the entity, a contractor or a vendor. Shared tasks, such as access reviews or patch evaluations, should be split into named duties with a single accountable party for each. Mark any requirement the entity will not outsource at all. The output is a responsibility matrix that the CIP Senior Manager signs, and which the entity can show an auditor as its control ownership record.
Define the evidence each party delivers
For each assigned duty, write down the record the owner must produce, such as a signed training log, a patch evaluation record, a backup verification result or a vendor remote access session log. Specify the format, the storage location and who inside the entity receives it. Ask the partner to confirm it can produce evidence in these forms without changing the entity's systems. The step is complete when each duty has a named evidence item the entity can retrieve on request.
Set evidence retention and access rules
Agree how long each evidence type is kept, where it is stored and who can access it, including outside staff. Where a partner or cloud provider holds BES Cyber System Information, confirm in writing how the entity keeps control of it, since the NERC cloud BCSI guidance states that a provider's responsibilities do not transfer the Responsible Entity's compliance obligations. The check is a retention schedule the entity approves, with access and storage terms in the contract.
Agree personnel and access requirements
Confirm, before any outside person touches a CIP environment, how training, personnel risk assessments and access authorization apply to contractor and vendor staff. CIP-004-7 Part 3.4 requires criteria or a process to verify that contractor personnel risk assessments meet Parts 3.1 to 3.3, and Part 2.2 requires training before authorized access. Record these checks as a list the entity can audit. Done when every outside individual with access is traceable to a completed record.
Set review checkpoints in the contract
Write scheduled review points into the agreement, timed to the entity's recurring CIP obligations such as the 15-calendar-month reviews and 35-day patch cycle, so that gaps surface before an audit notice. Ask the partner to state how it reports missed evidence and how fast corrections are made. The output is a review calendar attached to the statement of work, with named reviewers on both sides.
Put the scope and split in writing
Sign a fixed scope that lists the systems, the responsibility matrix, the evidence items and the review calendar, and states that the registered entity keeps accountability for every CIP requirement. Confirm that the partner prepares systems and records but does not issue audit reports or certificates, since CIP has no certificate and monitoring is done by the Regional Entity. The sequence is complete when the entity holds an approved, signed scope it can present to its auditor.

Who owns each NERC CIP activity

This table compares who holds accountability, who may prepare work, and who may supply tools or services for each recurring NERC CIP activity. Read the first column as the task, then the registered entity column as the party that must answer to the Regional Entity. The main takeaway is that outside parties can prepare records and run tasks, but the registered entity and its CIP Senior Manager keep the decisions and the accountability.

Activity	Registered entity owns	Partner may prepare	Vendor may provide	Independence note
Policy approval	CIP Senior Manager approves cyber security policies at least every 15 calendar months	Drafts policy text and tracks the review calendar	Not applicable	Approval cannot be delegated to a contractor's staff
Delegation records	CIP Senior Manager approves each delegation and its updates within 30 days	Maintains the delegation register and change log	Not applicable	Delegates act for the entity, so the entity must hold the signed record
Categorization decisions	Entity decides high, medium or low impact ratings under CIP-002	Gathers asset data and runs the bright-line analysis	Asset inventory tooling, if the vendor supplies it	Entity signs off the categorization it defends at audit
Recurring patch and log evaluations	Entity reviews results and records its decisions	Runs the 35-day patch evaluation and 15-day log review workflows	Patch feeds and log platforms	Reviewer should be an entity employee or documented delegate
Personnel risk assessment verification	Entity sets criteria and verifies vendor PRAs meet CIP-004-7 Parts 3.1 to 3.3	Collects and checks vendor PRA evidence against entity criteria	Background check provider completes the screening	Entity must verify contractor PRAs under Part 3.4, not accept them unreviewed
BCSI handling and cloud controls	Entity remains responsible as data owner for controls at any provider	Configures access reviews and encryption settings under entity direction	Cloud provider supplies platform controls and logs	Provider's shared responsibility model does not transfer compliance duty
CIP-013 vendor procurement reviews	Entity approves the supply chain risk plan and accepts vendor risk	Prepares questionnaires and contract review checklists	Vendor answers questionnaires and provides security documentation	Entity decides whether to accept each vendor's risk

What a partner cannot do under NERC CIP

A partner can prepare systems, documents and evidence, but several CIP roles stay with the registered entity or with the Compliance Enforcement Authority. The cards below set those limits so procurement and the CIP Senior Manager know where outside help ends.

No CIP certificate or compliance report

There is no CIP certificate. Compliance is monitored by the Compliance Enforcement Authority, a Regional Entity or NERC, through audits, Spot Checks, Self-Certifications and Self-Reports. A partner cannot issue a report or attestation that a registered entity is compliant. Check that any proposal describes deliverables as evidence packages and gap findings, not as a compliance statement the partner signs.

Cannot act as CIP Senior Manager

CIP-003-9 requires the registered entity to name a CIP Senior Manager, who approves cyber security policies at least every 15 calendar months and approves any delegations. That accountability stays with a named individual employed by the entity. A partner can draft policy text and track the approval cycle, but the approval and the delegation record must be the entity's own.

No Regional Entity audit role

Audit team members must be free of conflicts of interest, sign confidentiality agreements and complete NERC or NERC-approved auditor training. A consultant that helped build the program cannot be on the audit team for that entity. Ask a partner to confirm in writing that its staff will not be proposed as auditors for any client it has prepared.

Outside staff cannot audit their own work

Under Appendix 4C, section 4.1.4, employees or contractors of the audited entity may not serve as auditors. A partner's staff who configured monitoring, wrote procedures or ran vulnerability scans for an entity are part of that entity's compliance work, so they cannot test it on the auditor's side. Confirm which staff prepared evidence so the entity can explain that work to the audit team.

No guaranteed audit outcome

Compliance Audits and other monitoring are run by the Compliance Enforcement Authority, and findings depend on what the auditors test and what the entity can show. A partner cannot promise a finding-free audit, a penalty result or a particular audit date. Ask for scope, deliverables and retesting terms in writing, and treat any guarantee of audit results as a warning sign.

Questions buyers ask before outsourcing NERC CIP work

Can a contractor serve as the CIP Senior Manager?

Nothing in the supplied CIP-003-9 requirements limits the role to employees, but the CIP Senior Manager is the person the registered entity names to own the cyber security policies and the CIP program, and that accountability stays with the entity. CIP-003-9 requires the entity to name the CIP Senior Manager and to document changes to that designation within 30 calendar days. Before any contractor takes on a delegated task, confirm with your Regional Entity and your legal team how the entity's governance documents describe the role, and keep the named Senior Manager as a person who can answer for the program in an audit. A partner can prepare the policies, calendars and evidence, but cannot approve them on the entity's behalf.

How are outside staff vetted and trained for CIP work?

Outside staff who reach BES Cyber Systems or BES Cyber System Information must go through the same personnel and training controls as employees. CIP-004-7 requires training before authorized electronic or unescorted physical access is granted, except during CIP Exceptional Circumstances. Part 3.4 requires the entity to have criteria or a process to verify that personnel risk assessments performed by contractors or service vendors meet Parts 3.1 to 3.3, including the criminal history records check evaluation in Part 3.3. Ask the partner for its training records, its background check process and the verification method you will use, and confirm that these records are kept in a form you can produce during an audit.

Can an entity run its CIP program without outside help?

Yes, the standards place obligations on the registered entity, not on a consultant, so an entity with qualified staff can run the program in-house. The main cost is internal time: the recurring tasks include quarterly security awareness and access authorization checks under CIP-004-7, 35-day patch evaluations under CIP-007-6, 35-day configuration monitoring for high impact systems under CIP-010-4, and 15-month reviews and tests across several standards. The work that usually needs outside help is the one-time build, such as categorization, system hardening, logging and evidence tooling, and staff who can run those tasks consistently. Compare your internal capacity against this calendar before deciding which parts to hand over.

What should the entity review from a partner's output?

Review every artifact as if an auditor will test it, because the entity is accountable for it. Check that the CIP Senior Manager has approved policies and that each delegation is recorded with the delegate's name or title, the specific actions delegated and the date, as CIP-003-9 R4 requires. Confirm that the partner's configuration baselines, patch evaluations and log reviews match the Applicable Systems in each standard, and that the scope agrees with your current CIP-002 categorization. Check also that any BES Cyber System Information stored by a partner or cloud provider is still under your controls. The NERC cloud BCSI guidance states that a provider's shared responsibilities do not transfer compliance responsibility from the Responsible Entity.

How long does it take to set up a split of CIP work?

The setup time depends on how many BES Cyber Systems are in scope, how many of them are high, medium or low impact, and how much of your evidence already exists in repeatable form. The work includes confirming the categorization, writing a responsibility matrix that names an owner for each requirement, agreeing the evidence format and retention location, and setting up access and training for outside staff. Ask any partner for a written scope, a named list of deliverables and a schedule that shows how the handover will be tested before the first recurring task falls due. Avoid any plan that does not give you a dated handover of recurring tasks.

Who is accountable if a partner misses a CIP task?

The registered entity remains accountable. Penalties under the NERC Sanction Guidelines attach to the entity, not to the contractor, and the maximum civil penalty referenced in the supplied sanction guidance is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 (January 2025). Your contract should therefore set out how missed tasks are reported to you, how quickly they are corrected, and what evidence proves the correction. Track the missed task in your own program records, report it through the self-reporting process where required, and keep a mitigation plan that names the person responsible inside the entity. Ask the partner how it will alert you before a 15-month or 35-day deadline falls due.

Where DeployOpen fits in the split

DeployOpen sits on the contractor side of the split. It plans, implements, hardens, documents and supports self-hosted open-source platforms inside the registered entity's own infrastructure, whether that is its cloud accounts, data centers or air-gapped networks, and it prepares the systems, configurations and evidence that a CIP control depends on. The registered entity keeps ownership of every control. The CIP Senior Manager remains accountable for the program under CIP-003-9, and the entity decides what its BES Cyber Systems require, approves the policies and signs off on delegations. DeployOpen does not issue audit reports, attestations or certifications, and it does not act as the Compliance Enforcement Authority's auditor. Only the Regional Entity or NERC monitors compliance, and no CIP certificate exists to obtain.

Before engaging any partner, ask for a written scope that names the systems in each Applicable Systems category, the CIP requirements the work touches, the deliverables (for example, configuration baselines, patch-tracking reports, backup test records or procedure drafts), who receives each deliverable and who approves it. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and any quote follows from that written scope. Confirm whether a proposal covers one-time build work, recurring operation, or both, because the recurring 35-day, 15-day, quarterly and 15-month tasks continue after go-live and need a named owner inside the entity.

Ask how the partner will keep its staff and evidence within the entity's controls. Any contractor with electronic or unescorted physical access must be covered by the entity's personnel risk assessment and training process under CIP-004-7, and the entity must verify that contractor assessments meet Parts 3.1 to 3.3. Evidence generated by a partner should be stored where the entity can retrieve it for a Compliance Audit, and the entity should confirm how long it holds that evidence. Ongoing support, upgrades and continuous testing are available as retainers, so decide early which items the entity will run itself and which it will hand to a retainer.

How DeployOpen works on this

DeployOpen works on the technical side of outsourcing NERC CIP work: preparing self-hosted open-source platforms and the evidence they produce inside your own infrastructure. The registered entity and its CIP Senior Manager keep ownership of every control and every delegation, and only the Regional Entity auditors assess compliance.

How we scope

Scope is agreed in writing before work starts, listing the systems, controls and evidence covered.
The written scope names which recurring CIP tasks DeployOpen prepares and which stay with your staff.
Ongoing support, upgrades and continuous testing can be added as a retainer once the initial scope is delivered.

How we build

Systems are planned and deployed inside your cloud accounts, data centers or air-gapped networks.
Configurations, access controls and logging are set up so the evidence each CIP requirement needs is generated automatically.
Security testing of the deployed platforms runs against the agreed scope before handover.

How we hand over

Documentation covers how each platform supports the in-scope controls, written for your CIP Senior Manager and delegates.
Evidence is delivered in an organized form so your team can retrieve it for a Regional Entity request, including the retention arrangements you choose.
Your staff are trained to run the recurring tasks, and ownership of each control is recorded in the handover.

How we support

Support, upgrades and testing after handover are available under a retainer that follows the written scope.
Ask for the responsibility matrix in your quote so it is clear which tasks DeployOpen performs and which your staff perform.
Confirm with your CIP Senior Manager and your Regional Entity how they expect evidence to be presented before the scope is signed.