External attack surface management vs external penetration testing

External attack surface management or external penetration testing: which do you need first?

If you cannot say with confidence which internet-facing assets you run, start with attack surface management. It answers 'what do we expose' on a recurring cycle, finding hosts, services and domains that were never inventoried, such as forgotten test environments, legacy DNS records and third-party-hosted pages. External penetration testing answers a different question: 'can an attacker get in through what we expose' at a point in time. Its value depends on the scope it is given, so an incomplete asset list means the test quietly skips the systems most likely to be weak. For federal civilian agencies, CISA's BOD 23-01 sets the discovery cadence in its own terms, with automated asset discovery every 7 days covering at least the entire IPv4 space. Commercial organizations have no equivalent mandate, so they should confirm their own discovery frequency with their internal owners and vendors rather than assume one.

Put the penetration test first when your asset list is already reasonably accurate, when a specific external system is about to change (a new public application, a migration to cloud hosting), or when a customer, regulator or audit requires a test before a go-live date. A test also comes first if the goal is to validate an exploitable path rather than to map the estate. NIST SP 800-115 describes external testing as starting with reconnaissance of public registration and DNS data, then enumerating hosts and listening services before attacking allowed protocols such as HTTP and SMTP. Much of that reconnaissance is work an attack surface tool can do for you, so a mature program lets the tool's output define the test scope rather than repeating it by hand each time.

Combining the two makes sense once you have both a recurring need for discovery and a recurring need for depth. Attack surface management feeds the penetration test: the tester receives a current list of in-scope hosts, the test is scoped against that list, and new findings from the discovery cycle trigger a targeted retest. Ask any penetration testing provider how they will confirm the scope, who owns the rules of engagement and what happens when discovery finds an asset outside the agreed boundary. Those questions decide whether the combined program is better than either tool alone. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, which is a floor for depth, not a substitute for knowing what is exposed.

How the two approaches differ across scope, method, cadence and evidence

This table compares external attack surface management and external penetration testing on goal, scope, method, cadence, authorization, output, compliance references and typical buyer. Read it as two complementary activities: one maintains an accurate picture of what is exposed, the other tests whether an attacker can exploit what is there.

Dimension	External attack surface management	External penetration testing
Primary goal	Find internet-facing assets you did not know you had and track changes to them over time	Determine whether a defined set of exposed systems can be exploited and what an attacker could reach
Scope	Discovery begins from seed data such as domains, IP ranges and registration records, and expands to what is found	Scope is fixed in the rules of engagement, listing target hosts, domains, protocols and any exclusions
Method at a buyer level	Largely passive or low-impact discovery, enumeration and classification of services and exposures	Reconnaissance followed by active testing, which can include real exploits against production systems
Cadence	Continuous or recurring, as in the federal discovery cycle of every 7 days under CISA BOD 23-01 (3 October 2022)	Periodic, point-in-time engagement. NIST SP 800-115 suggests periodic penetration testing alongside regularly scheduled scanning
What is authorized	Usually limited to monitoring assets you own or control. Confirm with the provider how third-party or shadow assets are handled	Explicit written authorization under rules of engagement covering each target, timing, testing limits and emergency contacts
Output	Asset inventory, changes, exposure findings and ownership gaps, often delivered as a live dashboard or feed	Written report with validated findings, attack paths, evidence and remediation guidance, plus retest results if purchased
Compliance references	CIS Controls v8.1 Safeguard 18.2 for periodic external testing; BOD 23-01 for federal agencies. Confirm which framework your assessor uses	CIS Controls v8.1 Safeguards 18.2 and 18.5 for at least annual external testing; NIST SP 800-53 CA-8 at high baseline; DORA Article 25(1) lists penetration testing as one test type
Typical buyer	Security operations, IT asset owners and teams with many domains, cloud accounts and subsidiaries	Security assurance, compliance and application owners who need validated exploitability evidence
What to confirm with the provider	Discovery sources, refresh frequency, handling of ephemeral assets and whether results feed your ticketing system	Tester qualifications, retest terms, report format accepted by your auditor and data handling for captured evidence

Which approach fits which organization and situation

