CIP-015-1 R3 INSM data protection: requirements and evidence

What CIP-015-1 R3 INSM data protection requires

CIP-015-1 R3 requires a responsible entity to document and implement processes that protect the internal network security monitoring data it collects under R1 and retains under R2 from unauthorized deletion or modification. If your high impact or medium impact BES Cyber Systems with External Routable Connectivity fall under CIP-015-1, you need this protection in place before enforcement begins on 1 October 2028. The requirement has an exception for CIP Exceptional Circumstances, which you must define and apply through your own documented process rather than assume it covers routine gaps. The intent is practical: if an attacker can alter or erase the monitoring record, the detection and evaluation work under R1 and R2 loses its value after an intrusion. FERC Order No. 887 pointed to the need to minimize the chance that an attacker removes evidence of their tactics, techniques and procedures from compromised devices, and R3 is the control that answers that concern for the monitoring data itself.

R3 carries a Lower Violation Risk Factor, which signals that the consequence of a lapse is judged less severe than for many other CIP requirements. Do not read that as an easy requirement. Auditors test whether protections exist and work, and proving a negative, that nothing was deleted or changed, is hard without the right records. Confirm with your Regional Entity how it expects you to show both the documented process and its operation. Then map which stores hold R1 and R2 data, including collectors, retention repositories and any copies, and decide who can write, delete or change each one. Separate administrative duties for monitoring platforms from those for the systems being monitored, and make sure the monitoring platform's own audit trail is also protected. Plan for integrity checks on stored data and alerts when stored data changes unexpectedly, since those checks are the evidence an assessor will ask to see.

Which systems, data and teams R3 reaches

R3 applies to network monitoring data collected inside Electronic Security Perimeters of high impact and medium impact (with External Routable Connectivity) BES Cyber Systems. Each card below is a scope decision that changes who, where and how the protection must be built and tested.

In-scope BES Cyber Systems

Start from your CIP-002 categorization. R3 reaches the monitoring data that comes from high impact BES Cyber Systems and from medium impact BES Cyber Systems with External Routable Connectivity, inside their ESPs. Low impact systems are outside this standard, so a single control room network can split into in-scope and out-of-scope segments. Confirm the boundary in writing before you size the data stores, because a wrong boundary either leaves evidence unprotected or spreads controls to systems that do not need them.

Collectors and monitoring data stores

Map every sensor, network tap, span port, flow exporter and aggregation server that gathers traffic inside the ESP, along with the database or index where its output is written. Each component is a place where an attacker could delete or alter records, so each needs its own access control, write-once or integrity setting, and logging. Ask your monitoring vendor exactly which of these components can be reconfigured or purged by an administrator without a second approval.

Retention locations and off-premise copies

Retained data often ends up in backups, replicas, log forwarders and cloud archives that sit outside the ESP. Each copy extends the protection problem, and an off-premise copy may bring BES Cyber System Information handling questions under CIP-011-3. List every location where R2-retained data lands, record who can reach it, and confirm that deletion in one copy is reflected or tracked in the others.

Administrators who can touch logs

Platform administrators, backup operators, database owners and hypervisor administrators can often alter monitoring data even when no one intends them to. Build a list of accounts and roles with delete, truncate, rotate or restore rights over R1 and R2 data, then check how each use is logged and reviewed. Separate duties so that no single person can both perform an action and erase its trail.

Vendors and managed SOC providers

A managed detection provider or outsourced SOC that receives, stores or analyzes monitoring data becomes part of the protection design. Its personnel, tooling and retention practices affect whether deletion or modification can be prevented or detected. Confirm contractually how the provider protects the data, who can access it, how long it keeps it, and how it notifies you of any change. Review these terms alongside your CIP-013 supply chain plan.

CIP-015-2 extension to EACMS and PACS

CIP-015-2 extends internal network security monitoring to the associated EACMS and PACS. NERC lists it as effective 1 October 2029, which is later than the CIP-015-1 date. Programs designed now should not assume that the data stores, collectors and administrator lists built for BES Cyber Systems will stay the same. Track this change so that access control and retention designs can accommodate access control and physical access systems without a rebuild.

How an auditor tests R3 data protection

This table sets out how a Compliance Enforcement Authority is likely to test CIP-015-1 R3, what evidence it will ask for, and where entities tend to fall short. Read each row as a step in an audit, not as a checklist that guarantees a finding. The Compliance Enforcement Authority, not DeployOpen, decides the outcome of any audit.

