What CIP-006-6 R3 requires for PACS maintenance and testing
If your organization runs high impact BES Cyber Systems, or medium impact BES Cyber Systems with External Routable Connectivity, you need proof that the badge readers, door controllers, locks, request-to-exit devices and related hardware at each Physical Security Perimeter still work. Part 3.1 of CIP-006-6 Requirement R3 sets the rhythm: each Physical Access Control System (PACS) and each locally mounted device at the perimeter must be maintained and tested at least once every 24 calendar months to confirm it functions properly. The requirement is about function, not paperwork. An auditor will ask what you did to each device, when you did it, and what the result was.
The risk behind the requirement is easy to picture. A door controller that fails open leaves a secured perimeter unlocked without any alarm. A controller that fails closed can block authorized staff during an outage, which pushes people toward propped doors and workarounds. A reader whose credentials have drifted, or a forced-door sensor wired to the wrong input, will quietly stop enforcing the access decisions your physical security plan under CIP-006-6 R1 depends on. A 24-month test interval only helps if the test would catch these failures before a real intrusion does, so the test steps should be specific to each device type rather than a generic power-on check.
The hard part is evidence. Many registered entities run dozens of substations, plants or control centers, each with a different mix of hardware, and the PACS may be operated by a vendor or integrator with its own maintenance records. Confirm with your Compliance team which devices fall inside each Physical Security Perimeter, build a single inventory that links each device to its last maintenance and test date, and agree in writing with any contractor what dated records they will return. Ask your PACS vendor how the system logs device health and test events, and whether those logs can be exported with timestamps you can defend. Gaps usually appear where a device was replaced or added between cycles and no one updated the 24-month clock.
Which PACS and perimeter devices fall under R3
R3 reaches further than the control room. Whether a site, a Physical Access Control System or a reader at a door is in scope depends on how CIP-002 categorized the BES Cyber Systems behind it. The cards below walk through the decisions that change the maintenance and testing workload.
High impact BES Cyber System perimeters
R3 applies to Physical Access Control Systems and locally mounted hardware at Physical Security Perimeters protecting high impact BES Cyber Systems. These are usually the Control Center perimeters that CIP-002 rated high impact. Confirm the categorization record first, because every PACS and door device at those perimeters is in scope for the 24 calendar month cycle, including devices that look like facilities equipment, such as badge readers at a secondary entrance.
Medium impact with External Routable Connectivity
Medium impact BES Cyber Systems bring R3 into scope only where they have External Routable Connectivity. A medium impact site without that connectivity may have a perimeter that R3 does not reach, while a neighboring site with routable access does. Check each medium impact asset against the connectivity definition in the standard, and record the basis for the determination so an assessor can follow it.
The PACS as a scoped system
The Physical Access Control System itself is in scope, not only the doors it controls. That includes the badge management server, the access control panels, the software that grants or revokes credentials and the database that holds the rules. Build an inventory of every PACS component with its owner, location and last test date. An assessor will ask for the list before asking for the test records.
Locally mounted devices at each perimeter
Locally mounted hardware at a Physical Security Perimeter includes card readers, door position switches, request-to-exit sensors, controllers, alarm contacts and local power supplies that support them. Each perimeter should have a device list, so that a reader replaced during a door upgrade does not drop out of the maintenance cycle. Tie each device to its perimeter and its maintenance record.
Shared and vendor-hosted PACS ownership
When a facilities group, a landlord or a managed service provider operates the badge system, the registered entity still owns the R3 obligation for in-scope PACS. Write down who performs maintenance and testing, who holds the records and how the entity gets them. Contracts should require the provider to supply dated test evidence, and the entity should confirm that a hosted PACS can still be inspected during an audit.
Vendor-hosted cloud PACS
A cloud-hosted access platform raises a question about where the PACS sits and who can test it. Ask the provider which components run in their environment, which the entity can verify, and whether the entity can produce dated maintenance and test records on request. Confirm this with your Regional Entity and your legal team, since placement and data handling can change the evidence you must keep.
How an auditor tests PACS maintenance and testing
This table sets out the assessor's steps for CIP-006-6 R3, from confirming the device inventory to inspecting dated records. Read it as a checklist of what the entity should have ready before a Compliance Audit or Spot Check, with the common findings to prevent.
| Assessor step | What the assessor checks | Evidence to have ready |
|---|---|---|
| Confirm scope | The PACS and locally mounted devices at each Physical Security Perimeter, matched to the high and medium impact categorization from CIP-002 | Current PACS and PSP inventory tied to the BES Cyber System categorization list |
| Review the program | A documented maintenance and testing program that states what is maintained, how it is tested, and who performs the work | Written maintenance and testing program with roles, test procedures and the test cycle |
| Sample devices | A selection of PACS and local devices, checking each one for a maintenance and test record in the audit period | Asset-level listing showing each device and its last maintenance and test dates |
| Check the 24-month window | Whether each sampled device was maintained and tested at least once every 24 calendar months, with no gap beyond that window | Dated records spanning the full audit period, showing consecutive cycles per device |
| Inspect dated records | That each record names the device, the date, the work or test performed, the result, and the person responsible | Signed test reports, maintenance tickets with closure dates, and functional test outputs |
| Confirm function | That the test actually shows the device works properly, such as door controllers, badge readers and alarms reporting correctly | Test scripts, observed results and corrective actions for any failed tests |
| Common finding: missing devices | Locally mounted devices or PACS components that were left off the program or inventory | Reconciliation between the inventory and the maintenance schedule |
| Common finding: gaps and undocumented tests | Devices with no record beyond 24 months, or tests performed but not written down | Overdue alerts, exception records and retained test documentation |
Steps to build a PACS maintenance and testing program
This sequence turns CIP-006-6 R3 into a working schedule: every Physical Access Control System and locally mounted device at each Physical Security Perimeter is inventoried, given a defined test, assigned an owner, and tracked so that each one is maintained and tested within 24 calendar months.
Inventory PACS and locally mounted devices per perimeter
Start from your CIP-002 categorization and list every Physical Security Perimeter that protects high impact or medium impact (with External Routable Connectivity) BES Cyber Systems. For each perimeter, record the PACS components (badge readers, controllers, management servers, door hardware, alarm and video links) and any locally mounted hardware or devices. Confirm the list with physical security and the operations team so nothing is missed. The output is a per-perimeter asset register with a unique identifier for each device.
Define the test procedure for each device type
Group the inventory by device type, such as readers, door controllers, servers, and alarm sensors, and write a maintenance and test procedure for each group. The procedure should state what is checked (power, communications, credential reads, forced-door and held-door alarms, time sync, and logging), the expected result, and the steps to record a failure. Ask the vendor for its recommended checks and confirm them against your own configuration. The output is an approved procedure for each device type.
Assign a named owner to each device group
Assign one accountable owner for each device group and each perimeter, along with a backup. The owner is responsible for scheduling the work, performing or witnessing it, and filing the record. If an internal team, an integrator, or a managed service performs the test, document that party's role in writing, but the registered entity keeps the obligation. The output is a responsibility matrix that an auditor can read without interviews.
Schedule every device inside the 24-month window
Set a first test date for each device and a recurring date no more than 24 calendar months after the last completed test. Spread the work across the cycle so that teams can complete it without disrupting operations, and use the same cycle for devices that share a perimeter where practical. Document the rule used to set the interval so an assessor can see that the calculation is based on the last completed test date, not the calendar year. The output is a schedule that shows every device with a due date.
Run tests and record dated results
Perform each test using the approved procedure and record the date, the tester, the device identifier, the results of each check, any defects found, and any corrective action with its closure date. Retain screenshots, controller logs, or signed test sheets as supporting evidence. If a device fails, open a corrective action and retest before closing the item. The output is a dated record for each device showing that it was maintained and tested within the period.
Track due dates and escalate overdue items
Move the schedule into a tracking system that issues reminders before each due date and flags overdue devices to the owner and the compliance lead. Review the tracker at a fixed interval so that a missed test is caught well before it becomes a violation. Keep the change history of the tracker so you can show when schedules were revised. The output is a current status view of every device that can be exported for an audit request.
Review the program and update it for changes
Revisit the inventory and procedures whenever a PACS component is added, replaced, or retired, and whenever a perimeter is changed or a CIP-002 categorization is revised. Confirm that the new device receives a test date and an owner before it goes into service. Record each review with its date and approver. The output is an updated inventory and a change log that keeps the program accurate between cycles.
Tracking the 24 calendar month cycle without gaps
The 24 calendar month interval is measured from the last completed test, so the schedule has to be built per device, not per site or per vendor visit. Keep one record for each Physical Access Control System component and each locally mounted device at a Physical Security Perimeter: card readers, door controllers, locks, alarm sensors, cameras and the badge server or management software they depend on. For each record, store the asset identifier, its location and PSP, the test method, the date the test was completed, the tester, the result and the next due date, calculated as 24 calendar months from that completion date. Review the list at least quarterly so that a device approaching its due date is scheduled with margin rather than discovered after the fact. Confirm with your Compliance Enforcement Authority or internal compliance lead how they expect the due date to be recorded and whether they want the test date, the completion date or both.
Mid-cycle changes are where gaps usually appear. When a device is added or replaced, start its own clock on the date it is placed into service and tested for proper function, and record the replacement as a change to the PACS inventory so the old device is closed out, not left in the list. A replacement does not inherit the predecessor's due date. If a device is moved between doors or PSPs, update its location field and confirm the test still covers its new function. Document the reason for each change, such as a vendor end-of-life replacement or a failed component, because an auditor will compare the inventory against the maintenance records and the change tickets.
When a test fails, the device is out of service until repaired and retested, and the repair must be recorded as its own dated event. Keep the failed test record, the repair ticket, the post-repair test result and any compensating measures used while the door or alarm was degraded, such as added guard coverage or an escort procedure. The new completed test date then resets the 24 month clock. Plan for a failure by identifying spare parts and vendor support windows before the due date arrives. Illustrative example: a reader fails its functional test in month 19, is replaced in month 20 and passes in month 20. The next due date is 24 calendar months after that passing test, not after the original test.
Evidence that satisfies R3 and how to keep it current
An auditor testing CIP-006-6 R3 looks for a documented program, a complete inventory and dated records that tie each device to a maintenance and test event. The cards below cover the artifacts that pass and the routines that keep them complete between audits.
Written maintenance and testing program
The program is the document that defines how each Physical Access Control System and locally mounted device is maintained and tested, who performs the work, what each test confirms and how the 24 calendar month interval is tracked. Auditors read it first, so it should name the test steps for each device type, not a generic statement that testing occurs. Check that the program matches what staff actually do, because a program that differs from practice invites findings even when the records are good.
Current PACS and device inventory
The inventory lists every Physical Access Control System and locally mounted hardware or device at each Physical Security Perimeter, with location, asset identifier, owner and the date of its last maintenance and test. Without a complete inventory, an entity cannot show that no device was missed, so reconcile it against physical walkdowns and access control configuration at least once a year. Confirm that devices added during construction or replacement appear in the inventory before they go live.
Dated maintenance and test records
Each device needs its own record showing what was done, when, by whom and the result, so an auditor can confirm every device fell within 24 calendar months. Batch sign-offs for a whole site are weaker evidence than per-device entries. Store records in a system that preserves timestamps and author identity, and avoid edits to closed entries; corrections should be appended as new entries.
Test results showing function
A maintenance entry alone does not show the device works. Test results should record the function exercised, such as door strike actuation, badge read, alarm transmission, and log generation, along with the expected and observed outcome. Failed tests need a documented disposition. Capture screenshots or system exports where they strengthen the record, and keep them with the matching device entry.
Corrective action records
When a test or maintenance check finds a fault, the record should show the defect, the interim control used while the device was out of service, the repair, the retest and the closure date. Auditors look for the gap between discovery and repair, so the timeline must be visible. Link each corrective action to the device record it concerns, not only to a general ticket queue.
Change records for replaced devices
When a reader, controller, lock or camera is replaced, the change record should show the removal, the new device's inventory entry, its initial test and the date it went into service. This prevents a replacement from silently resetting or breaking the 24 month clock. Confirm with the device vendor whether firmware or configuration changes require a retest in your own environment.
What meeting R3 costs in money and effort
This table breaks down the cost and effort components of meeting CIP-006-6 R3 for PACS and locally mounted devices at each Physical Security Perimeter. Read each row for who is paid, whether the cost is one-time or recurring, and what drives it up or down. No dollar figures are given because none were researched for this requirement, so use the quote questions in the final column to compare offers.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it and what to ask for in a quote |
|---|---|---|---|
| PACS maintenance contracts or internal technician time | Vendor field service, or your own facilities and security technicians | Recurring, every maintenance cycle | Device count and site count. Ask whether the quote covers locally mounted devices at each perimeter, not only the central server. |
| Test equipment and test credentials | Your team or the integrator, for badge readers, door sensors, alarms and test cards | One-time purchase, plus periodic replacement | Number of door types and reader models. Ask which test tools the vendor requires and whether they are included. |
| Engineering time to build the program and asset inventory | Internal compliance and OT staff, or an implementation partner under a fixed-scope agreement | One-time, with periodic updates | Number of Physical Security Perimeters and how many PACS components exist per site. A current inventory shortens this work. |
| Maintenance and testing procedure and evidence upkeep | Internal compliance staff, who keep dated records for every PACS and device | Recurring, tied to each test cycle | Record format and tooling. Records kept in a ticketing or wiki system with clear dates reduce rework during an audit. |
| Ticketing and documentation tooling | Your team, or a hosting provider if you run the platform for them | Recurring for hosting and support, one-time for setup | Open-source tools such as GLPI, Zammad, XWiki or BookStack carry no license fee, but hosting, patching and staff time still apply. Confirm current license terms with each project. |
| External review or test support | Independent consultant or integrator, if you buy it | Optional, usually per engagement | Scope of the review and number of sites. Ask for a written scope and deliverables before work starts. |
| Auditor sampling effort | Your staff during the Regional Entity audit or Spot Check | Recurring, each audit cycle | Number of sampled devices and how quickly records can be produced. Well-indexed evidence cuts time spent in the audit. |
Which open-source tools support R3 evidence
GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets teams create, follow and process tickets, problems and changes using ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For R3, this matters because each PACS maintenance or test task can be a ticket that records who performed it, what was checked and when it was closed. Recurrent tickets can be set up so the work is reissued on a fixed cycle, which helps the team stay inside the 24 calendar month interval in Part 3.1 without relying on memory.
- Recurrent tickets: Create a template for each PACS component and each locally mounted device, and set the recurrence to match your internal interval, which should be shorter than the 24 calendar months the standard allows.
- Closed-ticket records: Keep the completed ticket, its attachments (such as test results or vendor reports) and the closing technician as the dated record of the work.
- Planning views: Use the planning and statistics features to show overdue items before the cycle expires.
- Change linkage: Link a ticket to a change record when a firmware update or reader replacement alters the device.
Before relying on this, confirm with your team that the ticket templates capture the device identifier, the test performed and the pass or fail result, because GLPI will store whatever fields you define.
Zammad is licensed under AGPL-3.0-only. It is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. In an R3 program, its main value is keeping correspondence with access control vendors, integrators and internal facilities staff attached to the device record. A fault report sent by email, a vendor's remote diagnosis and a field technician's callback can all sit in one thread, so an auditor asking why a reader was out of service can see the full sequence in one place.
- Single thread per device: Route device issues and vendor replies into the same ticket so the maintenance history is not split across mailboxes.
- Vendor correspondence: Store support case numbers, firmware advisories and service reports in the ticket for later review.
- Escalation trail: Record when an issue was raised, who acknowledged it and when it was resolved.
- Access to the ticket system: Restrict agent accounts so that only authorized staff can view or change physical security tickets.
Confirm with your vendors whether they accept email routing into your helpdesk and whether any of their communication contains details your CIP program must protect, since those messages may need to be handled under your information protection controls.
XWiki is licensed under LGPL-2.1-or-later. Every change to a page is kept under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For R3, this gives the maintenance and testing program, its procedures and its test checklists a traceable history. An assessor who asks which version of the procedure was in force during a given test cycle can be shown the exact revision that applied on that date.
- Dated revisions: Each edit to the maintenance program is stored with its author and timestamp.
- Version comparison: Show what changed between two review cycles, such as a new test step added after a vendor update.
- Rollback control: Restore an earlier version only through a documented approval, and record that action.
- Procedure references: Link each procedure page to the ticket templates in GLPI so the program and the records point to each other.
Version history shows what was edited and when. It does not prove that the procedure was followed, so pair it with dated test records.
BookStack is licensed under MIT. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. For R3, this lets you separate who can change the maintenance program from who can read it. Field technicians may need to view the test procedure, while only the designated program owner should be able to alter the interval, the scope or the acceptance criteria. Restricting edit rights protects the program from unreviewed changes that would weaken the evidence trail.
- Role-based editing: Grant edit rights to the program owner and reviewers, and read-only access to technicians.
- Page-level overrides: Lock the page that defines the test interval so that a book-level permission cannot accidentally open it.
- Account review: Remove access for staff who leave or change roles, and document the review.
- Permission records: Export or screenshot role assignments at review time as supporting evidence.
Before relying on these controls, test them in your own instance with a non-production account, because the effective permissions depend on how roles, shelves and books are configured in your environment.
Where R3 programs usually fall short
CIP-006-6 R3 looks simple on paper: maintain and test each Physical Access Control System and locally mounted device at the Physical Security Perimeter at least once every 24 calendar months. Most gaps appear in the records, not the testing itself, because devices are missed from inventory, tests are done but not dated, and replacements quietly restart or lose the cycle.
Locally mounted devices left off the inventory
Door controllers, card readers, request-to-exit sensors, and alarm contacts mounted on the perimeter are easy to omit when the PACS list is built from the central server alone. R3 reaches locally mounted hardware and devices at the Physical Security Perimeter, so a device missing from the inventory is a device that never enters the 24-month cycle. Reconcile the list against physical walkdowns of every perimeter door and gate, and record the asset owner and location for each device. Close it by building one inventory that lists every PACS component and every local device, then checking it against site drawings and door schedules.
Tests performed but not dated
Technicians often test a reader or controller and record only a pass in a shared checklist, a ticket that was later closed, or a photo of the device. An auditor needs dated records that tie each specific device to a maintenance and testing event within the window. A test with no date, no device identifier, or no tester name is hard to defend even when it happened. Close it by requiring every test record to carry the device identifier, the date, the test performed, the result, and the person who ran it.
Cycles drifting after device replacement
When a reader, lock, or controller is swapped during a repair or upgrade, the new device often inherits no history in the maintenance system. The 24-month clock then runs from an old date, or resets silently without a record. Confirm for each replacement whether the new unit was tested at installation and when its next test falls due. Close it by adding a replacement step to change management that opens a new maintenance record and sets its due date from the installation test.
Vendor reports that omit the device
Integrators and service providers frequently deliver a summary report stating that the access control system was serviced. Such a report may not name each controller, reader, or local device, so it cannot show that a particular device at a particular door was tested. Ask vendors to list each device serviced by serial number or asset tag, the test method, and the date. Treat a general service statement as a starting point, not as R3 evidence. Close it by writing device-level reporting into vendor contracts and rejecting summaries that do not name the devices.
Maintenance and testing program not documented
Some teams test devices on a routine basis but have no written program describing what maintenance covers, how testing is done, and how the 24-month interval is tracked. Without that document, the records look like ad hoc activity rather than a controlled process. A short program that names the scope, the test steps, the responsible roles, and the tracking method gives the evidence a consistent frame. Close it by writing a maintenance and testing program that maps each device class to its test procedure and due-date rule.
Questions buyers ask about R3 maintenance and testing
How much does CIP-006-6 R3 maintenance and testing cost?
No public price applies to this work, and DeployOpen does not publish a price list. Cost follows from the written scope: how many Physical Security Perimeters are in scope, how many PACS components and locally mounted devices each one has, whether the systems are on-premises or vendor hosted, and how much testing your staff perform versus contractors. Costs fall into one-time items (inventory, the maintenance and testing program, test procedures, evidence templates) and recurring items (the scheduled testing itself, replacement parts, vendor visits and records upkeep). Ask any provider for a quote that separates the one-time build from each 24 calendar month cycle, lists every device in scope, and states who performs each test and who keeps the records.
How long does it take to build the first R3 inventory and program?
The duration depends on scope, and no fixed timeline fits every site. The main drivers are the number of Physical Security Perimeters, the number of PACS components and locally mounted devices at each one, whether device records already exist, and how many vendors must supply documentation or test tools. As an illustrative example, a single control center with one set of door controllers and a few badge readers needs far less discovery than several substations with mixed hardware and no asset list. The first pass usually covers the device inventory, the maintenance and testing procedure, and a sample of dated test records. Ask a provider to agree the inventory deliverable and the schedule in writing before work starts.
What does the R3 work need from our team?
Most of the effort falls to people who know the physical environment. You need someone who can grant access to every Physical Security Perimeter, a facilities or security lead who knows the badge, alarm and access panel vendors, and a CIP compliance owner who approves the procedure and reviews the records. Engineers who understand controllers, the network path to the PACS server and how each device fails must confirm what a valid test looks like. Vendor support agreements matter because some tests need manufacturer tools or firmware files. Records should be signed and dated by the person who performed the test. An implementation partner can draft procedures and evidence templates, but your organization owns the controls and the staff who carry them out.
Can we run CIP-006-6 R3 testing in-house?
Yes. Many registered entities perform this work with their own staff, and the standard does not require an outside firm. In-house testing works best when the team has the skills to test each device type, has time inside the 24 calendar month window, and keeps dated records showing that each PACS and locally mounted device was maintained and tested. Outside help often covers specific pieces: a gap review of the existing program, procedure drafting, evidence design, or a pre-audit check. Compare the cost of staff time, vendor visits and any tooling against the size of your estate. Whichever path you choose, confirm that the written program names an owner for each device and that records are retained as your Compliance Enforcement Authority expects.
What does a 24 calendar month cycle mean for scheduling?
It means each PACS and locally mounted device must be maintained and tested at least once in every 24 calendar month period. The clock runs per device, so locations that were installed or serviced on different dates need separate tracking. Build a schedule that gives each device a last-tested date and a due date, then group visits by site to limit disruption. Plan a buffer ahead of each due date for failed tests, parts lead times and vendor availability. Recurring tickets in a helpdesk or ITSM tool can carry these due dates, and the GLPI Assistance module documents recurring ticket handling. Confirm with your Regional Entity how it reads the period for devices added or replaced mid-cycle.
Can a partner replace the auditor for CIP-006 R3?
No. A partner can prepare systems, procedures and evidence, but it cannot issue audit findings or stand in for the body that monitors compliance. NERC and the Regional Entities monitor CIP compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other tools, and no CIP certificate exists. Under the NERC Rules of Procedure, entities registered as Balancing Authorities, Reliability Coordinators or Transmission Operators receive a Compliance Audit at least once every three years, while other registered entities are audited on a risk-based schedule set by the Regional Entity. Use the partner to get the evidence ready, then let the Compliance Enforcement Authority judge it.
What does DeployOpen deliver for R3 maintenance and testing?
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can help set up the operational records that R3 depends on, such as ticketing for the test schedule and a version-controlled wiki for procedures. Engagements are usually fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support is available as a retainer. DeployOpen does not perform the controls on your behalf, does not issue audit reports, and does not certify compliance. Confirm with DeployOpen exactly which platforms, records and procedures sit inside a proposed scope before you sign.
How DeployOpen prepares R3 evidence
DeployOpen starts R3 work by agreeing a written scope that lists every Physical Access Control System and every locally mounted hardware or device at each Physical Security Perimeter that the entity has classified under CIP-002. The inventory records each device's name, location, the BES Cyber System it protects, the perimeter it sits on, its manufacturer and firmware version, and the person accountable for it. Because the 24 calendar month interval in Part 3.1 runs from the last maintenance and testing date for each device, the inventory also needs a last-tested date and a due date per device. The entity owns the classification decisions. DeployOpen confirms with the entity which devices fall inside the Applicable Systems scope and documents the reasons for any exclusion, so an auditor can trace the scope back to the impact rating.
Once the inventory is agreed, DeployOpen configures self-hosted open-source tools so the records are kept in one place. GLPI's Assistance module can carry each device's maintenance and test as a recurring ticket with a planned due date, a responsible owner and a closure record. XWiki can hold the maintenance and testing program as a controlled document, and its version history shows what changed, when and by whom. BookStack can hold the test procedures and role assignments, with permissions set per role so that only authorized staff can edit them. Each tool's license and edition limits should be confirmed with the vendor before the design is fixed. DeployOpen configures these systems inside the entity's own infrastructure, and the entity decides who receives access.
DeployOpen prepares the evidence package so the entity's own auditor can test it, but it does not issue audit reports, attestations or certifications. The package typically contains the maintenance and testing program, the device inventory with due dates, dated test records for each device, and the ticket history that links each record to its owner. Gaps are flagged before the auditor arrives, such as a device with no closed test or a test record that lacks a date. Most engagements are fixed-scope, and DeployOpen prepares a quote after the written scope is agreed. Ask the proposal to state the device count, the tools to be configured, the evidence items to be produced, and what the entity must provide, including staff time for the testing itself.