When nobody can produce a current list of internet-facing hosts, domains and certificates, the first gap is discovery, not exploitation. An external penetration test can only attack what the tester is given or can find, so a scoped test built on an incomplete list tells the client little about the rest of the estate. Attack surface management starts from registration data, DNS and certificate records and enumerates what is actually reachable. This advantage holds when the organization has enough ownership of its domains and address space for discovery results to be reviewed and assigned. It weakens if many assets belong to third parties that the organization cannot authorize.

Start with discovery: run external discovery first so the penetration test scope reflects reachable hosts and services, not the spreadsheet.
Expect false positives: shadow hosts may belong to a former vendor or a subsidiary, so each finding needs an owner before anyone tests it.
Document ownership: record who approves testing for each domain and address range, since a tester cannot assume authority.
Keep the penetration test as the second step: it validates whether discovered services can be exploited.
Plan for triage time: ask the vendor how discovered assets are reviewed and handed to your team.

Before buying either service, ask the provider which discovery sources it uses, how it handles assets it cannot attribute, and what written authorization it needs.

How discovery and exploitation work at the perimeter

External penetration testing starts with reconnaissance, not exploitation. NIST SP 800-115, in its *Technical Guide to Information Security Testing and Assessment*, describes the external test as beginning with a review of public registration data and DNS records. The tester then enumerates externally reachable hosts and listening services, and only after that attacks the protocols you have agreed to test, such as HTTP and SMTP. The output is a snapshot of what the tester could find and reach during the engagement window. An attack surface management platform runs the discovery half of that work on a schedule instead, so it keeps reporting when a new host, certificate or service appears after the test ends. Confirm with your provider whether the test scope is fixed to a list you supply or whether the tester will rediscover assets from scratch, because that choice decides which hosts the report covers.

The risk profiles differ sharply. NIST SP 800-115 classes review techniques as passive, with minimal risk to systems, while penetration testing uses real exploits against production systems and data and carries high risk. Discovery and monitoring sit on the passive side: they query public sources and probe for exposure without attempting to break in. A penetration test does attempt to break in, so it needs a signed rules of engagement, a named contact who can stop testing, agreed windows for high-impact activity, and a plan for what happens if a production service degrades. Before approving testing against an internet-facing system, check that its owner knows the test is coming, that backups exist, and that the asset is one your organization actually controls, since third-party hosting may require separate permission.

NIST suggests that organizations do not treat these as alternatives. Its guidance favors regularly scheduled scanning interspersed with periodic penetration testing, so that routine exposure data tells you where to aim the next exploit-level test. In practice, use continuous discovery to refresh the target list before each penetration test, and feed the test findings back into the monitoring baseline so that a fixed issue is confirmed closed and a newly exposed service is flagged between tests. This loop only works if someone owns the reconciliation step, reviewing new assets each cycle and deciding which ones enter the next test scope.

What each approach finds and what it misses

External attack surface management and external penetration testing answer different questions about the same internet-facing estate. The cards below show where each one sees more than the other, and where each one leaves a gap that the other can close.

Asset discovery gaps

Attack surface management finds hosts nobody registered, such as shadow IT, forgotten test servers and DNS records left behind after a migration. A penetration test only covers what the client hands over as scope, so an unknown host is usually never tested. Check whether your scope list comes from discovery output or from an old inventory. Ask the testing provider to reconcile its target list against fresh discovery results before testing starts, and record any host that appears in discovery but not in scope.

Exposure and misconfiguration

Discovery and enumeration tools flag exposed admin panels, open listening services, outdated TLS settings and expired certificates across the whole estate on a schedule. These findings are real but often low in exploitability on their own, so they can be buried in a long list. Use the discovery feed to decide which exposures a penetration tester should confirm and chain, and ask for a severity rationale tied to what each exposure actually allows.

Exploitable chains and business logic

A penetration test shows whether several weaknesses combine into a working attack, such as an exposed staging login that leads to a token with production rights. Discovery tools report each weakness separately and cannot judge the path between them. Confirm that the test report documents each step of the chain with evidence, and that business logic flaws, like a discount applied twice or an account recovery flow that skips verification, are part of the test plan rather than assumed to be covered.

Exploits not yet attempted

Discovery shows that a service exists and reports its version, but it does not prove that the service can be abused in your environment. A penetration test attempts real exploitation against allowed protocols such as HTTP and SMTP, which NIST SP 800-115 describes as a high-risk activity to be scoped and authorized. Ask whether the provider will attempt exploitation on production targets, what rules of engagement apply, and how a failed exploit attempt is recorded in the report.

