What CIP-007-6 R2 patch management requires in practice
CIP-007-6 R2 asks you to run a documented patch management process for high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. In practice that process has three parts: identify the sources you monitor for released patches for each updateable Cyber Asset (Part 2.1), evaluate those patches for applicability at least every 35 calendar days (Part 2.2), and then, within 35 calendar days of finishing that evaluation, either apply each applicable patch or create or revise a dated mitigation plan that says how the vulnerability will be addressed and by when (Part 2.3). Part 2.4 then requires you to carry out each mitigation plan within its timeframe. Any extension must be approved by the CIP Senior Manager or a delegate. The two 35-day windows are separate clocks, so a compliance lead should track the evaluation date and the apply-or-plan date for every patch source, not just a single annual cycle.
The hard part is volume and provenance. A typical environment draws patches from many vendors across operating systems, firmware, controllers, engineering workstations and applications, and each source needs a named owner and a documented monitoring method. Some Cyber Assets are offline, vendor-managed or sit behind a vendor's remote support, so the team may not see releases when they are published. Confirm early which assets are in scope for R2 under your CIP-002 categorization, then check which of them are updateable, since the requirement is tied to updateable Cyber Assets. Ask each vendor how it notifies you of security releases and what it needs from you to receive them.
The second difficulty is proof. An auditor will ask for dated records showing when each evaluation happened, what was decided for each applicable patch, and which mitigation plan covers patches you did not apply. Spreadsheets kept by hand often miss a date or lose the link between a patch and its plan. Decide now how each evaluation is recorded, who signs off on a mitigation plan and where the timestamps come from, and run one sample patch through the whole chain before your next audit notification. Confirm with your Regional Entity which evidence format it expects.
Which systems and teams fall under R2 patch management
CIP-007-6 R2 applies only to systems in scope under the CIP-002 categorization, and only to the Cyber Assets on those systems that can be updated. Each card below marks a scoping decision that changes who does the work and which evidence the audit team will ask to see.
High and medium impact BES Cyber Systems
R2 applies to high impact and medium impact BES Cyber Systems, so the first step is confirming the impact rating from the CIP-002 categorization. A low impact system falls outside R2 unless it is reclassified. Check that the list of in-scope systems is current and matches the categorization record, because a system added to the network without being categorized is the most common gap auditors find.
Associated EACMS, PACS and PCA
R2 also covers the Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets associated with those BES Cyber Systems. Teams often treat these as peripheral because they sit outside the control room network. Build an explicit list of each associated system, including jump hosts, badge controllers and historians, so the patch process does not skip them.
Updateable Cyber Assets only
The patch process applies to Cyber Assets that are updateable, meaning they can receive a security patch from a source. Fixed-function devices with no patch path may fall outside the process, but that conclusion must be documented per asset. Ask each asset owner to record whether firmware, operating system and application components can be updated, and keep that record with the patch inventory.
Vendor-supplied firmware and appliances
Network devices, protective relays, human-machine interface appliances and similar equipment often receive firmware from a vendor rather than from the operating system channel. Identify each vendor as a patch source and record how notifications arrive, whether by advisory email, portal or support contract. A source that nobody monitors is a gap in the Part 2.1 source list even if the asset is in scope.
Operating system and application owners
Operating systems, databases and engineering applications usually have different owners, and each owner tracks its own patch releases. Assign a named owner for every platform and confirm who evaluates patches every 35 calendar days and who approves installation. Shared responsibility without a named owner is where evaluation cycles slip past the required interval.
Network device operations teams
Switches, routers and firewalls inside the Electronic Security Perimeter are commonly run by a network operations group rather than the control system team. Confirm that this group evaluates firmware releases on the same cycle, and that its changes flow through the change management process used for other in-scope assets. Ask the group to show its patch source list and its last evaluation record during your readiness review.
How an assessor tests R2 patch evaluation and application
The assessor starts with the documented list of sources the entity monitors for released patches. Part 2.1 requires that the process identify these sources for each applicable Cyber Asset that is updateable, so the list should map back to an inventory of those assets. The assessor compares the list against the asset inventory and asks who owns each source and how it is checked. Sampling here is usually light and focused on coverage: the assessor picks several asset types or vendors from the inventory and confirms each has a named source. Common findings include sources listed for one product line while the inventory contains other products from the same vendor, sources that name a vendor but not the specific product feed, and no record of when the source list was last reviewed.
- Source to asset mapping: Each updateable applicable asset or asset class should trace to at least one monitored source.
- Named owner: The list should say who watches each source, not only which website or feed it is.
- Review record: Evidence that the list was revisited after new hardware, firmware or software was added.
- Scope match: Only applicable Cyber Assets within high impact and medium impact scope belong in the review.
- Non-updateable assets: A short note explaining why certain assets are excluded keeps the assessor from raising questions.
Before the audit, check that every updateable applicable asset in the inventory appears in the source mapping, and confirm the list can be produced quickly.
Part 2.2 requires that the entity evaluate security patches for applicability at least once every 35 calendar days from the identified sources. The assessor looks for a dated record for each evaluation cycle and measures the interval between consecutive records against the 35-day limit. Sampling usually picks a set of source feeds and walks forward through successive evaluation dates to see whether any gap exceeds the limit. The clock is what matters, so the assessor tests continuity rather than the quality of any single review. Common findings include evaluation dates that drift past 35 days during holiday periods or staff changes, records that show the evaluation was done but not which patches were assessed, and tracking tools that do not retain the history needed to prove the cadence.
- Dated cycles: Each evaluation should carry a date that shows when it occurred and which sources it covered.
- Interval proof: Consecutive evaluation dates should show no gap longer than 35 calendar days.
- Patch identification: The record should list the patches reviewed or reference the advisory set reviewed.
- Evaluator identity: A named person or role should appear on each evaluation.
- Retention: Confirm with the auditor and your Regional Entity how far back the records must go for the audit period.
Before sampling begins, build a timeline of evaluation dates for each source and confirm no interval exceeds 35 calendar days.
Part 2.3 gives the entity three outcomes within 35 calendar days of completing an evaluation: apply each applicable patch, create a dated mitigation plan, or revise an existing mitigation plan. The assessor tests whether every applicable patch from an evaluation has one of these outcomes and whether the timing is recorded. Sampling typically takes patches from several evaluations and traces each to a change ticket, a dated plan, or a plan revision. The plan must state how the vulnerability will be addressed and give a timeframe, so the assessor reads plans for those two elements. Common findings include patches with no recorded decision, decisions dated after the 35-day window, mitigation plans that name a control without describing how the vulnerability is addressed, and plans without a timeframe.
- Decision per patch: Each applicable patch needs an apply, plan or revise outcome on record.
- Timing: The decision date should fall within 35 calendar days of the evaluation.
- Plan content: A dated plan should state the vulnerability, the method to address it, and the timeframe.
- Change linkage: Applied patches should connect to a change record showing the installation date.
- Revisions: A revised plan should keep its history so the assessor can see the original date.
Before the audit, pick a recent evaluation and trace every applicable patch to its decision, change ticket or plan, then confirm the dates.
Part 2.4 requires that each mitigation plan be implemented within its stated timeframe. Any revision or extension of that timeframe must be approved by the CIP Senior Manager or a delegate. The assessor checks whether planned actions were completed on time and whether each extension has the required approval before the new date passes. Sampling usually selects open and recently closed plans and compares their stated timeframes with completion evidence. Common findings include actions completed after the stated timeframe with no extension on record, extensions approved after the original deadline, approvals signed by someone without delegated authority, and completion evidence that does not match the action named in the plan.
- Completion evidence: Each planned action should have a record such as a change, configuration export or test result.
- Timeframe match: Completion should fall within the timeframe written in the plan.
- Extension approval: Each extension needs approval by the CIP Senior Manager or a delegate, dated before the original deadline.
- Delegation records: Keep the current delegation list so the assessor can confirm the approver's authority at the time.
- Closure: Plans should be closed with a record showing the vulnerability was addressed.
Before the audit, review every open plan, confirm its timeframe and any approved extension, and verify that the approver held delegated authority on the approval date.
Building a patch management process that meets the 35-day cycle
The sequence turns CIP-007-6 R2 into a repeatable routine: know which Cyber Assets can be patched, know where patches come from, evaluate on a fixed calendar, and record a decision for every patch. Each step produces a record an auditor can sample.
Inventory updateable Cyber Assets in scope
Start from the BES Cyber System categorization and list every Cyber Asset in the applicable systems: high impact and medium impact BES Cyber Systems with External Routable Connectivity, plus their associated EACMS, PACS and PCA. Mark which assets are updateable, since the requirement's patch tracking applies to those. Operations and engineering staff confirm the list against the network and asset records. The output is a signed-off asset list with an updateable flag and a named owner for each asset, which becomes the scope for every later step.
Identify and record patch sources per asset class
For each updateable asset class, such as operating systems, network devices, control system software and firmware, identify the vendor or other sources where released security patches are published, and record the exact source for each class. Subscribe the responsible team to those feeds and document how notifications reach them. Ask each vendor which channel it uses for security advisories and whether support agreements change the feed. The output is a patch source register that names every monitored source, the assets it covers and the person who watches it.
Set a recurring evaluation calendar
Build a recurring calendar that evaluates security patches for applicability from the identified sources at least once every 35 calendar days, as Part 2.2 requires. Assign an owner and a backup for each evaluation, and keep the cycle dates in a system the compliance team can export. Because the cycle is calendar based, a missed evaluation is a violation even if no patch was released. The output is a dated evaluation log showing each cycle, who performed it and which sources were checked.
Define the apply or mitigate decision and its record
Document the decision rule the team uses after each evaluation: apply the patch, or create or revise a mitigation plan. Specify who may approve each path, what testing or change control must precede installation, and what evidence is kept for a patch that is not applicable. Part 2.3 gives 35 calendar days after the evaluation to act, so the rule should state how that window is tracked. The output is a written procedure and a decision record template for each patch, with the evaluation date, the assets affected and the chosen path.
Write dated mitigation plans with timeframes
When a patch will not be applied within the window, write a dated mitigation plan. Part 2.3 requires the plan to state how the vulnerability will be addressed and the timeframe for doing so. Describe the compensating measure, the affected assets and the target date, and link the plan to the decision record. Ask engineering and the vendor whether a patch is coming and what compensating controls are feasible. The output is a dated plan for each unpatched vulnerability that an auditor can trace from the evaluation to the timeframe.
Implement plans and set approval routing for extensions
Track each mitigation plan until its timeframe ends, and confirm that the stated measures were in place, as Part 2.4 requires. Before any timeframe is revised or extended, route the request to the CIP Senior Manager or a delegate, who must approve it. Keep the approval in writing with the plan revision history. The output is a status register of open plans showing implementation evidence, revision history and the approver for each extension.
Reconcile records before each audit cycle
Periodically compare the asset list, source register, evaluation log and plan register against each other to find gaps, such as an asset added without a source or an evaluation that ran late. Correct the records and note the cause. Confirm with the compliance lead which evidence the Compliance Enforcement Authority is likely to request, and retain records for the period it specifies. The output is a reconciliation report with corrective actions, which shows the process operates as written rather than only on paper.
Which evidence shows R2 patch management is working
An assessor testing CIP-007-6 R2 follows the chain from source to decision to action, so the evidence must show each step with dates. The cards below cover the records that connect those steps and how to keep them current between audits.
Patch source list
The source list names each vendor advisory feed, security bulletin or patch portal monitored for released patches for each updateable Cyber Asset in scope. Assessors compare it against the asset inventory to see whether any updateable asset has no monitored source. Keep the list dated, record who approved changes to it, and note the assets each source covers so a new asset type cannot slip through without a source.
Dated evaluation records
Each evaluation shows the date it happened, the sources checked, the patches reviewed and an applicability decision for each one. Assessors sample evaluation dates and confirm that consecutive evaluations fall within 35 calendar days of each other. A record that says a patch is not applicable should state the reason, such as the component is not installed or the vulnerable feature is disabled.
Patch application and change tickets
For each applicable patch that was applied, the change ticket links the evaluation record to the installation date, the affected Cyber Assets, the approver and the verification result. Auditors use these tickets to test the 35-day window that runs from completing the evaluation. Confirm that the change system timestamps match the system logs, since a mismatch is a common reason for findings.
Dated mitigation plans
When a patch is not applied, the dated mitigation plan states the vulnerability, the compensating or mitigating action, the implementation timeframe and the date it was created. Assessors check that the plan was created within the 35-day window and that it was carried out on schedule. Mitigation plans that sit unrevised past their timeframe are a frequent source of exposure, so review open plans on each evaluation cycle.
Timeframe revision approvals
Any extension to a mitigation plan timeframe needs approval from the CIP Senior Manager or a documented delegate. The approval record should name the approver, state the date, give the revised timeframe and explain the reason. Keep the delegation record that authorizes the approver, because an assessor may ask whether the person who signed the extension held that authority on that date.
Retention across the audit period
Records must remain available for the audit period that the Regional Entity sets, so retention is a design decision made early, not at audit notice. Store evaluation records, tickets, plans and approvals in a system with access control, versioning and export. Ask the Regional Entity what it expects to see and confirm the retention period with your compliance lead before setting automated deletion rules.
What meeting R2 patch management costs
This table compares the cost components of running CIP-007-6 R2 patch management, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for scoping a quote: most of the ongoing spend comes from repeating the 35-day evaluation cycle across a growing asset and vendor base. No prices or durations are given because none were supplied for this topic.
| Cost component | Who is paid or carries the effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Patch tracking tools and licenses | Software vendor or open-source project; the entity pays for licenses and any support contract | Recurring (subscriptions, support); one-time setup | Number of tracked sources and products. Open-source options can reduce license spend but still need hosting and administration |
| Asset inventory and source mapping | Internal IT or OT staff, sometimes with an implementation partner | One-time build, recurring upkeep | Number of updateable Cyber Assets in scope and how often they change. Each new asset must be mapped to a patch source |
| Evaluation effort within each 35-day cycle | Internal engineers or operations staff, who review advisories and decide applicability | Recurring | Volume of released patches, vendor count and how many applicable Cyber Assets each patch touches |
| Deployment and testing | Internal operations staff, change advisory board, system owners; contractors for outage windows | Recurring | Outage constraints, need for test environments and number of distinct system configurations |
| Mitigation plan drafting and tracking | Compliance staff and system owners; CIP Senior Manager or delegate approves revisions | Recurring | Number of patches that cannot be applied within the cycle. Plan volume often tracks the vendor and asset mix, and revisions add approval work |
| Evidence upkeep | Compliance team; tooling administrator for exporting records | Recurring | How evidence is stored. Tool-generated, time-stamped records reduce manual collection |
| External review or testing | Independent assessor or testing firm, if engaged | Recurring if scheduled; one-time for a readiness review | Scope of the review and whether it covers sample populations or the full process |
| Auditor sampling effort | Entity staff who produce samples during a Compliance Audit or Spot Check; the Compliance Enforcement Authority performs the audit | Recurring by audit cycle | Size of the evidence population and how quickly records can be retrieved for the audit period |
Who owns R2 patch management and who can help
The registered entity owns CIP-007-6 R2 in full. Under the standard, the obligation sits with the entity, not with a vendor or contractor, so the entity must decide which sources it monitors for released patches, who evaluates each patch for applicability, which mitigation plans are approved, and when a timeframe is extended. Those decisions need named people and recorded approvals.
- Source identification: Decide which vendor, operating system and firmware sources cover each applicable, updateable Cyber Asset, and record them.
- Evaluation and decisions: Assign the people who evaluate patches on the cycle the standard sets and who decide whether to apply, mitigate or revise.
- Mitigation plans: Own the dated plan contents, including how the vulnerability will be addressed and the timeframe.
- Approvals: Route timeframe revisions or extensions to the CIP Senior Manager or a documented delegate before they take effect.
- Sign-off: Keep the evidence trail that shows the process ran, since the entity answers for it during monitoring.
Before engaging anyone, confirm that your named owners and approval chain are written down in your CIP program documents.
An implementation partner can prepare the systems and records that make the R2 process run on schedule. That work is operational and technical, and it can be outsourced, but it never replaces the entity's decisions. A partner builds the tooling and records; the entity decides what the records mean.
- Asset and source inventory: Build an inventory of applicable, updateable Cyber Assets and map each to its patch sources, so the source list in Part 2.1 is maintained rather than remembered.
- Tooling: Set up open-source tools that track inventory and findings, such as GLPI for asset records and Wazuh for system inventory data, configured to match your scope.
- Evidence folders and calendars: Create folder structures, naming conventions and reminders tied to the 35-calendar-day evaluation and action cycle.
- Templates: Draft evaluation records and mitigation plan templates for your approvers to review and adopt.
- Handover: Document how each tool and calendar is operated so your staff can run it after the engagement ends.
Ask any partner to state in writing which deliverables they produce and which decisions remain with your staff.
An independent auditor tests whether the entity's R2 process works as written and was followed. The auditor does not design the process, write the mitigation plans or choose the patch sources, because doing so would remove the independence the assessment depends on. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, and there is no CIP certificate to issue.
- Sampling: The auditor selects applicable assets and patch cycles and asks for the evaluation records and dated decisions behind them.
- Timing checks: The auditor compares evaluation dates with the 35-calendar-day limits and checks that each applied patch or mitigation plan falls within its window.
- Approval checks: The auditor confirms that extensions were approved by the CIP Senior Manager or delegate.
- Findings: Any gap is reported to the entity, which then works through the monitoring and mitigation process with its Regional Entity.
- Scope limit: Consultants who helped build the process can prepare evidence, but they should not be the ones assessing it.
Confirm with your Regional Entity how it expects evidence to be presented before the monitoring engagement begins.
The independence line is the single most useful boundary to set before you buy help. Advice that helps you prepare is different from work that makes a decision on your behalf or grades your own work. Mixing those roles weakens both the compliance record and the value of an audit.
- Can outsource: Inventory building, tool configuration, calendar setup, evidence organization and staff training on the process.
- Keep in-house: Patch applicability decisions, mitigation plan content, timeframe extensions and final approvals.
- Independent by design: Audit testing and any formal findings come from the auditor or Regional Entity, not from the people who set up the process.
- Contract terms: Put scope, deliverables and ownership of records in writing, so the entity keeps the evidence after the engagement ends.
- Recurring work: Monthly evaluations and tool upkeep continue after go-live, so price and assign that effort as an ongoing responsibility.
Ask any provider how they will avoid assessing their own work before you sign.
Where R2 patch programs usually fall short
Most CIP-007-6 R2 findings come from paperwork and scope rather than from missed updates. The gaps below cover sources, evaluation dates, mitigation plans, extension approvals and asset inventories, and each one has a closing action that an auditor can verify.
Missing sources for vendor firmware
Teams often monitor the operating system vendor but not the vendors of BIOS, firmware, relays, HMIs, network devices and embedded controllers. Part 2.1 requires the process to name the sources monitored for each updateable Cyber Asset, so an unnamed firmware source is a gap even if patches exist. Check each Applicable System type against a written source list, and confirm who receives each vendor's notices.
Evaluations without dates
A patch review recorded as done this quarter does not show that Part 2.2 was met. Each evaluation must fall within 35 calendar days of the previous one, and the record should show the source checked, the date, the reviewer and the patches assessed. Undated or inconsistent entries make the cycle impossible to prove, so set a recurring calendar entry tied to the evaluation log.
Mitigation plans without timeframes
When a patch is not applied, Part 2.3 requires a dated mitigation plan that explains how the vulnerability will be addressed and states a timeframe. Plans that say only that a compensating control exists, or that a patch is pending, do not meet the requirement. Each plan should name the vulnerability, the compensating measure, the owner and the date by which it will be implemented.
Extensions without approval records
Part 2.4 requires each mitigation plan to be implemented within its timeframe. When a deadline slips, a revision or extension must be approved by the CIP Senior Manager or a delegate, and that approval must be on record before the original date passes. Verbal agreements and email threads that are not filed with the plan are hard to defend. Confirm the approval chain and file signed revisions with the plan.
Inventories that drift from scope
R2 applies to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. An asset inventory that is out of date, or that lists assets by name without their category, can leave devices outside the patch process. Reconcile the patch tracking list against the CIP-002 categorization and the current Applicable Systems list each time a device is added, replaced or virtualized.
Unclear ownership of patch decisions
When operations, IT and vendors each assume another group is tracking updates, patches go unevaluated and no one can show who decided to defer one. The process should name who monitors each source, who evaluates, who approves mitigation plans and who tracks deadlines. Document these roles in the patch management process and confirm that each named person can produce their records on request.
Questions about CIP-007-6 R2 cost, effort and audits
How much does it cost to meet CIP-007-6 R2 patch management?
No supplied figure sets a price for R2, so ask for a written quote built from your own scope. Cost comes from four places: the internal time to run the patch process, the tooling that tracks sources and records decisions, the work to test and apply patches in your BES Cyber System environment, and any outside help for setup or evidence. Tooling cost depends on whether you buy commercial software or run open-source tools, and open-source licenses remove license fees but not labor. Some costs are one-time (designing the process and building the inventory) and others recur (every 35-day evaluation cycle, mitigation plan upkeep and evidence retention). Ask any provider to split the quote into one-time and recurring items and to state which assumptions drive the number.
Do we need an implementation partner to comply with CIP-007-6 R2?
No. The standard places the obligation on the registered entity, and a partner is optional. Organizations with a small Cyber Asset population and existing patch processes often run R2 in-house. A partner is most useful when the inventory is incomplete, the patch sources are spread across vendors, or the team needs help setting up tools that produce dated, reviewable evidence. DeployOpen plans, implements and documents systems and evidence under a written, fixed scope, but it does not issue audit reports or certifications, and an independent auditor or Regional Entity makes the compliance determination. Confirm scope and deliverables in writing before any work begins.
How long does it take to set up an R2 patch management process?
No supplied timeline gives a duration, so confirm it against your environment. Setup time depends on how many applicable Cyber Assets are updateable, how many patch sources each vendor uses, whether a current inventory exists, and how change windows are scheduled at your control centers and generation sites. Ask any partner for a schedule tied to milestones: source identification, first full 35-day evaluation, first applied or mitigated patch set, and evidence review. The 35-day cycle in Part 2.2 is fixed by the standard, so plan the process around it from the first day of operation.
What does R2 ask from our internal staff?
Internal staff own the decisions that the standard reserves to the entity. Typical roles include a system owner who confirms which Cyber Assets are applicable, an operations or engineering lead who schedules outages and tests patches, a security or compliance analyst who evaluates patches and records outcomes, and an approver for mitigation plan timeframes. The CIP Senior Manager or a delegate must approve any revision or extension of a mitigation plan timeframe under Part 2.4. Plan for these people to spend recurring time each cycle, not just during setup, and document who holds each role.
Can open-source tools produce the evidence an auditor expects for R2?
Open-source tools can produce useful inputs for R2, but they do not decide compliance. GLPI can hold an asset inventory of computers, software and network equipment, and its native inventory can be fed by the GLPI Agent. Wazuh Syscollector collects installed software and Windows updates from each endpoint into dashboards and reports. DefectDojo can import findings from more than 500 report formats and deduplicate them, which helps track evaluations and mitigation items. Greenbone Community Edition runs vulnerability scans with scheduled tasks and stored results. Confirm each tool's license terms and edition limits, and confirm that it covers your patch sources and Cyber Asset types before relying on it as evidence.
How does an auditor test the 35-day evaluation cycle?
An auditor typically asks for the list of patch sources you monitor, then samples evaluation records and checks that each applicable source was evaluated at least once every 35 calendar days. They then trace each evaluated patch to a recorded outcome: applied within 35 calendar days of the evaluation, or covered by a dated mitigation plan created or revised within that window. For mitigation plans, they check that the plan states how the vulnerability is addressed, sets a timeframe, is implemented on time, and that any extension was approved by the CIP Senior Manager or delegate. Records need dates, sources, reviewer identity and linked decisions, so keep them consistent from the first cycle. Confirm the audit period and retention needs with your Regional Entity.
What happens if we miss the 35-day window?
A missed evaluation or decision is a potential noncompliance with R2, and it can lead to a Self-Report, a Compliance Exception or an enforcement action depending on severity and history. Penalty amounts are set under the NERC Sanction Guidelines, and FERC's maximum civil penalty reference is $1,584,648 per violation, per day, as adjusted by Order No. 906. Treat that figure as a ceiling, not an expected outcome. The practical protection is a documented process with alerts for approaching deadlines and a clear path to a dated mitigation plan when a patch cannot be applied in time. Review the enforcement details with counsel or your compliance lead.
How DeployOpen prepares patch evidence for an audit
DeployOpen plans, implements and prepares the systems and evidence that support CIP-007-6 R2, but it does not assess compliance. The Compliance Enforcement Authority, a Regional Entity or NERC, is the only party that audits or evaluates the entity against the standard, and DeployOpen issues no attestation or certificate. The registered entity owns its patch management process and its CIP Senior Manager decisions. Before any work starts, the scope should say which BES Cyber Systems, EACMS, PACS and PCA are in play, which patch sources the entity monitors, which Cyber Assets are updateable, and who approves dated mitigation plans and timeframe extensions under Part 2.4.
Engagements are fixed-scope. The written scope lists the deliverables, such as a documented patch source inventory, an evaluation record template with a dated 35-calendar-day tracking calendar, mitigation plan templates, and an evidence folder structure. It also sets the systems in scope, the handover date and the roles of each party. Ask the partner to show, in writing, how each deliverable maps to a sub-part of R2 and where the auditor can find it. Ask for a quote built from that scope, and check that it lists what is one-time (process design, tool configuration, initial inventory) and what recurs (each evaluation cycle, log exports, mitigation plan reviews).
Patch evaluation is a repeating obligation, so many entities add a retainer for ongoing evaluation cycles. Under a retainer, the partner can run the recurring evaluation, prepare the records and flag patches that require a mitigation plan before the 35-day window closes. The entity still decides whether to apply, mitigate or revise a plan. Confirm during scoping who holds the evaluation calendar, how evidence is retained for the audit period, and how a missed cycle is escalated internally. Any retainer term, response time or review frequency should appear in the signed agreement rather than in a general description.
How DeployOpen scopes and implements R2 patch management
DeployOpen works on CIP-007-6 R2 as an implementation partner inside the client's own infrastructure. The client owns the patch management process and its compliance obligations, while DeployOpen helps prepare the systems, tooling and evidence that show the process runs every 35 calendar days.
How we scope
- Engagements are fixed-scope, with the in-scope Applicable Systems, patch sources and asset lists agreed in writing before work starts.
- The written scope names which high and medium impact BES Cyber Systems, EACMS, PACS and PCA are covered by the R2 process.
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
How we build
- Configure an open-source asset inventory such as GLPI so each updateable Cyber Asset has a tracked record for patch review.
- Set up vulnerability and patch-source monitoring so evaluations can be dated and repeated within the 35-day cycle.
- Build a tracked workflow for applying patches or creating and revising dated mitigation plans, then test it against sample cases.
How we hand over
- Document the patch source list, evaluation cadence, approval steps and mitigation plan template for the client's CIP team.
- Deliver evidence samples showing evaluations, applied patches and dated mitigation plans that the client can present to an auditor.
- Confirm with the client's CIP Senior Manager or delegate which approvals and retention periods their own program requires.
How we support
- Review the process after each evaluation cycle and update patch sources when the client's asset inventory changes.
- Keep tooling current through upgrades agreed in the retainer, and retest the workflow after each change.
- Ask your Regional Entity or compliance advisor to confirm how they expect R2 evidence to be presented in an audit.
