A PRC-005 Evidence Checklist for Protection Maintenance Records

Most protection maintenance programs are better than their records. Devices get tested, technicians know what they did, and the equipment works. Then an audit asks for the evidence for a specific relay on a specific date, and forty minutes of searching produces a scanned PDF with no asset identifier on it.

This article is a checklist for that problem. It assumes you already know how to test a relay and focuses entirely on whether you can prove it afterwards.

Key takeaways

• PRC-005 applies to registered entities, not to products. No software, test set or service is “PRC-005 certified”, and no vendor can make an entity compliant.
• The recurring audit difficulty is evidence that is missing, incomplete or unretrievable — not equipment that was never maintained.
• A defensible record ties an identified component to a date, a method, an as-found and as-left condition, measured results against acceptance criteria, and an approval.
• Retrievability is a design property of your record system, not an afterthought. If you cannot produce the chain for an arbitrary component within minutes, you do not have it.
• Rehearse the audit: pick ten components at random and try to produce the complete evidence chain for each.
• GridAPM ProtectionAI ships both the record chain (per-asset test records, settings versions, attachments) and the tracking layer on top of it (per-asset programmes, editable NERC interval defaults, Compliant/Due Soon/Overdue status, a KPI dashboard, exportable evidence packages with a manifest). Multi-user approval routing is on the roadmap, not shipping — and no tool of any kind can hold a PRC-005 certification, because none exists.

What PRC-005 is, and what it is not

PRC-005 is the NERC reliability standard covering Protection System maintenance for the North American bulk electric system. Later versions extend the same treatment to Automatic Reclosing and Sudden Pressure Relaying. It requires an applicable entity to establish a Protection System Maintenance Program, apply defined maintenance activities at defined maximum intervals to the components in scope, and retain evidence of having done so. The standard text and its compliance section are on NERC’s PRC standards list; versions supersede one another, so confirm which one is currently enforced before you write a procedure around it.

What PRC-005 is not is a product qualification. It is worth being blunt about this because the market is not:

• No relay, test set, or software application can be PRC-005 certified. There is no such certification.
• No vendor can make you compliant. Compliance is a property of your program and your records.
• A tool can make the evidence easier to create, find and produce. That is the entire scope of what a tool can honestly claim.

If you see a product described as PRC-005 compliant or PRC-005 certified, read it as a claim about the vendor’s marketing department rather than about the standard.

The five things you actually have to satisfy

Stripped to its structure, the standard asks an entity to:

1. Identify the components in scope, by type.
2. Document a Protection System Maintenance Program stating the maintenance method and the maximum interval for each component type.
3. Specify the basis for those methods and intervals, including the extra documentation burden that comes with condition-based or performance-based approaches.
4. Perform the activities within the intervals.
5. Retain evidence that steps 1 to 4 happened.

Step 5 is where programs come apart. NERC’s own Supplementary Reference and FAQ is a useful companion for interpreting the activity and interval expectations — it is explicitly non-binding guidance, but it answers a lot of practical questions about what an activity is meant to demonstrate.

The checklist

Scope and inventory

• A component list exists, is current, and is the single authoritative one. Not three lists in three departments.
• Every component is classified by the type the standard recognises, and the classification rationale is written down somewhere a reviewer can read it.
• Components with unusual classifications — devices that could arguably fall in or out of scope — carry an explicit, dated justification.
• Additions are captured when equipment is commissioned, not at the next inventory sweep. There is a defined trigger from the commissioning process into the component list.
• Retirements and replacements are captured, with the date, so a decommissioned device does not sit forever as an overdue item and a replacement does not inherit its predecessor’s history by accident.
• Traceability runs both ways between the one-line diagram, the relay panel labelling, the asset identifier used in records, and the identifier used by the test tool. If those four names differ, document the mapping.

Program documentation

• The PSMP is a document, is versioned, and has a revision history with dates.
• It states, per component type, the maintenance activity and the maximum interval.
• It states the basis for each interval and method — manufacturer guidance, internal engineering judgement, industry practice, or performance data. “Because that is what we have always done” is not a basis.
• It identifies who approved the program and when, at a level of authority your organisation recognises.
• Procedures referenced by the PSMP exist, are findable, and match what technicians actually do in the field. A procedure nobody follows is worse than none.
• Superseded revisions are retained, because a record from four years ago has to be judged against the program that was in force then.

Intervals and due dates

• The interval for each component type is stated in the same units the standard uses, with no ambiguity about calendar months versus years.
• The date basis is defined: is the clock set by the date the work was performed, the date it was approved, or the end of the calendar year in which it fell? Pick one, write it down, apply it consistently.
• The due-date calculation is reproducible by someone who is not the person who built the spreadsheet.
• Overdue items have a defined escalation path with named ownership and a record of the escalation.
• Extensions, deferrals and grace situations are documented with the reason and the approval — not applied silently by editing a date.
• The documentation burden differs by approach, and the program says which approach applies where:

Approach	Additional documentation burden
Time-based	The interval, its basis, and the activity performed
Condition-based	The monitoring in place, what it verifies, and evidence that the monitoring itself is working
Performance-based	A defined population or segment, the countable-event data, and the analysis justifying the interval

