CIS 12.6 Secure network management protocols: evidence

What CIS Safeguard 12.6 secure network management protocols asks for

Safeguard 12.6 asks the enterprise to use secure network management and communication protocols on its network infrastructure, with 802.1X and WPA2 Enterprise or stronger cited as examples of the kind of authenticated, protected access CIS expects. If an assessor or customer questionnaire asks how network access and traffic are protected, this is the safeguard that answer maps to. The risk it addresses is straightforward: weak or unauthenticated protocols let an attacker join a network without proving identity, or intercept and alter management traffic that controls switches, access points and firewalls. Safeguard 12.6 applies to IG2 and IG3 enterprises only, and it sits in the Network asset class with the Protect security function, so an IG1 organization does not need to meet it to claim IG1 coverage.

The Controls Assessment Specification measures 12.6 with two metrics: Communication Protocol Coverage, the share of network segments using properly configured and authorized communication protocols, and Network Management Protocol Coverage, the share of network segments using properly configured and authorized network management protocols. Safeguard 12.3 is about how the organization manages its infrastructure, such as version-controlled configuration and secure management channels. Safeguard 12.6 is measured segment by segment, so an assessor will ask for a per-segment inventory of the protocols in use and proof that each one is authorized and correctly configured. Two prerequisites must be in place first: Safeguard 4.2, which covers a secure configuration process for network infrastructure, and Safeguard 12.2, which covers a secure network architecture. Without a defined segment model and a hardening baseline, the coverage percentages cannot be calculated in a meaningful way.

CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so mapped requirements in SOC 2, ISO/IEC 27001 or NIST SP 800-53 still need their own evidence. The Assessment Specification covers what to measure, not how, so the organization or its implementation partner must decide the method, tooling and sampling approach, and confirm it with the assessor before collecting evidence. Confirm with your assessor which segments and protocols they expect to see listed, and whether they accept a configuration export as evidence of authorization.

Which network segments and protocols fall under secure network management protocols

Safeguard 12.6 is measured segment by segment, so the scope you draw determines how much work it creates. The cards below cover the decisions that change that work: which access networks, management planes, third-party services and enterprise tiers the Safeguard reaches.

Wired and wireless access networks

Wired and wireless access networks are where 802.1X and WPA2 Enterprise most often apply, because user and device authentication happens at the port or the access point. Inventory every access segment, including guest and building networks, and record which ones authenticate through a RADIUS or directory-backed service. Ask the assessor whether a segment that uses a pre-shared key counts as properly configured and authorized under the metric.

Management planes for network devices

Routers, switches and firewalls expose management interfaces that carry administrative protocols, and these planes are easy to omit from scope because they sit outside user traffic. List each device's management protocols, including web, SSH, SNMP and any vendor-specific API, and confirm which ones are enabled and authorized. Treat the management plane as its own segment in the inventory so its coverage is measured separately.

Segments carrying management traffic

Management traffic often crosses segments that users also reach, such as shared VLANs, jump hosts or monitoring networks. Each segment that carries management traffic adds to the denominator, and a single unmanaged segment lowers the coverage score. Map which segments carry administrative sessions, log collection and configuration backups, then confirm that each uses an authorized protocol or is isolated from user networks.

Third-party and managed network services

Managed WAN, carrier circuits and outsourced network operations still carry protocols the enterprise must evidence, even when the provider runs the equipment. Ask providers for a list of management and communication protocols on the services delivered to you, and write the evidence obligation into the contract. The enterprise owns the Safeguard, so provider configuration reports must be reviewed and retained on your side.

IG2 versus IG3 applicability

Safeguard 12.6 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. IG3 organizations with regulated or sensitive assets face the same measurement but usually hold more segments and stricter evidence expectations. Confirm your Implementation Group before scoping, and document the basis for the decision so an assessor can follow it.

Prerequisites and framework mappings

The assessment specification treats Safeguards 4.2 and 12.2 as prerequisites, so a segment cannot be scored well without a secure configuration process and a documented network architecture. The CIS Controls Navigator maps 12.6 to NIST SP 800-53 Rev. 5 AC-18, SC-23 and SI-4(22), ISO/IEC 27001:2022 Annex A 8.21 and SOC 2 CC6.1. Confirm with your assessor whether those mappings fit your scope, since mapping fit depends on how your organization was assessed.

