Implement appropriate vulnerability scanning methods

Suppose a new advisory names a flaw in one version of a database engine, and this week's scan report lists no affected host. Before trusting that silence, check the report’s scope and scan status against inventory to answer three questions: was every host running that engine on the target list, could the scanner see installed software versions, and did it reach the network segment where the databases live? A vulnerability scanning method is the set of answers to those questions, chosen deliberately for the evidence a scenario needs. CompTIA's CySA+ V4 exam objectives summary lists "Implement the appropriate vulnerability scanning method", "Analyze output from vulnerability assessment tools" and "Prioritize and mitigate vulnerabilities" as separate objectives under Vulnerability Management (26%) (CompTIA: CySA+ V4 exam objectives summary^[1]); for the second and third, see Analyze vulnerability assessment output and Prioritize and mitigate vulnerabilities.

Three decisions used in this guide

1. The target list. Which assets the scan covers, built from an asset inventory and checked against discovery scans (scans that find which devices are actually present on a network).
2. The method. How the scanner sees each target, described by the four scan dimensions: viewpoint (internal or external), access (credentialed or non-credentialed), deployment (agent-based or agentless) and interaction (active or passive). A scan can also have a purpose other than finding known vulnerabilities: discovery, or security baseline scanning, which compares a system's settings with an approved standard.
3. The plan. The constraints that fit the method to the environment: authorization, scheduling, operations, performance, sensitivity levels, segmentation and regulatory requirements. NIST's testing guide calls the document that records them an assessment plan and says every assessment should have one, whatever its scope or intrusiveness (NIST SP 800-115, section 6.5^[2]).

The question a scenario asks picks the method; the plan then fits that method to the environment, and it can send you back to change the method, for example when a segment's fragile equipment rules out probes. The figure below traces that loop and the last step: running the scan and recording the viewpoint and access it used, because a result means something only alongside the position and access that produced it.

The takeaway: a scan result is evidence about the targets it listed, from the viewpoint it used, with the access it had, and about nothing else.

An asset inventory defines intended coverage, while discovery, reachability and scanner settings determine which assets a scan actually assesses. NIST's patch management guide recommends that organizations "establish and constantly maintain up-to-date software inventories" for their physical and virtual computing assets, including operational technology (OT), Internet of Things (IoT) and container assets (NIST SP 800-40 Rev. 4, section 3.2^[3]).

What each inventory record needs

• Software detail, not just addresses. Record installed operating systems, applications, firmware and relevant package or library versions. CISA's vulnerability management guide lists model numbers for hardware, version numbers for software and the location of each component as the information needed to match vulnerability information to technology assets (CISA CRR Resource Guide, Vol. 4: Vulnerability Management^[4]). With that detail an analyst can match a new advisory to the hosts that run the affected component, instead of assuming every device of the same general type is vulnerable; a list of IP addresses cannot do that.
• Who administers the asset. SP 800-40 Rev. 4 lists the party who administers each asset (IT department, third party, end user, vendor or manufacturer, or a shared responsibility model) and contractual restrictions on patching, such as an asset that only its manufacturer may patch after testing and certification. That record identifies whom to consult about scanning and remediation: vendor-managed equipment may need a different assessment or patching arrangement from servers the internal IT team runs, and pushing it into internal patch automation ignores those restrictions.
• Platform type and management path. The same guide lists the asset's platform type (IT, OT, IoT, mobile, cloud, virtual machine) and the tools used to manage it, which tells you how the asset can be assessed.

Keeping a dynamic inventory current

