03.01.16 Wireless access: requirements and evidence

What 03.01.16 wireless access requires and why assessors look hard at it

03.01.16 requires usage and connection rules for each type of wireless access, authorization before any wireless connection is made, disabling wireless capabilities that are not intended for use before a device is issued, and protection of wireless access with authentication and encryption. If a contract or CMMC scope brings SP 800-171 into your environment and any part of the system has, or could gain, a wireless connection, this requirement applies to that part of the system. The risk is simple to state. An access point, a radio on a laptop or a forgotten Bluetooth or Wi-Fi adapter on a peripheral can become a path into the CUI boundary that bypasses the firewall, the VPN and the network segmentation you have documented. Each wireless type you permit needs its own rules, and each device that connects needs an approval on record. Rev. 3 absorbed the Rev. 2 requirement 3.1.17, which covered wireless access protection, into 03.01.16, and NIST's change analysis classifies the change as significant because the new text asks for more detail and foundational tasks. Rev. 2 assessors who tested 3.1.16 and 3.1.17 separately should expect one combined assessment under Rev. 3. Under the CMMC program, which still uses Rev. 2, the same practice is scored as AC.L2-3.1.16 and carries a high point value, and 32 CFR 170.21 does not allow it on a plan of action and milestones for conditional status. Confirm the current scoring and POA&M rules in the eCFR text for 32 CFR 170.24 before you plan remediation. Wireless access is hard to evidence for three reasons. Organizations rarely have a complete inventory of wireless devices, especially personal hotspots, printers and handheld scanners. Radios are often enabled by default on laptops, docking stations and peripherals, and nobody has been asked to turn them off before issuance. Finally, wireless configuration usually has no single owner: network teams manage access points, endpoint teams manage laptop radios, and facilities teams may have installed the guest network. Assessors will interview the people who manage these settings and test whether the configuration matches the documented rules, so assign one accountable owner and reconcile the device inventory against the approved list before the assessment.

Which wireless access points, devices and networks fall under 03.01.16

03.01.16 applies to wireless access to the system that handles CUI, so the scoping question is which wireless components, networks and devices can reach that system or hold CUI. The cards below cover the decisions that most often change the work, and the exact wireless types should be confirmed against your own environment before the boundary is documented.

Access points and wireless controllers

Any access point, wireless controller or cloud-managed wireless service that bridges into the CUI system falls within the requirement. Inventory every SSID, radio and controller, including those installed for facilities or temporary projects, and record which ones connect to the CUI enclave or to networks that route to it. An access point on a shared switch port can be in scope even when no one intends it to carry CUI, so trace the actual network path rather than the floor plan.

Guest and visitor networks

Guest Wi-Fi that shares infrastructure with the CUI system needs a documented answer to whether it is separated at layer 2 and 3, and whether any rule permits traffic from guest clients to the enclave. Confirm the separation with a test from a guest device, not only from the configuration file. If guest access is isolated by a firewall policy, the policy and its change history become part of the evidence an assessor will request.

Laptops and mobile devices with built-in radios

Company laptops, tablets and phones issued with Wi-Fi or Bluetooth are often the most common wireless surface. Decide which of their radios are needed for the job, then disable the rest before issuance through the device image or management profile. Users who connect these devices to home, hotel or public networks create wireless access that the system security plan should address, so the usage restrictions must cover them too.

Wireless-capable peripherals

Printers, scanners, badge readers, conference systems and other collaboration devices may have Wi-Fi or Bluetooth enabled by default and may join networks without a visible user action. Check each model's radio settings and whether it is attached to a network that reaches CUI. Where a device cannot be configured to meet the connection requirements, document the decision and the compensating limits rather than leaving it unaddressed.

Third-party and managed wireless services

When a managed service provider or cloud platform operates the wireless network, the organization still needs evidence that the usage, configuration, authorization and encryption requirements are met. Ask the provider which controls it operates, which it leaves to you, and what logs or configuration exports it can give you. Contract terms should cover how the provider reports changes to wireless configuration that could affect the CUI system.

The system security plan boundary

The system security plan defines what counts as the system, so the wireless scope should be stated there and reconciled with the network diagrams. Any wireless component left outside the boundary needs a documented reason and a boundary control that keeps it separate. An assessor will compare the plan, the diagrams and the live configuration, so inconsistencies between them are a common source of findings.

