CIP-006-6 R2 Visitor control program: requirements and evidence

What CIP-006-6 R2 asks for when a visitor enters a Physical Security Perimeter

When a vendor technician, auditor or contractor needs to enter a control center or substation building that houses BES Cyber Systems, CIP-006-6 R2 requires two things: the visitor must be continuously escorted for the whole time they are inside the Physical Security Perimeter, and every entry and exit must be logged with the visitor's name and a named point of contact responsible for them. Part 2.1 covers the escort, which applies to anyone given access without authorization for unescorted physical access and continues except during CIP Exceptional Circumstances. Part 2.2 covers the log, which may be kept manually or automatically and must record the date and time of the initial entry and last exit, the visitor's name and the responsible individual. Part 2.3 sets retention at no less than ninety calendar days. The requirement reaches high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity, along with their associated EACMS and PCA. Confirm the applicable systems for each site against your CIP-002 categorization before writing the procedure, since low impact assets follow a different set of controls.

The risk is simple: an unvetted person standing next to a console, network cabinet or substation relay can cause damage without ever touching a logged account. The escort and log requirements exist so that a person near these systems is always accompanied by someone accountable for them, and so that an assessor can later reconstruct who was inside and when. In practice, three things make compliance harder than the wording suggests. Escorts get pulled to other work, and a visitor left alone for a few minutes can be a violation. Visitor records end up split across a paper sign-in sheet, a badge system, a ticket and a shift handover note, so the entry and exit times do not match. Exceptions, such as an emergency repair during which the normal escort was impossible, are handled verbally and never written down, which makes it hard to show that the exception was a CIP Exceptional Circumstance.

A practical starting point is a single visitor log per Physical Security Perimeter, with one entry per visit, a rule that escorts must sign in and out with the visitor, and a periodic check that the log matches badge and camera records for the same period. Ask your compliance team which of your sites are in scope and whether your Physical Access Control System already records visitor badges. Logs that are kept electronically can be protected with access controls and retained for the full ninety days, and open-source document and audit tools can store the record and the change history. Those tools do not decide compliance: your organization owns the procedure, and the Regional Entity assesses it. Use the NERC CIP-006-6 standard to confirm the exact wording of each part before you draft internal procedures.

Which systems, sites and people fall under the visitor control program

CIP-006-6 R2 applies only to specific BES Cyber Systems and their associated support systems, so the first decision is which assets and Physical Security Perimeters the program covers. The cards below walk through that scope, who counts as a visitor, and where a documented exception may apply.

High impact BES Cyber Systems

R2 applies to high impact BES Cyber Systems and their associated EACMS and PCA. Categorization under CIP-002-5.1a decides which assets are high impact, mainly Control Centers of Reliability Coordinators and qualifying Balancing Authority, Transmission Operator and Generator Operator Control Centers. Confirm the categorization list is current and that every Physical Security Perimeter housing these systems is mapped to the visitor procedure.

Medium impact with External Routable Connectivity

Medium impact BES Cyber Systems are in scope only when they have External Routable Connectivity, along with their associated EACMS and PCA. A medium impact site without that connectivity may fall outside R2, which makes the connectivity assessment a document worth keeping. Review it whenever network paths change, since a new routable link can move a site into scope.

Associated support systems

EACMS and PCA associated with in-scope systems must be covered by the visitor program even when they sit in a different room or building from the main system. Identify each associated asset and its perimeter during scoping, because a support system left out of the visitor process is a common gap found in reviews. Record the mapping so an assessor can trace each asset to its controls.

Who counts as a visitor

A visitor is an individual given access to a Physical Security Perimeter who is not authorized for unescorted physical access. Staff with unescorted authorization under the access program are not visitors, so the access list must be accurate before visits begin. Contractors and vendor technicians without unescorted authorization are visitors and need continuous escort, while badge holders with unescorted access are not.

Contractors, vendors and staff without badges

