11.2 Wireless access point detection: requirements and evidence

What PCI DSS 11.2 asks for and why an assessor checks it

Requirement 11.2.1 asks you to test for wireless access points at least once every three months, detect and identify every authorized and unauthorized access point, and alert personnel if the detection is automated. Requirement 11.2.2 asks you to keep an inventory of authorized wireless access points, with a documented business justification for each. When an assessor requests wireless evidence, they want two things: proof that scans ran on schedule and actually looked for rogue devices, and a list of approved access points that someone can explain. If your team cannot produce both, the answer to the assessor is usually a gap, even when no wireless network is in use. The risk behind the requirement is simple. A rogue access point plugged into a switch port, or a device that an employee sets up in a back office, can bridge a wired network into the cardholder data environment without passing through the firewall. The SAQ D note to Requirement 11.2.1 states that the requirement applies even where policy prohibits wireless technology. That means a written "no wireless" rule does not remove the obligation. You still need to run the test and show that the result was checked. Confirm with your assessor or acquirer whether any wireless detection expectations differ for your validation type before you rely on that reading.

Teams struggle for three predictable reasons. First, devices are undocumented: guest networks, mobile hotspots, handheld scanners and vendor equipment appear on sites without a record. Second, nobody owns the inventory, so the list goes stale after the first site visit. Third, scans happen but leave no record, such as a walkthrough that no one wrote down or an alert that was never reviewed. A useful first step is to ask who owns the authorized access point list, when it was last reconciled against a detection result, and where the scan reports are stored. The inventory in the CMDB or asset register is a natural home for this evidence, and a clear owner, a quarterly calendar entry and a retained scan report usually resolve most of the questions an assessor asks.

Which wireless environments and teams fall under 11.2

Requirement 11.2 applies to every wireless environment that can reach the cardholder data environment, wherever it sits and whoever runs it. The cards below cover the scoping decisions that change the work and the teams that must agree on them before the first test is scheduled.

Access points inside or connected to the CDE

Any wireless access point installed in the cardholder data environment, or wired to a network segment that reaches it, is in scope without debate. Confirm this against the CDE boundary and data-flow diagrams, not against the floor plan. An access point on a switch port in a shared data center rack can be in scope even if nobody thinks of it as Wi-Fi. Record each one with its network segment so the test covers it and the inventory under 11.2.2 can show why it exists.

Wireless at sites that handle cardholder data

A store, branch or call center that processes card data is in scope as a location even when its Wi-Fi never touches the payment network. The 11.2.1 test must still detect rogue devices in that room, because an attacker placed nearby can target the payment side. Ask operations teams for a list of every site that accepts card payments, and check each one against the scope document rather than assuming only headquarters matters.

Guest and corporate Wi-Fi on the same premises

Guest networks and staff Wi-Fi sharing a building with payment equipment are the most common source of scope disputes. If they share radio spectrum or a controller with payment devices, assessors will ask how the separation was verified. Document the segmentation decision, the controller configuration and the evidence that guest traffic cannot reach the CDE. Where the separation depends on a firewall rule, note the rule and the test that confirms it.

Wireless payment terminals and peripherals

Wireless payment terminals, handheld readers and cordless peripherals connect to the payment environment and must be included in the wireless inventory and scans. Confirm which devices use Bluetooth, Wi-Fi or cellular links and whether each one attaches to a base station that is itself an access point. Terminals often arrive from a vendor with their own management portal, so ask who holds the device list and whether it matches what the test finds on the floor.

Third-party managed wireless

When a managed service provider, landlord or mall operator runs the access points, the organization still needs evidence that 11.2.1 testing covers them. Put the testing responsibility, the inventory feed and the reporting path in a written agreement, and ask the provider for the access point list and the last test output. If the provider runs its own detection, confirm which alerts reach your security team and who acts on them.

Teams that must agree on scope

Network engineering owns the access point configuration and controller data. Facilities or property teams know which rooms, shared spaces and tenant areas share the building. Store or branch operations manage devices on the floor and the staff who bring in personal hardware. Security owns the test, the alert path and the sign-off. Scope follows the CDE documented elsewhere in your assessment, so agree the wireless boundary with these four teams before any scan begins.