Test area	What the auditor reviews	Common findings
Documented processes	The written R3 process, its scope covering R1 data and R2 retained data, its owner, and evidence that staff follow it	Process names the store but not the controls protecting it, or has not been updated after the monitoring architecture changed
Integrity sampling	A sample of retained monitoring data, with the integrity controls applied to it and records showing those controls ran	Retained data cannot be shown to be unchanged, or integrity checks exist but no records of their results are kept
Access restrictions	Who can read, write, move or delete the monitoring store, with account listings and the approval trail for each grant	Shared administrative accounts, standing privileged access, or accounts with delete rights that are not needed for operation
Change logs on the store	Audit logs of administrative actions on the store, retention of those logs, and whether they are protected from the same administrators	Logs stored only on the monitored system, gaps in logging during maintenance, or no review of logged changes
Deletion and modification detection	A test where an authorized-looking deletion or edit is made in a controlled way and the entity shows whether an alert or record was produced	Detection exists for the operating system but not the monitoring store, or alerts fire but nobody reviews them
CIP Exceptional Circumstances	Records of each time the exception was invoked, who approved it, why it applied, and when normal protection was restored	Exception used without a written record, or invoked for conditions that the documented definition does not cover
Evidence retention	Whether the entity can produce protection evidence for the audit period, including logs and configuration records	Evidence overwritten by the same retention cycle it was meant to protect, or no record of configuration before a change

How integrity and access controls protect monitoring evidence

R3 is satisfied by a layered design, and the entity chooses that design itself. The usual layers are restricted write and delete rights on the monitoring store, immutable or append-only retention where the platform supports it, integrity baselines on the stored files, separate audit logging of administrator actions, and off-host copies. No single layer is enough on its own, because an attacker with administrator rights on the collection host can often reach every local control at once. The practical question for the entity is which layer still holds if the host that writes the data is compromised.

Start by mapping who can write, modify or delete retained monitoring data, including the service accounts of the collector, the storage and the backup job. Remove delete rights from interactive and routine administrative accounts, and confirm that log rotation and retention jobs cannot remove records before the retention period set under R2. Integrity baselines work as a second check: a file integrity tool such as Wazuh can record checksums and attributes for the monitoring directories and alert on creation, modification or deletion, and a backup tool's Verify jobs, such as those in Bareos, can compare stored files against cataloged attributes. Confirm that the baseline itself is stored where the monitored host cannot rewrite it. Also confirm whether the platform offers immutable or object-lock storage, since that capability varies by product and deployment.

Administrator actions on the monitoring stack need their own trail, sent to a location the administrators cannot edit. Audit devices such as those in OpenBao log every API request and response with sensitive values hashed, and Nextcloud's admin_audit app can write to a separate audit log path set with logfile_audit. Ship these logs off the host in near real time, and test that a deleted local log still leaves the remote copy intact. Off-host copies of the monitoring data should be encrypted, stored in a separate account or security domain, and restored in a test to confirm they are usable. Ask your platform vendor and your auditor to confirm each control on the exact versions you deploy, and document the result as evidence for the R3 processes.

Implementing R3 in sequence

This sequence takes CIP-015-1 R3 from scoping to a tested and reviewed control. Each step ends with an artifact an auditor can examine, and the order matters: the process cannot protect stores that have not been inventoried, and tests cannot prove protection that was never configured.