Anyone entering without an unescorted badge, including staff who forgot a badge, is handled as a visitor and must be escorted and logged. Define how escorts are assigned, what they must do, and how a vendor's own staff are identified before entry. Ask your vendors and integrators how their people will be signed in and escorted, since their practices affect your evidence.

CIP Exceptional Circumstances

CIP Exceptional Circumstances are a separate, documented case in which the continuous escort requirement may be set aside, such as an emergency that threatens safety or life. The entity must define the circumstance in its process and record each use so the exception can be reviewed. Treat it as an exception with its own evidence, not as a routine way to skip escorts.

How an auditor tests escort and visitor log evidence

The Compliance Enforcement Authority, which is a Regional Entity or NERC, reviews CIP-006-6 R2 through a Compliance Audit, a Spot Check or a Self-Certification. In practice the reviewer tests whether the visitor control program works day to day, not just whether a procedure exists. The most common approach is sampling visitor log entries and tracing each sampled entry back to other records. The reviewer picks visits from the log, then checks that the entry and exit times, the visitor's name and the named point of contact agree with badge or access control data, door events and camera or guard records where the entity keeps them, and with the escort's written or signed statement if one was requested. A visit that appears in the log but not in the access data, or an escorted visitor whose escort is not identified, is the type of gap a reviewer will follow up on.

A sample is usually drawn from the whole audit period and spread across different sites, shifts and Physical Security Perimeters, so the reviewer can see whether the program is consistent. Sampling may also target visits that look unusual, such as long visits, visits outside normal hours or visits by people who appear to have been left unescorted. The reviewer will want to see that the log was retained for at least ninety calendar days and that the retained records are complete and unaltered. Entities should confirm with their Regional Entity the audit period, the sampling method, the format of the evidence request and whether the reviewer expects records from a specific system, such as a manual logbook or an automated log. Confirm also how the entity handles visitors who entered before a CIP Exceptional Circumstance and whether any exception was documented at the time.

Before an audit, run the same test yourself. Pick a set of visits, trace each one to access data and escort records, and note every mismatch and its cause. Keep the reconciliation as evidence of your own review, because it shows the reviewer that the entity checks its program and does not rely on the log alone. If the log is kept in a self-hosted system, confirm that its audit trail is enabled and stored where the retention period can be met. A reviewer will ask who can edit or delete log entries and how such changes are recorded, so have those answers ready with the configuration evidence to back them up.

What an assessor checks, the evidence requested and common findings

This table pairs each assessor test step for CIP-006-6 R2 with the evidence usually requested and the findings that appear most often. Read it as a checklist to run before an audit: if a row's evidence cannot be produced for a sample of visits, expect a finding against that step.

Test step	Evidence requested	Common finding
Escort continuity during the visit	Visitor escort procedure, escort assignments for sampled visits, and any badge or access records showing the visitor's movements inside the perimeter	Escort left the visitor alone for part of the visit, or the visitor was in the perimeter with no escort named at all
Log entry: initial entry and last exit times	Visitor log entries showing the date and time of first entry and last exit for each sampled visit	Only a sign-in time is recorded, with no exit time, or times are blank for multi-day visits
Log entry: visitor name	Completed log lines with full visitor names matched against sign-in sheets or identity checks	Initials, company names or generic labels such as 'contractor' used in place of the visitor's name
Log entry: point of contact	Named point of contact on each log line, and a roster showing that person was responsible for the visitor	Point of contact field left empty, or filled with a shared department name rather than an individual
Ninety-day retention	Log copies or system exports covering the retention window, with the retention setting or schedule that keeps them	Logs purged on a shorter cycle, or paper sheets discarded after the visit without a retained copy
Visitors logged in one place but not another	Reconciliation of visitor logs against access control system records and facility sign-in books for the same period	A visitor appears in the access system but has no matching log line, or a log exists for someone who never entered the perimeter
Missing logs for exceptions	Records of any CIP Exceptional Circumstance invoked, plus the logs for visits that occurred during or around it	Exception invoked with no documentation, or visits during the exception left unlogged because staff assumed the exception covered logging