What changed from Rev. 2 3.1.16 and 3.1.17 and why it matters now

In Rev. 2, wireless access was covered by two requirements: 3.1.16, which set authorization and configuration rules for wireless access, and 3.1.17, which required protecting wireless access with authentication and encryption. Rev. 3 folds the protection work into 03.01.16 and withdraws 03.01.17. NIST's change analysis classifies the move from 3.1.16 to 03.01.16 as a significant change, because the Rev. 3 requirement carries more detail and foundational tasks. In practice, a wireless evidence package built for Rev. 2 will not map cleanly onto Rev. 3 without rework. Authentication and encryption settings for each wireless network now belong to the same requirement as usage restrictions and authorization, so one assessor question can reach across the whole wireless design.

The version question is the one that changes what you build. CMMC Level 2 still uses Rev. 2 numbering, so the wireless practice appears as AC.L2-3.1.16, worth 5 points under the scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so it must be fully met. The DoW's current contract baseline, set out in Class Deviation 2026-O0025, Revision 3, names Rev. 2 explicitly. A proposed FAR overhaul published 23 June 2026 would instead require Rev. 3, with organization-defined parameter values published by the DoW CIO. That rule was not final as of October 2026, so the parameter values for wireless access may not yet be available to you.

Before you build wireless evidence, confirm in writing which SP 800-171 revision your contract, task order or CMMC assessment scope cites, and ask the contracting officer or prime contractor whether any parameter values have been assigned for wireless access. Keep the wireless design, authorization records and encryption settings in a form that can be traced to both numberings, and record which numbering each artifact supports. If the contract cites Rev. 2 today and Rev. 3 later, plan for the wireless protection work to be re-evidenced under the new structure, not simply renumbered.

How an assessor tests wireless access under 03.01.16

This table compares the three SP 800-171A assessment methods for 03.01.16 by the objects an assessor reviews, the evidence to prepare and the findings that appear most often. SP 800-171A Rev. 3 applies eight determination statements to this requirement, so each row maps to work that must be shown, not just described. Use it to check your own readiness before an assessor arrives.

Method and objects	Evidence to prepare	Common findings
Examine: access control policy and procedures	Current access control policy and procedures that name wireless access, approval owners and review dates	No documented wireless usage rules, or policy that covers remote access but is silent on wireless
Examine: procedures for wireless system access	Written steps for requesting, approving, configuring and removing each wireless connection type	Procedures exist only in an administrator's head or in a ticket template with no approval step
Examine: wireless configuration and connection requirements	Configuration baseline for each wireless type, with allowed authentication and encryption settings	Baseline missing for one access point model, or settings differ from what the policy states
Examine: configuration management plan	Plan entries and change records showing wireless settings and radios are controlled and baselined	Wireless hardware added through change tickets that never update the baseline or inventory
Interview: personnel managing wireless connections and personnel with information security responsibilities	Named owners who can explain authorization steps, configuration checks and how unneeded radios are disabled	Staff describe the process differently, or the owner of wireless approvals is unknown
Test: wireless access management capability	Demonstration of authorizing a wireless connection, plus records of approved and rejected attempts	Connections are possible without an approval record, or the team cannot show a rejected request
Test: protection mechanisms for wireless access to the system	Live checks of authentication, encryption settings and blocked wireless networking on issued devices	Radios left enabled on issued devices, weak or open wireless encryption, or wireless links absent from the system security plan

Implementing wireless access controls in the order that produces evidence

This sequence moves from knowing which wireless paths exist, to defining and approving them, to locking down devices and testing the result, so each step leaves an artifact an assessor can examine. The order matters because authorization and configuration records are only credible if they describe the wireless environment that actually exists.