Confirm scope against CIP-002 categorization
Start with the CIP-002 categorization of each BES Cyber System to confirm which high impact and medium impact systems with External Routable Connectivity sit inside an Electronic Security Perimeter and therefore fall under R3. The compliance lead signs off the list of in-scope systems and the monitoring data they generate. The step closes when the list matches the current categorization record and every in-scope system has a named owner. Systems that change category or connectivity must be rechecked before the list is final.
Map monitoring data stores and retention points
Document every location where R1 collection feeds network monitoring data and where R2 retention keeps it, including sensors, collectors, log stores, analytics indexes and backup copies. Engineers record each system, its storage type, its retention point and who can reach it. The output is a data flow inventory that shows where someone would have to act to erase evidence. The inventory is checked against the R2 retention records before sign-off, because any store missing from the map will be missing from the R3 process.
Write the R3 process with roles and exceptions
Write a documented process that states how collected and retained monitoring data is protected from unauthorized deletion or modification, who owns each control and how the process is reviewed. Include the handling of CIP Exceptional Circumstances, which R3 permits, covering who may invoke it, how the use is recorded and how normal protection resumes. The output is an approved, versioned procedure that names the stores from the inventory and is signed by the designated approver under your CIP governance.
Restrict access to monitoring data
Apply least privilege to the monitoring stores so that only named roles can delete or change retained data. Where your design allows, separate administrators of the monitored systems from administrators of the monitoring platform. Use individual accounts, record privileged logins and remove standing access that no current role needs. Ask each platform vendor or integrator to confirm in writing how its role model handles delete and modify permissions. The output is an access matrix checked against the actual account lists.
Configure integrity controls on stored data
Turn on mechanisms that detect changes to the monitoring data and to the configuration that governs it. Examples include file integrity monitoring that baselines checksums and attributes and flags creation, modification or deletion, and catalog-based verification of backup copies. Coverage depends on which directories and stores are configured, so confirm each tool's behavior in your own environment. The output is a documented baseline for each monitored store and a written statement of what it covers and what it does not.
Route audit and integrity alerts to responders
Send alerts from audit logs and integrity monitoring to a queue that a named person reviews, with escalation into the Cyber Security Incident process when a deletion or modification is unexplained. Confirm that the audit trail records who made each change and when. For example, an unplanned deletion in a retained store (illustrative) should open a ticket in the same workflow used for other security events. The output is an alert routing table and a sample alert traced to its ticket and closure note.
Test deletion and tamper detection
Run controlled tests under change control: delete and alter a test record in each retained store, then confirm that the integrity control raises an alert, the audit log records the actor and the alert reaches the named responder. Repeat the tests after platform upgrades or configuration changes. Record the test plan, timestamps, results and any gaps, and send each gap to the process owner's remediation list. The output is a signed test record for each store.
Set a review cadence and retain evidence
Set a recurring review of the process, access matrix, inventory and test results, and trigger an out-of-cycle review after a change to in-scope systems, a new storage location or a use of exception handling. Keep approved versions and the evidence from every earlier step so an auditor can trace the current state. Confirm with your Regional Entity or auditor which evidence format and retention period they expect, since the audit period shapes what must be kept.

Open-source tools that support R3 evidence

Nextcloud's admin_audit app records additional administrative and security events and writes them to an audit log file. For R3, this layer matters when monitoring data or the systems that hold it are managed through a web application, because an attacker who gains administrative access may try to change settings or remove traces of their actions. The log gives the security team a record of what happened inside the application, but only if the log destination is protected from the same accounts that could alter it.

Log destination: Audit events go to audit.log in the data directory by default, or to a path set with logfile_audit. Confirm which path your deployment uses.
Event coverage: Confirm which events the app captures in your version, since coverage determines what evidence exists for a given change.
Separation: Ship copies to a location that application administrators cannot write to, so a compromised admin account cannot quietly edit the record.
Retention: Set how long copies are kept and who approves deletion, and record that decision in your retention procedure.
Limits: The app logs application events only. It does not capture network traffic, operating system changes or activity outside Nextcloud.

Confirm with your own configuration and test that a deliberate change produces an entry in the expected location.

Evidence that passes an R3 review

CIP-015-1 R3 is tested by asking whether monitoring data is protected from deletion or modification for as long as it is retained. The cards below cover the artifacts an auditor typically reviews, and each one shows a different angle on the same question: can someone with access erase or alter the evidence without anyone noticing?

Documented R3 process

The written process is the first artifact an auditor reads. It should name the data stores holding R1 collections and R2 retained data, state how deletion and modification are prevented, describe how tampering is detected, and identify the roles that approve exceptions. Check that the document shows an owner, an approval record and a review date, and that it matches what the systems actually do. A process that describes controls the configuration exports do not show will fail review.

Access lists and role assignments

Export the accounts and groups that can reach each INSM data store, including administrators, service accounts and backup operators. Compare each entry against a named role and a business need, and record who approved it. Remove standing administrative rights that are not needed for the monitoring function. Keep dated snapshots of these lists so the auditor can see access during the audit period, not only today.

Configuration exports for write and delete controls

Export the settings that restrict writes and deletes on the monitoring stores, such as file permissions, object lock or immutability settings, and append-only options where the platform offers them. Confirm each setting against the documented process and note the platform version. Ask your vendor or integrator to confirm which settings are supported in your release, because the presence of a feature in documentation does not prove it is enabled in your environment.

Audit log samples