Per-activity evidence

A defensible record for one activity on one component contains:

• The component identity and physical location, using the authoritative identifier.
• The date the activity was performed.
• Who performed it — an identifiable person, not just a company name.
• The method used, and the test set or instrument identity where relevant.
• The as-found settings the device was actually carrying when work started.
• The measured results, as values, against the stated acceptance criteria. “Pass” alone is a weak record; “pass” next to measured values against a tolerance is a strong one.
• The as-left settings, and confirmation they match the approved setting record.
• Any deficiency found, described specifically.
• The corrective action taken, and evidence of its closure.
• The review or approval, with the reviewer’s identity and date.

The as-found and as-left pair deserves emphasis. It is the only part of the record that demonstrates the device was in the intended state both before and after the work, and it is the part most often reduced to a checkbox.

Countable events and performance-based programs

• If any interval is justified by performance data, the population or segment definition is written down and the components in it are individually identifiable.
• The countable-event data is retained, not just the resulting statistic.
• The analysis that converts the data into a justified interval is a document a reviewer can follow.
• Segment membership changes over time are tracked, so the population you analysed matches the population you claimed.

Unresolved maintenance issues

• Every deficiency found during maintenance opens a tracked item with an owner.
• Items are tracked to demonstrable closure, and the closure evidence is attached to the same component record as the original finding.
• Open items have visibility at a level where they get resourced, not just logged.
• The link between the finding, the corrective work order and the retest result is navigable in both directions.

Retrievability

• The retention period is defined in your program, consistent with the compliance section of the enforced standard version, and is actually implemented in the storage system.
• Records live somewhere with a defined owner, defined backup, and defined access.
• You can produce the full chain for an arbitrary component on request, not just for the components you prepared.
• Records created by a technician or contractor who has since left are still findable. If they lived in a personal folder or a departed employee’s mailbox, they are effectively gone.
• Records held in a vendor tool’s proprietary database can be exported in a form that survives the tool. Ask this question before the tool is retired, not after.
• Attachments are tied to a component identifier inside the record system, so a file’s usefulness does not depend on its filename.

Audit readiness

• Rehearse. Pick ten components at random from the inventory — genuinely at random, not ten you chose — and try to produce the complete evidence chain for each within a defined time.
• Record how long it took and what was missing. That result is your real compliance posture.
• Repeat with a different sample after remediation.
• Include at least one component maintained by a contractor and one whose responsible technician has left the organisation.

Common gaps, described concretely

• The record shows the old settings. A setting change was implemented but the maintenance record still carries the previous values, so the as-left state cannot be reconciled with the approved setting record.
• A spreadsheet of dates with nothing behind it. The interval tracker says a device was tested in March. There is no test record. The tracker is an assertion, not evidence.
• Scanned PDFs with no asset identifier. A stack of test sheets that can only be attributed to a device by reading handwriting, or not at all.
• Data trapped in a proprietary database. Complete, detailed test results that exist only inside a tool nobody can export from — often because the export path was never tested and the person who knew it has moved on.
• Hand-maintained interval clocks. Due dates calculated manually, with the calculation living in one person’s head and the escalation depending on that person remembering.
• Contractor work with no handover. The work was done to a high standard and the records never crossed the organisational boundary.

Where software helps, and where it stops

The genuinely useful contribution a system can make is a retrievable chain: an asset record that knows its own identity, a versioned settings history so as-found and as-left mean something, attached documents that stay attached, and test records bound to the asset rather than to a folder. That much removes most of the failure modes in the list above, because it removes the manual steps where the link between a component and its evidence gets lost.

A separate and distinct capability set is compliance automation: interval clocks per component type, due-date dashboards, overdue escalation, and generated evidence packages assembled for a named component or sample. These are not the same feature as a good record store, and it is worth being precise about which one a vendor is offering you.

Here is where GridAPM ProtectionAI stands, without softening.

Shipping today, the record layer: an asset and settings database that keeps relay records with lifecycle states, full version history on settings, document attachments, and test records held per asset. That is the foundation of a retrievable evidence chain — the part that makes “produce everything you have for this relay” a query rather than a search.

Shipping today, the tracking layer: per-asset maintenance programmes, NERC interval defaults that you can edit per component type and per monitoring level, a Compliant, Due Soon or Overdue status against each asset’s programme, a KPI dashboard across the population, and exportable evidence packages that carry a manifest.

On the roadmap, not shipping: multi-user approval routing. Sending a completed maintenance record through a named reviewer and a named approver before it counts as closed is planned capability, not current capability. If your program’s controls depend on a segregated review step being enforced by the tool rather than by your own process, that gap is the one to ask about.

And to restate the point this article opened with: nothing here makes any tool or any entity compliant. Compliance belongs to the entity and is established by its own documented program and its own retained evidence. A tool can reduce the effort and remove some of the ways records get lost. It cannot hold a certification that does not exist.

See the ProtectionAI capabilities page for what the asset and settings database does today, and the standards page for the standards coverage and its stated limits. For the testing side of the same workflow, see relay testing software.