octoplant and NERC CIP: Baselines, Change Monitoring and Recovery Plans

The octoplant NERC CIP question comes from electric utilities and generators that need to meet CIP-010’s configuration baseline and change monitoring requirements and CIP-009’s recovery plan requirements, and want to know whether AMDT’s platform helps. AMDT says its products “support the operational processes and documentation behind frameworks such as NERC CIP” (AMDT energy and utilities). In our view the fit is real but partial: octoplant is strongest on controller and device content, while CIP-010 baselines are written largely around hosts. This page sits under octoplant compliance in the AMDT cluster.

NERC CIP in brief

The Critical Infrastructure Protection standards are mandatory reliability standards for registered owners and operators of the North American bulk electric system (BES), enforced by NERC and its regional entities. CIP-002 categorises BES Cyber Systems as high, medium or low impact, and each later standard states, in an applicability table, which requirements apply to which category. A requirement that applies to a high impact control centre may not apply at all to a low impact substation. Applicability decides scope before any tool discussion starts.

Requirement numbers below follow CIP-010-4 and CIP-009-6, which NERC lists as subject to enforcement as of October 2026. NERC also lists CIP-010-5, CIP-009-7.1 and new versions of CIP-002 as subject to future enforcement from 1 July 2028 (NERC CIP standards), so check which version applies to your registration on the date of your audit.

The standards are written as requirements on the entity, measured by evidence. Auditors look for proof that a process ran on schedule for every applicable asset, so a tool’s value under CIP is mostly in how reliably it runs, how completely it covers the asset list, and how easily its records can be produced per requirement.

CIP-010: baselines and change monitoring

CIP-010 is the standard where a configuration change tool does most of its work. For applicable systems:

• R1, baseline configuration. A baseline per asset covering the operating system or firmware, intentionally installed commercial or open-source software, custom software, logically accessible network ports, and applied security patches.
• R1, change control. Changes that deviate from the baseline are authorised and documented; the baseline is updated within 30 calendar days; security controls affected by the change are identified beforehand and verified afterwards. For high impact systems, changes are tested in a test environment where possible. A later revision added verification of software source and integrity before a change.
• R2, configuration monitoring. For high impact systems, monitor for changes to the baseline at least once every 35 calendar days, and document and investigate unauthorised changes.
• R3, vulnerability assessments. At least once every 15 calendar months, with an active assessment at least every 36 months for high impact systems.

Where PLC and relay logic fits is a question of interpretation. Firmware is clearly in the baseline. Whether controller logic or device settings count as “custom software” is something entities decide and document, and auditors review. A tool that versions logic gives stronger evidence than the minimum either way.

An illustrative case. A generating station’s high impact control system includes several PLCs that run balance-of-plant equipment. The 35-day monitoring run compares each running program with its approved version and finds one difference: a changed alarm delay on a cooling water pump. The change log shows an authorised work order from three weeks earlier, but the baseline was never updated. The finding is not an unauthorised change; it is a missed 30-day baseline update. The compare found it in minutes. Deciding what it means, and whether it is a possible violation to self-report, is a compliance judgement.

CIP-009 recovery plans and octoplant

CIP-009 requires recovery plans for applicable systems that include the conditions for activation, roles and responsibilities, processes for backing up and storing the information needed to recover, processes to verify that backups complete and to handle failures, and preservation of data that helps determine the cause of an incident. Plans are tested at least once every 15 calendar months, including a test of a representative sample of the backup information, with an operational exercise at least every 36 months for high impact systems. Plans are updated within 90 days of a test or an actual recovery.

This is octoplant’s home ground. Scheduled device backups, job success records, known-good versions and restore procedures map closely to these requirements. The disaster recovery page covers how restores work.

octoplant, NERC CIP tooling and Industrial Defender

Utilities typically automate three things: collecting baselines from many assets, comparing them on a schedule, and assembling evidence for audits. The established specialist in this niche is Industrial Defender, which combines OT asset management, configuration baselines, change detection, vulnerability data and NERC CIP compliance reporting, with partnerships with Dragos and Nozomi. Banneker Partners took a majority stake in January 2026 (Orrick). We found no public head-to-head comparison with octoplant.

CIP area	octoplant-type tool (device content)	Industrial Defender-type tool (host and device baselines)	Entity responsibility
CIP-010 R1 baseline	Firmware and logic versions for supported devices	OS, software, ports and patches on hosts and many devices	Defining baseline elements per asset, interpretation
CIP-010 R1 change control	Approved versions, check-in, approvals	Change tracking against baseline	Authorisation records, security control verification
CIP-010 R2 monitoring	Scheduled compare, alerts	Scheduled collection and compare	Investigating and documenting deviations
CIP-010 R3 vulnerability	With octovision, CVE matching from asset data	Vulnerability data per asset	Assessment execution, remediation plans
CIP-009 recovery	Device backups, restore of logic and configuration	Generally not a device restore tool	Plan, test, exercise, update within 90 days
Audit evidence	Reports and exports	Compliance-oriented reporting	Evidence packaging, audit responses

The fair reading: a utility with a mature CIP programme on host-baseline tooling would look at octoplant for device backup and recovery, not to replace that tooling. A generator or utility with many PLCs, DCS controllers and HMIs and weak recovery would find octoplant addresses its larger gap.

Questions to settle before using octoplant for NERC CIP

1. Which assets and baseline elements will octoplant evidence, and which will come from another tool? Write it down per asset type, so nobody assumes coverage that does not exist.
2. Is the 35-day monitoring schedule enforced by jobs, and what happens when a job fails on day 34?
3. How is “authorised” proven? Link approvals in octoplant to the work order or change ticket.
4. Can a baseline update be traced to the change that caused it, with dates that show the 30-day window?
5. How is a CIP-009 restore test recorded, and is the sample representative of the asset types?
6. Who reviews deviations, and where is the investigation documented?

Where it gets hard

• The tool becomes a CIP asset. A server that connects into an Electronic Security Perimeter to collect baselines may itself be categorised, for example as a Protected Cyber Asset. That is the entity’s determination, and it brings the server into scope.
• Evidence format. Auditors want evidence by requirement and by asset. Check that reports can be produced that way without manual reassembly.
• Coverage of field devices. Relays, RTUs and gateways in substations may not be in a manufacturing- focused device matrix. AMDT’s matrix is behind the myAMDT login; verify asset by asset.
• Water is not CIP. Combined utilities run two regimes; see octoplant for utilities and water.

An OT network assessment can map assets, perimeters and data flows before a tool is chosen. Across the cluster, see octoplant, NIS2 and IEC 62443 for the European equivalent.