How an assessor scores CIS 12.6 protocol coverage

This table walks through how an assessor tests Safeguard 12.6, from the prerequisites checked first to the two coverage metrics the CIS Controls Assessment Specification uses. Read each row as a step in the test, the evidence the assessor will ask for, and the findings that most often cause a segment to fail the count.

Test step	Evidence requested	Common findings
Check prerequisites 4.2 and 12.2 first	Documented secure configuration process for network infrastructure (4.2) and the network architecture design with segmentation (12.2)	Configuration process exists on paper but is not applied to switches, access points or firewalls
Build the segment population from inventory	Network segment list with owner, purpose and device count, reconciled against the asset inventory	Segments missing from the inventory, so they never enter the sample or the denominator
Sample segments for testing	Sample selection record showing how segments were chosen and which ones were tested	Only well-known segments tested, while lab, guest or legacy segments are left out
Compare configured protocols to the approved list	Approved communication and management protocol list, and configuration exports from wireless controllers, switches and routers for each sampled segment	Legacy or weak protocols still enabled, such as unencrypted management access or outdated Wi-Fi security modes
Verify 802.1X and WPA2 Enterprise or stronger where used	Authentication server settings, client authentication logs and wireless security profile for each sampled wireless segment	Pre-shared keys left on a segment that should use enterprise authentication
Check certificates used by protocols	Certificate inventory with issuer, expiry date and the systems that use each certificate	Certificates expired or untracked, causing outages or unplanned fallback to weaker settings
Check authorization for each protocol	Change records or approvals showing who authorized each protocol on each segment and when	No evidence of authorization, or approvals that do not match the configuration found
Calculate Communication Protocol Coverage	Count of sampled segments using properly configured and authorized communication protocols, divided by the sampled segments	Coverage reported from configuration intent rather than from observed configuration
Calculate Network Management Protocol Coverage	Count of sampled segments using properly configured and authorized network management protocols, divided by the sampled segments	Management access over insecure protocols on devices that are otherwise well configured

Implementing secure network protocols in sequence

This sequence moves Safeguard 12.6 from an approved protocol list to measured coverage, so that each network segment uses authorized communication and management protocols and the organization can show an assessor how it knows.

Confirm the 4.2 and 12.2 prerequisites
Before any protocol work starts, the network owner confirms that a secure configuration process for network infrastructure (Safeguard 4.2) and a documented secure network architecture (Safeguard 12.2) exist and are current. The CIS Controls Assessment Specification treats both as prerequisites for measuring 12.6, so an assessor will ask for them first. The output is a short readiness record that names the owner of each document, its last review date and any gaps that must close before the protocol work continues.
Define the approved protocol list
The security architecture and network engineering teams write a list of approved communication protocols and approved network management protocols, with the settings each one must use. For example, the list might state that wireless clients authenticate with 802.1X and WPA2 Enterprise or stronger, and that device management uses encrypted channels only. Security and network leadership approve the list and it is version controlled. The output is an approved protocol register that the auditor can compare against the observed configuration in later steps.
Inventory segments and their current protocols
The network team lists every network segment, including wired, wireless, management, out-of-band and cloud-connected segments, and records the communication and management protocols each one currently uses. Configuration exports from switches, wireless controllers, firewalls and access points are the usual source, and the inventory should be cross-checked against the asset inventory maintained under Control 1. The output is a segment-to-protocol map that becomes the denominator for the coverage metrics, so an incomplete list will distort the result.
Configure 802.1X and WPA2 Enterprise where applicable
For each segment where the approved list requires it, the network engineers configure port-based authentication with 802.1X and WPA2 Enterprise or a stronger standard, and remove legacy settings that the approved list does not allow. Changes are made through the documented change process and tested on a pilot segment before wider rollout. Certificates for authentication servers and devices come from an internal certificate authority. The output is a configuration record per segment, with change tickets and test results that show each segment matches the approved register.
Issue and rotate device and server certificates
The PKI owner issues certificates for the authentication servers, network devices and management endpoints that the approved protocols depend on, and sets a rotation schedule that the team documents. Open-source options such as FreeIPA, which includes a Dogtag-based certificate authority, or OpenBao's PKI secrets engine, which issues dynamic X.509 certificates, can automate issuance so that services avoid manual key and signing requests. Whichever tool is chosen, the organization should confirm its certificate lifecycle features before relying on them. The output is a certificate inventory with issuance, expiry and rotation records.
Remove or block non-approved protocols
The network team disables protocols that the approved list does not allow, such as unencrypted management channels or legacy wireless security modes, and adds firewall or access rules that block them on each segment. OPNsense rules can pass, block or reject traffic by source, destination, port and protocol, and rule-match logging helps show that the block is in effect. Each change is verified with a test from an approved and an unapproved host. The output is a before and after record for each blocked protocol, together with the rule set and the test evidence.
Set up recurring coverage measurement
The security team calculates the two assessment metrics on a schedule the organization sets and documents: Communication Protocol Coverage and Network Management Protocol Coverage, each expressed as the share of segments that use properly configured and authorized protocols. The results are reviewed by the owner of the approved list, and gaps are logged as findings with owners and remediation dates. Ask the auditor which measurement frequency and sampling approach they expect for your environment. The output is a dated coverage report with its underlying segment data, which is the evidence an assessor will request.