Inventory every wireless type and radio in scope
Walk the CUI boundary and list every wireless technology that touches the system, including Wi-Fi access points, client radios in laptops and phones, Bluetooth peripherals, cellular modems, and wireless printers or sensors. For each entry, record the owner, location, the systems it connects to, and whether it can reach CUI. Ask your network and endpoint teams to confirm the list against device management data and switch or controller records, since radios often appear in places nobody documented. The output is a wireless inventory that is reviewed and signed off by the owner of the system security plan. Treat it as the baseline for every later step, because an assessor will compare it against what they see during examination and testing.
Write usage and connection requirements per type
For each wireless type in the inventory, write a short standard that states who may use it, what it may connect to, which network segments it may reach, and which configuration settings are mandatory. Separate requirements for corporate devices, managed guest access, and any approved mobile or field equipment, since the same radio can carry different risk depending on the device. Have the standards reviewed by the people who run the wireless infrastructure and by the security team, and confirm they match your access control policy and procedures. The output is an approved wireless configuration standard with version control and an owner. Requirements that are written only as intent, with no settings an administrator can check, will be hard to show as implemented.
Define the authorization process before any connection
Set out how a wireless type or device is authorized before it connects. Name the role that approves each type, such as the system owner for corporate Wi-Fi and the security lead for any new radio technology, and describe the request steps, the criteria checked, and the conditions for revocation. Record every decision in an authorization log that captures the requester, the approver, the date, the device or access point identifier, the approved configuration version, and any exceptions. Tell your team that an unrecorded connection is an exception, and report exceptions to the people who own the risk. The output is a written procedure and a log that an assessor can sample during interviews and examination. Confirm with your assessor which level of record they expect for your environment.
Disable unneeded wireless capabilities before issuance
Before a laptop, phone, tablet, or other device is issued, turn off wireless networking functions that the device does not need for its intended use, such as unused Bluetooth, Wi-Fi direct, or cellular radios where they are not approved. Apply these settings through a hardened image or device management policy so they are enforced at build time rather than left to the user. Check the result on sample devices before each image is released, and record the settings in the configuration baseline so the change is traceable. The output is a documented hardened image or policy, a configuration baseline entry for each device class, and a test record showing the radios were disabled on sample units. Coordinate this step with the configuration management work for the same systems so the two sets of records agree.
Enforce authentication and encryption on approved paths
For every approved wireless path, configure authentication that identifies the user or device before network access is granted, and use encryption for the wireless link. Confirm which protocols and authentication methods your platform and your cryptography policy support, and document the chosen settings, since the requirement is met only where the configuration can be shown. Where a platform does not provide a capability, record the gap and the compensating control in the system security plan rather than assuming coverage. Keep the settings in the wireless configuration standard so administrators can compare live configuration against it. The output is a configuration export or screenshot set for each approved path, plus a list of any unsupported settings with their documented treatment.
Document system security plan entries and open items
Update the system security plan so that each wireless type, its usage and connection requirements, its authorization owner, its authentication and encryption settings, and the device baseline appear in the description of how 03.01.16 is implemented. Link each claim to the artifact that supports it, such as the inventory, the standard, the authorization log, or the configuration export. Where an element is still in progress or depends on another team, record it as an open item with an owner and a plan rather than describing it as complete. The output is a system security plan section for wireless access with traceable references. Ask whether your contracting or assessment process requires a specific format for this entry.
Test the controls and retain the results
Test the wireless controls as an assessor would, using the examine, interview, and test approach in the assessment procedure for 03.01.16. Examine the policy, standards, and configurations; interview the people who manage wireless connections and information security; and test the live environment by attempting an unauthorized connection, checking that a sample device has unneeded radios disabled, and confirming that a connection without approved authentication and encryption is refused. Record the test scope, the method, the results, and the remediation for each failure, then retest after any fix. The output is a dated test record that ties back to the determination statements for the requirement. Testing can be performed by your internal team, and an independent assessor will check its own results separately.

Which evidence satisfies 03.01.16 and how to keep it current

An assessor testing 03.01.16 looks for a chain of records: the standard that sets wireless rules, the inventory of what is actually connected, the authorizations behind each connection type, and proof that the configuration and test results match. Each artifact below should be tied to a named owner and a review date, and every one must agree with the system security plan.

Wireless usage and connection standard

This document sets the usage restrictions and the configuration and connection requirements for each type of wireless access in use, such as corporate Wi-Fi, guest networks, or wireless peripherals. It is the reference point the assessor uses to judge every other artifact. Keep it under version control and update it whenever a new wireless technology is approved or retired. Check that the system security plan describes the same access types, using the same names.

Approved wireless inventory with owners

List every access point, controller, wireless client type and wireless-capable device that can reach CUI, with each item's location, owner and approved access type. Inventory gaps are the most common reason wireless evidence fails, because an unlisted access point undermines every other record. Reconcile the inventory against network discovery results each quarter, and require an inventory change for every new or removed device. Tie inventory updates to change tickets rather than to the audit calendar.