Keep samples of audit logs that record access to and changes within the monitoring data stores. A useful sample shows the event type, the actor, the time, the object affected and the result. Store logs in a location the monitored administrators cannot edit, and confirm that log retention covers the audit period. An illustrative check: pick one administrative change and confirm it appears in the log with a matching change ticket.

Integrity alert records and tickets

File integrity monitoring produces alerts when a monitored file is created, modified or deleted, including who made the change and when. Keep the alert records and the tickets showing how each one was triaged, investigated and closed. Alerts with no disposition are a common gap. Confirm that alerts on the monitoring data itself are routed to people who can act on them, and that the baseline is updated only through an approved change.

Deletion and tamper test results and exceptions

Run a controlled test that attempts to delete and alter a sample of retained monitoring data using the access levels an attacker might hold, and record whether the controls stopped or detected each attempt. Keep the test plan, results, and any exception records under CIP Exceptional Circumstances with their approvals and closure dates. Retest after platform upgrades or access changes, and record the review date on each artifact so currency is visible between audits.

What meeting R3 costs in money and effort

This table breaks down the money and effort behind protecting INSM data under CIP-015-1 R3, separating one-time setup from recurring upkeep. Use it to see who is paid for each component and which drivers move the total. No prices or durations are given, so the final column lists what to request in a written quote.

Cost component	One-time or recurring, and who is paid	What drives it	What to ask for in a quote
Tooling or licenses	Commercial licenses are recurring. Open-source platforms remove license spend but still need hosting and support decisions.	Number of monitoring points, data volume, and whether storage tiers need separate products	Itemized license terms, renewal basis, and any per-sensor or per-terabyte pricing
Engineering time to configure protections	One-time. Paid to the organization's staff or an implementation partner for setting write-once storage, access separation and integrity checks.	Number of collection points, retention locations, and how many systems already log to a central store	Written scope listing each INSM data store, the protection method per store, and acceptance tests
Evidence upkeep	Recurring. Paid in internal staff time to review integrity alerts, export logs and keep procedures current.	Frequency of integrity reviews, number of stores, and staff turnover on the CIP team	Named owner, review cadence in the procedure, and the evidence set each review produces
Access control and key management	Recurring. Internal staff time, plus any hardware or key service fees.	Number of administrators who can reach retained data, and whether keys sit on premises or with a vendor	Role list for INSM data access, key custody model, and rotation practice
External testing or review	Recurring or periodic. Paid to an independent tester or reviewer when the organization buys one.	Breadth of test scope, number of retention locations tested, and whether tests target deletion or modification paths	Test objectives tied to R3, deliverables, and whether retests are included
Auditor sampling	Set by the Compliance Enforcement Authority, not purchased. Internal effort to answer requests and show evidence.	Audit schedule, sample sizes the auditor selects, and how quickly records can be produced	Confirm the audit approach with the Regional Entity and the evidence format it accepts
Vendor involvement	Recurring if a vendor hosts or operates the INSM data store. Paid per service agreement.	Whether data leaves the organization's control, and the vendor's own change and access processes	Written statement of where data is stored, who can administer it, and how deletion is recorded
Self-hosted open source	Removes license spend. Hardware, staff time and any support contract remain.	Skills needed to configure and patch the stack, and the audit trail the chosen tools produce	Confirm each tool's license and edition limits before relying on a feature for R3 evidence

Questions buyers ask before outsourcing R3

Can we meet CIP-015-1 R3 in-house without an outside partner?

Yes, if your team has the skills to design and document the processes, and the staff to run them. R3 asks for documented processes that protect monitoring data collected under R1 and retained under R2 from unauthorized deletion or modification, with an exception during CIP Exceptional Circumstances. The organization owns those processes and must be able to show they operate. Many entities already have change control, log management and backup practices that can be extended to cover monitoring data. Confirm early whether your existing tools write monitoring data to locations that administrators can alter, because that gap usually decides how much design work remains.

What does outside help cost in effort terms for R3?

Cost is driven by the amount of design, build and documentation work, not by a fixed package. Outside help usually covers reviewing your current monitoring architecture, setting integrity controls on storage, configuring alerting on changes to retained data, and writing the procedures and evidence those controls produce. Costs recur where operations continue, such as periodic reviews and retesting after changes. Ask any provider for a written, fixed-scope quote that lists the systems in scope, the deliverables, the evidence each deliverable produces and the assumptions about your environment. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that scope. No price is given here.

What work does R3 require from our internal staff?