Ephemeral and third-party SaaS assets

BOD 23-01 excludes ephemeral assets such as containers and third-party SaaS from its discovery requirement, so a federal program built only on that directive will not inventory them. Cloud workloads that appear and disappear between scans, and vendor-hosted portals that carry your brand, can both be missed. Confirm whether your discovery tool watches cloud accounts and SaaS tenants directly, and add these assets to the penetration test scope only after confirming ownership and the vendor's permission to test.

Internal paths and trust relationships

External discovery only sees what faces the internet, so it cannot show how an attacker who lands on a public host would move laterally into the internal network. An external penetration test can be extended to test that pivot, but only if the client authorizes it and provides the network scope. Ask for an explicit decision on whether the external engagement stops at the perimeter or continues into an internal or authenticated phase, and record that decision in the rules of engagement.

How an accurate asset list makes an external penetration test better

The sequence runs from continuous discovery to a confirmed inventory, a scoped test, targeted validation and findings that feed back into monitoring, so the penetration test spends its time on assets that are known, owned and in scope. Each step depends on the output of the one before it.

Run continuous discovery across the external footprint
Discovery starts with public registration data, DNS records and address ranges the organization holds, then enumerates hosts and listening services that answer from the internet. The security team or its attack surface management provider runs this on a recurring schedule, not once. It is done when the team can list each discovered host, service and certificate with a first-seen date and a named owner or an open question about ownership. Unowned or unexpected assets go to triage before any test is planned.
Build and reconcile the asset inventory
Discovered assets are compared against the CMDB, cloud account inventories, DNS zones and the owners named by application teams. Each asset is tagged as in scope, out of scope, third-party or retired. Assets with no clear owner are escalated because nobody can authorize testing against them. The inventory is complete when every internet-facing asset has an owner, a status and a record of how it was confirmed.
Scope the rules of engagement from confirmed assets
The client and tester agree the rules of engagement, using the template in NIST SP 800-115 as a starting point. The written scope lists the confirmed IP addresses, domains and applications, the protocols allowed to be attacked, testing windows, emergency contacts and any assets that must stay untouched. Third-party hosts and SaaS services need their own authorization or are excluded. The step closes when both parties sign off on a target list that matches the inventory.
Validate targets before exploitation begins
Before active testing, the tester re-checks that each target still resolves to the client's infrastructure and still matches the inventory record. Assets that moved to a cloud provider, a CDN or a SaaS vendor are flagged and handled under the agreed scope. This prevents testing against addresses that have been reassigned. The output is a validated target list with any discrepancies documented and resolved in writing.
Combine discovery, scanning and manual testing
NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. Here the tester uses the inventory and scanning results to choose where manual penetration work goes, such as authentication flows on newly found web applications or exposed management interfaces. Exploitation is limited to the agreed rules. The step is complete when each target has either a documented test outcome or a recorded reason it was not tested.
Feed findings back into inventory and monitoring
Findings are mapped to the assets they affect, and the inventory records the exposure, the owner and the fix status. Services the test uncovered that were absent from the inventory are added and placed under continuous monitoring. Any control gap that let an asset go unnoticed, such as a missing ownership tag, is logged for the process owner. The step is done when every finding is linked to an inventory record and every new asset is tracked.
Retest and confirm the inventory stays current
After remediation, the team retests the affected assets and checks that the inventory reflects the fixed state, including any decommissioned hosts. Monitoring then confirms that changes since the test are detected before the next scheduled test. The output is a retest record per finding and an updated inventory that the next test will start from. The team should ask the provider how retests are billed and scoped before signing, since that depends on the written scope.

What CISA BOD 23-01 sets for discovery and enumeration cycles

CISA's Binding Operational Directive 23-01, issued on 3 October 2022, sets the most explicit cadence published for keeping an external asset inventory current. It requires federal civilian agencies to run automated asset discovery every 7 days, covering at least their entire IPv4 space, and to enumerate vulnerabilities across all discovered assets every 14 days. Vulnerability detection signatures must be updated no more than 24 hours after the vendor releases them. The directive covers IP-addressable assets reachable over IPv4 and IPv6, including roaming and cloud assets, but excludes ephemeral assets such as containers and third-party SaaS. Those exclusions matter: a short-lived container or a SaaS tenant can expose a login page for weeks without appearing in a directive-driven inventory, so teams should not assume the federal cadence covers them.