How an assessor tests 11.2 wireless detection

This table sets out what an assessor checks for Requirements 11.2.1 and 11.2.2, the evidence each check relies on, and the findings that most often delay a validation. Read it as a preparation checklist: each row is a test step, so the evidence in the right column is what should already exist before the assessor arrives. Gaps in dates, alert records or inventory justifications are the usual reasons these checks fail.

Assessor test	What the assessor examines	Evidence requested	Common finding
Detection method and frequency	Whether the scan or automated monitoring runs at least once every three months and covers the whole in-scope environment	Scan or monitoring configuration, schedule, and scan reports for the last 12 months	Quarterly records missing for one or more periods
Test record dates and coverage	Each dated test record, which locations and networks it covers, and whether any in-scope area is excluded	Dated scan results, site or network lists, and tool logs showing completion	Scans cover the office network but not warehouses or remote sites
Rogue device detection	Whether unauthorized access points are identified, located and reported when found	Detection reports listing any unauthorized devices and their remediation records	Reports show detections with no documented removal or follow-up
Alert handling	Whether personnel receive alerts when automated monitoring finds a device, and how quickly they act	Alert configuration, notification records, and a sample of alert tickets with responder and outcome	No evidence that alerts were answered or who received them
Inventory comparison	Whether scan results match the inventory of authorized access points, with each device accounted for	Current inventory and a side-by-side comparison against the most recent scan results	Access points seen in scans are absent from the inventory
Business justification	Whether each authorized access point has a documented business reason and an owner	Inventory entries with justification text, approval records and dates of last review	Inventories list devices without justifications
Policy versus practice	Whether the entity prohibits wireless technology in policy yet still runs the 11.2.1 testing	Policy statement, and testing records showing the scan or monitoring continues regardless	Policy says wireless is prohibited, so no testing is recorded

Implementing 11.2 in six steps

This sequence turns Requirement 11.2 from a policy statement into a repeatable quarterly routine: a defined wireless scope, an authorized inventory, a detection method, alert routing, a recorded baseline test, and documented reconciliation of every unexpected device. Each step ends with an artifact an assessor can read.

Define the wireless testing scope against the CDE
Start by mapping where wireless technology exists within or near the cardholder data environment (CDE). Include corporate Wi-Fi, guest networks, payment terminals with wireless links, handheld devices, and any building or site area where a rogue access point could reach CDE systems. Network and security staff own this step, and the output is a scope statement that names the physical locations and network segments covered. Confirm the scope with your QSA or internal assessor before testing begins, because the SAQ D note to 11.2.1 makes clear the requirement applies even where policy prohibits wireless technology, so a 'no wireless' policy does not remove the scope. The step is done when every location and segment has a named owner and the scope statement is signed off.
Build the authorized access point inventory
Create the inventory that Requirement 11.2.2 expects: every authorized wireless access point, with its identifier (such as MAC address, SSID, location and asset tag), a named owner, and a documented business justification explaining why it exists. Pull the initial list from wireless controller exports, network device records and procurement history, then have each owner confirm entries. Many organizations keep this in an IT asset management system such as GLPI, where the Assets module can record network equipment entered manually or pushed by the GLPI Agent. Whatever tool you use, the output is a versioned inventory with an approval record, and the step is done when no access point in scope lacks an owner or justification.
Choose the detection method
Decide how you will detect access points: periodic wireless scanning with a tool that surveys the scoped locations, automated wireless monitoring that runs continuously, or both. Requirement 11.2.1 accepts either approach, but automated monitoring triggers an additional duty to alert personnel. Compare options on coverage of your physical sites, ability to identify both authorized and unauthorized devices, and whether results can be exported as evidence. Ask any vendor or implementation partner to demonstrate detection against your own inventory rather than a generic lab. The output is a short method decision record naming the tool, the sites it covers, and the reasons for the choice. Confirm each product's exact capabilities with its vendor before you rely on them.
Set the quarterly schedule and alert routing
Requirement 11.2.1 requires testing at least once every three months, so set a recurring calendar with named owners for each scan or monitoring review and a backup owner for absences. If automated monitoring is used, configure alerts so that detected unauthorized access points reach a named security or operations queue and an on-call person, with a record of who received them. Document the escalation path for an alert that appears outside business hours. The output is a schedule, an alert routing configuration, and a written escalation procedure. The step is complete when a test alert has been sent and acknowledged through the routing you described.
Run and record the first test
Run the first full wireless test across the scoped locations, using the detection method you selected. Record the date, the operator, the tool and its version, the locations surveyed, and the complete list of detected access points with their identifiers, signal details and classification (authorized, unauthorized or unknown). Keep the raw output alongside the summary so an assessor can trace findings back to source data. This first run establishes the baseline against which later quarters are compared. The step is done when the raw output, summary report and classification list are stored together in the evidence repository with restricted access.
Reconcile results and document each unexpected device
Compare every detected access point against the authorized inventory. Any device that does not match an approved entry must receive a documented response: confirm whether it is an authorized device missing from the inventory, a personal or guest device, a third-party installation, or a rogue device requiring removal and investigation. Record the decision, the person who made it, the date and the action taken, and update the inventory or the incident record accordingly. Rogue devices connected to the CDE should also be handled through your incident response process. Repeat this reconciliation every quarter. The step is complete when every unexpected device has a closed record and the inventory matches the latest test results, which is what an assessor will sample first.