Evidence that shows secure network management protocols are in place

The Assessment Specification scores Safeguard 12.6 with two coverage metrics, so the evidence must show which network segments use which protocols and whether those protocols were approved and configured correctly. The cards below cover the records an assessor will ask for, and each one should be refreshed on a schedule and whenever a segment, device or protocol changes.

Approved protocol standard

This is the written standard that names the communication and network management protocols the organization permits, such as 802.1X for port authentication and WPA2 Enterprise or stronger for wireless. An assessor compares every segment in the inventory against this list, so it must state the approved versions and the cases where a legacy protocol is allowed. Confirm that the standard was approved by the accountable owner and that its revision history is kept. Review it when a protocol is deprecated or when Safeguard 4.2 secure configuration baselines change.

Segment inventory with protocol status

A current register of network segments that records, for each one, the communication protocols and management protocols in use and whether each is approved. This table is the numerator and denominator behind both CAS metrics, so gaps here distort every coverage figure. Generate it from the device and configuration sources where possible, and link each segment to the architecture record from Safeguard 12.2. Update it whenever a VLAN, subnet or access point is added, moved or retired.

Device configuration exports

Exported configurations from switches, wireless controllers and access points that show 802.1X authentication and WPA2 Enterprise or stronger settings in effect, not just in a template. Store exports in version control so an assessor can see the configuration at a given date and who changed it. Check that disallowed options, such as open or pre-shared key modes on production segments, are absent. Schedule exports at a defined interval and also after every change window, then compare them with the approved standard.

Certificate inventory and issuance records

802.1X and enterprise Wi-Fi depend on certificates for devices and RADIUS servers, so the inventory should list each certificate, its issuing authority, subject, validity period and the systems that trust it. Issuance records should show who requested each certificate, when it was signed and how private keys were generated. A private certificate authority such as the one in FreeIPA, or certificates issued through OpenBao's PKI secrets engine, can produce these logs automatically. Confirm that expired or revoked certificates are tracked and removed from authentication servers.

Authorization records for protocols and changes

Approval records show that each protocol in use, and each change to a protocol setting, was authorized before deployment. For Safeguard 12.6 the assessor will look for a link between an approved protocol decision and the segment where it appears. Keep change tickets that name the segment, the protocol, the approver and the rollback plan. Confirm that emergency changes receive a retrospective review and that exceptions are not used to bypass the approval path.

Coverage reports and exception tracking

Periodic reports that calculate Communication Protocol Coverage and Network Management Protocol Coverage from the segment inventory, plus a register of every segment that is not compliant. Each exception needs an owner, a documented reason, a compensating measure and a closure date that is tracked to completion. An assessor will check whether exceptions are reviewed and whether the trend improves over time. Ask the team to confirm the reporting interval set in the organization's own policy, since the Assessment Specification does not set one.

What meeting secure network management protocols costs in money and effort