BOD 23-01 applies to federal civilian agencies. If your organization is not one, treat the directive as a benchmark, not an obligation, and confirm with your regulator, contracting officer or internal audit whether any equivalent discovery cadence applies to you. For eligible US organizations with public, static IPv4 addresses, CISA's no-cost Cyber Hygiene Services offers continuous monitoring of internet-accessible assets, with weekly reports and ad hoc alerts for urgent issues. Check eligibility against CISA's current service terms before planning around it, and note that its scope is narrower than the directive: it does not replace discovery across IPv6, cloud or ephemeral assets.

For an external penetration test, the practical question is which cadence your own program can actually sustain. Ask whether discovery runs on a schedule that matches how quickly your external footprint changes, whether IPv6 and cloud ranges are in scope, and who reviews new findings before the next test is scoped. If discovery runs weekly but the test is booked once a year, the test should start from the inventory as it stands that day, not from a list written months earlier. Confirm these details with your provider in writing before the scope is agreed.

What you receive from each approach

This table sets the outputs of continuous attack surface management against the outputs of an external penetration test, so you can see which artifacts each one gives you and which you must confirm before signing. Read the rows as questions to put to each provider, because formats, retention and evidence depth vary by vendor and by written scope.

Deliverable	Attack surface management	External penetration test
Primary output	Continuous inventory of discovered internet-facing hosts, services and domains, with change records over time	Written report of validated findings for the scoped targets, produced at the end of a defined test window
Alerts and cadence	Exposure alerts and change notifications as discovery runs, which may be daily or continuous depending on the product	No ongoing alerts; results arrive at report delivery and any retest is a separate, scoped engagement
Evidence of exploitation	Usually none. Shows that a service exists and its exposure, not whether it can be abused	Proof of exploitation or validation steps for each confirmed finding, with the conditions required to reproduce it
Retest results	Re-detection of assets and changes shows up in the inventory, but this does not confirm a fix worked	Retest of named findings against the original evidence, typically recorded in a follow-up report
Executive summary	Dashboards or summary views may exist; confirm whether they are exportable for leadership reporting	Narrative summary of risk and scope written by the testers, usually included as a standard section
Format and export	Confirm whether inventory exports are in CSV, JSON or API form and whether they can feed your CMDB or ticketing system	Confirm report format, whether a machine-readable findings export is included, and who signs the report
Retention	Confirm how long asset history and change records are kept and whether you can export them before deletion	Confirm how long the report, raw evidence and tester notes are retained, and where they are stored
Audit use	Supports asset-list and scope evidence; confirm with your assessor whether they accept inventory output as scope proof	Supports a penetration test record; confirm with your assessor whether the report scope, method and tester qualifications meet their requirements

When compliance frameworks call for each approach

Compliance frameworks rarely ask for attack surface management or external penetration testing by name. They set cadences, baselines and evidence expectations, and those expectations decide how much of each approach an organization needs. The cards below map the supplied requirements to the decisions a team has to make.

Annual external penetration tests under CIS 18.2

CIS Controls v8.1 Safeguard 18.2 asks for periodic external penetration tests based on program requirements, and no less than annually. The safeguard sets a floor for the attack itself, not for continuous discovery. A team that only tests once a year can miss a host brought online in March, so the test scope should be fed by an asset inventory built between tests. Confirm with your assessor which assets count as in scope and how they will verify that the list used for testing matches the internet-facing estate.

Validating detections after each test

Safeguard 18.4 asks organizations to validate security measures after each penetration test, so that detections cover the techniques testers used. This is the point where external testing feeds monitoring. Discovery tooling tells you which new hosts and services appeared, while the test shows whether an attacker reaching them would be noticed. Ask for a mapping from each test finding to the detection that should have fired, and keep that record as evidence for your assessor.

Scheduled scanning alongside periodic testing

NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing. Scanning covers the known asset list on a routine schedule, while the penetration test checks whether the weaknesses found by scanners can be chained into real access. Where a framework expects both, document which tool discovers assets, which tool enumerates vulnerabilities, and how each output is handed to the tester before the engagement starts.

Independent testers at the high baseline