How detection and the inventory prove each other

Requirement 11.2.1 and 11.2.2 should be evidenced together, because each one only means something against the other. A detection result that lists unknown access points is useful only if the team has a current, justified inventory to compare it against. Likewise, an authorized access point list is only credible if a test would have caught a device that was missing from it. An assessor who sees a clean scan report and a spreadsheet with no dates will ask how the two were reconciled. Plan one review cycle that produces both artifacts, and keep the scan output, the alert handling record and the inventory version that was current at the time of each scan.

Network-side tooling can support the reconciliation without replacing air-space testing. OPNsense runs Suricata in its intrusion detection and prevention system, and Suricata can write EVE JSON records for alerts and protocol transactions to syslog or to separate log files. Those records show what traffic crossed the monitored segments, which helps confirm that unexpected devices are appearing on wired networks. On the inventory side, GLPI's Assets module and the Wazuh Syscollector module can record hardware, network interfaces and installed software for managed endpoints, and that data can be exported or reviewed as the basis for the authorized device list. Confirm with your own team which devices these sources actually see, because a device that never touches the monitored network or the managed inventory will not appear in either.

Wireless scanning of the air space is a separate activity. Neither Suricata nor the inventory agents listen for radio signals, so they cannot tell you whether a rogue access point is broadcasting in a warehouse or a store back room. Decide early whether the environment has a wireless detection capability, such as a dedicated scanner, a wireless controller with rogue detection, or a sensor that the team already operates, and confirm what that capability can see before you rely on it for the 11.2.1 evidence. If it cannot be confirmed, document that gap and the compensating method in the policy, so the assessor sees a deliberate decision rather than an assumption.

Evidence that passes 11.2 and how to keep it current

An assessor testing 11.2 wants to see that the wireless inventory is accurate, that scans or monitoring ran in every three-month window, and that every unexpected device was investigated and closed. The cards below cover the records that prove each of those points and the routine that keeps them current between assessments.

Authorized wireless access point inventory

This is the baseline the assessor compares every scan against. Each entry should record the access point identifier, location, network segment, the named owner, the documented business justification, and the date it was last reviewed. Review the inventory at the start of each quarter and confirm that every access point on the floor still has a current entry. Remove entries for retired hardware so the list stays a true record of what is authorized today. Confirm with your assessor whether they expect the inventory in a specific format.

Dated quarterly detection reports

Each three-month window needs its own dated record showing that wireless detection ran and what it found. The report should name the method (scheduled scan, dedicated sensor, or wireless intrusion monitoring), the scope and locations covered, the date and time range, and the operator. Keep one report per quarter, even when the result is clean, because a missing quarter is the most common gap assessors find. Store the reports where they can be produced without a search.

Alert logs with response tickets

Where automated monitoring is used, 11.2.1 expects alerts to reach personnel when an unauthorized access point appears. Keep the raw alert record with its timestamp, the detected identifier and signal details, and the recipient. Link each alert to the ticket that shows who triaged it, what was decided, and when the device was contained. An alert without a closed ticket shows that detection worked but response did not, so check the open queue before each quarterly review.