Authorization records for each connection type

For each wireless access type, keep a dated approval that names the authorizing official, the permitted users or devices, and the conditions for connecting. Authorization must come before the connection is made, so the record date should precede the first connection in logs. Re-authorize when the access type changes, when an owner leaves, or when the standard is revised. Confirm that approvals cover every access type shown in the inventory and the system security plan.

Hardened baselines and radio settings before issuance

Keep configuration baselines or images that show wireless networking capabilities not intended for use are disabled before a device is issued and deployed, such as Bluetooth or cellular radios on managed laptops. Export the settings from the device management or imaging tool and store them with the build date and version. Each time an image changes, record which baseline it replaced. Sample a few recently issued devices and confirm their settings match the baseline.

Authentication and encryption configuration exports

Capture screenshots or exported settings that show how wireless access is authenticated and encrypted, including the authentication method, the encryption protocol and key handling. Store exports from the controller or access point, not from a memo describing intent. Re-export after every firmware update, since upgrades can reset or change these settings. Compare the exports with the standard and the system security plan, and document any deviation with its approved exception.

Periodic test records and rogue access point scans

Keep dated records of periodic checks, including scans for unauthorized access points, reviews of devices connected to wireless networks, and results of any penetration test that covered wireless access. Each record should list what was scanned, who reviewed it, what was found and how each finding was closed. Schedule the checks in the security assessment plan and confirm that the cadence is written there. Treat an unexplained rogue device as an incident under the incident response plan, not as a closed scan item.

What wireless access controls cost to meet

This table compares the cost components of meeting 03.01.16 Wireless access, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a scope and request quotes that separate platform spend from engineering, evidence and assessment effort. No figures are given because none were supplied, so treat the drivers as the questions to price with your vendors and advisers.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Wireless platform or controller licenses (where applicable)	Recurring, paid to the wireless vendor or reseller if you run a managed controller. Not needed for a wired-only or open-source-only setup.	Number of access points and wireless types in use, and whether the controller already enforces centralized policy for authorization and encryption.	Itemized license terms, renewal dates, per-access-point or per-device basis, and which 03.01.16 functions the platform covers natively.
Engineering time to write standards and configure baselines	One-time to start, then recurring on change. Paid to internal staff or an implementation partner.	Number of wireless types (corporate, guest, IoT, contractor), whether usage and connection requirements already exist in the access control policy, and how many SSIDs must be defined.	Named deliverables such as the wireless usage standard, configuration baseline, connection requirements per type, and a fixed scope with a written acceptance step.
Device imaging and MDM work to disable unneeded radios	One-time per device image or profile, then recurring for new hardware. Paid to internal IT or a partner, plus MDM licensing if used.	Number of issued device models and images, whether Bluetooth, Wi-Fi ad hoc and other radios can be disabled centrally, and how many devices are already enrolled.	Confirmation that radios are disabled before issuance, the imaging or enrollment steps, and how exceptions are documented and approved.
Evidence upkeep and periodic reviews	Recurring. Paid to internal compliance or security staff, or to a retainer partner who collects logs and configuration exports.	Frequency of access point and authorization list reviews, number of wireless segments, and how much evidence is produced automatically by logs and configuration management.	Review frequency, evidence list (configuration exports, authorization records, review sign-offs), and who owns each recurring task.
External testing such as wireless assessments	Recurring or periodic, paid to an independent tester. DeployOpen performs security testing but does not issue assessment reports.	Physical footprint, number of sites, whether rogue access point and wireless intrusion testing is in scope, and the depth of testing requested.	Written test scope by site and wireless type, methods, rules of engagement, deliverable format, and how retest findings are priced.
Auditor or assessor sampling	Recurring at each assessment cycle, paid to the independent assessor or certification body.	Number of wireless configurations and authorization records sampled, and whether evidence is consistent across sites and device types.	The assessor's sampling approach in writing, the evidence they expect for 03.01.16, and whether re-sampling is included if evidence is incomplete.
Boundary monitoring and logging tools	Recurring infrastructure cost for hosting and storage. Open-source tools such as Suricata, Zeek and OPNsense remove license spend for these functions, though staffing and storage remain.	Traffic volume at the wireless boundary, log retention period, and whether logs are forwarded to an existing log management tool.	Hosting and storage estimates from your own environment, retention requirements, and confirmation of which logs your assessor will request for wireless access.

