What a NERC CIP compliance checklist must cover before the first audit notice
There is no NERC CIP certificate to obtain. Compliance is ongoing, monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, and the Regional Entity can open a Compliance Audit, a Spot Check or an investigation at any point. If your organization has a regulatory duty to show CIP compliance and no working checklist, the first job is to write one that lists your categorization decision, your cyber security policies, every recurring task and the evidence each task produces. As of 17 October 2026, NERC lists 13 CIP standards as mandatory and subject to enforcement in the United States, so the list should cover every standard that applies to your assets, not only the ones your team already runs. The checklist is a working document, and it is the first thing an auditor will ask to see. The right checklist depends on your impact split. Your CIP-002 categorization decides how many BES Cyber Systems are high impact, medium impact and low impact, and most CIP requirements are scoped by those applicable systems. An entity with only low impact assets carries a lean list built around the CIP-003 plan, while an entity with high impact Control Centers carries most of CIP-004 through CIP-011 plus the recurring 15-day, 35-day and quarterly tasks. Confirm your categorization against the current version of CIP-002-5.1a and the CIP Senior Manager's approval date before you build anything else, because every later line item inherits that decision. Roles on the checklist should be explicit. Your organization owns its controls and the evidence that proves them. The CIP Senior Manager, or a documented delegate, approves policies and categorization. An implementation partner can prepare systems, configuration baselines and evidence records, but it cannot sign off on compliance or speak for the entity. Keep evidence of each requirement for three calendar years, and keep noncompliance records until mitigation is complete and approved. Because the Regional Entity must give at least 270 days' notice before a planned Compliance Audit, you have time to close gaps before the notice arrives, but only if the checklist is already running.
How CIP-002 categorization sets every other checklist item
The categorization sequence turns a list of assets into a set of rated BES Cyber Systems, and each rating decides which CIP requirements apply to which systems. Every later checklist task, from policies to patch cycles to evidence retention, is scoped from this record.
Inventory assets and candidate BES Cyber Systems
Start by listing every facility, Control Center and asset that your operations may bring into scope, with its owner and function. Operations, engineering and the CIP Senior Manager or a delegate usually work from the registered entity's one-line diagrams, network diagrams and asset registers. Group Cyber Assets that perform a common reliability function into candidate BES Cyber Systems. The output is a working inventory that names each candidate system, its location and the people who can confirm what it does. You know this step is done when every asset on the inventory maps to a candidate system or is documented as out of scope.
Apply the Attachment 1 impact criteria
Test each candidate BES Cyber System against the bright-line criteria in Attachment 1 of CIP-002-5.1a. The criteria separate high impact, medium impact and low impact systems based on the type of facility and its reliability role, such as Control Center functions and generation or Transmission Facilities at listed thresholds. Record the criterion that drove each rating, not just the result, so an assessor can retrace the reasoning. Confirm the threshold values against the current standard text, because the attachment governs the decision. The output is an impact rating per system with a written rationale.
Record External Routable Connectivity
For each medium impact BES Cyber System, determine whether it has External Routable Connectivity, meaning whether it can be reached from outside its Electronic Security Perimeter over a routable protocol. This determination matters because several CIP requirements apply only to medium impact systems with that connectivity. Network architects and the engineers who manage firewalls and remote access paths should verify the answer against the actual configuration, not the design document alone. The output is a connectivity flag per medium impact system, backed by the network evidence used to reach it. You know this step is done when every medium impact system carries a documented yes or no.
Document the categorization record
Assemble the results into a categorization record that lists each BES Cyber System, its impact rating, the supporting criterion, its connectivity status and its physical or logical location. Include the Cyber Assets and associated Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets that belong to each system, because these determine later applicability. Keep the record in a controlled repository with version history. The output is the categorization record itself, the document a Regional Entity auditor will ask for first. You know this step is done when a reviewer can trace any system from the record back to the inventory.
Derive applicable systems for each standard
Use the categorization record to build a matrix that shows which systems each CIP standard reaches. Most CIP requirements are scoped in tables by Applicable Systems, so a high impact system pulls in different tasks than a low impact system or a medium impact system with External Routable Connectivity. Compliance or engineering staff should map each standard, from CIP-004 through CIP-011, to the systems that trigger it. The output is an applicable systems list per standard, which becomes the scope column of the recurring task calendar. You know this step is done when every recurring task names the systems it covers.
Obtain CIP Senior Manager or delegate approval
Present the categorization record and the applicable systems list to the CIP Senior Manager or a delegate for review and approval. The approver should confirm that the rationale is documented and that the people who supplied the data agree with it. CIP-002-5.1a requires this review and approval at least every 15 calendar months, so the approval date and the next review date belong on the record. Any delegation of approval authority must itself be documented under CIP-003-9. The output is a signed or dated approval that starts the 15-month review clock. You know this step is done when the approval is on file and the next review is calendared.
Trigger updates when assets change
Treat the categorization record as a living control rather than a one-time exercise. Changes such as a new substation, a commissioned control system, a retired asset or a new remote access path can alter ratings, connectivity or applicable systems. Set a change intake process that routes these events to the people who maintain the record and to the change management workflow under CIP-010. The output is a dated change log linking each update to the affected systems and the approval that followed. You know the process is working when every configuration change that touches a rated system is traceable to a categorization review.
Which CIP Senior Manager and policy items must be in place
CIP-003-9 requires the registered entity to name one individual as the CIP Senior Manager. This person holds overall accountability for the CIP program, including approval of policies and the scope of the program, and that accountability does not transfer to a contractor or vendor. The name should be recorded in a form the auditor can trace to a date, so that the entity can show who held the role at any point in the audit period.
- Named individual: Record the CIP Senior Manager by name and title, not by role alone.
- Current record: Document any change of the CIP Senior Manager and make that change within 30 calendar days.
- Authority: Confirm the person has the authority to approve policies and to commit resources.
- Contact continuity: Keep a backup contact path so the Regional Entity can reach the entity during staff changes.
- Outside support: A consultant or implementation partner may prepare material, but the CIP Senior Manager remains responsible for it.
Confirm that your records show the current holder, the effective date of the last change and where the 30-day documentation is stored.
The CIP Senior Manager may delegate specific CIP-003-9 authority to other named individuals. CIP-003-9 requires that these delegations be documented. An undocumented delegation is a gap, even if the delegate performed the work correctly, because the auditor cannot confirm that the person acted with authority.
- Written record: Document each delegation with the delegate's name, the authority delegated and the effective dates.
- Limits: Describe what the delegate cannot approve, so that the record does not imply broader authority than intended.
- Revocation: Record when a delegation ends, especially when a delegate changes role or leaves the organization.
- Vendor staff: Do not delegate approval authority to contractor personnel unless your own governance allows it and the record is clear.
- Review: Check delegation records each time the policy review cycle runs.
Confirm that every person who approved a CIP document during the audit period either is the CIP Senior Manager or appears on a documented delegation covering that date.
CIP-003-9 R1 requires one or more documented cyber security policies. The CIP Senior Manager must review and approve those policies at least once every 15 calendar months. The policies set the direction for the other CIP standards, so the approval record matters as much as the policy text. Missing a 15-month approval is a common finding because the date is easy to lose across several documents.
- Policy set: Maintain policies that cover the topics in scope for your impact categories, with a version and an owner for each.
- Approval evidence: Keep dated approvals signed or recorded by the CIP Senior Manager or a documented delegate.
- Calendar control: Track each policy's last approval date in a register that triggers reminders before the 15-month limit.
- Change history: Record what changed in each revision so the auditor can match the policy to the controls.
- Retention: Keep superseded versions for the evidence retention period.
Confirm that every policy has an approval date within the last 15 calendar months and that the approver is authorized on that date.
An entity with high or medium impact BES Cyber Systems carries the full CIP-003-9 governance set, and it must also meet the detailed requirements of CIP-004 through CIP-011, CIP-013 and CIP-014 as applicable. Governance is the first layer that the auditor checks, because the other standards refer back to the policies and to the CIP Senior Manager. The impact categorization under CIP-002-5.1a determines which systems the policies must cover.
- Scope link: Confirm that the policies name the high and medium impact BES Cyber Systems identified under CIP-002-5.1a.
- Cross-reference: Check that each policy topic maps to the requirement in the standards it supports.
- Approval cycle: Schedule approvals so that the 15-month cycle does not fall during a major system change.
- Delegations in practice: Confirm that delegates named for operational tasks also appear in the governance record.
- Supplier governance: Confirm the CIP-013 supply chain plan has been approved under the same authority.
Confirm that a reviewer can trace each high or medium impact system to a policy, an approver and an approval date.
An entity whose assets contain only low impact BES Cyber Systems has a lighter set of obligations, centered on the CIP-003-9 R2 plan and Attachment 1. The plan must cover security awareness, physical access controls, electronic access controls, an incident response plan tested every 36 months, and malicious code mitigation for Transient Cyber Assets and Removable Media. Since 1 April 2026, CIP-003-9 also requires vendor electronic remote access controls for low impact BES Cyber Systems.
- Documented plan: Maintain the R2 plan with a named approver, a review date and a clear link to each low impact asset.
- Vendor remote access: Document how vendor electronic remote access is authorized, monitored and disabled, and confirm this control was in place from 1 April 2026.
- Vendor records: Keep a list of vendors with remote access and the date each access path was approved and last reviewed.
- Incident plan testing: Record the most recent test of the incident response plan and schedule the next test within 36 months.
- Approval cycle: The plan is governed by the same CIP Senior Manager and 15-month review discipline as the policies.
Confirm that the vendor remote access controls operated as documented from 1 April 2026 and that you can produce a dated record for each vendor access path.
Which recurring CIP tasks fall due every 15 days, 35 days, quarter and 15 months
Most of a NERC CIP program runs on fixed clocks set by each standard. Short cycles fall on technical teams, while the longer cycles tend to fall on the CIP Senior Manager and policy owners. Confirm exact requirement wording against the current standard PDF for each item, because the schedule is set by the standard itself.
Fifteen-day log reviews
CIP-007-6 R4 requires log review on a 15-day cycle for high impact BES Cyber Systems, so a shift that is skipped in the middle of a month becomes a finding. Ask who reviews logs on each cycle, which systems feed the review, and whether the reviewer keeps dated records showing that the review happened. A log collector that stores data but does not prompt a review does not, by itself, show the task was completed.
Thirty-five-day patch and baseline checks
CIP-007-6 R2 calls for security patch evaluations on a 35-day cycle, and CIP-010-4 R2 calls for baseline configuration monitoring every 35 days for high impact systems. Both tasks need a named owner, a tracked list of applicable patches, and a dated record of each evaluation. Check whether the patch source and the configuration baseline cover the same assets, since an auditor will compare them.
Quarterly awareness and access checks
CIP-004-7 sets quarterly obligations for security awareness reinforcement and for access authorization checks on BES Cyber System access. These tasks are easy to miss because they do not fall on a fixed calendar date each month. Confirm which access lists are reviewed each quarter, who signs off, and how revoked accounts are matched against the authorization record.
Fifteen-month policy and plan reviews
Categorization under CIP-002-5.1a, cyber security policies under CIP-003-9, training, access reviews, incident response plan tests, recovery plan tests and vulnerability assessments all recur on a 15-calendar-month cycle. Because they share one interval, many programs assign them to a single annual planning calendar. Ask for a dated approval record from the CIP Senior Manager or delegate for each item, and check that the cycle restarts from the last approval, not from the original adoption date.
How long to keep CIP evidence and what it must show
The general rule is that most CIP standards require you to keep evidence of each requirement for three calendar years. Under CIP-003-9, section C, information about any noncompliance must be kept until mitigation is complete and approved, if that takes longer than the three-year period. Treat the three-year figure as the starting point, not the end of the story: an open finding or an unapproved mitigation plan can keep records alive well past it. Confirm the retention period for each standard against the Regional Entity's current compliance materials before you set your deletion schedule, because the Compliance Enforcement Authority is the party that will judge whether your records are sufficient.
Build the evidence file around requirement IDs, not around systems or folders. For each evidence item, record the requirement ID (for example, the CIP-007-6 patch evaluation for a given 35-day cycle), a named owner who can explain and produce the item, and the date it was created or approved. A patch report with no owner or date is hard to defend, even if the patching itself was done correctly. Include the approval record for each CIP Senior Manager review, since a policy that is current but unapproved on the day it was due is still a gap. This structure also lets you answer a request for documents quickly and show that each recurring task ran on its cycle.
Ask your Regional Entity and your internal audit team to confirm three points before you finalize the evidence schedule: which retention period applies to each standard in scope, how the Regional Entity expects evidence to be submitted and labeled, and whether any open noncompliance changes the retention clock for related records. If you use an implementation partner to collect or organize evidence, confirm in writing that the partner keeps the records under your control and that the registered entity, not the partner, remains accountable for producing them. Set the retention schedule in the same written procedure that governs your recurring calendar so that evidence is neither purged early nor kept without a defined reason.
What must be ready before an audit notification arrives
The Compliance Enforcement Authority announces a planned Compliance Audit well before fieldwork begins, in two stages. An entity that keeps its categorization, policies, evidence index and audit contacts current through the year can answer each stage without rebuilding its program under deadline pressure.
Confirm the current BES Cyber System categorization
The CIP Senior Manager or delegate reviews the CIP-002-5.1a categorization of every BES Cyber System as high, medium or low impact, and records the approval date. The categorization sets which requirements auditors will test, so it should match the current asset list, including any new or retired facilities. The step is done when the approved categorization, its supporting asset list and the approval record can be produced together without reconstruction.
Verify policy approvals and CIP Senior Manager records
Check that each cyber security policy under CIP-003-9 was reviewed and approved by the CIP Senior Manager within the 15-calendar-month cycle, that the Senior Manager designation and any changes were documented within 30 calendar days, and that every delegation of authority is written down. Auditors ask for these records early, so they should sit in one controlled location. The step is done when each policy shows a current approval date and each delegation has a matching record.
Build the evidence index by requirement
Create an index that maps each applicable CIP requirement to the evidence that shows it, the system of record holding that evidence, the owner, and the retention period. Most CIP standards require keeping evidence for three calendar years, and noncompliance records must be kept until mitigation is complete and approved. Map evidence to the Applicable Systems in each table so that scoping questions can be answered without a search. The step is done when every in-scope requirement has at least one indexed source and an owner.
Test recurring tasks against their cycles
Review the logs and records for the 15-day, 35-day, quarterly and 15-month tasks, such as high impact log reviews, patch evaluations, configuration monitoring, access authorization checks and security awareness. Look for gaps and missed cycles now, and document any self-identified issues through the entity's internal process. The step is done when a sample of each recurring task shows completed, dated and signed records, and any gap has an open remediation entry.
Name an audit liaison and confirm contacts
Assign a named audit liaison who will receive the Regional Entity's notices, coordinate the evidence response and track deadlines against the notification timeline. Confirm that the Compliance Enforcement Authority has current contact details for the CIP Senior Manager and the liaison, and that delegates know their evidence responsibilities. The step is done when a written contact sheet exists and the liaison has walked through the request process with the compliance team.
Prepare for the 270-day notice
The Compliance Enforcement Authority must notify the entity at least 270 days before a planned Compliance Audit (Appendix 4C, section 4.1.1). On receipt, the liaison confirms the audit period, reviews which standards the notice covers, and checks the evidence index for gaps against those standards. The output is a short internal readiness memo with open items, owners and a plan for each. The step is done when the memo has been reviewed by the CIP Senior Manager.
Prepare for the 90-day document request
At least 90 days before the audit, the Compliance Enforcement Authority sends the list of standards in scope, the audit team members with their recent employment history, and the request for documents, data and information (Appendix 4C, section 4.1.1). The entity should check the audit team for conflicts, collect the requested items from the evidence index, and confirm the response owner for each request. The step is done when the response package is staged and the CIP Senior Manager has approved the submission plan.
How to check each checklist item before the auditor asks
Each card describes one item an auditor will ask for under NERC CIP and a way to test it internally before a Regional Entity notice arrives. The checks are written so a CIP Senior Manager can assign them, see gaps early and decide what needs fixing. The organization owns every control and signs off its own records, while an independent auditor from the Regional Entity makes the compliance determination.
Current categorization record
Confirm that the CIP-002-5.1a list of BES Cyber Systems, with its high, medium or low impact rating, is written down and was reviewed and approved by the CIP Senior Manager or a documented delegate within the last 15 calendar months. Test it by walking the asset list against current one-line diagrams, recent commissioning records and substation or plant changes, and look for systems added or retired since the last approval. Sign-off: the CIP Senior Manager or delegate, with the operations engineer who owns the asset inventory.
Approved policies within the window
Check that each cyber security policy required under CIP-003-9 R1 carries an approval by the CIP Senior Manager dated within the last 15 calendar months, and that any change to the CIP Senior Manager was documented within 30 calendar days. Also confirm that every delegation of authority is written down under R4. Test it by sorting the policy register by approval date and comparing it with the change log. Sign-off: the CIP Senior Manager personally, since this approval cannot be delegated away from the role's accountability.
Evidence index mapped to requirements
Build one index that lists each applicable requirement, the systems it covers and the file, ticket or log that proves it, with an owner and a storage location. Gaps appear quickly when a requirement has no artifact or an artifact covers a system outside the applicable scope. Test it by picking three random requirements and asking someone outside the team to find the evidence within a few minutes. Sign-off: the compliance lead reviews the index, and the CIP Senior Manager accepts it as the program's evidence baseline.
Recurring task calendar with completion records
Maintain a calendar covering the recurring cycles that apply to your categorization, including the 15-day and 35-day tasks, quarterly reviews and the 15-month obligations. Each entry should link to a completion record showing who performed the task, when, and what was found. Test it by reviewing the last full cycle and checking that every due date has a matching record, not just a calendar tick. Sign-off: each task owner signs the record, and the compliance lead confirms the calendar weekly against open items.
Retention rules for the evidence window
Most CIP standards require keeping evidence of each requirement for three calendar years, and noncompliance records for longer if mitigation is not finished. Confirm that retention rules are written, that storage keeps originals with timestamps and that deletion is blocked during the period. Test it by restoring an artifact from three years back and confirming it opens, is complete and shows its date. Sign-off: the records owner and the CIP Senior Manager, with IT confirming storage and backup settings.
Self-reports and mitigation status log
Keep a running log of every possible or confirmed noncompliance, each self-report or self-logged item, and the status of its mitigation plan, including target dates and evidence of completion. Compare the log against your evidence index to confirm that each issue links to the requirement it affects. Test it by checking whether any item has been open without a status update for a full review cycle. Sign-off: the CIP Senior Manager approves each closure, and the Regional Entity receives the formal submissions.
Who owns each checklist item and what a partner can prepare
This table compares five checklist areas across three columns: the registered entity's accountable role, what an implementation partner such as DeployOpen can prepare or run, and what the Regional Entity or NERC reviews. Read each row left to right to see where ownership stays inside the entity and where outside help can prepare systems and evidence. A partner prepares and never issues a report or certificate, and hiring one does not guarantee an audit result.
| Checklist area | Registered entity (accountable) | Implementation partner can prepare or run | Regional Entity or NERC reviews |
|---|---|---|---|
| Categorization (CIP-002-5.1a) | CIP Senior Manager or delegate approves the BES Cyber System categorization at least every 15 calendar months | Inventory support, asset data collection and draft impact rating worksheets for the entity to review | Whether the categorization is documented and applied consistently with the Attachment 1 criteria |
| Policies and governance (CIP-003-9) | CIP Senior Manager names the role, approves policies every 15 calendar months and documents delegations | Draft policy templates, change logs and delegation record formats for internal approval | Whether the policies exist, were approved on time and match what the entity actually does |
| Recurring technical tasks (35-day, 15-day, quarterly, 15-month) | Owners set the schedule, perform sign-off and decide on exceptions and mitigation | Scripted or tooled evidence collection for patch evaluations, log reviews and access checks, run under the entity's direction | Sampled evidence that each recurring task ran on its deadline and that gaps were logged |
| Evidence retention | Entity sets retention rules and keeps records for the required period, including longer periods for open noncompliance | Evidence repositories, naming conventions, hashing or write-once storage and retrieval procedures | Whether requested evidence can be produced in full, on time and in a form that shows what it proves |
| Audit liaison and notifications | CIP Senior Manager owns the relationship, responses and any self-reports or self-logging | Pre-notification readiness checks, mock evidence pulls and drafts of evidence indexes for internal review | Notifies the entity, issues the audit schedule and scope, reviews evidence and issues the draft and final report |
Questions buyers ask about a NERC CIP compliance checklist
Can we build a NERC CIP compliance checklist ourselves?
Yes, a registered entity can build and run its own checklist, and the standards make the registered entity accountable either way. The checklist has to follow your own categorization under CIP-002-5.1a, because the applicable requirements depend on which BES Cyber Systems you rate as high, medium or low impact. Your CIP Senior Manager or a delegate must approve the categorization and the cyber security policies at least every 15 calendar months, and that approval cannot be handed to an outside party. The practical question is capacity. A small team with clear ownership of each recurring task can run the checklist in-house. A team without spare engineers for patch tracking, log review and evidence collection often brings in outside help for the technical tasks while keeping the accountability internal. Confirm how your Regional Entity expects evidence to be presented before you design the checklist around it.
What drives the effort of a NERC CIP checklist?
The main drivers are the number of BES Cyber Systems, their impact ratings, and how many of your assets sit inside the applicable categories. Each high or medium impact system brings in more requirements, and the tables in CIP-004 through CIP-011 apply by Applicable Systems, so every added system or Protected Cyber Asset adds tasks to the recurring calendar. Cloud use changes the picture too, because BES Cyber System Information stored off-premise falls under CIP-011-3 and personnel access under CIP-004-7. The following factors move effort up or down:
- Count and impact rating of BES Cyber Systems
- Whether medium impact systems have External Routable Connectivity
- Number of Electronic Access Control or Monitoring Systems and Physical Access Control Systems
- Use of cloud or SaaS services that store or process BCSI
- Vendor remote access paths and the number of vendors involved
Ask any partner to tie its scope to this list in writing before quoting.
How much internal time do the recurring CIP tasks take?
No supplied figure gives a reliable hour count, so the reader should measure this against their own environment rather than rely on a general estimate. The effort is set by the calendar. Some tasks recur every 15 days for high impact systems, such as log reviews under CIP-007-6, while patch evaluations and baseline monitoring recur every 35 days. Quarterly tasks cover security awareness and access authorization checks under CIP-004-7, and many training, access review, incident response and recovery plan test obligations come up every 15 calendar months. Low impact assets carry a lighter set of obligations under CIP-003-9. To size the work, list every recurring task, the owner, the cadence and the evidence it produces, then time a single cycle of each with the people who will do it. Ask a partner to show how it would track that calendar.
What does a partner need from our organization to start?
A partner needs accurate inputs and named people who can make decisions. The first input is your current CIP-002-5.1a categorization, including the asset list, the BES Cyber System inventory and the impact rating basis for each system. The partner also needs your current policies, the CIP Senior Manager and any delegation records, network diagrams showing Electronic Security Perimeters, access lists, and the existing evidence for each requirement. Expect to provide access to the systems under review in your own environment, and to name a technical owner for patching, configuration and backups. Good preparation includes:
- Current categorization and approval records
- Network and asset inventories with system boundaries
- Access control and personnel records, handled under your own rules
- Existing evidence and retention locations, including any off-premise storage
DeployOpen works inside the client's own infrastructure and prepares systems and evidence, so access and data handling must be agreed in the written scope before work starts.
How far ahead of an audit notice should we start preparing?
Start well before any notice arrives, because the notice period is only the window in which your records are checked. Under NERC's Compliance Monitoring and Enforcement Program, the Compliance Enforcement Authority must notify the entity at least 270 days before a planned Compliance Audit, and must send the list of standards in scope, the audit team details and the document request at least 90 days before the audit. Those 270 days are a useful planning window, but a checklist that is only started when the notice arrives will not produce a clean evidence trail. Most evidence must be kept for three calendar years, so records from the audit period should already exist. Begin by confirming that your categorization, policies and recurring task logs are current, then test a sample of evidence against each requirement.
Can a partner issue our NERC CIP compliance result?
No. A partner can prepare your systems, controls and evidence, but it cannot issue a compliance result, because NERC CIP has no certificate. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, spot checks, self-certifications, self-reports and investigations. Responsibility for compliance stays with the registered entity and its CIP Senior Manager, and findings come from the Regional Entity, not from a consultant or implementation partner. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's infrastructure, and prepares evidence for assessments. It does not issue audit reports, attestations or certifications. Ask any firm you evaluate to state its role in writing, and to confirm which parts of the program it will not own.
How DeployOpen prepares NERC CIP systems and evidence
DeployOpen 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. For a NERC CIP checklist, that work typically covers the systems that produce recurring evidence: configuration baselines, patch tracking, log collection and review, access records, backup and recovery testing, and the vulnerability assessment records that feed the 15-month and 35-day tasks. Work is agreed on a fixed written scope, so the deliverables, the systems in scope and the timelines are settled before any changes are made to a BES Cyber System environment.
DeployOpen prepares systems, controls and evidence for a compliance assessment. It does not issue audit reports, attestations or certifications. Under the NERC monitoring model, the Regional Entity or NERC is the Compliance Enforcement Authority, and the registered entity remains accountable for its controls. The CIP Senior Manager, or a documented delegate, still approves the policies and the categorization and signs off on evidence. Before engaging, the entity should confirm in writing which evidence artifacts each deliverable produces, who in its organization owns each one, and how long each must be retained under the evidence rules in the applicable standards.
Ongoing support is available as a retainer for work that continues after the initial scope closes, such as patch and configuration monitoring, backup testing and upgrades to the platforms DeployOpen has implemented. A retainer should name the recurring tasks it covers, the evidence each task produces, and what happens when a standard changes. Ask for a quote built from the written scope, and confirm that personnel risk assessment and access rules for any outside staff with access to BES Cyber System Information are settled before work begins.