SP 800-40 Rev. 4 notes that refreshing inventories monthly or quarterly by running a vulnerability scan was once acceptable, when assets were mostly static, and states that this model "should no longer be used". Cloud resources, virtual machines and containers can be created and removed between two scheduled scans, so the last periodic network scan is not a cloud inventory. The guide recommends combining automation techniques, including the inventory capabilities built into platforms (for example a cloud platform's APIs), with vulnerability scans and passive network monitoring, which still help with asset discovery. A vulnerability scan used for software inventory needs credentialed access to the assets (the scanner logs in to each host; NIST calls this authenticated scanning, and Credentialed vs non-credentialed scans below explains it).

Discovery results feed back into the inventory in both directions; Discovery: mapping scans and device fingerprinting below describes that reconciliation.

The takeaway: an inventory that records software versions, owners and short-lived cloud assets helps define intended coverage; reconcile it with discovery, reachability and scan results before calling coverage complete.

Scan types come in named pairs that describe different aspects of an assessment, rather than rival products. Describe an assessment with these four distinctions, noting any that do not apply:

• Viewpoint (internal or external): where the scanner sits relative to the filtering boundaries between it and its targets.
• Access (credentialed or non-credentialed): whether the scanner logs in to the host.
• Deployment (agent-based or agentless): whether an assessment component runs on the host itself.
• Interaction (active or passive): whether the scan sends traffic to the target at all.

Not every distinction applies to every assessment: passive monitoring, for example, records hosts and traffic "without sending out a single probing packet" (NIST SP 800-115, section 4.1^[2]), so it never logs in to a host and the credentialed or non-credentialed choice adds nothing about it. One compatible combination is a scanner on the internal network that logs in to each server remotely and sends probes: an internal, credentialed, agentless, active scan. A scenario may constrain the method (no software may be installed on this appliance; nothing may probe this controller) and leave other choices to the question being asked.

NIST SP 800-40 Rev. 4 contrasts "passive (unauthenticated)" with "active (authenticated)" vulnerability scans (NIST SP 800-40 Rev. 4, section 3.6^[3]), using active and passive to describe access. This page keeps the dimensions apart: active and passive say only whether the scan sends traffic to its target, and credentialed or non-credentialed says whether it logs in. Similarly, a scan's viewpoint (where the scanner sits) is not the same thing as an asset's exposure (where its vulnerable service can be reached from).

The takeaway: use these distinctions, noting any that do not apply, and choose the method from the evidence the scenario needs.

Viewpoint is the scanner's network position relative to the filtering boundaries (firewalls, routers and access control lists) between it and its targets, and it decides which services a scan can reach at all.

• External scan. NIST SP 800-115 describes external testing as conducted from outside the organization's security perimeter, showing the environment as it appears from outside, usually from the internet, with the goal of revealing weaknesses an external attacker could exploit (NIST SP 800-115, section 2.4.1^[2]). External scanning must contend with perimeter devices that block traffic, which limits it to the ports allowed through (section 4.3).
• Internal scan. Internal testing works from the internal network, in the position of a trusted insider or of an attacker who has already passed the perimeter defenses (section 2.4.1). SP 800-115 notes that internal scanning usually uncovers more vulnerabilities than external scanning and that testing from both viewpoints is important (section 4.3).

The two viewpoints answer different questions, so neither substitutes for the other: a clean external scan says nothing about internal servers that the external scanner could not reach.

Segmentation and scanner placement

A scanner placed inside a segment is still an internal viewpoint, positioned past an internal boundary. Segmentation, one of the planning considerations, applies the same logic inside the network. SP 800-115 notes that internal testing can still be limited by internal firewalls, routers and switches (section 2.4.1), so a scan that cannot reach an in-scope subnet produces silence, not a clean result. For devices that are shielded by firewalls, SP 800-115 lists placing the scanner on a segment that can access them among the options (section 4.2), as the figure below shows alongside the external and internal positions. In practice: arrange an authorized assessment path through the boundary or place a scanner inside the segment, and record which viewpoint produced each result. Raising scan thoroughness from the same blocked location changes nothing, because the boundary still drops the traffic.

Allowlisting the scanner changes the question

When firewalls or network address translation (NAT) block assessment traffic, SP 800-115 says assessors can ask for port forwarding, for network access behind the NAT device, or for host-based firewalls to permit traffic from the test system's IP addresses (section 4.3). NIST is explicit about the trade-off: these steps give assessors more insight but "do not accurately reflect the capabilities of an external attacker", although they may better indicate what a malicious insider, or an attacker who already controls another internal host, could reach. Report findings gathered through such an exception as findings on the permitted assessment path, separate from what an ordinary internet requester can reach.

The takeaway: a scan result always carries its viewpoint; choose the position that matches the exposure question, and label any result obtained through an allowlisting exception as such.

Access is the dimension that decides how deep a scan sees into each host. A credentialed scan logs in to the host with an account, so it can read installed software, patch levels and local configuration; a non-credentialed scan sees only what the host exposes to a requester without credentials.

NIST SP 800-115 describes both kinds of network-based scanner: some "have administrator-level credentials on individual hosts and can extract vulnerability information from hosts using those credentials", while others have no such credentials and must locate hosts on the network and scan them from outside, in which case the scan mainly performs network discovery and identifies open ports and related vulnerabilities (NIST SP 800-115, section 4.3^[2]).

• Remote inspection of local patch and configuration evidence normally needs sufficient authorized credentials. Verifying a host's local patch inventory requires host evidence that network checks cannot reach, and software that exposes no network service can be vulnerable without a non-credentialed scan ever seeing it. NIST SP 800-40 Rev. 4 warns that unauthenticated scans "will generally underreport vulnerabilities" compared with authenticated ones (NIST SP 800-40 Rev. 4, section 3.6^[3]).
• Exposure to requesters without credentials is assessed with a non-credentialed scan. A non-credentialed scan is the right instrument when the question is what a requester without credentials can reach, one common purpose of an external scan.

The credentials themselves must be authorized and carry enough privilege for the checks. SP 800-115 notes that detailed local inspection usually requires a root or administrative account (section 4.3); an account that cannot read the software inventory leaves that coverage incomplete.

The takeaway: use authorized remote credentials when the question requires installed or configured host state, and use a non-credentialed scan when the question is what an outsider without credentials can see.

Deployment is the dimension that asks whether an assessment component runs on the host itself. An agent-based scan installs software on each assessed host; an agentless scan assesses the host from somewhere else.

• Agent-based. NIST SP 800-115 describes local vulnerability scanning, in which "a scanner is installed on each host to be scanned", primarily to identify host operating system and application misconfigurations and vulnerabilities, both network-exploitable and locally exploitable (NIST SP 800-115, section 4.3^[2]). The component on the host inspects local state directly.
• Agentless. Nothing is installed on the target, so the assessment depends on some remote path into the host's state: typically network access plus credentials for a remote interface, as with the credentialed network scanners in the previous section. Other agentless approaches depend on their available access to the target.

Choose agentless when installing software on the target is prohibited, for example an appliance that does not permit additional software. A scan agent there violates the target's deployment constraint, whatever else it would offer.

Access and deployment are different dimensions

Credentialed and agent-based are easy to merge because both can see local state, but they describe different things: credentialed describes the access used for the assessment, and agent-based describes where an assessment component is deployed. A remote scanner can log in to a host and inspect its configuration without installing a persistent agent, so that scan is credentialed and agentless at once. Calling every credentialed network scan agent-based confuses access with deployment.

The takeaway: ask "may an assessment agent be installed on this target?" for deployment and "does the scan log in?" for access, and answer the two questions separately.

Interaction is the dimension that asks whether the scan sends any traffic to its targets. NIST SP 800-115 draws the line for network discovery: passive techniques use a network sniffer to monitor traffic and record active hosts, the ports in use and the operating systems seen, "without sending out a single probing packet", while active techniques send packets such as Internet Control Message Protocol (ICMP) pings to solicit responses (NIST SP 800-115, section 4.1^[2]). Passive discovery can also show which hosts talk to each other, how often and with what kind of traffic.

Property	Active	Passive
Traffic to the target	Sends probes and analyzes the responses	None; observes existing traffic
Time to gather information	Usually little	More; a complete picture needs traffic to reach the observation point
What it misses	Hosts that are off, disconnected or behind blocking firewalls	Hosts that send or receive no traffic during monitoring
Side effects	Network noise, possible latency at high volume, intrusion detection system (IDS) alerts	No added traffic

Passive assessment is the choice when a requirement says equipment must not be probed. NIST SP 800-82 Rev. 3, the guide to operational technology security, describes passive scanning as introducing no additional traffic, which suits sensitive OT devices that "may exhibit unexpected behavior when directly probed"; it can reveal manufacturers, part numbers and firmware versions from observed traffic, but it cannot identify devices that are not communicating, cannot inspect encrypted traffic without special provisioning, and often takes days to complete (NIST SP 800-82 Rev. 3, appendix E.2.2^[5]). The same guide records a ping sweep on an active supervisory control and data acquisition (SCADA) network that caused a robotic arm to swing around 180 degrees (appendix C.3.4). That is why a slow, low-rate active scan does not meet a no-probe requirement: slower probes are still probes. Some OT-specific tools combine the two, learning about equipment passively and then querying it with device-specific communication (appendix E.2.3).

The takeaway: active scanning adds load and noise to solicit timely responses; passive assessment sends no probes, but each method has coverage limits.

Discovery is the scan purpose that answers "what is actually on this network?" before anyone asks what is vulnerable. Here, discovery has two jobs that produce different evidence.

• Mapping scans establish which hosts and services are present and how the network is arranged. NIST SP 800-115 lists generating topology maps among the uses of active discovery, and its port and service identification produces a list of the active devices that responded and their responding ports (NIST SP 800-115, sections 4.1 and 4.2^[2]).
• Device fingerprinting infers what a device is from how it responds or behaves. In OS fingerprinting, a tool sends a mix of normal, abnormal and illegal traffic and compares the responses with the known traits of specific operating systems; open-port patterns and TCP sequence-number behavior give further clues. NIST stresses that OS fingerprinting "is not foolproof", because firewalls block some traffic and administrators can make systems respond in nonstandard ways. Fingerprinting can also be passive: the previous section showed passive observation revealing operating systems, manufacturers and firmware.

A topology map is connectivity evidence, not proof of a host's operating system; fingerprint evidence can help support that claim, but is not foolproof. Fingerprints are used to select the relevant follow-up checks, so a wrong fingerprint leads to the wrong checks.

Reconciling discovery with the inventory

When reconciling discovery with the asset inventory, this guide traces three outcomes in the figure below:

1. Found by discovery and in the inventory. The asset stays on the target list; confirm its recorded details still match.
2. Found by discovery but missing from the inventory. Reconcile its identity, ownership and authorization before treating scan coverage as complete. It may be an unmanaged asset that scheduled scans never targeted; SP 800-115 notes that network discovery can detect unauthorized or rogue devices (section 4.1). Scanning only the existing inventory list leaves such a device outside the assessment.
3. In the inventory but silent during discovery. A missing response is not proof of absence. SP 800-115 warns that active discovery identifies only hosts that are on and connected at the time, and that host-based firewalls may block discovery traffic (section 4.1). Check other inventory evidence (platform records, management tools, the asset's owner) before removing the asset from scope.

SP 800-115 also notes that discovery run on a regular schedule gives more accurate results than sporadic runs, and that continuous discovery products can alert as soon as a new device appears.

The takeaway: discovery tests the inventory in both directions, and neither a new device nor a silent one changes the target list until it has been reconciled.

A security baseline scan asks a different question from a vulnerability scan: not "which known flaws are present?" but "do this system's settings match the approved standard?". NIST defines a baseline configuration as a documented set of specifications for a system that has been formally reviewed and agreed on at a given point in time and can be changed only through change control (NIST CSRC glossary: baseline configuration^[6]). A baseline scan compares observed settings, such as account and password restrictions, logging and enabled services, with the required or recommended values.

Patch currency and secure configuration are distinct checks, so a fully patched host can still fail a baseline scan, and a patch report alone cannot establish overall baseline compliance. NIST SP 800-115 lists both among what vulnerability scanning can find: outdated software versions, missing patches and misconfigurations (NIST SP 800-115, section 4.3^[2]).

Where the standard comes from

NIST calls such a standard a security configuration checklist (also known as a lockdown guide, hardening guide or benchmark): instructions or procedures for configuring an IT product to an operational environment, for verifying that the product has been configured properly, and for identifying unauthorized changes (NIST SP 800-70 Rev. 4, section 2.1^[7]). A checklist can include machine-readable content, for example Security Content Automation Protocol (SCAP) XML files, which is what lets a scanner check settings automatically, and NIST notes that checklists are intended to be tailored to each organization's security and operational requirements.

The CIS Benchmarks from the Center for Internet Security (CIS) are one example. CIS describes them as prescriptive configuration recommendations for more than 25 vendor product families, developed through a consensus-based effort of security experts. Each Benchmark targets a specific product, so the right choice is the Benchmark for the target's product and deployment; there is no universal settings list that fits every operating system and application.

The takeaway: run a security baseline scan when the question is configuration, choose the product-specific benchmark, and never read patch status as hardening status.

Planning starts with permission, because a reachable system is not automatically an authorized one. The planning considerations (scheduling, operations, performance, sensitivity levels, segmentation and regulatory requirements) all sit inside the document that grants that permission.

NIST SP 800-115 says each assessment should have an assessment plan, regardless of scope, intrusiveness or who performs it, providing "the rules and boundaries to which assessors must adhere" (NIST SP 800-115, section 6.5^[2]). The plan also protects the assessors by ensuring that the organization's management understands and agrees to the assessment's scope, activities and limitations. The plan answers what the scope is, who is authorized to assess, what the logistics are, how sensitive data is handled and what happens in the event of an incident, so it records items such as these:

• Authorized targets and exclusions. The systems and address ranges that may be examined and tested, plus an exclusion list of systems that may not, for example a payroll database judged too mission-critical for a type of testing.
• Permitted and prohibited activities. The type and level of testing allowed, such as port and service identification or vulnerability scanning, and any prohibited activities, stated "in a way that leaves no room for interpretation".
• Timing, contacts and origin. The assessors' hours of operation, a call plan with points of contact, and the IP addresses of the assessment machines so that administrators can tell assessment activity from a real attack.
• Stop conditions. What assessors do if they cause or uncover an incident: whether testing stops, and when and on whose authority it may resume.

Systems owned by someone else need that owner's consent. If part of the network sits on a third party's network, SP 800-115 says the other network's owner usually must also consent in writing to the plan. Scanning every reachable address that mapping turned up could extend testing beyond the agreed authorization boundary unless each address is within the approved scope. Rules of engagement (ROE) are a related document that holds the same information and also authorizes activities an organization normally prohibits, such as attacks during a penetration test.

The takeaway: the assessment plan, not reachability, defines what may be scanned, how, and when to stop.

Scheduling and performance are separate levers: scheduling decides when a scan's load lands, and scan intensity decides how much load there is. Confusing the two can lead to the wrong scanning decision.

Scheduling and operations

NIST SP 800-115 recommends running tests that could disrupt systems during periods of low network traffic, such as overnight or at the weekend, and notes that port scanning can be conducted after hours to minimize impact on operations (NIST SP 800-115, section 4.2^[2]). When routine scans compete with business peaks, move them to an agreed lower-demand window. Agreeing the window is the operations part: coordinate with operations staff, because an hour that is quiet for users may be when backups, batch processing or maintenance run. SP 800-115 gives a related operational example, delaying testing until a major upgrade has been completed (section 6.2).

Scheduling changes only when a scan runs. Switching an internal scan to an external one to escape a busy period changes the viewpoint and coverage without reliably resolving the original contention or providing equivalent evidence.

Performance: scan intensity

Scans consume capacity on the targets and on the network. SP 800-115 notes that active discovery generates network noise that can cause latency and, at high volume, slow traffic or drop packets on poorly configured networks (section 4.1); that network-based vulnerability scanning generates significantly more traffic than port scanning and can affect the scanned hosts and the network segments the traffic crosses; and that more aggressive internal scans significantly increase the chance of disrupting operations without necessarily improving results (sections 4.2 and 4.3). When an approved window still produces latency or resource exhaustion, reduce concurrent work or divide the assessment into smaller batches. CISA's vulnerability management guide makes the same planning point: it may be impractical to scan everything at one time (CISA CRR Resource Guide, Vol. 4: Vulnerability Management^[4]). Moving an unchanged high-load scan to another hour does not reduce its own load; if that load exceeds available capacity even then, reduce its intensity.

The takeaway: fix contention with the schedule, fix overload with intensity, and agree both with operations.

Sensitivity works in two directions on a scan, and the plan has to cover both: how sensitive the target is to the scan, and how sensitive the scan's output is.

Fragile and availability-critical targets

NIST SP 800-115 warns that any time a test interacts with a system, "the potential exists for unexpected system halts and other denial of service conditions"; it advises organizations to decide their acceptable level of intrusiveness and notes that excluding tests known to create denial-of-service conditions reduces these impacts (NIST SP 800-115, section 2.3^[2]). Vulnerability scanners make this concrete: many include network-based tests for denial-of-service attacks, and scanners often allow all of them to be suppressed (section 4.3). SP 800-115 also cautions that some scans can cause failures on older systems with weak security, and that the closer a scan is to normal activity, the less likely it is to cause operational problems (section 4.1).

For fragile or availability-critical equipment, agree safe assessment methods with the system owner and leave disruptive checks out unless they are specifically approved. Selecting every available check for a fragile production system is not thoroughness; it includes tests designed to exercise disruptive conditions. Where no probes are acceptable at all, use passive assessment (see Active vs passive scans above). Another option is a non-production copy: SP 800-115 suggests running a technique likely to cause denial of service against a non-production system, while noting that test and production configurations usually differ somewhat, which can hide vulnerabilities (section 6.3).

Sensitive assessment results

Scan output is sensitive in its own right. SP 800-115 describes how assessment data is handled as critical to protecting sensitive information such as system architecture, security configurations and system vulnerabilities; it makes assessors responsible for secure storage of vulnerabilities, analysis results and mitigation recommendations, and warns that inappropriate release "can damage the organization's reputation and increase the likelihood of exploitation" (section 7.4). Restrict access to scan reports, protect them in storage and in transit (SP 800-115 lists encrypting individual files or the communication channel), and define retention and removal in the assessment plan. When testing could expose personal data such as payment card numbers, SP 800-115 suggests a non-production system with test data instead (section 6.3).

The takeaway: match the checks to the target's tolerance, and protect the results according to what they reveal.

Regulatory requirements, the last planning consideration, can dictate a scan's frequency, its arrangement and the standard it is measured against. NIST SP 800-115 notes that assessment frequency "is often driven by an organization's requirements to demonstrate compliance with specific regulations or policies" (NIST SP 800-115, section 6.2^[2]). This section contrasts PCI DSS with the ISO/IEC 27000 family, which work differently.

PCI DSS: requirements that fix who scans

The Payment Card Industry Data Security Standard (PCI DSS), published by the PCI Security Standards Council (PCI SSC), "provides a baseline of technical and operational requirements designed to protect payment account data" (PCI SSC: PCI DSS^[8]); here "baseline" refers to that set of requirements, not to the approved settings standard a security baseline scan compares a system against. For external scanning it also fixes the arrangement. An Approved Scanning Vendor (ASV) is an organization with a set of security services and tools (its "ASV scan solution") that conducts external vulnerability scanning to validate adherence with the external scanning requirements of PCI DSS Requirement 11.3.2, and PCI SSC tests and approves that solution before adding the vendor to its list of ASVs (PCI SSC: Approved Scanning Vendors^[9]). When an assessment explicitly requires an ASV scan, arrange one; an internally generated scan report, however thorough, is a different assessment arrangement and does not take its place.

ISO/IEC 27000 family: management-system requirements and control guidance

The ISO/IEC 27000 family is a collection of information security standards, not one list of machine settings; ISO/IEC 27001 and ISO/IEC 27002 are among its standards (ISO: ISO/IEC 27000 family^[10]).

• ISO/IEC 27001 sets out requirements for an information security management system (ISMS), the organization-wide system of policies, processes and risk management for information security; it has organizations apply a risk management process suited to their size and needs (ISO: ISO/IEC 27001^[11]).
• ISO/IEC 27002 provides a reference set of generic information security controls, with implementation guidance (ISO: ISO/IEC 27002^[12]).

Scan evidence can support an ISMS, but a technical scan result alone does not establish that the whole management system conforms, so a passed baseline scan is not ISO/IEC 27001 certification. An assessment described as aligned with the ISO/IEC 27000 family therefore still has to name the applicable requirements and the technical checks used as evidence, which is where a product-specific benchmark from Security baseline scanning and CIS Benchmarks above comes in.

The takeaway: PCI DSS can dictate the scanning arrangement itself, while ISO/IEC 27001 is a management-system standard that scan evidence supports but never satisfies on its own.

CompTIA's CySA+ V4 exam objectives summary lists "Implement the appropriate vulnerability scanning method: Tools and techniques used to identify vulnerabilities across systems, networks, and applications" under Vulnerability Management (26%) (CompTIA's CySA+ V4 exam objectives summary^[1]). In the scenarios below, identify the constraint or piece of evidence and choose the appropriate scanning method or action that respects it.

Scenario constraint or evidence	Appropriate scanning method or action	Alternative that fails, and why
Discovery finds a device the inventory does not list	Reconcile identity, owner and authorization, then add it to the target list	Scanning only the inventory list: the unmanaged device stays unassessed
An advisory names a library version; which hosts are affected?	Use an inventory with software versions, gathered by credentialed scanning	An IP-address inventory: it does not identify software components
Cloud workloads come and go between weekly scans	Feed platform inventory data and lifecycle updates into the target list	The last periodic network scan as the cloud inventory: it misses short-lived resources
A vendor maintains the device under contract	Arrange assessment and patching with the responsible party	Internal patch automation: ignores the third-party maintenance restriction
A topology map is offered as proof of a host's OS	Use fingerprint evidence for OS claims	The map: it shows connectivity, not device characteristics
An inventoried host did not answer one sweep	Check filtering, power and other records first	Removing it: no response is not proof of absence
Scans slow business applications at peak hours	Move to a lower-demand window agreed with operations	Switching to an external scan: changes the viewpoint, not the window
The scan exhausts the target even in its approved window	Reduce concurrency or split into batches	Moving the unchanged scan to another hour: same load
Mapping turned up addresses on a provider's network	Scan only the authorized scope; get the owner's consent first	Scanning everything reachable: exceeds the authorization boundary
A fragile production controller must be assessed	Owner-agreed safe checks, no denial-of-service tests unless approved	Every available check: includes disruptive tests
Equipment must receive no probes at all	Passive assessment of existing traffic	A low-rate active scan: still sends probes
The scanner cannot reach an in-scope subnet	Authorized path or a scanner inside the segment; record the viewpoint	A more thorough scan from the same spot: still blocked
A clean external scan is cited for internal servers	Verify coverage and run an authorized internal scan where needed	Treating the external result as certification: it does not establish internal coverage
The firewall allowlisted the scanner's IP address	Report findings as the exception path	Reporting them as ordinary internet exposure
Local patch levels must be verified	Credentialed scan with sufficient privileges	Non-credentialed network checks: no host evidence
An appliance prohibits additional software	Agentless assessment; use authorized credentials where supported and needed	Installing a scan agent: violates the deployment constraint
A remote scan logs in without installing anything; classify it	Credentialed and agentless	Calling it agent-based: confuses access with deployment
A fully patched server needs hardening evidence	Security baseline scan against the product's CIS Benchmark	A missing-patch report: says nothing about settings
The PCI DSS assessment requires an ASV scan	Engage an Approved Scanning Vendor	Submitting an internal scan report instead
A passed baseline scan is presented as ISO/IEC 27001 certification	Identify the ISMS requirements still to be met	Treating the scan as certification
Scan reports sit in a widely shared folder	Restrict access and protect storage and transfer	Treating diagnostic output as public

The takeaway: identify which of the three decisions (target list, method, plan) the scenario’s constraint touches, then pick an answer that satisfies all relevant constraints.