Which open-source tools produce boundary and monitoring evidence for wireless access

These three tools generate boundary and monitoring evidence for the network that carries wireless traffic. They do not configure wireless radios, authenticate users or authorize devices, which remain with the wireless controller and access points. Confirm those functions with the wireless vendor, and confirm each license in your own review before deployment.

OPNsense firewall rules

OPNsense is a stateful packet filter licensed under BSD-2-Clause. Its rules pass, block or reject traffic by source, destination, port and protocol, so you can show that wireless clients reach only the segments their role allows. Use aliases to group address ranges, such as the wireless client subnet and the CUI enclave, so an assessor can read the rule set without reconstructing it. Enable logging on the rules that matter, review the live log view, and retain those records under your own policy. Confirm with the wireless vendor which isolation features the controller provides and how they match these rules.

Suricata EVE JSON alerts

Suricata is an intrusion detection engine licensed under GPL-2.0-only. Its EVE JSON output writes records for rule alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, along with file information and engine statistics. The output can be split into separate files, so alerts from wireless-facing sensors can move into the log management tool your team reviews. Check that the sensor can see traffic from the wireless segment, which may require a span port or tap on the relevant uplink. Confirm the license terms in your own review before distribution.

Zeek connection logs

Zeek is a passive network monitor licensed under BSD-3-Clause. Its conn.log records who talked to whom, for how long, how much data moved and over which protocol for TCP and UDP traffic. Protocol logs such as dns.log and http.log, along with weird.log for anomalous events, share a unique connection identifier, so an assessor can trace one wireless session from the connection record to its protocol detail. Zeek records activity but does not block it. Plan storage for these logs, since Zeek writes dozens of logs by default, and confirm with your reviewers what they must keep and for how long.

Who owns wireless access controls, what partners prepare and what the auditor tests

Your organization owns the wireless access control requirement. Under 03.01.16, the decisions that make wireless access acceptable are management decisions: which wireless access types are permitted, what each type must be configured to do, who may authorize a connection, and which authentication and encryption methods are acceptable. These decisions belong in the access control policy and the system security plan, and your leadership, not a contractor, must sign off on them. A partner can draft the material, but the people accountable for CUI must adopt it and keep it current.

Approve wireless types and rules: Decide which wireless access types are allowed, and document the usage restrictions and configuration and connection requirements for each.
Authorize connections: Name the role that authorizes each wireless type before any device connects, and keep a record of those authorizations.
Sign the system security plan: Confirm that the wireless description in the plan matches the real environment and the stated requirements.
Keep the policy current: Review the access control policy and procedures on a schedule you set, and update them when wireless hardware or standards change.
Own the operating evidence: Keep the authorization records, configuration exports and review notes that show the controls run day to day.

Check that a named internal owner can answer for every wireless decision without referring to the partner.

Common questions about meeting wireless access requirements

Does guest Wi-Fi on the same premises fall under 03.01.16?

It can, if the guest network is connected to the system that stores, processes or transmits CUI, or if it shares infrastructure, switches or a network path with that system. Requirement 03.01.16 covers wireless access to the system, so the question is whether the guest network reaches the CUI environment and how the organization defines its system boundary. Most teams answer this with segmentation: the guest network is isolated from the CUI enclave at the boundary, and the boundary rules are documented and tested. Confirm the boundary with your assessor before you rely on it, because the scoping decision is yours to document in the system security plan.

Can an organization meet 03.01.16 without outside help?

Yes, an organization can implement and document 03.01.16 with its own staff, provided it has people who can configure wireless controllers or access points, define usage and connection requirements, and produce evidence for each assessment method. The requirement asks for usage restrictions, authorization before any wireless connection, disabling wireless capabilities that are not intended for use before devices are issued, and authentication and encryption for wireless access. Teams that lack wireless engineering or documentation experience often bring in an implementation partner to prepare configurations and evidence. Ownership stays with the organization in either case, and only an independent assessor can issue a finding on compliance.

How long does wireless access work take, and what drives the timeline?