This table breaks down the cost components of meeting Safeguard 12.6, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No prices or durations are stated because none are supplied for this Safeguard, so use it to structure your own estimate and quote requests.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring if commercial, one-time setup	Number of network device types, whether 802.1X authentication servers and certificate authorities are commercial products, and vendor licensing per device or per user	Choose open-source options such as FreeIPA for certificate issuance where they fit your environment, then confirm each platform's capabilities against your requirements before committing
Engineering time for protocol configuration	One-time, with ongoing changes	Number of network segments, number of device vendors, and how many wireless and wired access methods must enforce authenticated, approved protocols	Standardize configuration templates per device class and manage them as versioned code so each segment is configured the same way
Certificate lifecycle engineering	Recurring	Number of devices and services that need certificates, renewal frequency, and whether issuance is manual or automated through a CA integration	Automate issuance and renewal through a certificate authority that supports dynamic certificates, such as the OpenBao PKI secrets engine, to reduce manual key and request handling
Segment inventory and measurement upkeep	Recurring	Rate of network change, number of segments, and how often the two metrics in the assessment specification are recalculated and reviewed	Generate the protocol inventory from configuration data rather than spreadsheets, and schedule a fixed review cadence tied to change management
External review or testing	Recurring or per engagement	Scope of protocol testing, whether wireless and wired authentication are tested, and whether a third party reviews configurations against the prerequisites in 4.2 and 12.2	Limit the first review to the segments that carry sensitive traffic and expand scope once the baseline is stable
Auditor sampling effort	Recurring at each assessment	Number of segments the auditor samples, depth of evidence requested, and whether logs and configuration history are available on request	Keep configuration baselines, change records and coverage reports in one location so samples can be produced quickly
Internal coordination with prerequisite owners	Recurring	Dependence on secure configuration (4.2) and network architecture (12.2) work, which must be in place before 12.6 can be measured	Assign one owner for the protocol inventory and agree handoffs with the owners of 4.2 and 12.2 in writing

Open-source tools that support secure protocol evidence

Safeguard 12.6 is measured through the share of network segments running properly configured and authorized protocols, so evidence has to show configuration, authorization and enforcement. The three tools below can produce parts of that record, but each covers a different layer, and none of them proves wireless or switch port authentication on its own.

OPNsense packet filter rules

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses so that one rule set can express which segments may use approved management and communication protocols. Enable per-rule logging so each match appears in the live log view, then export rule sets and matched logs as the segment-level record an assessor will ask for. Confirm that the firewall sits on every path that carries the segments you are measuring, because wireless and switch authentication happen outside the firewall.

FreeIPA certificate authority

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. Certificates issued for network devices, RADIUS servers and management endpoints give you an inventory of which identities are authorized to use which protocols, and revocation records show when access was withdrawn. Assessors typically ask who issued each certificate, when it expires and how revocations are handled, so keep the issuance log alongside the device list. Confirm that your switches and access points can use certificates from this CA before you design the 802.1X trust chain around it.

OpenBao dynamic X.509 certificates

The OpenBao PKI secrets engine (MPL-2.0) issues dynamic X.509 certificates, so services receive certificates without an administrator generating a key and certificate signing request by hand and waiting for a CA to sign it. This matters for management interfaces and automated network tooling, where short-lived certificates reduce the chance of stale credentials remaining in use. Record the role definitions, lease durations and issuance audit entries, since those show that management protocols are authorized and renewed under control. Confirm that your management tools and network devices can consume dynamically issued certificates and that the renewal process will not break device connectivity.

Who does what for secure network protocols: your team, a partner and the auditor

Your organization owns Safeguard 12.6. Only you can decide which communication and network management protocols are approved, which network segments are in scope, and who is authorized to use each protocol. Those decisions are management decisions, and an assessor will look for them in written policy and in the inventory they produce. Your team also carries the operating responsibility: approving changes, reviewing exceptions and acting on drift.

Approved protocol list: Decide which wireless and wired authentication methods, such as 802.1X with WPA2 Enterprise or stronger, and which management protocols are permitted, and record the list in a policy your staff can enforce.
Segment inventory: Own the authoritative list of network segments and the protocols each one uses, kept current as the network changes.
Authorization decisions: Approve exceptions, such as legacy devices that cannot run approved protocols, with a named owner, a compensating control and a review date.
Operating the control: Run configuration changes and periodic reviews through your own change process, and retain the records.
Interpreting the result: Decide how to act on coverage gaps and document the remediation plan.

