Why a utility intranet is a compliance tool as well as a communications tool
If you run operations or security at a utility, the intranet is one of the few channels that can reach every employee and leave a dated record of what they were told. CIP-004-7 R1 treats intranet postings as a valid indirect communication channel for quarterly security awareness reinforcement, alongside posters, brochures and direct messages. That makes the platform part of your evidence set, not just a place for news. The evidence holds up only if you can produce dated copies of the material and show proof of distribution, so the intranet must keep publication dates, version history and read or acknowledgment data that an auditor can examine. The same platform can also become a leak path. CIP-004 reinforcement content is general by design, but staff routinely paste operational detail into posts, comments, wiki pages and attachments. Any content touching BES Cyber System Information needs a separate space with restricted membership, no search indexing for general users, and a rule that such material never goes into the awareness spaces. Confirm with your CIP program owner how BES Cyber System Information is defined in your information protection program before you configure spaces, because CIP-011-3 governs how that information is protected, and the intranet configuration has to match your own classification.
Two timing points matter for planning. The NERC CIP standards become mandatory in the United States only once FERC approves them under section 215 of the Federal Power Act, so the version of each standard that applies to you is the one currently in force, not the one in a draft. NERC lists 13 CIP standards as enforceable as of 17 October 2026, including CIP-003-9 and CIP-012-2, and several virtualization revisions take effect in 2028 and 2029. Check the status page for your applicable standards before you fix retention settings. For platform fit, HumHub, XWiki or Nextcloud can serve as the intranet core, with identity, hosting and logging provided by corporate IT under the same controls used for other CIP-scoped systems. The right choice depends on how granular access control must be and where the platform is hosted, so settle those two questions before comparing products.
Which CIP and NIS2 requirements shape the intranet build
This table maps the NERC CIP and EU requirements most likely to touch an energy intranet to the spaces, identity, hosting and vendor access decisions they influence. Read each row as a question to settle with your compliance team, because scope depends on your impact classification under CIP-002-5.1a and on confirmation of applicability with your Regional Entity or national authority.
| Requirement | What it asks for | What it means for the intranet |
|---|---|---|
| CIP-004-7 R1 measures | Quarterly security awareness reinforcement, with evidence such as dated material and proof of distribution, which can include intranet posts. | Keep a dedicated, dated security awareness space with immutable post history, read tracking where feasible, and an export path for evidence packages. |
| CIP-011-3 information protection | Protect BES Cyber System Information through documented methods for identifying, handling and disposing of it. | Do not place BCSI on broad spaces. Use restricted spaces with named membership, disable public sharing and confirm that search indexes and exports respect those limits. |
| CIP-005-7 electronic security perimeter | Routable assets of high and medium impact systems sit inside an Electronic Security Perimeter, and interactive remote access passes through an Intermediate System with encryption and multi-factor authentication. | Host the intranet on the corporate IT side of the boundary, not inside the ESP. Remote staff reach it through the approved access path with multi-factor authentication. |
| CIP-013-2 supply chain risk management | Plans covering vendor incident notification, vulnerability disclosure, software integrity verification and coordination of vendor remote access, reviewed at least every 15 calendar months. | Record the intranet platform, its plugins and its update channel in the supply chain plan. Verify release signatures or checksums before upgrades and restrict vendor remote support to approved sessions. |
| NIS2 Annex I, energy | Energy, including electricity, district heating and cooling, oil, gas and hydrogen, is a sector of high criticality under Directive (EU) 2022/2555. | If you are in scope, expect risk management, incident reporting and supplier security duties to apply to the intranet as a supporting business system. Confirm applicability with your national competent authority. |
| Delegated Regulation (EU) 2024/1366 | Network code on sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943. | Relevant if you operate cross-border electricity flows. Ask whether its rules reach business IT systems or only operational technology, and map any resulting controls to spaces and access. |
| Scope check under CIP-002-5.1a | Impact categories (high, medium, low) set which systems and requirement tables apply, using bright-line criteria in Attachment 1. | Classify the intranet as outside BES Cyber Systems only after documenting why. Confirm the classification and any applicable requirements with your Regional Entity before the build starts. |
How intranet posts become CIP-004-7 quarterly reinforcement evidence
CIP-004-7 R1 lets an entity use intranet content as evidence of quarterly security awareness reinforcement, provided the record shows what was sent, when, and who could see it. The measure names several acceptable forms: dated copies of the material, proof of distribution through direct communications, indirect communications such as posters, intranet or brochures, and management support and reinforcement. An intranet post therefore fits as indirect communication, but only if the record is strong enough for an auditor to reconstruct the event. For a utility, that means treating each quarterly post as a controlled record, not a page that someone edited last week. A compliant record for each post should contain four things: a dated, versioned copy of the exact content as published, the audience or space it reached (for example, a named group for operations staff with access to BES Cyber Systems, or a contractor space), read or acknowledgment data where the platform supports it, and a retention rule that outlasts the audit window. Export the post with its revision history on the publication date, store it in a write-once location inside corporate IT, and record the group membership at that moment, because group membership changes over a quarter. Confirm with your platform team which intranet modules expose read counts and acknowledgments, and which only show views. Before you rely on this approach, confirm with your Compliance Enforcement Authority how it will accept intranet evidence, including the format of exports, the level of detail on distribution, and whether screenshots or database exports are acceptable. DeployOpen prepares the publishing workflow, export routines and evidence folders, but it does not issue audit results or determine whether your records satisfy CIP-004-7. Those decisions belong to your compliance team and the auditor, so agree the evidence specification with them before the first quarter is published.
Which content belongs on which intranet space
General security awareness content is the material that supports CIP-004-7 quarterly reinforcement: phishing alerts, clean desk reminders, badge and visitor etiquette, reporting channels and lessons from recent incidents. It is written for everyone with network access, so it can live on a broad, company-wide space. The standard's R1 measures accept dated copies of the material and proof of distribution through indirect channels such as an intranet, so the intranet post itself can serve as evidence if it is dated, versioned and retained.
- Access model: open to all employees and contractors with a directory account, with read access only for most users and edit rights limited to a named communications or security group.
- Belongs on the intranet: yes, as news posts or a dedicated awareness space with publication dates visible.
- Evidence handling: keep dated copies of each post and record who received it, using read receipts or distribution logs where the platform supports them. Confirm the retention period with your compliance team.
- Controls: enable search indexing for this space, and avoid embedding internal system names or network diagrams that would not be needed for awareness.
- Attachments: keep PDFs and slides in the document library, and link to them from the post rather than inserting them into broad news streams.
Before launch, confirm with your CIP program owner which materials count as reinforcement and how long dated copies must be kept.
Operational procedures such as switching guides, shift handover steps and on-call escalation paths are useful to operators but not to the whole company. They should sit in spaces limited to the roles that perform the work, with membership managed through the directory. Access should follow the same role model the entity uses for its CIP access authorization, so that a person who cannot access a system in the field cannot read the procedure for it on the intranet.
- Access model: named roles or groups synchronized from the directory, with access reviewed on the same cadence as other access reviews in the entity's program.
- Belongs on the intranet: only the procedure summaries and pointers the role needs. Detailed system-specific steps that describe how a specific asset is configured usually belong in a controlled repository, not on a general wiki.
- Controls: exclude restricted spaces from search results for users outside the role, and disable comments on procedure pages that might collect sensitive questions.
- Logging: enable audit logs for page views, edits and permission changes so that access to restricted content can be shown later.
- Mobile and external access: confirm whether restricted spaces can be opened from personal devices, since this affects the entity's remote access controls.
Check with your security and operations leads which procedures are role-restricted and whether any of them describe the assets in scope for CIP-005-7 or CIP-007-6.
BES Cyber System Information (BCSI) is information about BES Cyber Systems that could be used to plan or execute an attack, such as network topology, device configurations, asset lists and vulnerability details. CIP-011-3 governs how entities identify, protect and handle BCSI, and the entity's own information protection program defines the detailed rules. In most utilities the safe default is that BCSI does not go on the intranet at all, and the intranet should point to a controlled repository with its own access and logging.
- Access model: named individuals with a need to know, approved through the entity's BCSI access process, not role membership alone.
- Belongs on the intranet: no. Store BCSI in the controlled repository that the program designates, and keep the intranet to a pointer that does not reveal the content.
- Controls: no search indexing, no attachments, no comments, no external embeds, and no copies in personal storage or chat channels.
- Accidental exposure: plan a check for uploads that contain configuration files or diagrams, since users may paste BCSI into a general page without noticing.
- Vendor access: confirm with your supply chain program whether vendors can reach any intranet area, because CIP-013-2 covers vendor-initiated remote access.
Before you design any BCSI space, ask your CIP compliance lead to confirm how the program classifies information, because the classification decides where the boundary sits.
Which open-source intranet platforms fit a utility
A utility intranet usually splits into three jobs: a social layer for news and mandatory reads, a controlled wiki for procedures, and a file layer for documents. The cards below cover the platform for each job and the on-premises chat and asset components that sit beside them. Confirm LDAP, SAML and audit logging support for the edition you plan to run before you commit.
HumHub for news and spaces
HumHub is the social layer most utilities start with: news streams, spaces per control center, plant or department, and comments. For security awareness, its Professional News module is the feature to evaluate, because it is the relevant route for mandatory read notices that you can later show as dated distribution evidence under CIP-004-7 R1. Confirm which edition provides that module, LDAP and SAML, and how read acknowledgments are recorded. Keep BES Cyber System Information out of general spaces and create restricted spaces with named membership.
XWiki for controlled procedures
Operating procedures, switching checklists and security policies need page-level rights, version history and approval routines rather than social posts. XWiki gives structured documentation with fine-grained access rights, which lets you separate general staff content from procedures that reference restricted system details. Check whether the edition you need supports directory integration, SAML and audit logging, and decide whether procedure documents are published on the intranet at all or only referenced by link from a restricted space.
Nextcloud for the document layer
Nextcloud holds the files behind the intranet: policy PDFs, training material, and the dated copies that serve as evidence. Its AGPL-3.0 license and current release line matter for your legal review, and its sharing controls (expiry dates, passwords, group-only shares) determine whether a document can leave the utility. Map which folders hold anything derived from BES Cyber System Information and limit those to restricted groups. Confirm the audit logging and external sharing options available in your edition.
Mattermost or Matrix for on-premises chat
Operational teams often need faster messaging than an intranet post allows. Mattermost compiled releases are MIT-licensed, while its source is available under AGPL-3.0 subject to listed exceptions, so license review is required. Synapse, the Matrix homeserver maintained by Element, is AGPL-3.0. Keep chat hosted inside corporate IT, decide which channels may discuss restricted system topics, and confirm retention and export capabilities for your edition before using chat as a record.
GLPI or iTop for asset context
Intranet content about a site or system is only as reliable as the asset record behind it. GLPI, licensed under GPL-3.0, provides IT asset management and ITIL service desk functions, and Combodo iTop, licensed under AGPL-3.0, offers configuration management. Use either to keep the asset inventory that informs which procedures apply to which systems, so intranet pages do not drift from the actual estate. Confirm which CMDB and integration features you need before selecting one.
Deployment pattern inside corporate IT
An intranet that carries CIP evidence and security awareness content should sit with other corporate IT services, not with OT or control systems. The cards below cover where the platform runs, how it connects to identity and recovery systems, and how vendor access is handled under the supply chain plan.
Host inside corporate IT
Run the intranet in the corporate data center or in a cloud account the utility already governs under its IT change and access processes. The intranet holds training material, policy text and awareness records, not operational data, so it belongs in the same administrative domain as email and HR systems. Confirm with your compliance team that no BES Cyber System Information is stored in the platform, because the hosting choice does not change what content is allowed on it.
Place behind the enterprise perimeter
Publish the intranet only on the corporate network and through the existing reverse proxy, web application firewall and remote access gateway. Keep it out of the public internet unless a documented need exists, and record the exposure decision. Ask your network team to confirm which segments can reach the platform and which administrative paths are restricted, since topology details depend on your own environment.
Separate it from OT networks
The intranet should have no network path into operational technology or control networks. Application servers, database servers and the intranet's administrative interfaces must not be placed in or routed through the segments that host BES Cyber Systems. Document this separation as part of your CIP-005-7 boundary review, and confirm with your OT security team that any shared service, such as directory or logging, crosses the boundary only through approved paths.
Integrate directory and recovery systems
Connect the intranet to the corporate directory for single sign-on and group-based access to spaces, so that removing an employee's access also removes intranet access. Send authentication and audit logs to the central log platform, and include the intranet in corporate backup and retention schedules. Confirm with your identity team which directory protocols and edition features your chosen platform needs, because these vary by product.
Control vendor remote access path
If a software vendor or support partner needs to reach the intranet, route that access through the same intermediate system and multi-factor controls used for other interactive remote access, and log every session. CIP-013-2 requires your supply chain risk management plan to cover coordination of vendor-initiated remote access, so record who may connect, when, and how access is approved and revoked. Review the plan at least every 15 calendar months.
Plan vendor patching and integrity checks
Your supply chain plan also covers vendor incident notification, vulnerability disclosure and software integrity verification. For the intranet, agree in writing how the vendor will notify you of security issues, how you will verify the authenticity of each release and update package before installation, and how patches move through a test environment before production. Ask any implementation partner to show how these checks are recorded as evidence.
How the rollout runs from classification to first audited cycle
The sequence moves from deciding which information belongs on the intranet to a documented evidence routine that the compliance lead accepts before the first audited quarter. Each step closes with a named artifact so the compliance, security and IT owners can check progress before the next step begins.
Review content and impact classification with compliance
Start by agreeing which information types the intranet will carry, and which BES Cyber System Information or CIP-related details must stay out. The compliance lead, the CIP program owner and the intranet owner review the in-scope facilities and their CIP-002 impact categories with the intended content list. The output is a signed content classification register that names what may be posted, what is prohibited, and who approves exceptions. The step is done when the compliance lead has signed the register.
Design spaces and the access matrix
Translate the classification into a space map: which spaces exist, who can read and post in each, and which spaces are restricted to named operational groups. Test the design with a sample of roles from operations, security and field teams, and confirm that no restricted content can be reached through search, mentions, file attachments or cross-links. The output is a signed-off space map and a tested access matrix showing each role's permissions per space. Done means every test case in the matrix passes and the owners accept it.
Integrate identity and directory access
Connect the intranet to the corporate directory and single sign-on so that group membership drives space access, and joiners and leavers are removed without manual lists. Confirm with the identity team which directory groups map to which spaces, and confirm which features each intranet edition supports for LDAP or SAML before committing to the design. The output is a documented group-to-space mapping and a test log of provisioning and deprovisioning. The step closes when a removed test account loses access to every restricted space.
Harden the platform and set up backup
Apply the hosting baseline inside corporate IT, covering the operating system, web server, database, TLS, logging and administrative access, and document each setting. Set up backups and restore tests for the database and file store, and keep the backup scope and retention aligned with the classification register. The output is a hardening record, a configuration baseline and a successful restore test report. The step is done when an independent reviewer has checked the hardening record against the baseline.
Run a pilot with one operational group
Select one operational group that already receives CIP awareness material and run the intranet with real posts for an agreed period. Track what is posted, how acknowledgments are captured, whether anyone reaches restricted content, and where moderators need guidance. The output is a pilot report listing defects, access exceptions and the changes made to the space map or templates. The step closes when the pilot owner and the compliance lead agree the pilot results are acceptable.
Agree the evidence procedure with the compliance lead
Define how the reinforcement material is evidenced: dated copies of each post, proof of distribution such as view or acknowledgment records, and the export method used to preserve them. Agree who collects the evidence, where it is stored, how long it is retained, and how the audit team will request it. The output is a documented evidence runbook that maps each quarterly item to the CIP-004 evidence type it supports. Done means the compliance lead has approved the runbook in writing.
Operate the quarterly reinforcement cycle
Run the intranet on the agreed quarterly rhythm: publish reinforcement content, capture distribution and acknowledgment records, store dated copies, and review access and moderation logs. Each quarter, the content owner and compliance lead check the evidence package against the runbook before it is filed. The recurring output is a quarterly evidence package and a short access review record. Keep the classification register and access matrix current whenever the CIP scope or staffing changes.
Evidence auditors ask for and which component produces it
This table maps each piece of evidence a CIP or NIS2 assessor may request to the intranet component that produces it and the requirement it relates to. Read it as a checklist of what to build and retain, then confirm with your Compliance Enforcement Authority or NIS2 competent authority which artifacts they expect in your context. The main takeaway is that intranet evidence is only useful if the records are dated, retained and kept outside the restricted content they describe.
| Evidence | Producing component | Requirement it supports |
|---|---|---|
| Dated copies of quarterly security awareness posts | Intranet news or announcement space with fixed publication dates and archived versions | CIP-004-7 R1 quarterly reinforcement (confirm the exact measure with your auditor) |
| Proof of distribution to targeted groups | Read or view tracking for the posts, plus audience targeting by group or site | CIP-004-7 R1 indirect communication evidence (confirm how your Regional Entity accepts view data) |
| Management support and reinforcement records | Signed-off drafts, approval workflow history and manager comments on the posts | CIP-004-7 R1 management support and reinforcement measure |
| Access review records for restricted spaces | Group membership exports from the directory, with periodic review sign-offs recorded in the intranet or ticketing tool | CIP-004-7 access management (confirm scope for your Applicable Systems) |
| Audit logs of restricted space access | Intranet audit log and forwarded logs from the web server and database, retained outside the intranet | CIP-007-6 security event monitoring and CIP-005-7 access controls (confirm which logs your scope requires) |
| Change records for the intranet platform | Change tickets, release notes and patch records from the ITSM or change system, linked to the platform version | CIP-010-4 configuration change management (confirm whether the intranet is in scope as an associated system) |
| Supply chain records for the intranet vendor and components | Vendor list, software bill of materials, signed release verification and vendor notification contacts | CIP-013-2 supply chain risk management plan (confirm with your procurement and compliance teams) |
| Information protection controls for BES Cyber System Information | Document classification labels, space permission model and a register of BCSI locations kept off broad spaces | CIP-011-3 information protection (confirm how your BCSI program defines storage locations) |
What utilities ask before they hire an implementation partner
What does a self-hosted utility intranet cost, and what drives the price?
The cost depends on the written scope, which is agreed before work starts, so no fixed figure applies to every utility. The main cost components are the implementation work (platform setup, identity integration, spaces and permissions, theming and content migration), the infrastructure inside your own environment, and any vendor subscription if you choose an edition that requires one. Scope drivers include the number of spaces, how many directory sources must integrate, and how much classification review your team needs before content goes live. Ask for a quote that separates one-time work from recurring items such as hosting, patching and support retainers, and ask which items you would pay to a vendor versus to DeployOpen.
How long does an intranet rollout take in a utility change process?
Duration depends mostly on your change process rather than on the software itself. Plan time for the requirements review, the classification review of what content may appear where, the directory and single sign-on integration, and the approvals your change board or operational technology governance requires before a production change. Each approval step adds calendar time that the implementer does not control. Ask the partner to show a milestone plan with named client dependencies, and ask which steps are fixed in the written scope and which depend on your review cycles.
What must our utility provide before an implementation partner starts?
Three roles should be named before work begins. A compliance owner decides which CIP obligations the intranet supports and approves the evidence format. A directory administrator provides accounts, groups and the integration point for identity. Content owners, such as operations, training and security awareness leads, decide what each space contains and who may read it. Your team also needs to confirm where the platform will run, who holds administrator credentials, and who approves changes to access rules. Without these owners, the partner can build the system but cannot settle the policy questions that determine whether it is compliant.
Can our internal IT team run the intranet after handover?
Often yes, but it depends on your staffing, your skills in the chosen platform and how much operational responsibility you take on. Internal teams usually handle content administration, user onboarding and routine reviews well. Patching, backup testing, upgrade planning and security monitoring need named owners and time in the schedule. Ask the partner what documentation, runbooks and training are included in the fixed scope, and whether ongoing support is offered as a retainer. Confirm your own capacity before you decide, because a platform the team cannot patch on schedule creates its own compliance risk.
Do intranet posts alone satisfy NERC CIP-004-7 security awareness evidence?
No. An intranet post is one channel that can support the requirement, not a compliance program on its own. CIP-004-7 Requirement R1 measures accept dated copies of reinforcement material and proof of distribution through direct communications, indirect communications such as posters, intranet or brochures, or management support and reinforcement. Your evidence should show what was distributed, when, to whom, and how the distribution was recorded. Confirm with your Compliance Enforcement Authority and your compliance owner which combination of channels your program relies on, and ask the implementation partner how the intranet keeps dated, retrievable copies for audit.
Can the intranet be hosted inside our corporate IT environment?
Yes, DeployOpen plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. Confirm the hosting model against your network zoning, especially if any content touches systems that fall within CIP scope. Ask the partner how the intranet is separated from operational technology networks, how it reaches your directory, and which outbound connections, such as plugin downloads or update checks, are needed. Your security team should approve those connections before deployment.
How are upgrades and security patches handled after go-live?
Upgrades and patches are an ongoing responsibility, and the process should be written into the engagement before go-live. Ask how the partner tracks new releases of the chosen platform, tests them in a non-production copy, schedules changes around your maintenance windows, and documents each change for your change records. Security advisories should have a stated response path. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so compare what is included in a retainer against what your internal team would keep. Ask for the upgrade cadence and the rollback plan in writing.
Questions to put to an implementation partner for a utility intranet
Start with CIP experience measured against your own impact classification. Ask the partner which BES Cyber System categories they have worked under, and whether they have built intranets for entities whose systems sit at high, medium or low impact under CIP-002-5.1a. A partner that answers in general terms about NERC compliance has not yet shown it understands which Applicable Systems your intranet touches. Ask them to map your intranet's hosting, identity and logging components against the CIP-005-7 and CIP-007-6 requirements that your compliance team already tracks, and to state in writing which of those requirements they consider out of their scope. Ask who on their team holds a compliance background and who will sign off the design before any production content goes live.
Next, ask how restricted spaces and search exclusion are configured and tested. Require a written description of the space permissions model, the roles that can view or edit a restricted space, and the default for new spaces. Ask the partner to show, on a staging instance, how content that could reveal BES Cyber System Information is kept out of broad search results, indexes and notifications, and how the partner confirms that exclusion still holds after an upgrade. Ask for the names of the configuration keys or admin settings involved, so your security team can review them directly. Also ask how the partner would handle an accidental upload of sensitive content, including who removes it from search indexes and backups and how that removal is recorded.
Finally, ask four questions that determine whether the intranet supports your evidence and vendor controls. First, how the partner documents the CIP-004-7 quarterly reinforcement procedure, including dated copies of posts and proof of distribution, and whether the audit trail can be exported for your compliance evidence file. Second, how vendor access to the platform is controlled and logged, and how it fits into the supply chain risk management plan under CIP-013-2. Third, which edition is needed for LDAP and SAML integration with your directory, and what the partner will confirm in writing for that edition. Fourth, how patches are tested before deployment, including who approves a release, how a staging environment mirrors production, and how a rollback is performed. Ask the partner to confirm each answer in the statement of work.
How DeployOpen scopes and supports a utility intranet
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a utility intranet, that means agreeing in writing which spaces carry security awareness evidence, which content stays off broad spaces, and where the platform is hosted before any build work starts.
How we scope
- Written scope lists the audiences, spaces and content types that the intranet must serve for operations, field and corporate staff.
- Scope records which intranet posts will be kept as dated evidence of security awareness reinforcement, and who approves them.
- Scope confirms the hosting location inside corporate IT, directory integration and the identity source for employees and contractors.
How we build
- Installation and configuration on the client's infrastructure, with spaces, roles and permissions mapped to the agreed audience model.
- Integration with the client's directory and single sign-on, tested with real operator accounts and contractor access groups.
- Security testing of the intranet and its integrations, with findings reported and tracked to closure before handover.
How we hand over
- Documentation of the configuration, access model, posting and moderation rules, and the evidence export procedure.
- Runbooks for backup, restore, upgrades and incident handling, written for the client's own operations and compliance staff.
- Training for space owners and communications staff, so the reinforcement process runs without depending on DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing after the initial engagement.
- Upgrades are planned against the platform's release cycle and tested in a staging copy before production changes.
- Ask any partner to confirm response expectations, change control and who holds the evidence records during a regulator review.