Rogue device removal and authorization records

For every unauthorized device found, the file should show one of two outcomes: the device was removed and the removal verified, or it was added to the inventory with an owner and justification approved under your change process. Record who made the decision and the date. Wireless detection is only useful when findings lead to a documented outcome, so review these records against the open tickets each quarter.

Documented scanning procedure

The procedure explains how detection is performed, who runs it, which tools and sensors are used, how alerts are routed, and how findings move to tickets. It also states the three-month frequency and what happens when a test is missed. Version the document, record approval, and review it at least once a year or when sensors, locations, or staffing change. Ask your assessor whether they will accept a procedure that points to a separate runbook.

Quarterly calendar tied to evidence

Build a calendar with one entry per quarter for each artifact: inventory review, detection run, alert triage check, rogue device closure, and procedure review. Assign an owner to each entry and set a reminder before its due date. At the end of each quarter, file the evidence under the quarter it covers. This routine keeps the evidence current without a scramble before the assessment.

What meeting 11.2 costs in money and effort

This table breaks down the cost and effort components of meeting Requirement 11.2, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a request for a written quote, since no price or duration for these components has been published here. The main takeaway is that open-source tools remove license spend but not the engineering and evidence work.

Cost component	Who is paid or who does the work	One-time or recurring	What drives the cost
Wireless scanning tool or managed service	Tool licence or subscription to a vendor, or a service provider's fee; open-source tools carry no licence fee	Setup is one-time; licence or service fees recur	Number of sites, number of access points, and whether scans are run in-house or outsourced
Initial inventory of authorized access points	Internal network staff or implementation partner, with business justification sign-off from the business owner	One-time, then recurring updates	Number of access points, age of records, and how many locations lack a current asset register
Quarterly test execution	Internal staff or a contracted tester running the scan and recording results	Recurring, at least every three months	Number of sites, scan scope, whether rogue device searches are manual or automated
Alert triage and rogue device response	Security operations staff investigating alerts and removing or authorizing devices	Recurring	Alert volume, false positive rate, and whether automated monitoring alerts personnel directly
Self-hosted open-source platform engineering	Engineering time for deployment, integration with the asset inventory, and alert routing, often through an implementation partner	One-time build, then recurring maintenance and upgrades	Number of integrations, log retention design, and in-house skills available
Evidence upkeep	Compliance or security staff keeping scan reports, inventories and justifications current for assessment	Recurring	Frequency of network changes, number of sites, and how well the inventory is tied to the scan output
Assessor time for sampling	Qualified Security Assessor or internal assessor reviewing records and sampling test results	Recurring at each assessment cycle	Number of sites sampled, quality of records, and how many exceptions must be explained
Written quote	Request from each provider and assessor, tied to a defined scope of sites and access points	Obtain before work starts	Ask each party to state assumptions about sites, device counts, alert volume and included evidence

Open-source tools that support 11.2 evidence

None of the tools below scans radio airspace by itself, so the 11.2 evidence depends on pairing wireless detection with the records these platforms produce. Together they help show what the network looks like, which devices were seen, and who approved each authorized access point.

OPNsense intrusion detection output

OPNsense includes a built-in intrusion detection and prevention system that runs Suricata with rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic and send alerts to syslog in EVE JSON format. Its wired-side alerts help show monitoring of network boundaries, but it does not perform wireless air-space detection unless your environment confirms a wireless sensor or controller feeds it. Confirm that with the vendor and your own design before citing it for 11.2.1.

Suricata EVE log retention

Suricata's EVE output writes JSON records for alerts, anomalies, flows, protocol transactions, file information, dropped packets and engine statistics. You can split these into separate files so a log management tool can ingest them. For 11.2, the useful evidence is a dated record of monitoring activity and alerts generated over the review period. Check that the files are protected, retained long enough for your assessor's sampling, and that alert routing reaches personnel who act on them.

GLPI network equipment inventory

GLPI's Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in manually or pushed by the GLPI Agent through native inventory available since GLPI 10. For 11.2.2, this inventory is the natural home for the authorized access point list, with fields for location, owner and the documented business justification. Ask whether your team will record the justification in GLPI or in a linked document, and confirm that each access point entry is reviewed against detection results.