Check that the approved protocol list and segment inventory exist, have owners, and match what the network actually does today.

Where secure protocol programs usually fall short

Safeguard 12.6 is measured by coverage: the share of network segments running properly configured and authorized protocols. Most shortfalls come from the segment list being incomplete, legacy protocols staying switched on, and evidence that exists once but is never kept current. The cards below cover the gaps assessors most often find and a first action for each.

Segments missing from the inventory

The coverage metrics are calculated against the segments the team knows about. If guest Wi-Fi, lab networks, out-of-band management VLANs or branch sites are absent from the segment register, coverage looks higher than it is. Reconcile the segment list against switch and firewall configurations and against the asset inventory from Control 1 before calculating any percentage. Ask the assessor which source of truth they will use for the denominator.

Legacy management protocols left enabled

Many devices ship with Telnet, SNMP v1 or v2c, HTTP administration or unencrypted syslog still enabled beside the approved SSH, HTTPS and SNMPv3 options. A secure protocol is not enough if a weaker one still answers on the same interface. Run a port and service check on each device class and record which legacy services are disabled, with the change ticket that disabled them. Confirm the protocols with the vendor documentation for each platform.

Certificates without lifecycle tracking

Wireless 802.1X, management interfaces and internal services depend on certificates that expire, and an expired certificate can either break access or push teams to disable validation. Keep a register of each certificate with its issuing authority, subject, key size, expiry and the devices that trust it. For internal issuance, an open-source CA such as the one in FreeIPA can be used, and a dynamic PKI engine such as the one in OpenBao can reduce manual renewal. Confirm which option fits your device estate.

Authorization decisions not recorded

Coverage counts only protocols that are properly configured and authorized, so the team needs a record of who approved each protocol for each segment and why. Without that record, a configuration that matches the standard can still be classed as unauthorized during testing. Keep a short approval entry per protocol and segment, linked to the change record and reviewed when the segment changes. Store the record where the assessor can sample it.

Prerequisites 4.2 and 12.2 not evidenced

The assessment specification lists Safeguards 4.2 and 12.2 as prerequisites for measuring 12.6. If the secure configuration process for network devices and the network architecture design are undocumented or out of date, the protocol evidence has no supporting basis. Before collecting 12.6 evidence, confirm that a written configuration baseline exists for each device class and that the architecture design names the segments the protocol measures refer to. Start with the baseline for the most common switch and firewall models.

Coverage measured once, not maintained

A coverage figure calculated during an audit preparation sprint becomes stale as soon as a new switch, access point or segment is added. Assessors typically ask how the measurement is repeated and who reviews the result. Schedule a recurring check that compares the device configurations with the approved protocol list and records the drift. Decide in advance who owns the result and what happens to a segment that falls below the approved set.

Questions buyers ask before bringing in outside help on Safeguard 12.6

Can a small IG2 team implement Safeguard 12.6 without outside help?

Often yes, if the team already runs a documented network architecture and can operate its own identity and certificate services. Safeguard 12.6 is an IG2 Safeguard, so it applies once an enterprise has moved beyond essential hygiene. The work has three parts: deciding which communication and management protocols are authorized, configuring every network segment to use them correctly, and producing evidence that coverage is complete. Teams with few segments, one wireless design and staff who already run 802.1X or certificate issuance usually handle this internally. Teams without those skills, or with many sites and mixed device types, tend to ask for help with design and configuration. Either way, the organization owns the decision and the independent assessor, not the implementation partner, decides whether the Safeguard is met.

What drives the effort and cost of Safeguard 12.6 work?

Three factors move the effort most: the number of network segments, the mix of wireless and wired access, and the certificate authority choice. Each segment must be checked against the Communication Protocol Coverage and Network Management Protocol Coverage measures, so more segments mean more configuration review and more evidence. Wireless work with WPA2 Enterprise or stronger requires authentication servers, client certificates or credentials, and RADIUS policy, which adds design time that a wired-only estate does not need. The certificate authority choice matters because an internal CA such as one built on FreeIPA's Dogtag-based service, or an issuance engine such as OpenBao's PKI secrets engine, changes how certificates are enrolled, renewed and revoked. When requesting a quote, ask for the cost of each component, which parts are one-time and which recur, such as certificate renewal and protocol reviews, and who pays for assessment support.

