Why open source ITSM for energy and utilities needs a different build
A utility compliance or IT lead is usually asked the same question by auditors: can you show a current inventory of cyber assets, the configuration baseline each one should have, and the evidence for every change made to it? GLPI or iTop can carry the ITSM record layer for that work, but only when the design separates corporate and control-system scope. The NERC CIP obligations set the requirements, not the tool. The tool has to be configured to answer them.
The first design decision is impact categorization under CIP-002-5.1a, which sorts BES Cyber Systems into high, medium and low impact using bright-line criteria. That categorization determines which assets appear in the inventory, which controls apply and how much evidence each record must carry. NERC lists 13 CIP standards as mandatory and enforceable in the United States as of 17 October 2026, so the standards in force for a given entity should be confirmed against the NERC CIP standards page before the data model is designed. Assets, change tickets and baselines for control-system scope should live in a separate instance, workflow and access model from corporate IT, with a documented boundary and a reviewed set of integrations between them.
DeployOpen plans, implements and documents this kind of ITSM build inside the client's own infrastructure, including the separation, the CMDB model, the change workflow and the evidence procedures. DeployOpen does not issue audits, attestations or certificates. There is no CIP certificate, and compliance outcomes are determined by NERC, the Regional Entities and the auditors who assess your program. The practical question for a utility is whether its ITSM records can be exported and explained to an auditor without manual reconstruction, and that should be tested with the compliance team before any rollout is scoped.
Which NERC CIP and NIS2 requirements shape the ITSM design
This table maps each NERC CIP standard and the NIS2 energy classification to a specific design choice in a GLPI or iTop build. Read each row as a question to answer before configuration starts: what the standard asks for, where the source is, and what the service desk must record so an assessor can trace it.
| Requirement | Source | What it means for the GLPI or iTop build |
|---|---|---|
| CIP-002-5.1a impact categorization | NERC CIP standards, bright-line criteria for high, medium and low impact | Add an impact tag to every BES Cyber System asset class and every related CI. Confirm with compliance which control centers, plants and substations sit in each tier before loading assets. |
| CIP-005-7 Electronic Security Perimeter and Intermediate System | NERC CIP-005-7, Electronic Security Perimeter(s) | Model ESP boundaries and Intermediate System hosts as CMDB items with relationships to routable assets. Require a ticket linked to each interactive remote access session and to changes in perimeter rules. |
| CIP-013-2 vendor supply chain records | NERC CIP-013-2, Supply Chain Risk Management | Create vendor and contract records that hold incident notification contacts, vulnerability disclosure terms, software integrity verification evidence and vendor-initiated remote access approvals. Set a recurring review task at intervals no longer than 15 calendar months. |
| CIP-011-3 information protection | NERC CIP-011-3, Information Protection | Restrict access to tickets and attachments that contain BES Cyber System information through profiles and groups. Confirm how the chosen version handles encryption and retention of attachments before storing configuration files in tickets. |
| CIP-015-1 internal network security monitoring | NERC CIP standards page, enforceable 1 October 2028 | Plan asset and network discovery fields now so monitoring alerts can be linked to CIs later. Confirm the monitoring scope with the standard text before design freeze, since enforcement is not yet in effect. |
| NIS2 Annex I energy sector | Directive (EU) 2022/2555, Annex I | For entities in scope, record electricity, district heating, oil, gas and hydrogen assets and suppliers, and link incident tickets to affected assets with timestamps to support early warning and incident reporting timelines. |
How to separate corporate and control-system service desks
Running a dedicated GLPI or iTop instance for the control-system side gives the strongest boundary. The control-system desk has its own database, its own application users, its own file store and its own backups, so a misconfiguration or compromise in the corporate instance cannot expose BES Cyber System records by default. The BES Cyber System inventory never appears in corporate reporting because the corporate instance holds no copy of it. The cost is duplicated administration: patches, plugins, backup jobs and identity mappings are maintained twice.
- What it isolates: data, application code, database credentials, backups and administrator accounts.
- Inventory separation: corporate reports cannot query the control-system database, so BES Cyber System records stay out of corporate dashboards unless someone deliberately exports them.
- Authentication: each instance can point to LDAP directories with separate group filters, and step-up authentication for administrative actions in GLPI 12.0.0 can be enabled per instance.
- Audit trail: each instance keeps its own logs, so evidence for CIP-011 information protection is easier to scope, but cross-instance change correlation must be built by hand.
- Upgrade cadence: two instances may run different GLPI versions, which requires a documented update procedure for each.
Before choosing this option, confirm with the compliance team which records count as BES Cyber System Information and whether the control-system desk needs its own network segment.
A single instance with separate entities and profiles keeps one platform to operate while dividing records by organizational unit. Entities in GLPI and iTop organizations separate data by ownership, and profiles control which screens, actions and records each user can reach. This approach reduces administration effort, but isolation depends on access rules being configured and tested correctly. Any mistake in a profile or in a recursive visibility setting can expose records across the boundary.
- What it isolates: visibility of tickets, assets and reports, enforced through entity assignments and profile rights.
- Inventory separation: BES Cyber System assets sit in a control-system entity, and corporate report templates must be restricted to corporate entities.
- Authentication: LDAP group mappings assign users to profiles on login, so the mapping rules are the main control and need periodic review.
- Audit trail: a single log store holds both sides, which simplifies evidence collection but means reviewers must filter logs to show that cross-entity access was denied.
- Testing burden: each profile and entity combination should be tested with non-production accounts before go-live and after each upgrade.
Ask the implementer to show, with test accounts, that a corporate administrator cannot view, search or export control-system records through the interface, the API or saved reports.
A shared instance with restricted ticket categories is the lightest option. Control-system tickets are routed to a dedicated category and queue, and only designated staff can see that category. It fits organizations that have few control-system assets and a small, well-governed group handling them. The weakness is that categories are a workflow feature, not a hard security boundary, so assets, attachments and historical records may still be reachable by users with broad rights.
- What it isolates: ticket routing and queue visibility, not the underlying data store.
- Inventory separation: BES Cyber System assets remain in the same CMDB, so the separation depends on asset-level permissions or on excluding those classes from corporate reports.
- Authentication: role mapping from LDAP can limit who receives control-system queues, but administrators with global rights can still see everything.
- Audit trail: one log store covers all activity, which keeps evidence simple, but it also places control-system records next to corporate noise.
- Limits for CIP scope: this option is harder to defend when an auditor asks how BES Cyber System Information is protected from general staff.
Confirm with the compliance lead whether category-based restriction satisfies the entity's documented information protection program before adopting it.
Which platforms fit utility ITSM and why
Utilities rarely need one tool for every service desk job. The platforms below cover the CMDB and asset record, the process workflow, and the customer-facing queue, and the right mix depends on how cleanly you separate corporate and control-system work.
GLPI for assets, CMDB and tickets
GLPI combines ITIL service desk, asset management, CMDB, contracts and financial records under GPL-3.0, with GLPI 12.0.0 published on October 7, 2026. For utilities, its agent inventory through GLPI Agent covers Windows, macOS and Linux endpoints, and LDAP authentication lets you tie access to your directory. Check the platform requirements before you commit: the README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list older versions for GLPI 11.0, so confirm the exact version set for your environment with your implementation partner.
iTop for a customizable CMDB
Combodo iTop is licensed under AGPL-3.0, and version 3.3.0 was published on September 15, 2026. Its CMDB model can be extended, which suits impact tagging: marking which records are BES Cyber Systems, which sit inside an Electronic Security Perimeter, and which feed control-center operations. Expect model design and workflow configuration to be the main effort, and confirm with the vendor how upgrades handle custom classes before you extend the data model.
Zammad for a separate customer queue
Zammad is an AGPL-3.0 helpdesk for queues that face customers, contractors or field crews rather than internal staff. It suits a deployment where external parties raise requests that must not land in the control-system ticket stream. Zammad 7.2.2 was released on October 8, 2026 as a security update, so confirm your patch cadence and how tickets are linked back to CMDB records in GLPI or iTop.
FreeScout as a lighter front end
FreeScout is an AGPL-3.0 helpdesk, with release 1.8.248 published on October 17, 2026. It fits a smaller intake queue for vendors or site contacts where a full ITSM suite is more than the team needs. Before choosing it over Zammad, verify its audit logging, access controls and retention features against your evidence requirements, because these determine whether it can hold records that auditors will review.
Separate service desks by perimeter
A utility that runs one service desk for corporate IT and control-system support often mixes evidence, access and change approvals in a single queue. Treat the split as a design decision: separate instances or strictly segregated queues, with distinct asset classes and approval paths for the control side. Ask any partner how they will keep control-system tickets, assets and credentials out of the corporate queue, and how cross-references are kept without exposing data.
Integration points and deployment pattern for utilities
A utility GLPI or iTop deployment touches more systems than a corporate service desk, so each integration needs a defined data direction and owner. The cards below cover the inventory feeds, identity, vendor access and backup decisions that affect audit evidence.
Inventory collection with GLPI Agent
GLPI Agent collects hardware and software inventory from Windows, macOS and Linux endpoints and sends it to GLPI. For a utility, the decision is which corporate and control-center hosts run the agent and which do not, because agents on BES Cyber System hosts need change approval under the entity's own CIP-010 process. Confirm with the vendor and your compliance team whether the agent's network traffic is permitted through the Electronic Security Perimeter before rollout.
Network discovery without active scanning
Network discovery finds devices that have no agent, such as network gear, relays and some OT devices. Active probing can disrupt fragile protocols on control networks, so the design should start with passive or read-only methods agreed with operations staff. Record the scan scope, schedule and approver in the ITSM change record so the discovery itself is auditable.
Monitoring and SCADA-adjacent asset feeds
Asset records for control systems often come from historians, monitoring platforms or engineering databases rather than from agents. Define which system is the authoritative source for each asset class, and make the CMDB store identifiers rather than copies of control data. Confirm with the control-system vendor which exports are supported and whether they can run one-way, from the control environment into the service desk.
Identity through LDAP
GLPI checks authentication against its internal database, LDAP directories and other external methods in a set order, so the LDAP configuration determines who can open, approve or close control-system tickets. Map directory groups to GLPI profiles so that corporate and control-system staff hold separate roles. Confirm how your directory handles service accounts and whether control-room staff can authenticate when the directory is unreachable.
Vendor remote access tickets for CIP-013-2
CIP-013-2 requires supply chain risk management plans that cover coordination of vendor-initiated remote access, and the plan must be reviewed at least every 15 calendar months. A vendor session should open as a ticket linked to the asset and the contract, with the approver, start time, end time and actions recorded. Confirm with your compliance lead which fields the plan needs, since the ITSM record is evidence for the plan and does not replace it.
Backup of glpi.key and glpicrypt.key
GLPI stores encrypted data using keys in the config directory, so a database backup alone cannot restore encrypted fields such as stored credentials. Back up glpi.key and glpicrypt.key together with the database and files, and store them in a separate controlled location. Before each upgrade, the GLPI update procedure requires a backup of the database, files and config directory, so the key handling should be part of the change record for every release.
How a utility ITSM rollout runs in phases
The sequence moves from agreed scope and impact categories to a separated service desk, a reconciled asset baseline and an evidence pack that an auditor can follow. Each phase closes with a signed or indexed output, so the next phase starts from a known position.
Agree scope and impact categories
The utility's compliance lead, OT engineering, operations and the implementation partner run a scoping workshop to decide which entities, sites and systems fall in scope and how each is categorized as high, medium or low impact under CIP-002. Registered entity status, the Balancing Authority, Reliability Coordinator or Transmission Operator role, and any applicable state or regional rules should be confirmed with the compliance function at this stage. The step closes with a signed scope document listing in-scope facilities, the impact rationale for each, and the owners who approve later changes to that list.
Design the corporate and control-system split
Architects map which service desk, CMDB and inventory tools serve corporate IT and which serve control-system assets, then review how any shared components cross the Electronic Security Perimeter defined under CIP-005. The design records which ticket queues, integrations and remote access paths are allowed to touch BES Cyber Systems, and which ones are blocked. The step closes with an approved separation design and an ESP review record that compliance and OT security have both signed.
Build the inventory baseline through discovery
The team deploys GLPI Agent or a comparable discovery method on corporate endpoints and performs network discovery on permitted segments, while control-system assets are captured through reviewed manual records and vendor data because active scanning may not be appropriate in OT environments. Discovered records are matched against engineering documents and the impact categories from scoping. The step closes with a baseline inventory in which each asset has an owner, a location, a classification and a known source of its data.
Configure change and incident processes
The partner configures GLPI or iTop change and incident workflows with approval steps, required fields for affected CIP-scoped assets, and records for baseline configuration and its review. Roles are mapped to the people who authorize changes, and the configuration is tested with sample tickets that follow a realistic change through approval, implementation and closure. The step closes with a configuration record that lists each workflow, its approvers and the fields that hold configuration baseline data, so an auditor can see how a change is controlled.
Migrate and reconcile existing asset lists
Existing spreadsheets, legacy CMDB exports and vendor lists are loaded into a staging environment and matched against the discovered baseline. Duplicates, orphaned records and conflicting classifications are resolved by named owners, with each decision logged. The step closes with a reconciled BES asset list that shows source, owner and impact category for each entry, plus a list of open exceptions that compliance has accepted or rejected in writing.
Run in parallel and cut over
For a defined period agreed in the rollout plan, operators record changes and incidents in both the existing process and the new service desk, and the team compares results for completeness and timing. Any gaps trigger corrective action before the old process is retired. The step closes with a cutover approval signed by operations, OT security and compliance, and a record of the parallel-run comparison that shows where the two processes matched and where they diverged.
Hand off the evidence pack
The partner assembles the documentation an internal audit or regulator-facing review will ask for: the scope document, the separation design, the baseline inventory, change and incident configuration, retention settings, access records and the parallel-run results. An evidence index maps each document to the CIP requirement it supports, and the utility's team is trained to retrieve records during an audit. The step closes with a signed evidence index and handover of administration duties. Note that the evidence index supports audit preparation and does not replace the independent audit.
Evidence regulators and auditors ask for and where ITSM produces it
This table maps the evidence items a NERC CIP or NIS2 assessor typically requests to the GLPI or iTop component that can produce them. Read each row as a starting point: the tool generates records, but the utility still decides retention periods, sign-off authority and what counts as a complete record for its own program.
| Evidence item | What the auditor asks | Where GLPI or iTop produces it | What the utility must still own |
|---|---|---|---|
| Cyber asset inventory extract | Is every BES Cyber System and associated asset identified, classified by impact, and kept current? | GLPI assets and inventory from GLPI Agent, with CMDB-style relations in iTop; exports filtered by impact tag or classification field | Impact classification under CIP-002 criteria, the approved inventory baseline and periodic attestation by the CIP program owner |
| Change tickets with approval and baseline comparison | Was each change to a CIP-scoped system authorized, tested where required, and compared against the approved baseline? | GLPI change records with validation steps and linked assets; iTop change requests linked to configuration items and before and after snapshots | Definition of what counts as a baseline change, approver roles, and how emergency changes are reviewed after the fact |
| Vendor remote access records | Who accessed in-scope systems remotely, when, through which intermediate path, and under which approved vendor arrangement? | Tickets and linked assets record requests and approvals for vendor sessions; session logs themselves come from the access gateway, not the ITSM tool | Access gateway and multi-factor logs, the vendor access approval process and reconciliation of ticket records against actual sessions |
| Supply chain review records | Are vendor notification, vulnerability disclosure, software integrity and remote access coordination tracked and reviewed on the stated cycle? | Supplier and contract records in GLPI, with review tasks and reminders; iTop supplier objects linked to the systems they support | The supply chain risk management plan itself, vendor due diligence results, and the review cycle sign-off |
| Incident timestamps for NIS2 early warning | When was the incident detected, classified and first reported, and can the sequence be reconstructed? | GLPI or iTop incident tickets with creation, assignment and status history; linked assets show affected systems | Reporting authority decisions, deadline calculation rules, and confirmation that the timeline matches the regulator submission |
| Retention of records | Can records be produced for the required period, unaltered, and with their history intact? | Ticket and asset history retained in the database; export and backup procedures for the database, files and configuration keys | Retention schedule per record type, backup testing, access controls on the database, and legal hold procedures |
| Separation of corporate and control-system service desks | Can an assessor see which tickets and assets belong to the control-system environment and who could access them? | Separate entities, profiles and ticket categories in GLPI or iTop; access restricted by entity and group | Network segmentation design, role definitions, and the decision on whether a shared tool is acceptable for the scope |
What changes for utility IT and OT teams after go-live
The biggest change after go-live is that a baseline change to a BES Cyber System becomes a ticket that cannot be skipped. Once the ITSM workflow is live, a change to a cyber asset's configuration, software or ports should open a change record that names the asset, its impact classification under CIP-002-5.1a, the approver and the verification step before the change closes. Operations staff used to making changes through vendor consoles or local sessions need to learn that the ticket is the starting point, not a report written afterward. Confirm with your compliance lead which change types need a ticket before work starts and which, such as routine patch deployment within an approved baseline, follow a pre-approved standard change.
Asset owners take on a continuing duty to keep impact tags accurate. In a GLPI or iTop model, each cyber asset needs a named owner, a documented impact level and links to its Electronic Security Perimeter, remote access path and vendor contract where those apply. Someone must own the update when a substation is energized, a server is virtualized or a vendor is replaced. Ownership usually sits with OT engineering for control-system assets and with corporate IT for the shared services they depend on, so the ITSM design should assign each class of asset to one accountable team and one approver. Review the assignments with your CIP program owner at least every 15 calendar months, which matches the review cycle in CIP-013-2 for supply chain plans. Penalty exposure is the reason to document this process. The maximum civil penalty is $1,584,648 per violation per day under 18 CFR 385.1602, so an undocumented change or a missing owner can become a costly finding. Ask any implementation partner to show how the process produces that record without manual reconstruction.
Questions utilities ask before hiring an ITSM partner
What drives the cost of an open-source ITSM project for a utility?
The cost is driven mainly by scope: how many BES Cyber Systems and their associated assets you must inventory, how many sites and control centers are involved, how many systems the service desk must integrate with, and how much historical data must be migrated. Software licenses for GLPI or iTop are not the main cost, because both are open source. The one-time work covers requirements, CMDB modeling, process configuration, agent rollout and testing in a non-production environment. Recurring costs include administration, patching and, if you buy one, a vendor support subscription. Ask any partner for a quote that separates these components and states which systems are in scope and which are excluded.
Can a utility's internal team run an ITSM build without a partner?
Many utilities have capable IT staff who can deploy GLPI or iTop, but a CIP-aligned build also needs people who understand the impact classification of systems, change evidence and the difference between corporate and control-system assets. Your team should confirm whether it has the time, the database and web server skills for the platform, and someone who can own the records after go-live. A partner can fill gaps in configuration, migration and documentation, and DeployOpen implements and hardens self-hosted platforms inside your own infrastructure under a written, fixed scope. Whichever route you choose, agree in writing who maintains the evidence trail.
How long does an ITSM build take for a utility?
Duration depends on scope rather than on the platform alone. The main variables are the number of sites, the count of in-scope assets, the number of integrations with monitoring, identity and procurement systems, and whether change and asset history must be migrated. A narrow corporate service desk can move faster than a multi-site inventory that must be reconciled against BES Cyber System lists. No fixed duration applies to every utility, so ask for a timeline in the written scope and check which milestones depend on your staff, such as access approvals, outage windows and sign-off on the asset categories.
What does the work need from utility staff?
The engagement needs named people from several areas. Operations and control-system engineers must confirm which devices are BES Cyber Systems and which networks they sit on. Compliance staff must define the evidence they need for audits, such as change approvals and baseline records. Network and security teams must approve how discovery agents and integrations reach segmented networks, and the service desk owner must agree on workflows. Plan for these people to be available during discovery, design review and testing, because inventory accuracy depends on their input.
Do GLPI Network subscription tiers apply to a self-hosted utility deployment?
GLPI Network subscriptions are a separate, optional vendor offering from the open-source software. According to the GLPI Network subscriptions page, self-hosted subscriptions range from 100 euros per month for the Basic tier, which covers up to 10 agents and 500 assets, to 4,500 euros per month for the Enterprise tier, which includes level 3 support and marketplace plugins. The public and private cloud options are priced per user per month. Confirm current tiers and terms directly with the vendor, because the page may change, and decide whether you need vendor support or can rely on internal and partner support instead.
Does DeployOpen issue NERC CIP compliance certificates?
No. DeployOpen does not issue audit reports, attestations or certifications. There is no CIP certificate to buy. Compliance is assessed through audits by the Regional Entities under NERC oversight, and entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator are audited at least once every three years. DeployOpen plans and implements the ITSM systems, controls and evidence that support your readiness, and your auditors decide whether that evidence meets the standards. Ask any partner to show how the records will map to specific CIP requirements, including CIP-002 and CIP-011, without promising an outcome.
Should corporate and control-system service desks share one ITSM instance?
Many utilities keep them separate, but the decision depends on your segmentation and access model. Sharing a platform can simplify reporting, while separate instances or strictly partitioned data reduce the chance that corporate users and vendors reach control-system records. Discuss how CIP-005 Electronic Security Perimeter boundaries and remote access paths affect which system holds which records. Ask the partner how they will isolate tickets, assets and attachments, how they will audit administrator actions and how they will document the design for reviewers.
What should a utility ask for in a written scope?
Ask for a list of in-scope processes, asset classes, sites, integrations and migration sources, along with the named deliverables and acceptance tests. The scope should state how BES Cyber System data is classified and stored, which environments are used for testing, how backups and the configuration keys of the platform are protected, and how the update procedure will be run. It should also name the support model after go-live, the handover of documentation and who owns each record type. Clear exclusions prevent disputes later, so ask the partner to list what is not covered.
What to ask an implementation partner before signing
Start with CIP evidence mapping, because it decides what the partner builds. Ask which CIP requirements the partner will map to specific GLPI or iTop objects, fields, tickets and reports, and who signs off that each mapping is accurate. Ask how the partner will show that a BES Cyber System inventory record links to its impact rating under CIP-002-5.1a, and how change records tie to the baselines and configuration evidence that CIP-010 expects. Request a sample evidence package for one control before scope is signed. Confirm which CIP standards are in force for your registration as of the date of signing, since NERC lists 13 CIP standards as enforceable in the United States, with CIP-003-9 and CIP-012-2 on later dates. Also ask how the partner will track CIP-015-1 and the virtualization revisions, which take effect in 2028.
Next, test how impact categories are modeled. Ask the partner to show, in your own test instance, how high, medium and low impact classifications are stored in GLPI or iTop: as a dropdown, a custom class, a relation to a categorized asset, or a combination. Ask who can change an impact value, whether changes are logged, and how a reclassification triggers a review of linked tickets and assets. Ask how control-system data is kept out of shared instances. The usual answers are a separate instance in a separate network zone, or a logical split with strict profiles, and each has different hosting, backup and access consequences. Ask who holds administrator rights, how those rights are reviewed, and how the partner proves that corporate staff cannot read control-system records.
Backup and upgrade handling needs a direct answer. The GLPI update procedure requires backing up the database, the files and the config directory including glpi.key and glpicrypt.key, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Ask who tests each plugin against a new release, where that test runs, how long a suspended plugin can leave a CIP-relevant workflow broken, and how the partner restores the key files during a recovery drill. Ask about support subscription coverage too: confirm whether the GLPI Network tier covers plugin issues, upgrade assistance, and response to security updates, and which party is responsible if a vendor subscription does not cover a third-party plugin. Finally, settle who owns the evidence retention policy. Your compliance team should own the retention periods and the decision to keep or purge records, the partner should implement them, and the contract should say who approves any deletion of audit evidence.
How DeployOpen scopes, builds and supports utility ITSM
The sequence moves from a written scope to a tested, documented service desk with separated corporate and control-system workflows, and leaves the utility with evidence it can hand to its own auditors. DeployOpen prepares that evidence but does not issue audit reports or certifications.
Agree scope and separation boundaries in writing
DeployOpen reviews the utility's registration and impact context with its compliance and operations leads, then defines which systems fall under the control-system service desk and which stay in the corporate desk. The scope document lists ITIL processes, CMDB classes, integrations, deliverables and acceptance criteria. Work does not start until the utility signs off on this document, which is the baseline every later step is measured against.
Design the corporate and control-system service desks
The design sets out separate GLPI or iTop instances or segregated spaces, with distinct queues, roles, approval paths and network placement, so that control-system tickets never flow through corporate tooling. It maps which integrations cross the boundary and how they are authorized and logged. The output is an architecture and access model that the utility's security and operations teams review and approve before build.
Build the cyber asset inventory and CMDB model
DeployOpen configures the CMDB classes, relationships and asset lifecycle states the utility needs to record cyber assets, their classification and their owners. Inventory agents and discovery are set up according to what the utility's network and change rules allow, and the first population is reconciled against existing asset registers. The check is a reconciliation report that lists unmatched assets, which the utility resolves with its asset owners.
Configure change tracking, baselines and approvals
DeployOpen builds change request types, approval workflows, baseline records and back-out fields so that configuration changes to in-scope systems are authorized, dated and linked to the affected assets. Emergency change paths are defined separately with their own review steps. The check is a set of test changes run through each path, with the resulting ticket history reviewed by the utility's change board.
Set up evidence retention and audit trails
DeployOpen defines which ticket, asset and change records are kept, how long they are retained under the utility's own policy, and how logs and timestamps are protected from alteration. Retention settings, backup jobs and access logging are tested against the requirement list agreed in step one. The output is a retention and evidence map that shows which artifact supports which requirement, which the utility's compliance lead signs off.
Implement and integrate inside your infrastructure
Implementation runs in the utility's own cloud accounts, data centers or isolated networks, with integrations to monitoring, identity and procurement systems built to the separation design. DeployOpen hardens the platform, configures authentication through the utility's directory, and documents each component. The check is a completed integration test plan with results recorded for each connected system.
Prepare documentation and assessment evidence
DeployOpen compiles operating procedures, configuration records, the evidence map and test results into a package that the utility's own auditors or compliance team can review. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and the utility's auditors or regulators make those determinations. The package is accepted when the utility confirms it matches the agreed scope.
Support upgrades and operations under retainer
After handover, the utility can keep DeployOpen on an optional retainer for platform upgrades, backups, ongoing support and periodic testing. Upgrades are planned against the change process so that each one produces its own approval and back-out record. Pricing for any retainer comes from a written quote tied to the agreed scope, since DeployOpen does not publish a price list.
Sources and further reading
- NERC: CIP Reliability Standards (status and US effective dates) ↗
- NERC: CIP-005-7, Cyber Security: Electronic Security Perimeter(s) ↗
- NERC: CIP-013-2, Cyber Security: Supply Chain Risk Management ↗
- NERC: CIP-011-3, Cyber Security: Information Protection ↗
- GLPI installation docs: Prerequisites ↗
- GLPI Agent documentation ↗