Wazuh network interface inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, services and users from each endpoint, then stores the results in the Wazuh indexer for dashboard views and reports. Wireless adapters on managed endpoints appear in this inventory, which helps reveal unexpected wireless interfaces on in-scope systems. This does not replace air-space scanning of the environment. Confirm which endpoints run the agent, how often inventory refreshes, and how changes are reported.

Reconciling inventory with detection

The evidence that satisfies 11.2 is the comparison between what detection finds and what the inventory says should be there. Illustratively, a scan that reports an unknown access point with no matching GLPI record should produce a ticket, an investigation and a closed record showing the outcome. Assign a named owner for this reconciliation, keep the timestamps, and make sure the three-month testing cadence is visible in your records. Ask your assessor which format they expect for this comparison before you build it.

Who does what for wireless detection

Your organization owns Requirement 11.2. That means the wireless testing is performed or received on schedule, the authorized access point inventory is accurate, and someone acts when a rogue device is found. The requirement applies to you even if your written policy prohibits wireless technology, so the ownership question is not whether wireless exists in your environment but who checks for it and who answers when something appears.

Owning the inventory: Name an owner for the list of authorized access points, the business justification recorded for each device, and the review process that removes retired hardware.
Running or receiving tests: Decide whether internal staff run the scans, a managed provider runs them, or both. Keep the test records, including dates, scope and results.
Answering alerts: Define who receives alerts from automated monitoring, the response time you commit to internally, and how unauthorized devices are investigated and removed.
Keeping the calendar: Confirm that the testing runs at least once every three months and that gaps are caught before the assessor finds them.

Before your next assessment, confirm that each access point on the inventory has a named owner and a documented justification you could explain to an assessor today.

Where 11.2 usually fails and how to close each gap

Most 11.2 findings are not about missing scanners. They come from testing that happens once, alerts that nobody owns, inventories without reasons, policies nobody checks, and networks that sit outside the scan. Each card below names one gap and the action that closes it.

Testing once or without a dated record

A wireless scan run during the annual assessment does not satisfy 11.2.1, which requires testing at least once every three months. Assessors look for a dated record of each run, the scope covered, and who reviewed the results. Set a recurring schedule in your ticketing or calendar system, and keep each run's output with its date and tester. Confirm the schedule with your QSA before fieldwork, since the exact evidence format is set by your assessor and the requirement text.

Alerts with no owner

If automated wireless monitoring is used, 11.2.1 expects alerts to reach personnel. A sensor that logs rogue access points to a console nobody watches is a gap. Route wireless alerts into the same queue your security team uses for other incidents, name a primary and backup responder, and record how each unauthorized device was handled. Test the path by introducing a known test device and confirming that a ticket is opened and closed.

Inventory without business justification

Requirement 11.2.2 asks for an inventory of authorized wireless access points, and the inventory must include a documented business justification for each device. A list of MAC addresses and locations does not meet that test. Record the owner, the purpose, the network segment and the approval for each access point. In GLPI, the Assets module can hold network equipment records, and the justification can sit in a custom field or linked document. Confirm the field design with your assessor.

Wireless ban with no check

Many organizations state in policy that wireless is prohibited. The SAQ D note to 11.2.1 is explicit that the requirement still applies in that case. A policy statement is not evidence that no access point exists. Run the same detection testing in environments that have no approved wireless, and treat any finding as a rogue device to investigate. Document the result as you would for an environment that does use wireless.

Guest and branch networks outside the scan

Teams often scope wireless testing to the main office and forget guest networks, branch sites, warehouses and temporary event setups that touch the cardholder data environment or could connect to it. Build a list of every physical location with wireless equipment, including contractor-owned devices, and confirm each is inside the detection scope or documented as out of scope with a rationale your assessor accepts. Review that list whenever a site opens, closes or changes its network.

Questions buyers ask about 11.2 cost, effort and outside help

How much effort does requirement 11.2 take for a single-site merchant compared with a multi-site operator?

