How do you respond to the NERC CIP Evidence Request Tool before an audit?
When a notification letter arrives, the registered entity owns every response in the CIP Evidence Request Tool (ERT) workbook, and the Regional Entity's audit team decides what gets sampled. The team selects samples from the Level 1 detail tabs and then asks for Level 2 implementation evidence on the items it samples, so the Level 1 workbook is effectively the map of what the auditors can test. The submission schedule and format come from the audit notification letter, and that date controls the work plan.
The effort needed to answer well depends on three things: the number of in-scope BES Cyber Systems, which drives the size of each detail tab; the state of evidence that already exists for each request ID, such as CIP-002-5.1a-R1-L1-03; and the strength of the entity's internal controls, which shape how the compliance team assembles and reviews the answers. Start by counting the populations per tab and checking whether each population can be produced from current records without manual reconstruction. Gaps found at this stage are cheaper to close than gaps found after the audit team samples them.
DeployOpen can help prepare the systems, configuration records, logs and evidence packages that support those responses, under a written scope. It does not write findings, decide sample sizes or accept responses on the entity's behalf. Only the Compliance Enforcement Authority, a Regional Entity or NERC, issues audit findings. Before engaging any outside party, ask the compliance lead to confirm the notification date, the submission format and which detail tabs apply to the entity's impact categories.
Reading request IDs such as CIP-002-5.1a-R1-L1-03
Each Evidence Request Tool item carries an ID that ties it to one standard, one requirement, one level and one position in the list. Reading those IDs correctly lets a team track what was asked, what was sent and where the proof lives, so that a sampled item never arrives as a surprise.
Decode the ID structure
The example CIP-002-5.1a-R1-L1-03 reads as standard CIP-002-5.1a, requirement R1, Level 1 request, third item. The segments tell you which requirement the request belongs to and whether it is a general request or a sampling population. Confirm the exact segment order and separators in your own ERT workbook before you build any tracking formula or spreadsheet on top of them.
Match each ID to one requirement
Map every request ID to exactly one requirement and one owner. A single control often answers several requirements, so the same evidence file may be cited under more than one ID. Record each ID against the requirement it answers, and flag any request that seems to cover two requirements so the compliance lead can decide which one it satisfies.
Track what has been submitted
Keep a submission log that lists each ID, the date it was answered, the file or tab provided and the person who approved it. Mark partial responses clearly. A log that shows which IDs remain open lets the team answer the auditors' schedule from the audit notification letter without rebuilding status from email threads.
Plan for Level 2 follow-up
A Level 1 item on a detail tab can become a sampling population. When the audit team selects items from that population, Level 2 requests ask for implementation evidence for those specific items. Treat every Level 1 entry as a possible sample, so the evidence behind each row is ready before the sample is drawn, not after.
Cross-reference IDs to evidence locations
Maintain a cross-reference that links each request ID to the internal repository path, system of record and named evidence owner. The path should be stable across the audit period so that retained evidence can be found years later. Keep the cross-reference under change control, because an outdated path is a common reason a correct answer cannot be produced on time.
How the submission schedule follows the notification letter
The audit notice sets a sequence of phases, each with its own output, so the entity knows what to deliver and when before fieldwork begins. Confirm every date and submission format against the notification letter for your own audit.
Receive the 270-day audit notice
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 log the notice, confirm the named Compliance Enforcement Authority contact, and record the date the notice was received. The output is a dated audit intake record that anchors every later deadline in the internal plan. Confirm the exact dates in your own letter, since the notice sets the actual schedule.
Receive scope, team and document request
At least 90 days before the audit, the CEA must send the list of standards in scope, the audit team members with their recent employment history, and the request for documents, data and information. The entity reviews the standards list against its CIP-002 categorization and its registration, and confirms the request IDs in the Level 1 tabs that apply. The output is a scope confirmation and a gap list of Level 1 workbooks that must be populated. Ask the CEA to clarify any standard listed that the entity believes does not apply.
Populate the Level 1 detail tabs
Program owners complete the Level 1 detail tabs for Cyber Assets, electronic security perimeters, access points, physical security perimeters, personnel, removable media and the other sampling populations, along with the programs, processes and procedures requested. Each tab entry should be traceable to a request ID such as CIP-002-5.1a-R1-L1-03. The output is a complete Level 1 workbook, reviewed for internal consistency across tabs before submission. Confirm the submission format and the deadline for this workbook in the notification letter.
Submit the Level 1 workbook on schedule
The entity submits the completed Level 1 workbook and supporting program documents through the channel and format the notification letter specifies. The compliance lead keeps a submission log that records the version, date, recipient and any clarification requests from the audit team. The output is a submission record and a list of open questions from the audit team. Confirm the required format, file naming and any document marking rules in your letter before submitting.
Receive the sample list from the audit team
The audit team uses the populated Level 1 detail tabs as sampling populations and selects sample sizes and samples under the Compliance Monitoring and Enforcement Manual. The entity does not choose the samples, but it should confirm that every population tab is complete, since gaps can shape which items are drawn. The output is a sample list identifying the items for which Level 2 evidence is requested. Record each sampled item against its request ID so the evidence team can track it.
Assemble Level 2 evidence packages
For each sampled item, the evidence owner gathers the implementation evidence the Level 2 request asks for, such as configuration records, access logs, training records or change tickets. Evidence should show the control operating for the period in question, and each package should be cross-checked against the retention rules that apply. The output is one evidence package per sampled item, indexed to its request ID. Confirm how Level 2 evidence should be named, bundled and submitted in your notification letter.
Submit Level 2 evidence and track responses
The entity submits Level 2 evidence on the schedule the audit team sets, then tracks follow-up requests until each sampled item is closed. The compliance lead records every request, response and any evidence gap that needs explanation. The output is a closed request register showing that every sampled item received a response, which the team can use during fieldwork. Confirm the submission schedule for Level 2 requests directly with the audit team, since sampled requests can arrive in later rounds.
Which evidence each program area needs for the ERT
This area feeds the Cyber Assets and ESPs detail tabs, and it often feeds the EAPs tab as well. Auditors use these populations to confirm that you know what is inside each Electronic Security Perimeter and how traffic enters and leaves it. The records are usually inventories and diagrams, backed by the configuration and monitoring output that proves the inventory is current. Which tabs are populated depends on the standards that apply to your impact categories and whether a system falls under CIP-002 at high, medium or low impact.
- Cyber Asset listings: Hostnames, asset types, locations, and the BES Cyber System or PCA each asset supports, matching the CIP-002 categorization.
- ESP boundary records: Diagrams and lists showing each Electronic Security Perimeter and the Cyber Assets inside it.
- EAP evidence: Documentation of each Electronic Access Point, including the rules or devices that control traffic at the boundary.
- Baseline and change records: Evidence that inventories reflect current configuration, such as baseline exports and change tickets for recent updates.
- Dated snapshots: Versions of these lists that show what existed during the audit period, not only the current state.
Before submission, check that every asset in your Cyber Asset tab traces to a categorized system and that your ESP and EAP diagrams agree with each other and with the inventory.
This area feeds the Personnel and PSPs detail tabs, and it supports requests tied to access authorization and physical access. Auditors use the Personnel population to select individuals and then ask for proof that each person was authorized, screened and trained before receiving access. Physical access records for Physical Security Perimeters show who could enter protected spaces and how entry was controlled and logged. The records should line up with the access lists in your systems, so a sampled person can be traced from authorization to revocation.
- Personnel roster entries: Names or identifiers, roles, and the access granted, with dates of authorization and removal.
- Training and risk assessment records: Completion records and the dates of personnel risk assessments tied to each sampled individual.
- Access review evidence: Records of periodic review of who holds access and any corrections made.
- PSP access logs and visitor records: Entry logs for Physical Security Perimeters, escort records and access card or badge assignments.
- Revocation records: Timestamps showing access removed after a role change or separation.
Before submission, confirm that every person on the Personnel tab has a complete record chain and that dates in your access logs and your authorization records are consistent.
This area feeds the BCSI, Removable Media, Transient Cyber Assets, reuse and disposal, and procurement detail tabs. These populations test how you handle sensitive information and hardware that leaves your control. Auditors look for an identified repository of BES Cyber System Information, the controls on storage and transport, and records that show media and devices were sanitized or destroyed before reuse or disposal. Procurement evidence links to supply chain controls and shows the vendor terms in place when equipment or services were acquired.
- BCSI repository records: Locations where BCSI is stored, including any off-premise or cloud storage, and the access controls applied.
- Removable Media and Transient Cyber Asset logs: Inventory and use records for portable devices connected to in-scope systems.
- Reuse and disposal records: Sanitization or destruction certificates and logs for each sampled device.
- Procurement files: Contracts or purchase records with the security terms that apply to the acquired systems.
- Chain of custody: Documentation of who handled a device between removal from service and final disposition.
Before submission, confirm that every disposed device on your reuse and disposal tab has a matching sanitization record, and that BCSI locations are listed in the BCSI tab.
Why Level 1 workbooks stall and how to avoid it
Most delays in responding to the Evidence Request Tool come from the workbook, not the underlying controls. The five risks below share one root cause: the detail tabs, the evidence folders and the retention schedule were not built from the same asset and requirement records. Each card names the fix and the team that should own it before the notification letter arrives.
Inconsistent asset identifiers across tabs
The same Cyber Asset often appears under a hostname on one detail tab, a serial number on another and a asset tag in the ticketing system. Sampling populations then look incomplete or duplicated, and the audit team must ask follow-up questions before it can select samples. Fix this by issuing one asset identifier per Cyber Asset and reusing it on every Level 1 tab. Owner: the CIP compliance lead, with the CMDB administrator.
Level 1 entries without a requirement trace
A tab entry that cannot be tied to a specific CIP requirement and request ID, such as CIP-002-5.1a-R1-L1-03, is hard for the audit team to place in a sampling population. Each row should name the requirement it supports and the system category it belongs to, such as an Electronic Security Perimeter or a Physical Access Control System. Check every row against the Applicable Systems table of the standard before submission. Owner: the compliance analyst who maintains the requirement matrix.
Evidence held in unindexed folders
Screenshots, exports and approval records stored in personal drives or in folders named by date are slow to locate under a fixed submission schedule. Build an index that maps each Level 2 evidence item to its request ID, file name and location, and keep one owner for updates. A clear index also shows whether an item was produced for the audit or pulled from a system of record. Owner: the evidence custodian for each requirement family.
Retention shorter than the audit period
The audit period starts the day after the previous Compliance Audit ends, and most CIP standards require keeping evidence for three calendar years. Logs and some records may be kept for shorter periods, so the audit period may reach evidence that no longer exists. Compare each request against the retention schedule early and plan other means of demonstrating compliance where needed. Owner: the CIP Senior Manager's delegate for records management.
Vendor-held records nobody requested
Maintenance logs, remote access session records and configuration backups are often held by an integrator or cloud provider under a separate contract. If the entity does not request them in advance, the response can stall while the vendor is contacted under deadline. Review contracts for record-delivery terms and confirm with each vendor which records they hold and how quickly they can provide them. Owner: the procurement lead, with the CIP-013 supply chain owner.
Covering the whole audit period in your submissions
The audit period starts the day after the end date of the previous Compliance Audit, and the entity must show compliance for the entire period, not just the most recent months. When you answer the Evidence Request Tool, every Level 1 detail tab and every Level 2 sample has to be backed by evidence that reaches back to the first day of that period. Before you build any submission, confirm the end date of your last audit with your Compliance Enforcement Authority and calculate the start date from it. That single date tells your team how far back each population must go.
Most CIP standards require keeping evidence of each requirement for three calendar years, and the retention rules in each standard are the first thing to check against that window. For example, CIP-003-9 sets a three-year retention period for its evidence and extends retention for information about any noncompliance until mitigation is complete and approved. Where a standard's retention period is shorter than the audit period, the entity must demonstrate compliance for the uncovered months through other means, such as system-generated records, signed attestations supported by source data, or documents that show the control operated. Identify those gaps early, because a sampled item with no evidence for its period will be reported as a gap in the audit record. The rules are set out in NERC Rules of Procedure Appendix 4C, section 4.1.3.2.
Build a retention matrix that lists each standard and requirement, its retention period, the systems that generate the evidence, and the earliest date of evidence you still hold. Logs and monitoring outputs are often the first to be overwritten, so confirm rotation settings and archive locations for them now. Ask your team to name an owner for each population who can explain how the records were produced and where they are stored. If you rely on a cloud platform, a vendor, or a self-hosted tool for backups, confirm that the export format still shows the full period, not only the current configuration.
Common questions about responding to the ERT
How much effort does an Evidence Request Tool response take?
The effort depends mainly on how many in-scope Cyber Assets, Electronic Security Perimeters, Physical Security Perimeters and personnel records the entity has, and on how many Level 1 detail tabs the audit team uses as sampling populations. Each Level 1 request is a population that must be complete and accurate before the team draws a sample, so gaps in an inventory multiply across every tab that depends on it. Effort also rises when evidence for the audit period is spread across ticketing, log, badge and HR systems that must be exported, reconciled and dated. Ask the Regional Entity for the notification letter's submission schedule and format early, then size the work against the number of tabs and the age of the records you hold. Teams that maintain current inventories and consistent request IDs usually spend far less time on each submission.
Can an entity answer the ERT without outside help?
Yes, the entity can answer the Evidence Request Tool itself, because the organization owns its controls and is responsible for the submission. Outside help is most useful for preparing systems, inventories and evidence exports before the request arrives, and for checking that a response matches the program the entity actually runs. Staff who already administer CIP controls can usually handle the Level 1 detail tabs, provided they know which tabs feed sampling and which request IDs apply to each standard. Plan for the effort to be recurring across audits, not a one-off task, and confirm with your Regional Entity how it expects responses to be formatted and where questions go.
What can a consultant do for an ERT response, and what can't they do?
A consultant can help assemble inventories, map evidence to request IDs such as CIP-002-5.1a-R1-L1-03, build repeatable exports and review drafts for gaps. A consultant cannot sign, attest or certify the submission on the entity's behalf, and cannot decide which requirements the entity meets. Only the registered entity answers to the Compliance Enforcement Authority, and only independent auditors and certification bodies issue audit reports or certificates, which CIP does not use. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments under a written, fixed scope, but it does not issue audit reports, attestations or certifications. Ask any provider to state in writing which deliverables it owns and which remain with your team.
Can Level 2 evidence be prepared before the request arrives?
Yes, and preparing it early is one of the most effective ways to reduce pressure on a submission. Level 2 asks for detailed implementation evidence only for the items the audit team samples, and the team chooses those items from the completed Level 1 detail tabs. Because the sample is not known in advance, the practical approach is to keep evidence indexed by asset, date and requirement so any sampled item can be answered quickly. Retain records for the required period, which for most CIP standards is three calendar years, and keep logs and records for shorter retention periods exported before they age out. Confirm with the Regional Entity which retention rules apply to each standard in scope.
How should an entity handle requests for CIP-015 before it is enforceable?
The ERO Enterprise may include requests for standards subject to future enforcement, so an entity should not assume a request for a future standard is out of scope. CIP-015-1 was approved by FERC on 26 June 2025 and is subject to future enforcement from 1 October 2028, while CIP-015-2 is listed with an effective date of 1 October 2029. Ask the Regional Entity, in writing, whether a CIP-015 item is a readiness request or a request tied to an enforceable obligation, and document the answer. Preparing the internal network security monitoring design and evidence in advance is a reasonable planning step, but it should be scoped against the applicable version and date you confirm.
What should we do if an ERT submission date is at risk?
Contact the Regional Entity before the deadline, explain which items are at risk, and ask how it wants partial or revised submissions handled. The notification letter sets the schedule and format, so changes should go through the channel it names rather than being assumed. Start by ranking open items by sampling impact, since Level 1 populations that feed the sample usually matter more than general program documents. Record every request for an extension and every answer, because the audit record is part of your evidence. Confirm timing details with the Regional Entity, since no general deadline or extension practice is set out here.
Who owns the responses, who prepares evidence, and who audits it
The registered entity owns its CIP controls and is the party that submits every Evidence Request Tool response. Responsibility for compliance stays with the entity even when an outside firm helps assemble the material. The Compliance Enforcement Authority, which is a Regional Entity or NERC, sends the audit notification letter, sets the submission schedule and format, and selects the samples from the Level 1 detail tabs. Those decisions belong to the auditors, and the entity cannot negotiate them with a consultant. Before fieldwork, the entity's CIP Senior Manager and compliance lead should confirm who signs each response, who answers questions from the audit team, and who keeps the request ID log that ties each answer to the item it supports.
An implementation partner such as DeployOpen can prepare the systems and evidence that the entity will submit. In practice that can mean building an evidence index keyed to request IDs such as CIP-002-5.1a-R1-L1-03, mapping the detail tabs to the system records that populate them, and checking that logs, baselines and access lists are complete for the audit period. Those are preparation tasks with defined deliverables, and they should be written into a fixed scope before work begins. The partner does not decide whether an item is compliant, does not interpret the standard for the auditors, and does not issue any report or attestation. Ask any partner to state those limits in writing, and ask who will answer auditor follow-up questions during and after fieldwork.
Only the CEA's audit team judges compliance, and no CIP certificate exists. Monitoring is carried out through Compliance Audits, Spot Checks, Self-Certifications and other mechanisms, and the outcome is a finding set by the regional process, not a certification. Any firm that offers a CIP certificate or claims to pass an audit on an entity's behalf is describing something that does not exist in the NERC program. Before engaging help, confirm the scope of the engagement in writing, confirm who holds the evidence files and their retention, and plan for the entity's own staff to explain their controls directly to the audit team.
How DeployOpen prepares CIP evidence before the audit
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares the systems and evidence behind CIP requests. The organization owns its controls and its ERT submissions, and only the Regional Entity or NERC, acting as the Compliance Enforcement Authority, reviews and monitors compliance.
How we scope
- We confirm which CIP standards and Applicable Systems the audit notification letter places in scope before any evidence work starts.
- We map each Level 1 detail tab to the systems, assets and owners that would form its sampling population.
- Engagements are fixed-scope, so the written scope lists the ERT tabs, request IDs and deliverables we cover.
How we build
- We set up evidence collection for Cyber Assets, ESPs, EAPs and PSPs so records are generated as part of routine operation.
- We organize programs, processes and procedures into a folder structure that matches the request IDs in the ERT User Guide.
- We test that Level 2 implementation evidence for a sampled item can be retrieved quickly and shows the requirement was met in the audit period.
How we hand over
- We document how each evidence artifact was produced, who owns it, and where it is retained under the applicable retention rules.
- We prepare a request-by-request index so your team can match each ERT item to its supporting files before submission.
- We hand over the documentation, configurations and runbooks so your staff can maintain the evidence process after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for systems that keep changing between audits.
- We can update evidence collection when the audit notification letter changes the submission schedule or format.
- Your compliance team stays responsible for the final ERT submission, and an independent auditor or Regional Entity makes all compliance determinations.