No duration is fixed for this work, so ask for one in a written scope rather than relying on a general estimate. The main drivers are the number of wireless networks and access point types in the environment, whether controllers are centrally managed, how many device types connect, and whether the organization already has an authorization process for wireless connections. Documentation usually takes longer than configuration: the usage restrictions, connection requirements and configuration management records must match what is actually deployed. Environments with many legacy networks or several sites generally need more time for validation and testing.

What does the work need from the client's own staff?

The work needs staff who own the wireless infrastructure, the identity system used for wireless authentication, and the configuration management process. Network engineers provide access to controllers and access points, and they confirm which wireless capabilities the business actually uses. Identity administrators supply the authentication method and certificate or account processes. Security staff review the usage restrictions and approve the authorization workflow, and they receive the evidence the assessor will request. Plan for these people to be available during discovery, configuration changes and the evidence review, since the examine, interview and test methods all depend on them.

Can a partner certify that our wireless access meets 03.01.16?

No. A partner can prepare configurations, documentation and evidence, but only an independent assessor, certification body or the government customer's review process issues assessment results or certifications. For CMMC, the assessment is conducted by an authorized third-party assessor for Level 2 or by the government for other levels, and the organization's own staff and any consultant cannot issue that result. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Ask any partner to state this boundary in its written scope.

Does choosing Rev. 2 or Rev. 3 change the wireless access work?

The core technical work is largely the same, but the requirement text and assessment depth differ. NIST's change analysis traces 03.01.16 to Rev. 2 requirement 3.1.16 and classifies the change as significant, with more detail and foundational tasks. Rev. 3 also withdrew 03.01.17, which covered a separate wireless requirement in Rev. 2, and folded it into 03.01.16. Which version applies depends on your contract. DoD contractors are currently assessed against the 110 Rev. 2 requirements under CMMC Level 2, so confirm the version named in your contract and any pending DFARS or FAR change before you finalize your documentation.

Are plan of action and milestones items allowed for 03.01.16 under CMMC?

No. Under 32 CFR 170.21, a requirement can be placed on a plan of action and milestones only in limited cases, and 3.1.16 (AC.L2-3.1.16) is not eligible for a POA&M when an organization seeks Conditional status. The requirement carries 5 points under the 32 CFR 170.24 scoring methodology, so it must be fully implemented before assessment. Plan wireless work early, because an incomplete wireless control can block an otherwise favorable result. Confirm current CMMC eligibility rules with your assessor and the eCFR text, since program timing may change.

How should we scope a quote for wireless access work?

Ask for a written scope that lists each wireless network, its purpose, its connection to the CUI system, and each access point or controller type in use. The quote should state which authentication and encryption methods will be implemented, how authorization before connection will work, and how wireless capabilities will be disabled on devices before issuance. Ask for the deliverables: configuration baselines, usage restriction documentation, a test plan mapped to the examine, interview and test methods, and the evidence package. Also ask what is excluded, such as hardware replacement, ongoing monitoring, and assessor fees, so that the quote can be compared fairly with other proposals.

How DeployOpen scopes and prepares wireless access evidence

DeployOpen works on 03.01.16 Wireless access as a fixed-scope engagement inside the client's own infrastructure. We prepare the wireless configuration, connection rules and evidence that an independent assessor reviews, while the organization keeps ownership of its controls and the assessment outcome.

How we scope

Inventory every wireless access type in the system boundary, including corporate, guest, maintenance and device-specific connections.
Agree in writing which wireless components, controllers and access points are in scope for 03.01.16 Wireless access.
Confirm with the client which organization-defined parameters and authorization roles apply, since NIST does not assign those values.

How we build

Configure wireless usage and connection requirements for each access type, and document the authorization step before any device connects.
Disable wireless networking capabilities not intended for use on devices before they are issued and deployed.
Set authentication and encryption for wireless access, and record the configuration in the configuration management plan.

How we hand over

Deliver the wireless access policy, procedures and configuration records mapped to the eight determination statements in SP 800-171A Rev. 3.
Provide test evidence showing the wireless access management capability and protections work as documented.
Brief the personnel who manage wireless connections so they can answer an assessor's interview questions accurately.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review wireless configuration changes against the documented requirements when access points or controllers are upgraded.
Confirm with your assessor and your sponsoring agency which evidence format and review cycle they expect before work starts.

03.01.16 Wireless access