NIST SP 800-53 Rev. 5 control CA-8 covers penetration testing, with enhancements for an independent team and for red team exercises. SP 800-53B selects CA-8 and CA-8(1) only in the high baseline. If you run a federal or high-impact system, expect the independence requirement to shape who performs the external test. For systems at other baselines, confirm with the authorizing official whether CA-8 applies and whether the tester must be separate from the team that operates the asset.

Threat-led testing and DORA

DORA Article 25 lists testing methods that include vulnerability assessments and scans, open source analyses and penetration testing. Article 26 requires threat-led penetration testing at least every 3 years for entities their competent authority identifies. For a financial entity, the external attack surface is part of the scope the regulator will expect you to define. Ask your competent authority which entities are in scope for threat-led testing, and make sure your asset inventory covers the cloud and third-party-hosted services the testers will reach.

Federal discovery cycles under BOD 23-01

CISA's BOD 23-01 requires federal civilian agencies to run automated asset discovery every 7 days across at least their entire IPv4 space, and vulnerability enumeration across discovered assets every 14 days. The directive excludes ephemeral assets such as containers and third-party SaaS, so those still need their own inventory. Agencies outside the directive can borrow its cadence as a benchmark. Confirm with your agency whether cloud and roaming assets fall under the directive's scope before relying on its cycles.

Questions buyers ask before choosing external attack surface management or penetration testing

Does attack surface management replace external penetration testing?

No. Attack surface management finds and watches internet-facing assets, while an external penetration test tries to exploit specific weaknesses on those assets within agreed rules. NIST SP 800-115 describes external testing as beginning with reconnaissance of public registration and DNS data, then enumerating hosts and listening services before attacking allowed protocols such as HTTP and SMTP, so discovery is a step inside the test rather than a substitute for it. CIS Controls v8.1 Safeguard 18.2 asks for periodic external penetration tests, no less than annually, which discovery alone does not satisfy. Most mature programs run both: continuous discovery between tests, and a scheduled test that exploits what the discovery found.

What does each approach cost in effort, and what drives that effort?

Attack surface management is mostly recurring operational effort: tooling, reviewing new and changed assets, and assigning owners for each finding. A penetration test is a bounded engagement with a one-time effort that scales with the number of hosts, applications, authentication levels and the depth of exploitation agreed in advance. Ask any provider for the cost components in writing: who is paid for scanning, analyst triage, testing hours, retesting and reporting. Discovery effort rises with the size and churn of your internet footprint, including cloud accounts and third-party services. Test effort rises with scope breadth, the number of retests and whether production systems are included. Neither figure is published here, so request a quote built from your asset count and scope.

How long does each take to start producing value?

Discovery usually produces a first inventory sooner, because it starts from public registration data, DNS and scanning rather than a negotiated test window. A penetration test produces value at the end of its agreed timeline, when the written report and retest plan arrive. The timeline depends on scope, tester availability and how quickly the client confirms rules of engagement, so no duration is stated here. Confirm with each provider the time to first results, the time to a complete asset list, and when findings are handed over. Early discovery output also makes a later penetration test faster to scope, because the tester starts from a verified list.

What does the work need from our internal team?

Discovery needs an owner who can confirm which discovered assets belong to the organization, approve or reject third-party and shadow assets, and route findings to system owners. A penetration test needs a named contact for rules of engagement, approval of the testing window, test accounts where authenticated testing is in scope, and someone to fix and verify findings. The client also decides whether production systems may be exploited, which NIST SP 800-115 treats as high risk because real exploits run against production systems and data. Ask providers which of these items they expect you to supply and who signs off on each one.

Can we run external discovery in-house?

Often yes, for a bounded footprint with staff who can operate scanners, maintain the asset list and triage results. The tradeoff is ownership of coverage gaps: an in-house program must decide which discovery sources to use, how often to run them and how to validate what they report. Self-run discovery also needs a process for ephemeral assets, which are harder to catch on a schedule. Penetration testing for exploitation is different, because NIST SP 800-115 describes it as manual, skilled work that carries risk, and PCI SSC's penetration testing guidance says running an automated tool alone does not meet the requirement. Many teams keep discovery in-house and buy the test.

How does CISA BOD 23-01 apply outside federal agencies?