For a single site, the effort is usually a short recurring test, a current inventory of a few access points and a documented alert path, because there are fewer devices and locations to cover. For a multi-site operator, the work scales with the number of locations, the number of access points per site, and how many people must review alerts and update the inventory. Multi-site operators also need a consistent procedure so every site is tested on the same schedule. The cost drivers are site count, device count, whether monitoring is automated, and how many staff must respond to alerts. Ask any provider to quote the effort against your written site list and device counts.

Can we maintain the wireless access point inventory in-house?

Yes, in most environments a retailer or payment operator can keep the inventory in-house, provided someone owns it and updates it when devices change. The inventory must list authorized access points with a documented business justification, so the owner must record why each device exists and who approved it. Asset tools such as GLPI can hold network equipment records, and Wazuh's Syscollector can report network interfaces on endpoints, but neither replaces the justification record, which is a human decision. Confirm with your QSA which records they expect to see and how often they will ask for updates.

What can an implementation partner take on without affecting assessor independence?

An implementation partner can prepare the systems and records that 11.2 depends on, such as deploying detection tooling, configuring alert routing, building the inventory template, and documenting the test procedure. The organization still owns the control, the staff who run it and the decisions about authorized devices. The partner must not perform the assessment or write the conclusions a QSA will report. Only the QSA issues the Report on Compliance, and the organization must not let the partner's readiness work replace the assessor's independent testing. Agree these boundaries in writing before work starts.

Does PCI DSS require a specific wireless scanner for 11.2?

The researched facts do not name a required scanner or product for 11.2. The requirement describes what the testing must achieve: detect and identify authorized and unauthorized access points at least once every three months, and alert personnel when automated monitoring is used. Whether a particular tool, a manual walk-through or a wireless intrusion detection feature meets that outcome depends on your environment and on the assessor's review. Ask your QSA which methods they will accept and what evidence they expect from each method before you buy or deploy anything.

What does our team need to supply to an implementation partner?

Most partners will need a current list of locations, the wireless networks in use, the access point models and locations if known, the existing network diagrams, and the names of the people who will own alerts and the inventory. You should also supply your current policy on wireless technology, because the requirement applies even where policy prohibits it, and any records of past wireless testing. Include the cardholder data environment boundaries so the test covers the right locations. Ask the partner to list these inputs in the written scope so gaps are visible before work starts.

How long does preparation take for 11.2?

The preparation time depends on the scope, and the figure should come from the written scope rather than a general estimate. The main variables are the number of sites, how many access points each site has, whether automated detection already exists, and how much inventory and justification records must be created from scratch. Ask any provider to break the timeline into discovery, tooling, inventory, procedure and handover, with a named owner and dependency for each step. Confirm the timing with your QSA so that the evidence period you plan for matches what they will test.

How DeployOpen prepares wireless detection evidence

DeployOpen plans, implements and documents the detection and inventory side of Requirement 11.2 inside your own infrastructure. That means deploying self-hosted open-source tools in your cloud accounts, data center or air-gapped network, configuring them to match your wireless architecture, and writing down how the results are produced, reviewed and retained. Where you want an outside party to test the environment, DeployOpen can run wireless security testing on request. The organization still owns the control: you decide which access points are authorized, who receives alerts, and how a rogue device is investigated. DeployOpen does not issue reports, attestations or certifications. Only your independent assessor, typically a QSA for a ROC or an assessor completing the relevant SAQ, can conclude that the requirement is met.

Engagements are fixed-scope. Before work starts, the written scope names the sites, wireless networks, controllers and tools covered, along with the deliverables, such as the authorized access point inventory template, the scan and alert configuration record, the alert routing runbook, and the sample evidence set your assessor will ask for. Confirm with your assessor which artifacts they expect, because the exact format of the inventory, the business justification fields and the proof of each quarterly test should match their testing procedure. Ask DeployOpen to state in the scope which of these items it prepares and which remain with your team, so no evidence gap is left unowned.

Because Requirement 11.2 repeats every three months, one-time setup is only part of the effort. Ongoing testing, inventory maintenance and alert review are available as a retainer, which keeps the quarterly cycle and its records current between assessments. Ask for the retainer terms in writing, including who reviews each quarterly result, how new access points are added to the inventory with a justification, and what happens when a scan finds an unknown device. Those terms, not a general promise of support, are what your assessor will check against the evidence.