External network penetration testing: what an internet attacker sees
If a PCI DSS assessor, a CIS Safeguard 18.2 review, a customer security questionnaire or an insurer has asked for an external penetration test, the question is usually whether anyone on the internet can reach something they should not. An external test answers that by attempting what an outside attacker would see: the public IP ranges, the services listening on them, and the portals and gateways that customers and staff depend on. PCI DSS requirement 11.4.1 describes external testing as testing the exposed external perimeter and the critical systems reachable from public networks, and CIS Safeguard 18.2 asks for external tests at least annually, including reconnaissance of the enterprise and its environment. Both point to the same practical starting point: an inventory of what is actually exposed, which is often larger than the list the team maintains.
The external perimeter typically includes public IP addresses and hostnames, VPN concentrators, mail gateways, web portals and login pages, and the edges of cloud environments such as load balancers, storage endpoints and API gateways. It is tested separately from internal work because the attacker's starting position is different. An outside tester has no credentials, no trusted network position and no knowledge of internal routing, so the test measures what exposure alone allows. Findings on the perimeter tend to be the first things a real attacker would find, which is why they carry the most immediate risk. An internal test then answers what happens after a foothold is gained, and the two results should not be treated as interchangeable.
Before work starts, agree the scope in writing: the exact IP ranges and domains, which cloud accounts or addresses are owned by the organization and by whom, which third-party hosted services are excluded, and the testing window. Confirm that any hosting provider or cloud platform permits testing of the listed addresses under its own rules, and ask the provider to name a contact who can halt testing if a production system is affected. Timing matters: schedule the test after significant infrastructure changes, since PCI DSS requirements 11.4.2 and 11.4.3 also call for retesting after such changes, and confirm with your assessor whether the annual window and the change-triggered window will be met by one engagement.
Which external assets go into scope and who decides
External scope is set by what an internet attacker can actually reach, and by who has the authority to approve testing it. The decisions below connect the asset inventory, the testing style, the written rules of engagement and the third-party permissions that must be in place before any packet is sent.
Public IP ranges and domains
Start from the organization's own list of public IPv4 and IPv6 blocks, DNS zones and certificate records, then compare it against what the provider's reconnaissance actually finds. Each range should be tagged as in scope, excluded or unknown. Ask the client to explain any address space that is announced under its name but not documented, since shadow or forgotten hosts are a common finding in external work.
Cloud edge endpoints
Load balancers, API gateways, CDN origins and cloud-hosted storage endpoints often have public addresses that change with deployments. Confirm which accounts, subscriptions and regions own each endpoint, and whether the provider's published testing rules allow testing against them. Endpoints that are shared with other tenants are usually excluded unless the cloud provider's policy permits the test.
Third-party hosted assets
SaaS portals, managed mail gateways, outsourced VPN appliances and hosting provider ranges may belong to a vendor, not to the client. Testing them without the owner's written authority can create legal exposure for both sides. Request the vendor's consent or the vendor's testing terms, and mark these assets as conditional until that authority is in writing.
Exclusions and their reasons
Excluded assets should be listed with a reason, such as fragile legacy systems, production services that cannot tolerate scanning load, or assets covered by another test type. An exclusion with no owner and no reason is a gap in the record. Auditors reviewing an annual external test will expect to see that exclusions were a deliberate decision, not an omission.
Overt or covert testing
NIST SP 800-115 separates covert testing, run without IT staff knowledge but with upper management's permission, from overt testing, which is less expensive, carries less risk and is used more often. Covert work measures how an adversary could cause damage. Overt work finds the broadest set of exposed weaknesses. Most annual external tests for compliance are overt, while covert objectives belong in a separate adversary simulation engagement.
Rules of engagement and approval
NIST SP 800-115 treats planning as the phase where rules are identified and management approval is documented, and it provides a rules of engagement template in its Appendix B. The rules should name permitted techniques, testing windows, contacts for stopping the test, and the executive who approved the scope. Ask for a signed copy before the first scan, since it is the document an auditor will request.
How an external engagement runs from planning to retest
The sequence turns an internet-facing scope into a validated list of exposures, a report the client can act on, and evidence that the fixes hold. Each phase closes with a documented output so the client can see where the engagement stands at every stage.
Agree rules of engagement and approval
The tester and client define the in-scope IP ranges, domains and cloud edges, the testing window, permitted techniques, emergency contacts and what is out of bounds, such as third-party hosted services the client does not own. NIST SP 800-115 describes this planning phase and offers a rules of engagement template in Appendix B, which is a useful starting point for the written agreement. The step is complete when management approval and the signed rules are on file and every in-scope address has been confirmed as owned or controlled by the client.
Map the external footprint
The tester performs reconnaissance to build an inventory of what an internet attacker can see: registered domains, DNS records, certificate transparency entries, cloud-hosted assets and forgotten subdomains. This is where many organizations learn that their visible perimeter is larger than their asset register. The output is an agreed asset list that the client reviews, because anything that appears in the footprint but not in the scope must be resolved before testing continues.
Identify ports and services
Using the NIST SP 800-115 target identification category, the tester performs network discovery and port and service identification against the confirmed addresses. The goal is to establish which services answer from the internet, including VPN gateways, mail gateways, web portals, remote administration interfaces and management consoles, and which software versions they present. The step closes with a service inventory mapped to each host, which becomes the baseline for vulnerability work.
Run vulnerability scanning and triage
Vulnerability scanning checks the identified services against known weakness data, and the tester then triages the results manually. Scanner output alone produces false positives and misses configuration issues, so the tester confirms whether a flagged version is actually exposed, whether a patch is in place despite the banner, and whether a misconfiguration is reachable from the internet. Scanning is coordinated with the client's monitoring team so that the activity is recognized and rate limits are respected. The output is a validated candidate list, not raw scanner output.
Validate exposures within agreed limits
The tester attempts to confirm the most significant candidates under the rules of engagement, covering weak authentication on exposed portals and VPN login pages, exposed administrative functions, unsafe mail gateway configuration and cloud edge misconfigurations. Validation stops at the point needed to prove the weakness and its impact, and the tester does not pivot into internal systems unless that is explicitly in scope. Any finding that could cause a service disruption or data exposure is reported to the client's named contact at once. The step closes when each validated finding has evidence and a clear statement of what it allows an external attacker to reach.
Deliver the report and remediation plan
The tester issues a report covering methodology, scope, the asset inventory, each validated finding with severity, reproduction context at a defensive level, affected hosts and recommended remediation. A readout meeting walks the technical team through the results and clarifies priorities. The report serves as evidence for the client's own assessments, and it does not stand in for an independent assessor's conclusion. Clients should confirm the report format and content in the written scope before testing starts.
Retest fixed findings
After the client applies remediation, the tester re-checks each finding that was marked as fixed, confirms that the exposure is closed and records the result against the original finding. Findings that remain open or were only partly addressed are carried forward with updated status. The retest report documents which items were verified closed and which are still open, so the client has a traceable record for internal governance and for the next scheduled external test.
Weakness categories seen at the external perimeter
This table groups the weakness categories an external test usually surfaces, describing how each looks from outside the network and why it matters to the business. Read it as a checklist of what to expect in scope, not as a finding count, since results depend on what is exposed on the day of testing. The main takeaway is that most external findings come from exposure drift, such as forgotten hosts and management interfaces, rather than from a single hard problem.
| Weakness category | What it looks like from outside | Why it matters to the business |
|---|---|---|
| Unnecessary exposed services | Remote administration, database, file sharing or monitoring ports answering on public addresses that should sit behind a bastion or private network | Each open service adds a login surface and version banner an attacker can fingerprint and target |
| Exposed management interfaces | Admin consoles for firewalls, hypervisors, storage arrays or container platforms reachable from the internet | Compromise of a management plane often gives control over many systems at once |
| Unpatched VPN and gateway software | Version banners or known responses from VPN concentrators, firewalls and remote desktop gateways that match software with published vulnerabilities | Edge devices are frequent entry points, and a compromise there can bypass every internal control |
| Weak or missing MFA on remote access | Password-only logins on VPN portals, webmail or remote access pages, or MFA that can be bypassed through legacy protocols | Stolen or guessed credentials then grant full internal access without a second check |
| Misconfigured mail gateways and email authentication | Open relay behavior, weak TLS on mail transport, or domains without enforced sender authentication records | Spoofed mail from the organization's own domain supports phishing and fraud against customers and staff |
| Exposed web portals and forgotten hosts | Old test, staging or vendor-hosted sites, default pages, outdated CMS installs and login forms no current owner maintains | Unmanaged hosts usually lack monitoring and patching, so they are often the weakest route in |
| Cloud edge misconfiguration | Public storage endpoints, load balancers or API gateways with permissive access, or addresses exposed without an owner recorded in the inventory | Cloud edges sit outside the on-premises perimeter, so data exposure can occur without any network intrusion |
| TLS and certificate weaknesses | Deprecated protocol versions, weak cipher suites, expired or mismatched certificates and certificates issued for hosts no longer in use | Weak transport security can expose credentials and session data, and expired certificates erode trust in customer-facing services |
How the annual external test satisfies PCI DSS 11.4.3 and CIS 18.2
The annual external test is the requirement most often confused with a vulnerability scan, so the first decision is to label the engagement correctly in the statement of work. PCI DSS v4.x requirement 11.4.3 calls for external penetration testing at least once every 12 months and after any significant infrastructure or application change. The work must be performed by a qualified internal resource or a qualified external third party with organizational independence, and that party does not need to be a QSA or an ASV. An ASV scan is a different instrument. It is a vulnerability scan run by an Approved Scanning Vendor against the perimeter, and it shows what is exposed but not whether an attacker could chain those exposures into access. A penetration test answers the second question, so confirm with your assessor whether they expect both.
CIS Controls v8.1 Safeguard 18.2 asks for external penetration tests at least annually. It expects the work to include enterprise and environmental reconnaissance, meaning the tester maps the organization's internet footprint, the supporting infrastructure behind it and what that footprint reveals about how the environment is built. The safeguard accepts either clear box or opaque box testing. In a clear box test, the tester receives documentation and configuration context. In an opaque box test, the tester starts with only the target names, which shows what an outsider can learn unaided. Choose the model on purpose, record the choice and its reason in the rules of engagement, and check the wording of the safeguard in the CIS Controls Assessment Specification against your own program documents.
Acceptance belongs to the people who own each obligation. Your organization decides whether the test serves its security program, the QSA or other assessor decides whether it satisfies requirement 11.4.3 for the assessment, and a customer's security team decides whether CIS alignment meets their review. DeployOpen does not issue attestations or certifications. Its report is one input those parties weigh. Before signing, confirm with your assessor the exact IP ranges and domains in scope, the testing window, whether your change process will trigger a retest after significant changes, and how the tester's organizational independence will be documented. Ask for the rules of engagement in writing so the assessor can see exactly what was authorized and when.
What drives external testing cost and duration
This table compares the scope and approach decisions that change the effort of an external test and shows which items are paid once and which recur with each annual cycle. Read each row as a question to answer in the scoping call and in the written quote. The main takeaway is that the number of public assets and the test depth matter more than the label on the engagement.
| Driver | Why it changes effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Public IP addresses and domains | Each address or hostname adds discovery, service identification and validation work, and reporting entries grow with it | Scoped per cycle; the initial inventory is one-time, later cycles reconcile changes | Named IP ranges and domains in writing, with a rule for handling newly discovered assets |
| Exposed services and web portals | VPN gateways, mail gateways and login portals need protocol-specific checks and authentication testing, which takes more time than a static host | Recurs annually as services change | A list of exposed services by type and an estimate of how many portals need authenticated testing |
| Cloud edges and third-party hosted assets | Cloud load balancers, CDNs and SaaS-hosted pages may require provider rules, and third parties may need their own written permission | Permission and provider rule checks recur when hosting changes | Confirmation of which assets the client owns or controls and which need provider or third-party approval |
| Test depth | Discovery and mapping takes less effort than validating weaknesses through controlled exploitation within agreed rules | Recurs each cycle; depth can change between years | Whether the test stops at discovery and verification or includes validated exploitation, and the rules that bound it |
| Overt or covert approach | Overt testing with known staff is the more common and less costly approach; covert testing adds planning and a narrower set of people who know about it | Set at planning; changes apply to each cycle | Written statement of the approach, who knows about the test, and how alerts from the provider's monitoring are handled |
| Number of retests | Each retest checks fixed findings and adds effort in proportion to the number of items to recheck | Retests are usually separate and optional | Retest count, time window and whether retesting is included in the base price |
| Reporting depth | An executive summary differs from a report with per-finding evidence, remediation detail and an assessor-ready evidence pack | Report format is set once; each cycle produces a new report | Sample report, required sections and whether an auditor or customer format is needed |
| Change-triggered retests | Significant infrastructure changes can require a new test outside the annual cycle, which adds scoping and a separate effort | Recurring whenever significant changes occur | How change events are defined, who decides, and the cost of an off-cycle test |
How external testing differs for on-premises, cloud and hybrid perimeters
Where the internet edge sits in your own data center, the test scope is usually anchored to public IP ranges that your organization owns and routes. Firewalls, load balancers, VPN concentrators, mail gateways and web portals are typically physical or virtualized appliances that your team configures and patches. Because your organization controls the entire path, the tester can usually rely on your change records and network diagrams to confirm which addresses are live, and access is normally arranged through your own network and security teams rather than a third party.
- Scope by owned address space: Confirm which blocks are assigned to you, including addresses held by ISPs, colocation providers or legacy carriers, since those may not appear in your asset inventory.
- Access and timing: Agree a test window with the team that monitors the perimeter, and confirm whether the SOC should see the test as known activity or as an unannounced exercise.
- Change control: Confirm how appliance firmware and rule changes are recorded, because a test that follows a firmware upgrade falls under the retest expectations in PCI DSS requirements 11.4.2 and 11.4.3.
- Dependencies: Identify upstream DDoS protection, ISP filtering and any provider that may need notice before scanning starts.
- Hosts you do not own: Hosting or colocation providers may have their own rules, so check them before testing addresses in their facilities.
Before testing, confirm the address list in writing, the named contacts for emergencies, and who may stop the test.
When public endpoints run on a cloud provider, part of the perimeter is managed by the provider and part by you. Load balancers, managed gateways, storage endpoints and serverless front ends are often created and changed through automation, so the set of reachable services can shift between test cycles. The shared responsibility model determines what you may test: you can usually assess the configurations and workloads you run, but the provider's underlying infrastructure is outside your test scope, and most providers publish rules on which activities are permitted without prior notice and which need approval.
- Provider testing rules: Read the current published testing policy for each provider in use before scheduling, because permitted activities, prohibited activities and notice requirements change over time.
- Shared responsibility limits: Testing stops at the boundary of the provider's managed services. Ask for evidence of the provider's own assurance reports rather than testing their infrastructure.
- Dynamic inventory: Scope by account, subscription or project and tag, and require a discovery step that confirms public addresses and DNS names at the start of the test.
- Third-party services: Dependencies such as content delivery networks, email services or identity providers may need separate permission or be out of scope.
- Account access: Decide whether the tester receives a read-only review of cloud configuration alongside the external test, which is a separate piece of work.
Before testing, check the provider's current policy, record the accounts in scope and confirm who at the provider or your cloud team handles any alerts.
Many organizations expose a perimeter made of several parts: a data center edge that still receives traffic, cloud applications, and SaaS platforms that hold business data and authenticate users. Here the main challenge is defining the boundary. A SaaS vendor's login page may be reachable from the internet and linked to your domain, but the vendor, not your organization, operates it. The external test must separate what you control and can authorize from what belongs to a third party and can only be assessed through vendor-approved means.
- Boundary mapping: Build a single register of public endpoints that lists owner, hosting location and the authority that approves testing.
- Third-party authorization: Do not include a SaaS platform in scope unless the vendor's terms or written approval allow it. Otherwise, review your own tenant settings and the vendor's published assurance evidence.
- Shared domains: Subdomains that point to SaaS services, including forgotten or dangling records, are a common finding, so include DNS review in discovery.
- Reporting boundaries: Separate findings by owner so that remediation and retesting go to the right team.
- Hybrid links: Public endpoints that front on-premises systems may reach internal services, so note any path that crosses from cloud to data center.
Before testing, ask the provider for a written statement of what is in scope and what is excluded, and agree how vendor-owned findings will be reported.
External penetration testing questions buyers ask before hiring
What does an external penetration test cost, and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list, so the quote is the figure to compare. The main drivers are the number of live external addresses and hostnames in scope, how many services and portals sit behind them, whether the test is clear box (with credentials or architecture information) or opaque box, how many retest rounds are included, and how the report must be structured for an auditor or customer. Ask each provider to price the same written scope, deliverables and retest terms so the quotes can be compared line by line. Confirm whether the quote covers planning, testing, reporting, a findings review meeting and retesting of fixes, since these are separate pieces of work. The recurring cost is the next annual test and any retest after a significant change, not a fee for the same test to continue.
How long does an external penetration test take, and what does the client need to provide?
The duration depends on the number of targets, how quickly the target list is confirmed, and how many approvals the rules of engagement need before testing starts. NIST SP 800-115 treats planning as its own phase, where rules are identified and management approval is documented, and it provides a rules of engagement template in Appendix B. Ask the provider to state the expected duration and phases in the written scope. From the client, expect to supply a confirmed list of IP ranges and domains with named owners, contacts for the test window and for escalation, and approval from whoever owns the perimeter, including hosting or cloud providers where their rules apply. Decide in advance whether testers receive any credentials or architecture information. Share the source addresses testers will use so the monitoring team can recognize the test.
Can our own team run an external penetration test internally?
Yes, if the people doing it are qualified and independent. PCI DSS requirement 11.4.3 allows a qualified internal resource to perform external testing, provided the tester has organizational independence from the systems and the team that runs them. In practice, the tester should not be the administrator who configured the perimeter, and the work should be documented as if it were going to an assessor. Internal teams are well placed for routine checks and ongoing monitoring. The gaps usually appear in attacker-style reconnaissance, in judging whether a chain of weaker findings leads to something serious, and in writing findings that a customer or assessor will accept. Ask how independence will be shown, what evidence will be kept, and whether the team has tested the same kinds of edges before. An external provider brings independence and an outside view, and the choice between the two is a decision for your organization.
How often must an external penetration test be repeated?
PCI DSS requirement 11.4.3 requires external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. CIS Safeguard 18.2 asks for external tests at least annually, including enterprise and environmental reconnaissance. Treat the annual cycle as the minimum. Retest after changes that alter what is exposed, such as a new VPN or mail gateway, a moved web portal, a new cloud edge, a firewall or load balancer rule change, or a major upgrade on an internet-facing system. Define 'significant' in writing before the year starts, since an assessor will ask how that decision was made. Keep the change records and the decision record together so the evidence shows why a test was or was not triggered.
Does an external penetration test satisfy PCI DSS 11.4.3 or CIS 18.2?
An external penetration test can serve as evidence for PCI DSS requirement 11.4.3 and CIS Safeguard 18.2, but it does not confirm compliance on its own. The test meets the PCI DSS requirement only if its scope covers the exposed external perimeter and critical systems reachable from public networks, it is performed by a qualified tester with organizational independence, and it takes place within the required interval. The assessor decides whether the evidence is sufficient. DeployOpen does not issue audit reports, attestations or certifications. Before testing, ask your assessor what they will accept on methodology, scope and report format. Use a written scope that lists each address range and hostname so the report can be traced to what the assessor reviewed, and confirm whether reconnaissance results need to appear in the report to satisfy CIS Safeguard 18.2.
What happens to production systems during an external penetration test?
Testing can reach production systems, so the rules of engagement should state what is allowed before any traffic is sent. Typical controls include an agreed list of targets, a defined test window, rate limits on scanning and login attempts, a ban on denial-of-service testing unless it is specifically approved, and a named contact who can stop work at any time. NIST SP 800-115 describes overt testing as less expensive and carrying less risk than covert testing, which is why most external tests are run with the IT team aware of them. Ask the provider how it will handle an outage, a fragile legacy system or a third-party host. Agree in advance on a short channel for urgent findings so that serious issues do not wait for the final report.
How do we scope a large IP range efficiently for external testing?
Start by separating what is reachable from what is merely assigned. Reconcile the address space with DNS records, firewall and load balancer configuration, cloud account inventories and the asset register. Remove addresses that are unused, internal only, or owned by a third party without a testing agreement. Group what remains by function, such as VPN, mail gateway, web portal and cloud edge, so each group is tested against the questions that matter for it. Ask the provider to begin with discovery and port identification to confirm the live set, then agree how deep each target will be tested. Keep the final list in writing with named owners, because the rules of engagement and the report are built from it. Illustrative example: a large allocated block may shrink to a much smaller set of live, owned hosts once reconciled, and that smaller set becomes the working scope.
What the client receives and whether it satisfies an auditor
An external test produces several documents, and each serves a different reader: the executive team, the engineers who fix findings, the assessor checking the test, and customers asking whether it happened. The cards below cover what to expect in each, and where the auditor or QSA makes the final call on sufficiency.
Executive summary and scope record
The executive summary states what was tested, the overall exposure in plain terms and the most urgent items. The scope section lists the IP ranges, domains and cloud edges in the agreed rules of engagement, including anything excluded. Check that the scope matches the signed authorization exactly, because an assessor will compare the two first.
Methodology and test timing
The methodology section should name the phases used, the tools categories applied, the test dates and whether the test was clear box or opaque box. Auditors look for evidence that the approach followed a recognized guide, such as NIST SP 800-115, and that the test date falls within the required interval. Ask the provider to show how the test window was set.
Findings with severity ratings
Each finding should state the affected asset, the weakness category, the evidence that confirmed it, the severity rating and the rationale behind that rating. Ask how severity is assigned and whether the provider adjusts scores for your compensating controls. Unvalidated scanner output presented as findings is a common reason reports are challenged.
Evidence and remediation guidance
Evidence includes screenshots, request and response captures, banner data and timestamps that let your team reproduce each finding without repeating the attack. Remediation guidance should give a specific fix for each item, such as disabling a legacy protocol or patching a gateway, along with the owner and priority. Confirm that sensitive data found during testing is handled and redacted before the report is shared.
Retest report
A retest report confirms which findings were closed and how, and which remain open with a reason. It is issued after remediation and should reference the original finding identifiers so the history stays traceable. Ask whether retesting is included in the quote or priced separately, and whether it uses the same external IP scope.
Test letter for customers and auditors
A test letter summarizes the engagement date, scope in general terms, the methodology and the tester's organizational independence, and it is useful when a customer security review asks whether a test occurred. It is not an attestation, certification or audit opinion. The QSA, assessor or auditor decides whether the test and its evidence satisfy the requirement, so confirm their expectations before the test begins.
What your team must prepare before external testing starts
Before any packet leaves the tester's machine, your organization must put written authorization for every in-scope IP address and domain in front of the tester. Confirm that each address range and hostname on the scope list is owned by you, not by a hosting provider, a managed service or a partner, and that the person signing has the authority to approve testing against those assets. NIST SP 800-115 treats the planning phase as the point where rules are identified and management approval is documented, and its rules of engagement template in Appendix B is a practical starting point for the signed document. Also check the rules of your cloud and hosting providers. Many publish their own testing policies, and some require notice or prohibit certain activities against their platforms. Ask each provider what it permits before the test is booked, not after the first alert.
Name two kinds of contact before the test window opens. The first is a technical contact who can answer questions about the perimeter, such as which firewall rules are intentional, which VPN portal is retired, or which mail gateway is in front of which domain. The second is an escalation contact with authority to stop testing, usually someone in the security operations or incident response chain who can make that call at any hour. Agree a change freeze or a defined testing window for the perimeter, and record which firewalls, load balancers, WAFs and cloud edge services are excluded from any change during that period. Tell the SOC and any managed detection provider that external scanning and exploitation attempts will arrive from known source addresses, and give them the start and end times, so that alerts are triaged as expected activity rather than escalated as a live incident. Backup jobs that touch in-scope systems should also be listed, so that a degraded service is explained rather than investigated from scratch.
Decide in advance what happens if the tester finds a critical issue, such as an exposed administrative interface, a default credential on a VPN appliance or an unauthenticated service that reaches customer data. Agree who is notified, how quickly, through which channel, and whether the tester pauses on that asset until your team confirms it has been reviewed. Write down the severity threshold that triggers an immediate call rather than waiting for the final report. Confirm that the tester will not attempt to retain data beyond what is needed to prove the finding, and agree how evidence is stored and deleted afterward. This plan protects both sides: your systems stay available, and the tester has a clear route to report something urgent without guessing who should hear about it.
What to check and ask for before signing with a provider
A external test is only as useful as the agreement behind it. The cards below cover the decisions that shape what you receive: who tests, against which method, within which written limits, and how the results reach your team and your assessor. Check each item before you sign, not after the first finding arrives.
Organizational independence
Ask whether the testing team sits apart from the group that runs your firewalls, VPN gateways and mail relays. PCI DSS requirement 11.4.3 asks for a qualified tester with organizational independence, which means the people grading your perimeter should not be the people who built it. Ask who reports the results, to whom, and whether that line is written into the contract.
Method alignment with NIST SP 800-115
Ask the provider to describe its method in the four phases of NIST SP 800-115: planning, discovery, attack and reporting. A credible answer names how each phase is documented and how reconnaissance feeds validation. Vague answers such as "industry best practice" with no phase mapping are a signal to probe further.
Written rules of engagement
The rules of engagement set the permitted techniques, testing windows, source addresses, stop conditions and named contacts. Appendix B of NIST SP 800-115 provides a template you can use as a baseline. Confirm who signs for your organization and that your hosting or cloud provider's testing terms are reflected where they apply.
Fixed written scope by IP range
Ask for the scope as an explicit list of IP ranges, domains, cloud edge endpoints and exclusions, agreed before work starts. Ask who confirms ownership of each address, since testing a third-party host without permission creates legal exposure. Any range added later should go through a written change request.
Sample report structure and retest terms
Request a redacted sample report before signing. It should show an executive summary, a per-finding write-up with evidence, severity with the rationale behind it, and remediation guidance that your engineers can act on. Confirm in writing whether one retest of confirmed findings is included, how long after delivery it must happen, and whether the retest result appears in the same document.
Tester qualifications and data handling
Ask which certifications and experience the named testers hold, and confirm that they are individuals you can name in the contract. Then ask how findings, screenshots and credentials are stored, who can access them, how long they are kept and how they are deleted at the end. Scan output often contains sensitive configuration detail, so treat it as confidential data.
Escalation of critical findings
Agree in advance what counts as critical, such as an exposed administrative interface or a service that accepts default credentials, and who is called the same day. Ask the provider to confirm the escalation path, the contact hours and what happens if your team cannot be reached. The test should not wait for the final report to tell you about a live exposure.
How DeployOpen scopes, tests, reports and retests external networks
DeployOpen agrees a fixed, written scope before any external testing starts, and that scope is the single reference for what is tested. For an external engagement, the scope lists the IP ranges, domains, hostnames and cloud edge addresses in play, such as VPN concentrators, mail gateways, web portals and load balancers, along with the addresses that are explicitly excluded. The scope also records the test window, the named contacts who can halt testing, and whether the work is overt or covert. Authorization is documented in a rules of engagement agreement modeled on the approach in NIST SP 800-115, which covers planning, management approval and the boundaries of each activity. Before signing, confirm that every address in scope is owned by your organization or that the owner of any hosted or third-party system has given written permission. Ask for the rules of engagement to be reviewed by whoever signs off on production risk, not only by the security team.
During testing, the work stays inside those rules. The tester maps what the internet can see, identifies exposed services and their versions, and validates the weaknesses that matter most, such as authentication gaps on remote access gateways, outdated mail or VPN software, and portals that disclose more than they should. Testers do not run denial-of-service activity or exploit third-party infrastructure unless the agreement expressly covers it. Any finding that could affect availability or sensitive data is raised with your named contact during the engagement rather than held for the final report. The written report gives each finding a severity rating, a description of the affected asset, the evidence that supports it, the business impact and a remediation step your team can act on. Ask for the report to state the rating method and to identify which findings are validated and which are indicators that need further checking. Remediated findings are then retested, and the retest result is recorded against the original finding. For recurring annual or change-triggered testing, a retainer can keep scope, rules and reporting consistent from one cycle to the next.