Your staff keep ownership of the control, so they must supply knowledge the partner cannot infer. Expect requests for network diagrams, the list of ESP assets that produce monitoring data, retention locations, existing access groups and the people who approve changes to stored data. Security operations staff will need to review and act on integrity alerts, and compliance staff will map the procedures to the evidence they retain. Plan for these people to be available during design reviews and for a walkthrough before any assessment. Confirm named owners and backups for each step, since R3 controls fail when a single administrator holds all the access.

How long does R3 implementation take for our scope?

Duration depends on scope, which means how many high and medium impact BES Cyber Systems sit inside ESPs with monitoring data, how many collection and storage platforms are involved, and how mature your current logging and backup practices are. A narrow scope with one monitoring platform is quicker than a multi-site estate with several storage tiers. The enforcement date for CIP-015-1 is 1 October 2028, and that date is the outer limit you must plan around, not a guide to how long your work will take. Ask for a timeline tied to written milestones and to the evidence each milestone produces, and check it against your own change freeze and outage windows.

Can a partner issue proof that we comply with R3?

No. A partner can prepare systems, controls and evidence, but only the independent auditor or the Compliance Enforcement Authority decides whether you comply. For NERC CIP there is no certificate. Compliance is monitored through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms, and the Regional Entity or NERC makes the findings. Your organization owns the compliance result and answers for it. When you choose a partner, ask for deliverables that let your staff demonstrate each control directly, and make sure your compliance team understands what the auditor will request and when.

How does R3 affect R2 retention of monitoring data?

R2 defines how long you keep network monitoring data tied to anomalous activity, at least until the evaluation and response action is complete, and it does not require you to keep all captured traffic. R3 then protects the data that R1 collected and R2 retained, so the protection scope follows your retention design. If you change what you retain under R2, the set of records R3 must protect also changes. Design the two together so that retained records have a defined location, a defined owner, integrity monitoring and a defined deletion process that is itself controlled and logged.

Which open-source tools can help protect monitoring data from tampering?

Tools cover parts of the R3 need, but none satisfies R3 alone. Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories and raises alerts when a user or process creates, modifies or deletes a monitored file. Bareos Verify jobs compare files against previously cataloged attributes, which helps detect changes after an intrusion. OpenBao audit devices keep a detailed JSON log of API requests and responses, with most sensitive values hashed. Confirm each tool's licensing, edition limits and integration requirements for your environment before you rely on it, and check that its logs are stored where the people being monitored cannot alter them.

Who owns R3, who prepares it, and who judges it

The registered entity owns R3 in full. The CIP Senior Manager or a delegate must answer for the documented processes that protect INSM data collected under R1 and retained under R2 from unauthorized deletion or modification, and for any decision to invoke CIP Exceptional Circumstances. Outsourcing does not move that accountability to a vendor or integrator.

Process ownership: Write and approve the R3 process, assign who can change monitoring storage and who reviews those changes.
Data ownership: Decide which INSM data sets sit inside the scope of R1 and R2 and where they are retained.
Access decisions: Approve who holds administrative rights to log stores, backup catalogs and integrity tools, and remove access when roles change.
Exception decisions: Determine whether a situation qualifies as CIP Exceptional Circumstances and document the reasoning and the return to normal operation.
Evidence custody: Keep the records an auditor will request, including configuration snapshots, integrity alerts and their dispositions.

Check that a named individual signs off on the R3 process and that the team can explain each control without referring the auditor to a partner.

Where R3 programs usually fall short

CIP-015-1 R3 requires documented processes that protect collected and retained monitoring data from unauthorized deletion or modification. The gaps below tend to appear together: the same store that holds the evidence is often the one an administrator can silently alter, copy or drop.

Unrestricted delete rights on monitoring stores

Administrators who manage the sensor, collector or storage platform often hold delete rights over the retained data by default. If one account can remove a week of flows or logs without a second person or a logged approval, the protection on paper does not hold in practice. Fix: separate the administrator role from the retention role, require two-person approval for deletion, and confirm in a test that a standard admin account cannot purge retained records.

No integrity check on stored data

Retained monitoring data is only protected from modification if you can tell when it has changed. Many teams store logs and captures without any checksum or baseline, so an edited file looks identical to an original. Fix: record hashes or a file integrity baseline when data is written, alert on any create, modify or delete event against the retention path, and periodically verify stored files against the baseline.

Copies held only on the monitored host

If the only copy of the monitoring data sits on the device an attacker has compromised, the attacker can erase the evidence along with the device. Retention designs should keep a copy that the monitored host cannot write to. Fix: replicate retained data to a separate store within the ESP or an approved location, restrict its write access, and document where each copy lives and who can reach it.

