What a NERC CIP audit preparation checklist covers before fieldwork
The Compliance Enforcement Authority must notify the entity at least 270 days before a planned Compliance Audit, and at least 90 days before it sends the list of in-scope standards, the audit team members with their recent employment history, and the request for documents, data and information. That gap is the working window for this checklist, so the first task is to read the notification letter closely and record every date it sets. The organization owns its controls and the evidence that proves them. An implementation partner can help prepare systems, configuration records and evidence packages, but only the independent audit team issues findings, and any firm that helps you prepare cannot also serve as an auditor on the same engagement.
The checklist itself is not the same for every registered entity. Your registration, the impact categories assigned under CIP-002 and the number of standards in scope all change the work. An entity whose BES Cyber Systems are all low impact faces a short list centered on the CIP-003 cyber security plan, while a high impact Control Center may carry evidence populations under most of CIP-004 through CIP-011, plus CIP-013 and CIP-014 where they apply. Start by confirming which standards the letter lists, which Applicable Systems each one covers, and whether the Regional Entity has added standards that are subject to future enforcement. Ask the Regional Entity to clarify any scope question in writing, and keep that correspondence with your audit file.
How the 270-day notice and 90-day request set your preparation timeline
The sequence turns a formal audit notice into a confirmed scope, a populated evidence set and a gap list that is closed before fieldwork begins. Each phase produces a named output that the next phase depends on.
Read the 270-day notification and log its dates
The Compliance Enforcement Authority must notify the entity at least 270 days before a planned Compliance Audit. Compliance, legal and the CIP Senior Manager should read the notice together, record the planned audit start, the contact at the Regional Entity and any dates stated in the letter, and assign one owner for the audit file. The step is done when the dates are in a single tracked calendar and the owner has confirmed receipt in writing.
Confirm the standards and systems in scope
Compare the standards the Regional Entity lists against your CIP-002 categorization and the current impact ratings of each BES Cyber System. Check whether any standard is listed that is subject to future enforcement, because the ERO Enterprise may request those too. The output is a confirmed scope list that names each standard, each applicable system and each open question for the Regional Entity, signed off by the CIP Senior Manager.
Build the Level 1 detail tabs from system inventories
Level 1 of the Evidence Request Tool asks for completed detail tabs that become the populations auditors sample from, so incomplete tabs create a sampling problem before any evidence is reviewed. Assign each tab to the control owner who runs the process, reconcile every tab against the asset and account inventories, and record where a population is incomplete. The output is a populated Level 1 tab set with a reconciliation note for each tab.
Assemble program and procedure documents
Level 1 also requests the programs, processes and procedures that govern each in-scope requirement. Check that each document names its owner, carries a current revision and matches what staff actually do, because auditors compare documents against practice. The output is a document index that maps each requirement to its governing documents, with version dates and any documents flagged for revision before submission.
Run the 90-day package check and retention gap register
At least 90 days before the audit, the Regional Entity sends the scope list, the audit team with recent employment history and the document request. Use that package to test the audit period, which starts the day after the previous audit ended, against the retention rules in each standard. Where a requirement has shorter retention than the period, record the alternative evidence source. The output is a retention gap register listing each requirement, the period it must cover, the evidence on hand and the workaround or open item.
Submit Level 2 evidence on the notification schedule
Level 2 requests detailed implementation evidence for the items the audit team samples, and submission timing and format come from the audit notification letter, not from internal preference. Track each request ID, route it to the control owner, review the file for completeness and naming before upload, and log the submission date. The output is a submission log that shows what was sent, when and in what format, with any clarification requests noted.
Close gaps and prepare fieldwork
Before on-site work begins, resolve each open item in the retention gap register and each unanswered clarification. Brief the interview participants on the in-scope systems and the documents they will be asked about, and confirm the logistics for the audit team, including its conflict and confidentiality checks. The output is a closed or documented gap register and a fieldwork readiness sign-off from the CIP Senior Manager.
Confirm the audit scope before you collect a single file
Scope decides which standards, requirements and Applicable Systems the audit team will sample, so every later step depends on it. Work through the cards below against the notification letter and your own CIP-002 categorization before pulling any evidence.
Match the standards in the notice
The notification must list the standards in scope, and the audit team can add applicable standards even when they do not appear in the ERO CMEP Implementation Plan. Compare the list line by line with the standards you actually have in service, including CIP-003-9, CIP-012-2 and any standard the letter names for future enforcement. Ask the Compliance Enforcement Authority in writing about any standard that is listed but seems to have no in-scope assets, and record the answer.
Verify your CIP-002 impact ratings
Impact categories decide which Applicable Systems each requirement reaches. High impact BES Cyber Systems, medium impact systems with External Routable Connectivity, and low impact systems carry different obligations under the same standard. Rebuild your CIP-002-5.1a categorization against Attachment 1 and confirm that the Control Center, generation and Transmission criteria match the notice's scope. A rating that changed after the last audit can move whole groups of assets in or out of scope.
Map Applicable Systems per requirement
Most CIP requirements are scoped by Applicable Systems, including associated EACMS, PACS and Protected Cyber Assets. Build a table that lists each in-scope requirement and the asset populations it covers, then mark which populations feed Level 1 detail tabs. Gaps here usually show up as evidence that covers the wrong population, so check the table against your asset inventory before the sampling populations are fixed.
Account for Inherent Risk Assessments and controls
The Compliance Enforcement Authority tailors scope with Inherent Risk Assessments and an entity's internal controls. Find out whether the notice reflects a risk-based scope, and confirm which controls the audit team has already reviewed. If you have a formal controls review on record, check that its findings still match your current environment, because changed controls can change what gets sampled.
Check requests for future-enforcement standards
The ERO Enterprise can request evidence for standards subject to future enforcement, so a request may reach beyond current obligations. CIP-015-1 is approved with future enforcement from 1 October 2028, and CIP-015-2 extends monitoring to EACMS and PACS with an effective date of 1 October 2029. Ask whether any request relies on these standards, and keep a separate record of what is voluntary readiness and what is a current obligation.
Record the scope decisions
Once the scope is confirmed, write it down with the date, the notice reference, the CIP-002 categorization version and the names of the people who agreed it. Note any point you asked the Compliance Enforcement Authority to clarify and the reply you received. This record protects you if a sample later falls outside what you believed was in scope, and it gives your implementation partner or internal team a fixed baseline for the evidence work that follows.
How to prepare Evidence Request Tool responses
What are Level 1 detail tabs in the CIP Evidence Request Tool?
Level 1 detail tabs are the spreadsheet tabs in the CIP Evidence Request Tool (ERT) that you complete with a list of your in-scope assets, systems, accounts, or events for each requirement. Each completed tab forms a population, meaning the full set of items the audit team can choose from. The January 2026 ERT User Guide describes Level 1 as the place where you show what exists before anyone samples it. Accuracy matters here because an incomplete or inconsistent population can mean the auditors sample from the wrong set or ask follow-up questions. Confirm with your Regional Entity which tabs apply to your registration and which standards are in scope, since the audit notification letter sets that list.
Why do Level 1 tabs become sampling populations for auditors?
Auditors cannot review every asset or event, so they select sample sizes and samples from the Level 1 detail tabs under the Compliance Monitoring and Enforcement Manual. A population that is complete and internally consistent gives the audit team a defensible basis for sampling. If an asset is missing from a tab, the auditor cannot sample it, and if it later appears in another system, the mismatch can become an audit finding. Illustrative example: if a Cyber Asset appears in your patch records but not in your population for that standard, the auditor may question the completeness of the whole population. Reconcile each tab against your asset inventory and change records before submission.
What program, process and procedure documents does Level 1 ask for?
Level 1 also asks for the programs, processes and procedures that govern each in-scope requirement, alongside the detail tabs. These documents show how the entity designed its controls, who owns them, and how they are reviewed and approved. Typical examples include the cyber security policies, plans, and procedures that a standard requires, along with their approval records and revision history. Check that each document matches the version you actually operated during the audit period, because auditors compare design documents against the evidence in Level 2. Your compliance team should also confirm that documents referenced in the ERT are the controlled, current copies rather than working drafts.
What does Level 2 implementation evidence cover for sampled items?
Level 2 asks for detailed implementation evidence for the specific items the audit team samples from your Level 1 populations. Where Level 1 shows that a population exists and is governed, Level 2 shows that each sampled item was actually implemented as required. The evidence type depends on the requirement, such as configuration records, access logs, training completion records, or change tickets. Because you do not know in advance which items will be sampled, the practical step is to make sure that evidence for every item in each population can be retrieved quickly and in the requested format. Ask the audit team to confirm the exact Level 2 requests once the sample is drawn.
How are ERT request IDs tracked during an audit?
Each request in the ERT carries a request ID, and your responses should reference that ID so the audit team can match evidence to the request without guessing. Keep a single tracker that lists each request ID, the owner, the evidence location, the submission date, and any follow-up questions. Store evidence files with names that include the request ID, and record the version or date of each document. A tracker also helps you show the audit team what has been provided, what is pending, and where a response was revised. Confirm your tracking method with your Regional Entity contact before the first submission so that nothing is lost in later exchanges.
Who sets the ERT submission schedule and format?
The audit notification letter sets the submission schedule and the format for evidence, as stated in the ERT User Guide (January 2026). Do not assume a format from a previous audit or from another Regional Entity, because the letter governs what the audit team expects. Read the letter for due dates, file formats, naming conventions, and how to handle sensitive information. If the letter is unclear, ask the audit team in writing and keep the answer on record. Build your internal plan backward from the due dates in that letter, leaving time for internal review, legal or security sign-off on any BES Cyber System Information, and corrections.
Can an implementation partner prepare ERT responses for us?
An implementation partner can help organize systems, configuration records, and evidence so your team can prepare accurate ERT responses. DeployOpen prepares systems, controls and evidence for compliance assessments inside your own infrastructure, but it does not issue audit reports or certifications, and it does not act as an auditor. Under Appendix 4C, employees or contractors of the audited entity may not serve as auditors, so keep the roles separate. Your organization remains responsible for certifying the accuracy of its responses. Ask any partner to show, in a written scope, which evidence they will assemble and which decisions stay with your compliance staff.
What should we check before submitting ERT responses?
Before submission, check that each Level 1 population matches your current asset inventory, that every program or procedure is the approved version, and that every Level 2 response points to evidence covering the full audit period. Confirm that the request ID, file name, and format match the notification letter. Review sensitive material such as BES Cyber System Information so that it is shared only through the channels the letter permits. Finally, have someone other than the preparer read each response against the request text. This review catches gaps before the audit team does, and it creates a record that your internal controls were operating during preparation.
Covering the whole audit period without gaps
The audit period starts the day after the end date of the previous Compliance Audit, and the entity must show compliance for every day inside it. Before the notice arrives, build a period map that lists each in-scope requirement, the evidence it produces, how often that evidence is generated and where it is stored. Start from the requirement tables, not from the folder structure you already have. A requirement that runs monthly, such as a 35-day review, leaves a different trail than an annual review or a plan that is updated only after an event. The map shows where a gap would appear if a record was never created, was overwritten or was moved without a note.
Retention rules then decide what you can still produce. Most CIP standards require keeping evidence of each requirement for three calendar years, and CIP-003-9 is a typical example: its retention language sets the minimum period for the evidence of the cyber security policies, the CIP Senior Manager delegations and the cyber security plan. Check each standard's retention clause against the audit period you were given. Where the period is longer than the retention window, identify the other means you will use to show compliance for the earlier dates, such as exported system logs, signed approval records or ticket histories, and confirm with your Regional Entity that those means are acceptable before fieldwork.
Pay particular attention to noncompliance. Where a possible violation is still open, the retention obligation runs until mitigation is complete and approved, which can be longer than three years. Ask your compliance lead to list every open or recently mitigated item in scope and confirm the date its records must be kept until. Then ask your implementation partner or internal team to test a sample of older records for readability, completeness and restoration from backup, because a record that cannot be retrieved within the window is treated the same as one that was never kept.
Checking evidence against retention rules
This table compares each evidence type an audit team may request with its owning CIP standard, the retention rule to confirm in that standard's text, and the gap action if stored records fall short of the audit period. Most CIP standards require keeping evidence for three calendar years, but several rows depend on the specific standard, so confirm each one against the current text. The main takeaway is to run this check early, because retention gaps are easiest to close before the audit notification arrives.
| Evidence type | Owning standard and requirement | Retention rule to confirm | Where stored and gap action |
|---|---|---|---|
| Access reviews and revocation records | CIP-004-7, access authorization and periodic review | Three calendar years for most standards; confirm the CIP-004-7 text | Export review sign-offs and revocation tickets to a dated evidence store before the retention window closes |
| Patch assessment and installation records | CIP-007-6, security patch management on a 35-day cycle | Confirm the CIP-007-6 retention period | Keep each patch evaluation and decision record; rebuild gaps from change tickets and vendor advisories where needed |
| Configuration monitoring output | CIP-010-4, baseline configuration monitoring on a 35-day cycle | Confirm the CIP-010-4 retention period, which may differ from three years | Archive baseline comparison reports; if the stored period is shorter than the audit period, document alternative means |
| Backup and recovery test results | CIP-009-6, backup verification and testing every 15 months | Confirm the CIP-009-6 retention period for test records | Keep dated test plans, outcomes and lessons learned, each linked to the recovery plan version used |
| Security event logs and review records | CIP-007-6, security event logging and review | Confirm the CIP-007-6 log retention period, which may be shorter | Where logs age out sooner, retain the dated review records that show the logs were examined |
| Physical access and visitor logs | CIP-006-6, physical access control and visitor control | Confirm the CIP-006-6 retention period for access logs | Export PACS and visitor logs to off-system storage and match their retention to the audit period |
| Noncompliance and mitigation records | Any standard where a possible violation is identified | Keep until mitigation is complete and approved, if that is longer than the standard period | Open a dated record for each issue and keep it until the Regional Entity approves closure |
Vetting the audit team before it reviews your evidence
Once the notice arrives, the audit team is part of your scope decision, not a detail to settle later. The rules in Appendix 4C limit who can audit you, and the checks below let you confirm that before any evidence leaves your environment.
Confirm the rules on who can audit
Appendix 4C sets the baseline: audit team members must be free of conflicts of interest, sign confidentiality agreements, and complete NERC or NERC-approved auditor training. Employees or contractors of the audited entity may not serve as auditors. Treat these as the minimum you verify for every named person, and record the date you completed each check so the file holds up if the team changes.
Review recent employment history
The Regional Entity must send the audit team members with their recent employment history at least 90 days before the audit. Compare each employer listed against your own vendor list, your managed service providers, and any firm that has consulted on your CIP program. A past or current contractor relationship with your organization is the check most likely to surface a conflict, so raise it before the team starts reviewing evidence.
Raise conflicts in writing
If a team member appears to have a conflict of interest, put the concern in writing to the Compliance Enforcement Authority, name the person, the relationship and the supporting facts, and keep a copy. Do not resolve it informally with the individual. A written record lets the CEA decide on replacement and shows that your organization handled the question through the proper channel.
Confirm who from FERC may attend
FERC staff may participate in a CIP audit, but the rules do not make every person who attends a FERC representative. Ask the CEA in writing to identify each attendee and their organization before fieldwork begins. Record names and roles in the audit file, and confirm that any observer is covered by the same confidentiality expectations you apply to the audit team.
Check the team against your evidence access
Before you share BES Cyber System Information through the Evidence Request Tool or on-site, confirm that each team member's access is limited to what their sample requires and that their confidentiality agreements are on file. Log who received which evidence and when. This matters most for BCSI in shared repositories or cloud storage, where access is granted by account rather than by person.
Common mistakes that delay fieldwork or widen findings
Most delays in a CIP audit trace back to a handful of preparation gaps that were visible well before the audit team arrived. The mistakes below cluster around scope, the Evidence Request Tool, the audit period, retention and the people who assemble evidence. Each card names the check that prevents it.
Confirming scope after the notice
Teams often start collecting evidence before they know which standards and Applicable Systems the Regional Entity will test. The CEA tailors scope using risk-based processes and may include standards outside the ERO CMEP Implementation Plan, so a list built from last cycle can miss a requirement entirely. Once the list arrives at least 90 days before the audit, reconcile it against your current CIP-002 categorization, and confirm which high, medium and low impact assets are in play before any collection begins.
Populations that do not match detail tabs
Level 1 detail tabs become the populations auditors sample from, so a device, account or system missing from a tab can make the sample look incomplete even when the control works. Common causes are assets added after the last inventory, spreadsheets exported at different dates, and cloud or virtual systems not listed. Before submission, reconcile each detail tab against your asset and access records and keep the export date and query used to build it, so a sampled item can be traced back to its source.
Gaps at the start or end of the period
The audit period begins the day after the previous audit ends, and the entity must show compliance for the whole span. Teams often hold strong evidence for the middle months and thin evidence for the first and last few weeks, especially after a tool migration, a reorganization or a change in the CIP Senior Manager. Check each in-scope requirement against both boundary dates and document any change in tooling or ownership that falls inside the period, so a gap is explained rather than discovered by the auditor.
Shorter retention with no alternative
Most CIP standards require keeping evidence for three calendar years, but some records, such as certain logs, can have shorter retention. When the audit period is longer than a record's retention, the entity must show compliance by other means, such as periodic exports, summary reports or retained configuration snapshots. Map each evidence type to its retention rule before the audit, and where retention is shorter, document the alternative method and how it was run, so the team does not learn of the gap during fieldwork.
Relying on the partner without verification
An implementation partner can prepare systems, controls and evidence, but the organization owns its controls and must be able to explain them. Problems arise when evidence is generated or assembled by a partner and nobody on the entity side has tested that it reflects the live environment or can be defended in an interview. Assign an internal owner to each Level 2 item, have them reproduce the evidence from source systems, and confirm they can describe the control. Auditors who interview staff and find no internal understanding widen findings.
Where an implementation partner helps and where the entity must act
The registered entity owns its CIP controls, its evidence and every response it sends to the Regional Entity. An implementation partner such as DeployOpen can prepare systems inside your own environment, organize evidence into the folders and formats your audit team will expect, and document how each in-scope control operates. It does not issue audit reports, findings or determinations. Those come only from the Compliance Enforcement Authority, and hiring a partner does not guarantee any outcome. Set this boundary in the engagement scope before work starts, so that nobody on either side assumes the partner is accountable for the compliance position.
In practice, the partner's work and your work divide at the point of submission. Before each Evidence Request Tool response goes out, a named individual at the entity should confirm that the evidence is accurate, complete for the period in question, and matches the system as it actually ran, not as the procedure describes it. Ask the partner to show which evidence came from which system and when it was collected, and make sure your own compliance staff can explain each artifact without help. Where a response reveals a possible gap, the decision about what to disclose, and how, belongs to the entity and its counsel or compliance leadership, not to the partner.
Confirm the division of responsibilities in writing: who approves each response, who holds the submission account with the Regional Entity, who keeps the master evidence index, and who is the contact for follow-up questions during fieldwork. Also confirm that the entity's own staff, not a contractor who helped build the evidence, will be the people answering questions on the record. Auditors may not be employees or contractors of the audited entity, so any partner staff who helped prepare the environment should understand that their role is preparation, not testimony about the entity's compliance.
Questions buyers ask before preparing for a CIP audit
How much time does CIP audit preparation take from the compliance lead and system owners?
The time depends on how many in-scope requirements exist, how current the evidence already is, and how many people must produce it. The compliance lead carries the coordination load: reading the audit notification letter, tracking Evidence Request Tool (ERT) requests by request ID, and deciding what goes in each submission. System owners spend their time pulling configuration records, logs, access lists and test results for the items the audit team is likely to sample. The Compliance Enforcement Authority must give at least 270 days' notice before a planned Compliance Audit and at least 90 days before it sends the scope list, team members and document request, so the window between notice and fieldwork is long enough to plan. Ask the compliance lead to map each requirement to an owner and a named evidence source in the first weeks.
Can an internal team prepare for a CIP audit without outside help?
Yes, many registered entities prepare internally, and the decision usually turns on capacity and on how mature the evidence already is. An internal team needs people who know the BES Cyber System inventory, the Electronic Security Perimeters, and the tooling that produces logs and baselines. Outside help is commonly used for gap reviews, evidence mapping, building repeatable collection from self-hosted platforms, and test preparation. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or determinations. Only the Regional Entity or NERC, acting as the Compliance Enforcement Authority, decides compliance findings. Note that employees or contractors of the audited entity cannot serve as auditors.
What makes the effort for a CIP audit grow?
Four factors drive effort up the most:
- Scope: the number of CIP standards in play and whether high, medium or low impact BES Cyber Systems apply, since most requirements are scoped by Applicable Systems.
- Number of BES Cyber Systems and related assets: each system adds baselines, access records and test evidence to collect.
- Evidence maturity: evidence kept in ad hoc spreadsheets or tickets takes longer to pull and verify than evidence generated and retained by tools.
- Third-party systems: vendor-hosted logs, remote access services and cloud-held BES Cyber System Information need contract or provider input before the team can produce them.
The audit team may also request standards subject to future enforcement, which adds scope in some cases.
How do I request a fixed-scope quote for CIP audit preparation?
Send a written description of the work and let the scope set the price. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list. Include the following in your request: the audit notification letter or the date it is expected, the CIP standards and applicable impact categories in your CIP-002 categorization, the number of BES Cyber Systems and in-scope assets, the systems that hold evidence, and any third-party platforms involved. Ask the proposal to state which deliverables are preparation, such as evidence mapping and collection procedures, and which remain with your team, such as responses submitted to the auditor.
What should we do if a CIP audit notice arrives with little time left?
Start with the dates in the notice, not with the preparation plan. The Compliance Enforcement Authority is required to give at least 270 days' notice before a planned Compliance Audit, so a short notice is unusual and should be checked against the paperwork. Then confirm which standards and periods the audit will cover, and which ERT Level 1 detail tabs will become sampling populations. Prioritize evidence that is hardest to reconstruct, such as access revocation records, patch tracking and recovery test results, and confirm retention for each item. Communicate early with the Regional Entity contact about scope and submission schedule, and record every question and answer in writing.
Can we challenge the scope or timing of a CIP audit notice?
You can raise questions and request clarification, but the scope and schedule are set by the Compliance Enforcement Authority under its risk-based process. The CEA tailors each audit's scope using Inherent Risk Assessments and internal controls, and the scope may include applicable standards even when they are not listed in the ERO CMEP Implementation Plan. Notice must be given at least 270 days before a planned audit, and the scope list, team members and document request follow at least 90 days before. If you believe the team has a conflict of interest, you can raise it, because audit team members must be free of conflicts, sign confidentiality agreements and complete NERC or NERC-approved auditor training. Put any objection in writing, and confirm the procedure with your Regional Entity or with qualified counsel.
How DeployOpen prepares systems and evidence ahead of a CIP audit
DeployOpen agrees the preparation scope in writing before any work starts. For a CIP audit, that scope names the standards and Applicable Systems in play, the Evidence Request Tool detail tabs the team expects to populate, and the systems inside the client's own infrastructure that will be touched. Because the Compliance Enforcement Authority tailors audit scope from the entity's risk profile and internal controls, the entity should decide with its compliance lead which standards are in scope before preparation begins. DeployOpen then works inside the client's cloud accounts, data centers or isolated networks to prepare the systems, configuration records, access reviews, logs and procedures that the entity's own controls depend on. Where a control is missing or weak, the written scope should say whether DeployOpen will document a gap, fix a configuration, or leave the decision to the entity.
Preparation also means building an evidence index that maps each in-scope requirement to the artifacts that show it, the system that produced them, the owner who can explain them, and the retention period that applies. DeployOpen hands this index over with the documentation it produced, so the entity's compliance staff can answer Evidence Request Tool items from a single source and check that every item covers the full audit period. Ask for the index format, the naming convention for files, and a list of which artifacts were generated automatically and which were assembled by hand.
DeployOpen does not issue audit reports, attestations or certifications. Only the Regional Entity or NERC acting as the Compliance Enforcement Authority, through its audit team, makes findings about compliance. The registered entity remains responsible for its compliance decisions, for what it submits, for how it characterizes any noncompliance, and for the accuracy of every statement made to the audit team. Treat DeployOpen's work as preparation of systems and evidence, and confirm with the entity's compliance leadership and any counsel who signs off on submissions.
