Start with permission and an asset inventory
List the exact IP ranges and hosts the organization owns or is authorized to test. Record exclusions, service owners and business-critical systems. A hostname resolving to an address does not itself authorize testing other tenants or provider infrastructure at that address.
Choose the testing position
An external review asks what approved assets expose to the internet. An internal review asks what a defined internal position can reach. State the starting segment, access level and expected segmentation controls. Neither perspective automatically covers the other.
Agree operational limits
- Testing windows, source addresses and expected request rates.
- Fragile services, backup windows and prohibited actions.
- Named contacts, escalation routes and immediate stop conditions.
- Evidence handling and use of synthetic data where feasible.
- Separate approval for disruptive techniques, password attacks or exploitation beyond the minimum proof.
Distinguish reachability from vulnerability
An open port means a service is reachable from the test position. It does not prove a vulnerability. A banner can be incomplete or misleading, so version-based observations need context and validation. Likewise, a timeout is not evidence that a system is secure.
Account for distributed endpoints
CDNs, load balancers and rotating DNS can expose different endpoints over time. Record the hostname, resolved address, time and test position. For HTTPS, preserve the intended hostname during TLS and certificate verification. Describe endpoint variation and coverage limits rather than collapsing different results into a single unexplained verdict.
Ask for useful deliverables
Request an approved-asset coverage summary, evidence-backed findings, affected endpoints and prioritized remediation. The report should distinguish confirmed vulnerabilities, observations and blocked checks. Agree how segmentation findings and repaired services will be retested.
Preparing for an assessment
Provide owned or authorized IP ranges, exclusions, service criticality, maintenance windows and a technical contact. Shared infrastructure and third-party addresses require explicit authorization and must not be inferred from DNS alone.
Keep scope, access assumptions and exclusions explicit. Use redacted evidence and representative test data. Report what was verified, what remains uncertain and which checks could not be completed.
Where identity, hosts and networks interact, consider an infrastructure security assessment.
Related resources
Guides
Vulnerability Management Basics
Prioritize remediation using exposure, validation and business context.
Read articleChecklists
Security Configuration Review Checklist
Prepare a contextual hardening review, from permissions and exposure to evidence and exceptions.
Read checklist