Undocumented exception handling

R3 allows an exception during CIP Exceptional Circumstances, but an exception that is not written down is hard to defend. Auditors look for who can invoke the exception, what it permits, and how it is reviewed afterward. Fix: write the exception procedure with defined triggers and approvers, log each use with a reason and time, and review those records after the event to confirm the data was restored or the change was justified.

Evidence gathered only at audit time

Teams that assemble proof of protection just before a Regional Entity engagement often find gaps in logs they never reviewed. Protection controls must be shown to work across the audit period, not only on the day of the request. Fix: collect access logs, integrity alerts and exception records on a recurring schedule, keep them under the same protections as the monitoring data, and test one sample of deletion denial each quarter so the evidence already exists when it is asked for.

Vendor-held data without contractual controls

When a managed service or vendor stores monitoring data, the organization remains responsible for protecting it, but the vendor controls the deletion path. Contracts that say nothing about retention deletion, access by vendor staff, or notice of changes leave that gap open. Fix: write deletion and access terms into the agreement, require audit logs of vendor administrative actions to be made available to you, and confirm with the vendor how they prevent unauthorized changes to your retained data.

R3 questions answered for compliance and engineering leads

R3 protects the data that R1 and R2 produce, while R2 governs how long that data is kept. R2 requires retention of monitoring data tied to anomalous activity at least until the evaluation and response action is complete, and it does not require keeping all captured traffic. R3 asks a different question: once that data exists and is held, can someone with access to the system remove or alter it? For engineering leads, this means R2 retention settings and R3 protections are separate design items. A retention rule that deletes data on schedule is not a substitute for write protection, and a tamper-resistant store does not decide what to keep. Compliance leads should map each R2 retention period to a specific R3 control, such as write-once storage, restricted delete rights, separate administrative accounts or hash-based integrity checks, and document the owner of each.

CIP-015-1 R3 applies outside CIP Exceptional Circumstances only in the sense that the requirement itself is written with an exception for those circumstances. The exception is defined in the NERC Glossary and should be read in full before you rely on it. Your documented R3 processes should state what happens when an exception is declared, who declares it, how protections are restored afterward, and how the event is recorded for the auditor. Do not assume that an emergency lifts integrity expectations for the whole period. Ask counsel and your Regional Entity contact to confirm how an auditor would expect exception use to be evidenced, and test the procedure in a tabletop exercise before you need it.

For planning, CIP-015-1 is subject to future enforcement from 1 October 2028, and NERC lists CIP-015-2, which extends monitoring to associated EACMS and PACS, as approved by FERC on 10 August 2026 with an effective date of 1 October 2029. Entities with EACMS or PACS in scope should not wait for the later date to design their data stores. Choosing storage, access roles and integrity checks once for both versions avoids rebuilding evidence trails later. Confirm the current implementation plan and the applicable effective dates with NERC before you set internal milestones, since those dates can change through the standards process.

How DeployOpen prepares R3 controls and evidence

DeployOpen works on CIP-015-1 R3 by preparing the systems, documented processes and evidence that protect internal network security monitoring data inside a client's own environment. The organization keeps ownership of its controls, and an independent auditor or Regional Entity assesses them.

How we scope

Scope is agreed in writing before work starts, listing the monitoring data stores, retention locations and systems covered by R3.
The written scope states which high and medium impact ESP monitoring data sets are protected and which exceptions and owners apply.
Ongoing support for protection controls can be arranged as a retainer after the initial fixed-scope engagement closes.

How we build

Configure write-once or restricted-access storage, audit logging and integrity monitoring for collected and retained monitoring data.
Set up file integrity baselines and alerting so unauthorized deletion or modification of monitoring data is detected and attributed.
Document the processes for protecting monitoring data, including how CIP Exceptional Circumstances are handled and recorded.

How we hand over

Deliver configuration records, runbooks and evidence mapped to R3 so the entity's compliance team can present them to an assessor.
Document test results showing that protection controls detect tampering with monitoring data in the entity's own environment.
Confirm with the entity and its compliance team which records must be retained for the audit period and where they are stored.

How we support

Review protection controls after system changes, software upgrades or changes to the monitoring architecture.
Re-run integrity and audit log checks on a schedule the entity agrees, and update evidence as the environment changes.
Ask the entity's auditor or Regional Entity which evidence formats and retention periods they expect before the engagement begins.