How long does Safeguard 12.6 work take?

No duration is supplied for this work, so no timeline should be assumed from this page. The schedule depends on the segment count, the state of current network configuration, how many device types need reconfiguration, and whether the certificate authority already exists. Ask for a written schedule as part of the fixed scope, with milestones for design, configuration of each segment group, testing, evidence capture and handover to the internal team. A credible schedule also names the dependencies on Safeguards 4.2 and 12.2, because the assessment specification treats those as prerequisites for measuring 12.6. If a proposal omits dependencies or gives no milestones, ask for them before signing.

What does Safeguard 12.6 require from our own staff?

Your staff must supply knowledge of the network, decisions about authorized protocols and access to change windows. The network team needs to list every segment and the devices in it, identify which wireless networks exist and which clients use them, and confirm which management protocols administrators use today. Identity staff must confirm how users and devices authenticate and who approves changes to access policy. Security staff own the evidence requirements and the risk acceptance for any exception. Plan for these people to review designs, test changes in non-production segments and sign off on configuration baselines. The effort is often underestimated in proposals, so ask the provider to list the internal roles and hours it expects, and confirm them against your own calendar before work begins.

Can Safeguard 12.6 be assessed separately from Safeguards 12.3 and 12.2?

Safeguard 12.6 can be assessed as its own measure, but it cannot be assessed in isolation from its neighbors. The assessment specification lists Safeguard 12.2 on secure network architecture and Safeguard 4.2 on secure configuration of network infrastructure as prerequisites, so an assessor will expect those to be in place first. Safeguard 12.3 covers secure management of network infrastructure, such as SSH and HTTPS for administration, while 12.6 covers the communication and management protocols across segments. The two overlap in practice, because the same devices and management paths appear in both. Build one inventory of segments and protocols, then map each Safeguard's evidence to it. Ask your assessor how they want that mapping presented before you collect evidence.

Who issues the compliance conclusion for Safeguard 12.6?

Your organization owns its controls and makes the compliance claim, while an independent assessor or auditor issues any formal conclusion or report. CIS publishes the Controls and the assessment specification, but CIS does not certify your implementation through this Safeguard. An implementation partner such as DeployOpen can plan, configure and document the protocol environment and prepare the evidence, but it does not issue audit reports, attestations or certifications. Where a contract, regulator or customer asks for an attestation, the engagement must name the independent body that will perform it. Clarify this in the written scope so that no deliverable is mistaken for an assessor's conclusion.

How DeployOpen scopes and prepares evidence for secure network protocols

DeployOpen works on Safeguard 12.6 as part of a fixed-scope engagement inside your own infrastructure. We prepare the network segments, protocol configurations and evidence that the CIS Controls Assessment Specification measures, while your organization owns the controls and an independent assessor reviews the result.

How we scope

Agree in writing which network segments, devices and wireless or management networks fall within Safeguard 12.6.
Confirm the prerequisite work under Safeguards 4.2 and 12.2 before protocol changes begin, and record any gaps.
Define the two measured metrics, communication protocol coverage and network management protocol coverage, with named owners and sources.

How we build

Configure 802.1X and WPA2 Enterprise or stronger on wireless and wired access where your environment requires it, tested against your device types.
Deploy open-source tooling such as OPNsense rule sets with aliases and logging, and FreeIPA or OpenBao for certificate issuance to authenticated services.
Test protocol configuration in a non-production segment first, then document rollback steps before changes reach production networks.

How we hand over

Deliver configuration baselines, change records and coverage reports that map each network segment to its authorized protocols.
Provide runbooks for certificate renewal, protocol exceptions and periodic re-measurement of both Safeguard 12.6 metrics.
Walk your team and your assessor through the evidence package so your organization can present it and maintain it independently.

How we support

Offer ongoing support as a retainer for upgrades, protocol changes and periodic re-measurement after the initial handover.
Re-test configurations after firmware or device changes so coverage figures stay accurate between assessment cycles.
Confirm with your independent auditor which evidence they expect, since DeployOpen prepares evidence but does not issue reports or certifications.