How to implement the visitor control program in six steps

This sequence turns the CIP-006-6 R2 requirements into a working visitor program: defined roles, written escort rules for each Physical Security Perimeter, a complete log, trained staff, retention, and a test before an auditor asks.

Define visitor and escort roles
Start by writing down who counts as a visitor under CIP-006-6 R2: an individual who is provided access to the Physical Security Perimeter but is not authorized for unescorted physical access. Next, define who may act as an escort, which roles can serve as the point of contact for a visitor, and who approves the visit. Keep these definitions in the physical security plan so the program and the access authorization records use the same terms. The output is a short roles table signed off by the CIP Senior Manager or a delegate, and you know the step is done when every person who can grant or escort access appears in it by role.
Set escort rules for each perimeter
Write an escort procedure for each Physical Security Perimeter in scope, covering high impact BES Cyber Systems and the medium impact systems with External Routable Connectivity, along with their associated EACMS and PCA. The procedure should state that escorting is continuous from entry to exit, name the staff permitted to escort, and describe what an escort does if a visitor leaves their line of sight or if a CIP Exceptional Circumstance applies. Walk each perimeter with the people who will use the procedure and confirm that the rules fit the layout. The output is a perimeter-specific escort procedure that a reviewer can read and a site lead can sign.
Choose a log format with all required fields
Build a visitor log, whether on paper or in an automated system, that captures every field Part 2.2 requires: the date and time of the initial entry, the date and time of the last exit, the visitor's name, and the name of the individual point of contact responsible for the visitor. Decide whether entries are manual or automated, and document which method applies to each perimeter. Test the template with a sample visit so that no field is left to memory. The output is a log template with field definitions and a short instruction sheet, and the step is complete when a test visit produces a record with all four elements filled in.
Train escorts and point-of-contact staff
Train every escort and every point-of-contact employee on the escort procedure, the log fields, and what to do when a visit ends early or runs past its scheduled time. Record attendance and the version of the procedure each person was trained on, and repeat training when the procedure changes. Ask the training provider to show how the material maps to the escort rules, and keep the sign-off records with your other CIP training evidence. The output is a training record for each escort and point of contact, and the step is complete when no one who can escort or sponsor a visitor is missing from the record.
Connect logging to the 90-day retention store
Decide where visitor logs will live and how long they stay there. Part 2.3 requires retaining visitor logs for at least ninety calendar days, so configure a store that keeps records for that period and protects them from unauthorized change. If you use a document or wiki platform, enable version history so that edits to a log entry are visible. Write a retention schedule that states the storage location, the owner, the retention period and the disposal rule, and confirm that disposal cannot happen before the 90 days have passed. The output is a retention schedule and a tested retrieval of a log entry from the store.
Test the program with a mock audit sample
Before an auditor arrives, pick a sample of visits from the log and check each one against the requirement: was the visitor escorted continuously, are all four required fields present, and does the record exist within the retention window. Ask someone who did not run the program to perform the check, and record any gaps with an owner and a corrective action. Repeat the test after corrections and keep the results with the evidence package. The output is a written test record that shows the sample, the findings and the fixes. Your organization owns the result, and only the Regional Entity or NERC audit team determines compliance.

Manual logs, badge systems or a self-hosted wiki: choosing the record

A small site with one controlled entry point and few visits can often run on a bound paper logbook or a spreadsheet. The record meets the logging need when every entry captures the required details and the entries are kept as written. The weaknesses are retrieval and tamper evidence. Finding one visitor's entry from ninety days earlier means searching shelves or files, and a loose spreadsheet shows nothing about who edited a row after the fact.