BOD 23-01 is a binding directive for US federal civilian agencies, so it does not apply to private companies, banks or state bodies by default. It requires automated asset discovery every 7 days covering at least the entire IPv4 space, vulnerability enumeration across discovered assets every 14 days, and detection signature updates within 24 hours of vendor release, issued on 3 October 2022. Non-federal organizations can use its cadences as a benchmark for their own program, but should confirm with their regulator or contract whether any cadence is mandatory. The directive excludes ephemeral assets such as containers and third-party SaaS, so those need separate coverage. CISA's Cyber Hygiene Vulnerability Scanning service is available to eligible US organizations on public, static IPv4 addresses.

Why does an accurate asset list make an external penetration test better?

A penetration test can only attack what it knows about, so an incomplete list leaves forgotten hosts, old staging systems and unmanaged cloud endpoints untested. Starting from a verified inventory lets the tester confirm scope, avoid assets the client does not own, and spend effort on exploitation rather than discovery. NIST SP 800-115 describes reconnaissance and enumeration as the early steps of external testing, and an up-to-date list shortens them. Ask the provider how it will confirm asset ownership before testing begins, and how newly discovered assets found during the test will be handled under the rules of engagement.

What to confirm with a provider or your own environment before you buy

Before you buy either service, confirm what the discovery actually covers. An attack surface management provider should state in writing which asset types it finds: public cloud accounts, roaming endpoints, IPv6 space, and third-party SaaS tenants. Ask how it discovers assets that were never registered (DNS, certificate transparency, cloud account enumeration, or scanning of address ranges you supply), and whether it can be pointed at subsidiaries and acquired domains. Note the gaps too. The CISA BOD 23-01 model excludes ephemeral assets such as containers and third-party SaaS, so a provider that follows the same scope may still leave those blind spots open. Ask for the exclusion list in writing. The CISA Cyber Hygiene Services page is a useful reference for what a no-cost government model covers, which makes a good baseline for comparing commercial offers.

For the external penetration test, confirm the rules of engagement before any tester touches a system. The written rules of engagement and safe-harbor terms should name the in-scope IP addresses and domains, the permitted techniques, testing windows, emergency contacts, and what happens when a tester finds a live compromise. NIST SP 800-115 includes a rules of engagement template in its Appendix B, which you can use as a checklist when reviewing a proposal. Ask who owns the data the tester collects, how credentials and sensitive records found during testing are handled and destroyed, and where tester work papers are stored. Ask also whether scans are authenticated, because an unauthenticated external test and an authenticated one answer different questions, and the proposal should say which it performs and which it does not.

Finally, decide who in your team triages alerts and findings before the first run. An attack surface feed can raise many new exposures in a week, and each needs an owner, a severity decision and a path to a ticket. Name the person or role that accepts asset ownership, confirms whether a newly found host is authorized, and escalates urgent items. Ask the provider how alerts are delivered, how false positives are marked, and whether the tester and the monitoring team share one asset inventory. Check whether your own environment can support this: a current asset register, named owners for domains and cloud accounts, and a change process that tells the provider about planned launches. Ask for these points in the written scope, because they determine how useful the external test will be.

How DeployOpen scopes, delivers and supports external testing and asset visibility

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and runs security testing as part of that work. For external attack surface management and external penetration testing, we start from a written scope that sets which internet-facing assets are in play and how each activity is run, then hand over the records you need to keep the asset list and test results current.

How we scope

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the external assets, domains and address ranges to be included, and what is excluded.
We confirm the rules of engagement, testing windows and contacts for external activity before any testing begins.
Ask us to state which discovery sources feed the asset list and who approves additions to it.

How we build

We help build or configure the discovery and inventory process so the asset list is recorded in your environment.
External penetration testing follows a documented method covering reconnaissance, enumeration, validation and reporting.
Testers record which assets were in scope at test time, so findings can be traced back to a known inventory.
Where we deploy or configure monitoring tooling, we document its scope, schedule and data handling choices.

How we hand over

Deliverables include the agreed asset inventory, test report and a list of validated findings with reproduction steps.
Documentation covers the discovery cadence, scan schedule and how newly found assets are routed to owners.
We walk your team through the handover so ownership of the inventory and retests stays with your staff.
Ask for a sample report and inventory format before signing so you know what your auditors will receive.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
A retainer can cover periodic re-scoping as your internet-facing footprint changes.
Retests after remediation can be scoped as a defined piece of work, with the same method as the original test.
Confirm response expectations, reporting cadence and escalation contacts in the retainer terms before work begins.