Pre-printed bound books: Numbered pages and a fixed layout make removed pages or skipped lines visible during review.
Protected spreadsheets: Lock the structure, restrict edit rights to named staff and store a controlled copy where the site administrator cannot overwrite it silently.
Required fields on every line: Record the visitor's name, the date and time of initial entry, the time of last exit and the name of the responsible point of contact.
Periodic files: Keep one book or file per period so that any ninety-day window can be produced quickly.

Confirm with your Compliance Enforcement Authority or auditor that your format is acceptable, and document how you show that entries were not altered after they were made.

Evidence that passes a visitor control review

A Regional Entity auditor testing CIP-006-6 R2 will ask for a written procedure, records that show escorting happened, and proof that the logs were kept for the required period. The cards below cover the artifacts that answer those questions, and each one needs a recurring check so it is still accurate when the audit arrives.

Visitor control procedure

This is the documented process that tells escorts and staff how visitors are admitted, escorted and logged inside each Physical Security Perimeter. Check that it names the applicable locations, the exceptional circumstance handling and the log owner, and that the version in use matches the version staff were trained on. Keep it in a version-controlled wiki page so the approval history is visible. Review it on a fixed schedule and after any change to facility access.

Dated visitor logs

The log must record the visitor's name, the date and time of initial entry and last exit, and the name of the individual point of contact responsible for the visitor. Auditors sample entries and check that each one has all four fields. Whether the log is manual or automated, run a recurring review that flags incomplete rows, such as missing exit times, before the sample is drawn.

Escort assignment records

Continuous escorting is the core of Part 2.1, so the evidence should tie each visitor to a named escort for the full time inside the perimeter. Assignment records might be the escort's signature on the log, a badge hand-off record, or a shift roster. Ask the facility team to confirm that the records match what the logs show, because mismatched times are a common finding when a visit spans shift changes.

Escort training records

Escorts need to know what they are responsible for before they take a visitor inside. Keep records showing each escort received the visitor procedure training, the date it was completed and the procedure version covered. Refresh training when the procedure changes, and remove escort rights from anyone whose training has lapsed. Auditors often compare the training roster against the names that appear as points of contact in the logs.

Exception and exceptional circumstance records

Part 2.1 allows an exception only during CIP Exceptional Circumstances, so every departure from continuous escort needs a written record. The record should state the circumstance, the people involved, the time window and who approved the exception. Review exception records against the logs each month, because an unexplained unescorted visit is a direct finding. If no exceptions occurred, keep a dated statement that says so.

Retention and disposal records

Part 2.3 requires visitor logs to be kept for at least 90 calendar days, so the evidence includes the retention setting and proof that logs older than that period were handled under policy. Record where the logs are stored, who can access them, and how deletion is performed and confirmed. If logs live in a self-hosted application, confirm the audit trail for log changes is also retained. Test retrieval of a sample log from the oldest day in the retention window.

What meeting visitor control costs in money and effort

The largest recurring cost of CIP-006-6 R2 is escort staff time. Every visitor who is not authorized for unescorted physical access must be continuously escorted inside each Physical Security Perimeter, so the cost scales with how many visitors come in, how long they stay and how many people are qualified to escort them. Escorts are usually existing operations, security or facilities staff, so the expense is the share of their working hours that visits consume, plus any overtime for after-hours work. Before accepting a quote, the reader should confirm with the entity's own records how many visits occur per month at each site, and whether escorts are employees, contractors or a mix, since contractor escorts carry their own billing terms.

The one-time setup is smaller and more predictable. It covers writing or updating the visitor procedure, deciding whether visitor entries are logged manually or through an automated system, configuring the log fields so they capture the entry and exit times, the visitor's name and the point of contact, and training escorts and point-of-contact staff. Recurring upkeep covers keeping logs for at least ninety calendar days, reviewing them, refreshing training when staff change, and maintaining any logging software or storage. Self-hosted open-source tools can reduce license spend, but the entity still pays for installation, hardening, backups and support, and those costs belong in the quote as one-time or recurring items.

Cost moves with the number of in-scope sites, the visitor volume per site, the share of sites that run high impact or medium impact BES Cyber Systems, and how far log data must be searched or exported for audits. When requesting quotes, ask the provider to split the price into one-time setup, recurring support, storage sizing for the retention window, and any external review, and to state which items are the entity's own staff time. Ask whether the scope covers only the Physical Security Perimeters in the CIP-006 scope or every site, and confirm the retention period and log fields in the written scope before work starts. External review, if bought, is an optional expense: an independent assessor or consultant can test the logs against the requirement, but it does not replace the entity's own compliance obligations.

Cost components of visitor control and how to keep them down

This table lists each cost of running a CIP-006-6 R2 visitor program, who bears it, whether it is one-time or recurring, and what moves it up or down. Rows marked as the entity's own cost stay in-house, while rows marked as partner work can be bought as fixed-scope services. No dollar figures are shown because none are supplied for this topic, so ask for each line item in a written quote.

Cost component	One-time or recurring	What drives it and how to reduce it
Escort staff time (entity's own cost)	Recurring	Driven by visitor volume, number of Physical Security Perimeters and hours of access. Reduce it by scheduling visits in batches and limiting visitors to areas that need them.
Visitor log tooling or licenses (entity's own cost)	Recurring	Driven by whether logs are kept on paper, in a spreadsheet or in a commercial access system. Reduce it by choosing a tool that already records name, times and point of contact.
Self-hosted open-source logging (entity's own cost)	One-time setup, then recurring operations	License spend is removed, but staff time remains for hosting, patching, access control and backups of the log store. Confirm each open-source component's license terms with its vendor before deployment.
Training for escorts and point-of-contact staff (entity's own cost)	Recurring	Driven by staff turnover and how often procedures change. Reduce it by keeping one short written escort procedure and reusing it across sites.
Retention storage for 90-day logs (entity's own cost)	Recurring	Driven by visit volume and how much detail each entry holds. Logs must be kept at least 90 calendar days under Part 2.3, so size storage for that window plus a safety margin.
Program design and deployment support (partner work, fixed scope)	One-time	Driven by number of sites, existing tooling and how many logging workflows must be built. Ask the partner for a written scope listing sites, deliverables and evidence samples.
External review of the visitor program (partner or auditor, optional)	Periodic	Driven by whether the entity wants a readiness check before a Regional Entity audit. Independent auditors do not prepare evidence, so ask who performs each review step.
Auditor sampling effort (Regional Entity cost, shown to the entity as preparation work)	Per audit or request	Driven by the number of visitor log samples requested and how quickly records can be produced. Reduce it by keeping logs in one searchable location with consistent fields.

Who owns the visitor control program and who can help

Your organization is the registered entity, so it owns the CIP-006-6 R2 program in full. Accountability for escort rules, the people who escort, the visitor log and any CIP Exceptional Circumstances sits with you, and you cannot hand that accountability to a vendor or consultant. Your security and facilities staff decide who counts as a visitor, which areas are inside the Physical Security Perimeter, and how escorts are assigned.

Escort rules: Define who may escort, how many visitors one escort may accompany, and what happens when an escort must leave the area.
Visitor log: Record the visitor's name, the date and time of first entry and last exit, and the name of the point of contact responsible for the visitor, then keep the log for at least ninety calendar days.
Staff and training: Make sure escorts understand the rules and that the log is completed at the time of the visit.
Exceptions: Document each use of a CIP Exceptional Circumstance, who approved it and what was done to compensate.
Records: Keep logs in a form you can produce quickly for an auditor, whether paper, a database or a self-hosted system.

Before relying on any tool or partner, confirm internally that someone on your team can explain each escort decision and point to the log entry that proves it.

Where visitor control programs usually fall short

Visitor control under CIP-006-6 R2 fails less often in the policy than in daily practice. The gaps below cluster around three points: who is escorting, what is written down, and where the records live. Each one can be closed with a documented procedure, a logging step and a periodic check.

Escorts who leave the visitor

Part 2.1 requires continuous escorted access inside each Physical Security Perimeter, so an escort who steps away for a meeting or a restroom break leaves a visitor unescorted. Assign a named escort for the full visit, and require a handoff to another authorized escort if the escort must leave. Check during spot walkthroughs that the escort is still beside the visitor, not just signed in at the door.

Logs without a point of contact

Part 2.2 requires the visitor's name and the name of the individual responsible for the visitor. Sign-in sheets often capture the visitor and the time but leave the host blank, or record a department instead of a person. Make the point of contact a required field in whatever logging method is used, and reject entries where the responsible individual is not identified by name.

Exits that are never recorded

The log must capture the date and time of the initial entry and the last exit, so a visitor who leaves without signing out creates an incomplete record. Build an exit step into the escort's checklist, and have the security desk reconcile open entries at the end of each shift. Unclosed entries should be investigated, not left blank.

Retention shorter than the required period

Part 2.3 requires visitor logs to be kept for at least ninety calendar days. Badge or visitor systems often roll logs over on their own default schedule, and paper sheets are sometimes shredded at month end. Confirm the retention setting in each system that holds visitor records, and test by requesting a record from more than ninety days ago. Records that the retention job removes early are a violation even if the process appeared to work.

Exceptions handled without records

Part 2.1 allows an exception only during CIP Exceptional Circumstances. When an unescorted visitor is allowed, for example during an emergency response, the decision and its reason should be written down at the time. Undocumented exceptions are hard to defend because the assessor cannot tell an approved emergency from a lapse. Keep a short exception form linked to the visitor log entry.

Logs held on personal devices

Visitor logs sometimes live in a guard's phone app, a personal spreadsheet or a notes file on an individual laptop. Those records disappear when staff leave and cannot be produced reliably during an audit. Store logs in a controlled system with access limited to authorized staff and a clear retention schedule, and confirm that someone other than the author can retrieve them.

Questions buyers ask about CIP-006-6 R2 cost, effort and outside help

How much staff time does visitor control take each month?

Most of the effort is recurring escort time, so it grows with visitor volume and the number of Physical Security Perimeters in scope. CIP-006-6 Part 2.1 requires continuous escorted access for visitors inside each Physical Security Perimeter, except during CIP Exceptional Circumstances, so an authorized person must stay with each visitor for the whole visit. The cost components are escort staff time, the time to complete entries under Part 2.2, and the time to review logs. The main drivers are visits per week, how many perimeters each visitor enters, overlapping visits across shifts, and the distance escorts travel within a site. Ask any provider for a written estimate that separates one-time setup from recurring escort and logging hours, and state the visit volume it assumes. DeployOpen does not publish prices. A quote follows from the written scope.

How long does visitor control setup take?

Setup length depends on scope, so the timeline should appear in a written plan before work starts. The variables are the number of Physical Security Perimeters in scope, whether a documented physical security plan under CIP-006-6 R1 already exists, how many sites share one logging process, and whether visitor logs go into a system the entity already runs. Setup usually covers the visitor procedure, escort assignments, the log fields required by Part 2.2 (date and time of initial entry and last exit, visitor name, and the point of contact), retention settings for Part 2.3, staff briefings, and a sample evidence set. Running the procedure for a short period before the audit date shows whether the escorts and logs work in practice. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

Can we run visitor control in-house without an outside partner?

Yes. The obligation sits with the registered entity, so an in-house team can run the program if it has enough escort staff, written procedures and a habit of keeping evidence. The team must decide who owns the procedure, who escorts, who reviews logs each period, and who approves exceptions. An in-house team usually builds the log template, trains escorts, and sets a review routine. An outside partner can prepare the procedure, configure the logging system, draft evidence and test the process before an assessment. Whether outside help makes sense depends on the number of sites, the staff available for escorting, how often visits happen, and whether the team has done a CIP audit before. Read the requirement text yourself in the CIP-006-6 standard before deciding who does what.

What does a partner need from us before starting visitor control work?

A partner needs accurate inputs about your environment before it can prepare anything usable. Ask for the list below to be assembled before the scoping call:

Can a partner issue a CIP compliance finding for us?

No. A partner cannot issue a compliance finding. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, self-logging, periodic data submittals, investigations and complaints. There is no CIP certificate. Audits of Balancing Authority, Reliability Coordinator and Transmission Operator entities occur at least once every three years under Section 403.10.1 of the NERC Rules of Procedure, and other registered entities follow a risk-based schedule set by the Regional Entity. DeployOpen prepares systems, controls and evidence for assessments, and it does not issue audit reports or attestations. Ask any provider to confirm in writing what it delivers and that it makes no compliance determination on your behalf.

How do we keep visitor logs for 90 days?

Part 2.3 requires retaining visitor logs for at least ninety calendar days, so the retention routine must run on a schedule and be provable. Use a system that records who changed what and when, and limit edit rights to named roles. XWiki keeps version history for each page, recording what changed, when and by whom, which can support a log page maintained in the wiki. BookStack assigns abilities through roles and lets you override permissions per shelf, book, chapter or page. Nextcloud's admin_audit app writes additional event information to audit.log, which can help show administrative activity on a shared logging location, but confirm it captures the events you need. Set a deletion job that never removes a record younger than ninety days, export records before any purge, and test a restore before the audit.

What happens if visitor logs are missing or escorts are not present?

A missed requirement becomes a potential violation, and penalties are set through the Sanction Guidelines. The maximum civil penalty referenced by those guidelines, under 18 CFR 385.1602(d), is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 in January 2025 and shown in the eCFR in October 2026. Violations can come to light through Self-Reports, self-logging, audits or complaints, and an entity that finds its own gap early generally has more options than one that waits for an assessor. Practical steps include documenting the gap, fixing the procedure, recording a mitigation plan, and keeping the evidence of each step. Visitor logs that cannot be produced for a sampled visit are one of the simplest gaps to avoid, so build the log check into the regular review cycle.

How DeployOpen prepares visitor control evidence

DeployOpen begins with a written scope that names the BES Cyber Systems, their associated EACMS and PCA, and the Physical Security Perimeters where visitor control applies to the entity's own impact categorization under CIP-002. The entity owns its controls, including the visitor escort rule, the sign-in procedure and the decision on who may act as a point of contact. DeployOpen's role is to prepare the systems and records that show those controls operate. Before configuration starts, the entity should confirm which Physical Security Perimeters fall under R2 and which individuals hold the escort role, because those answers drive every record that follows. Scope, deliverables and timelines are agreed in writing before work begins.

DeployOpen then configures self-hosted open-source tools that hold the visitor log, the escort procedure and the change history. A wiki such as XWiki keeps versioned copies of the procedure, so an assessor can see what changed, when and by whom. A role-based tool such as BookStack can restrict who edits the procedure and who only reads it. Where the visitor log is kept in a shared application, Nextcloud's admin_audit app can write additional event information to audit.log, and the entity should confirm the retention of that file against its own 90-day requirement under Part 2.3. Each log field needed by Part 2.2 (entry and exit times, visitor name and point of contact) should be defined in the template before the first entry is recorded. DeployOpen does not decide these retention or access settings for the entity; the entity approves them.

Evidence packages are assembled from these records. A typical package for an illustrative escort sample would include the current procedure, its version history, sample log extracts covering the retention window, and the access roles that show who could edit the log. DeployOpen then runs a mock review in which an internal reviewer, not the people who built the system, asks the questions an auditor from the Compliance Enforcement Authority would ask. Gaps found in that review are fixed before the entity's audit period starts. DeployOpen prepares this material, but it does not issue audit reports, determinations or attestations. Only the Regional Entity or NERC, through its monitoring process, reaches a compliance conclusion.

CIP-006-6 R2 Visitor control program