Network penetration testing checklist

By The PenTest Index · Sources checked October 10, 2026

A network penetration testing checklist covers five stages: set the scope, check the quote, authorize and prepare, track the test, and close it out with fixes and a retest. For every check, get proof in writing, and keep what was agreed separate from what was actually tested. This checklist does not authorize testing.

Below are 43 checks in the order you'll need them. Each one shows who does it, the proof to get, and where the check comes from. Copy or print the list, then use the worked example to see how it changes a real price comparison.

The network penetration testing checklist

Work through the stages in order. A network penetration test (pen test, or pentest) is an authorized attempt by people to break into your network the way an attacker would, so you can fix what they find. Your side of that job is mostly paperwork: saying exactly what gets tested, who allowed it, and what you get back.

Pick the kind of test you're planning and the list trims itself.

How to record your answers. For each line, write down your answer, the proof, and one owner. Then mark it twice. Before the test: open, agreed, excluded (with the reason) or doesn't apply (with the reason). After the test: performed, blocked or not tested, with the result written separately. "Agreed" is not the same as "performed," and "performed" is not the same as "secure." Keep passwords, keys and findings out of this document.

In the Source column, "NIST" means NIST SP 800-115 and "PCI" means the PCI Security Standards Council's Penetration Testing Guidance v1.1. "Our guidance" means the check is our own advice, not something a standard says. Full references are in Sources.

Learning to run the test yourself? This page is for the company being tested. Start with NIST SP 800-115 and our walk-through of how a penetration test is done.

Test type

Checklist choices are not saved or submitted as a form.

Stage 1: Set the scope (before you ask for a price)

Stage 1: Set the scope (before you ask for a price)
No.	Check	Proof to get	Who	Applies to	Source	Checked
No.1	CheckWrite down the question the test must answer and who will read the report.	Proof to getThe request itself (insurer form, contract clause, audit request) or your own goal, with the deadline.	WhoYou	Applies toBoth	SourceOur guidance	Checked
No.2	CheckChoose where the tester starts: external (from the internet), internal (from inside your network), or both. If both, plan the external part first.	Proof to getOne line per phase saying where the tester starts.	WhoYou	Applies toBoth	SourceNIST §2.4.1	Checked
No.3	CheckList your external targets: public IP addresses and ranges, domains, VPN and other remote-access gateways.	Proof to getA dated target list with the number of addresses.	WhoYou	Applies toExternal	SourceNIST §6.5; PCI §2.2.1	Checked
No.4	CheckList your internal targets: subnets or VLANs, the number of live devices, directory domains, and sites.	Proof to getA dated inventory. Note the size of each range and the number of live devices separately. They are different numbers.	WhoYou	Applies toInternal	SourceNIST §6.5	Checked
No.5	CheckList what is off limits, by IP address and system name.	Proof to getAn exclusion list with a reason beside each entry.	WhoYou	Applies toBoth	SourceNIST §6.5	Checked
No.6	CheckMark every target you don't own or control: hosted, cloud, shared, or a supplier's.	Proof to getThe owner's written consent, or the platform's published testing policy.	WhoYou	Applies toBoth	SourceNIST §6.5; PCI §4.1.4	Checked
No.7	CheckDecide what the tester starts with inside: no account, a standard user account, or more.	Proof to getThe account type written into the scope.	WhoYou	Applies toInternal	SourceNIST §2.4.1	Checked
No.8	CheckDecide how the tester gets inside: a shipped device, a virtual machine, a VPN account, or a visit.	Proof to getThe access method and the network segment it sits on.	WhoYou and provider	Applies toInternal	SourceNIST §6.5; PCI §4.1.3	Checked
No.9	CheckSay yes or no to each extra: Active Directory or another directory, segmentation checks, wireless, cloud settings, web apps and APIs, phishing, physical entry.	Proof to getA written "in" or "out" for each one.	WhoYou and provider	Applies toBoth	SourceNIST §4.4; PCI §2.2.3, §2.5; our guidance	Checked
No.10	CheckIf you rely on segmentation, name each boundary: from where, to where, and whether access should be blocked or allowed.	Proof to getA boundary list both sides have seen.	WhoYou	Applies toBoth	SourcePCI §2.4, §4.2.3	Checked
No.11	CheckAgree the end point: what result means the test is done.	Proof to getSuccess criteria written into the rules of engagement.	WhoYou and provider	Applies toBoth	SourcePCI §4.1.5	Checked
No.12	CheckAsk the report reader what they need: full report or summary letter, tester independence, how recent, proof that fixes were checked.	Proof to getTheir reply in writing.	WhoYou	Applies toBoth	SourceOur guidance	Checked

A few terms. A network segment is a part of your network; a VLAN is one way to group devices into a segment. Segmentation uses controls to limit traffic between parts of the network. A directory such as Microsoft Active Directory is the system that holds your user accounts and decides who can log in to what.

Stuck somewhere on lines 1 to 12? Find My PenTest Match asks why you need the test and what needs testing, then gives you a scope checklist to copy or print. It's free, asks for no email, and sends nothing to providers. Our comparison covers mostly web app and API offers so far, so for a network test treat it as a scoping aid, not a provider list.

Find My PenTest Match

Stage 2: Check the quote against your scope

Stage 2: Check the quote against your scope
No.	Check	Proof to get	Who	Applies to	Source	Checked
No.13	CheckThe quote lists the same targets and the same counts as your lists in lines 3 to 5.	Proof to getTargets itemized per phase in the quote.	WhoYou	Applies toBoth	SourceOur guidance	Checked
No.14	CheckIt says how much is people testing and how much is automated scanning, and who confirms each finding.	Proof to getA written description of the method and the people.	WhoProvider	Applies toBoth	SourcePCI §2.1, §4.2.2	Checked
No.15	CheckIt says who tests, and that they are independent of the people who run your systems.	Proof to getNamed roles and relevant experience.	WhoProvider	Applies toBoth	SourcePCI §3	Checked
No.16	CheckThe price unit is clear (per IP address, per test, per day, or credits) and the total includes any required platform or subscription.	Proof to getAn itemized total in a stated currency. A required charge with no price means the total is incomplete, not zero.	WhoYou	Applies toBoth	SourceOur guidance	Checked
No.17	CheckRetest terms: how many, which findings, how long the window is, when the clock starts, whether the report is updated, and what it costs after that.	Proof to getThe retest terms in writing.	WhoYou	Applies toBoth	SourcePCI §4.3.2, §5.2.2; our guidance	Checked
No.18	CheckReport: you've seen a sample and you have a date for the final report.	Proof to getThe sample, and the date in writing.	WhoYou	Applies toBoth	SourcePCI §5.2.1	Checked
No.19	CheckThe contract says how your data and the test evidence are stored, sent, kept and removed.	Proof to getThe contract clause.	WhoYou and provider	Applies toBoth	SourceNIST §6.5; PCI §5.3.2	Checked
No.20	CheckYour legal contact has read the contract: liability, non-disclosure and privacy.	Proof to getTheir sign-off.	WhoYou	Applies toBoth	SourceNIST §6.6	Checked
No.21	CheckAlready have a provider? Hold your current agreement up to lines 13 to 19 before you buy again.	Proof to getWritten confirmation from that provider of what's included.	WhoYou	Applies toBoth	SourceOur guidance	Checked

A retest is the tester going back to check that a fix worked.

Scope written and ready for offers? Send every provider the same request so the answers line up. Our quote request template gives you the wording. Already holding a quote? Run it through the Quote Check.

Stage 3: Authorize and prepare (the week before)

Stage 3: Authorize and prepare (the week before)
No.	Check	Proof to get	Who	Applies to	Source	Checked
No.22	CheckWritten authorization, signed by someone with authority over every target, naming the targets, dates and allowed activities.	Proof to getThe signed document, plus any third-party consent required under line 6.	WhoYou	Applies toBoth	SourceNIST §5.2.1, §6.5	Checked
No.23	CheckRules of engagement agreed: testing hours, the type and level of testing allowed, what is banned (denial of service, locking out accounts), and how far the tester may go after getting in.	Proof to getThe signed rules of engagement.	WhoYou and provider	Applies toBoth	SourceNIST §6.5; PCI §4.1.3	Checked
No.24	CheckA call plan: named contacts on both sides, your security or network operations desk, who can say "stop," and who can say "resume."	Proof to getA contact list with phone numbers.	WhoYou and provider	Applies toBoth	SourceNIST §6.5	Checked
No.25	CheckThe IP addresses the tester will work from.	Proof to getThe list, written into the plan.	WhoProvider	Applies toBoth	SourceNIST §6.5; PCI §4.1.3	Checked
No.26	CheckBlocking and alerting tools: decide whether the tester's traffic is let through, and write down every exception.	Proof to getThe decision in writing and a list of each change made.	WhoYou	Applies toBoth	SourceNIST §6.5; PCI §4.1.7	Checked
No.27	CheckTell the people who would otherwise raise the alarm (security operations, your managed service provider, your hosting provider) and name who tells them.	Proof to getThe notices sent.	WhoYou	Applies toBoth	SourceNIST §6.5	Checked
No.28	CheckTest accounts created through your normal process, and the tester's device or VPN in place and confirmed working.	Proof to getAccount names (never passwords) and where the device sits.	WhoYou and provider	Applies toInternal	SourcePCI §4.1.3	Checked
No.29	CheckDocuments handed over: network diagram, the services you expect to be exposed, the last test report, recent scan results.	Proof to getSent through the private channel you agreed.	WhoYou	Applies toBoth	SourcePCI §4.1.2, §4.1.6	Checked
No.30	CheckA plan for surprises: if the tester finds a real intruder or reaches sensitive data, does testing stop, who is told, and who restarts it?	Proof to getThe incident section of the plan.	WhoYou and provider	Applies toBoth	SourceNIST §6.5; PCI §4.2.4	Checked
No.31	CheckBackups checked, and risky changes paused for the test window.	Proof to getA restore you tested recently; a change freeze note.	WhoYou	Applies toBoth	SourceOur guidance	Checked

Rules of engagement are the written limits both sides sign before testing. NIST SP 800-115 includes a template as its Appendix B.

Stage 4: During the test

Stage 4: During the test
No.	Check	Proof to get	Who	Applies to	Source	Checked
No.32	CheckConfirmation that testing has started, and from which addresses.	Proof to getA message from the test lead.	WhoProvider	Applies toBoth	SourceOur guidance	Checked
No.33	CheckKeep your own logs for the test window. They show you what your tools caught and missed.	Proof to getSaved logs with the dates.	WhoYou	Applies toBoth	SourceNIST Executive Summary	Checked
No.34	CheckSerious findings are reported when they're found, not saved for the final report.	Proof to getThe message, and how fast it arrived.	WhoProvider	Applies toBoth	SourcePCI §4.1.3; our guidance	Checked
No.35	CheckAny change (a new target, extra access, a blocking tool switched off) is approved in writing first and recorded.	Proof to getA dated change note.	WhoYou and provider	Applies toBoth	SourceOur guidance	Checked
No.36	CheckA target the tester couldn't reach is recorded as blocked or not tested. It is never recorded as clean.	Proof to getThe entry in the tester's notes or report.	WhoProvider	Applies toBoth	SourceOur guidance	Checked

Stage 5: Close it out

Stage 5: Close it out
No.	Check	Proof to get	Who	Applies to	Source	Checked
No.37	CheckCompare the report to the scope: targets tested, blocked and left out; where the tester really started and with which accounts; any limits on the work.	Proof to getThe report's scope and limitations sections.	WhoYou	Applies toBoth	SourcePCI §5.2.1, §5.4	Checked
No.38	CheckEach finding shows evidence, the systems affected, a risk rating with the rating method explained, and a fix.	Proof to getThe findings section.	WhoYou	Applies toBoth	SourcePCI §5.1.1, §5.4	Checked
No.39	CheckClean up: test accounts removed, tester tools removed, allow-list entries undone, the device returned.	Proof to getA cleanup note from both sides.	WhoYou and provider	Applies toBoth	SourcePCI §4.3.3	Checked
No.40	CheckFix the cause, not only the one place it was found. Give each fix an owner and a date.	Proof to getYour fix list.	WhoYou	Applies toBoth	SourcePCI §4.3.1; NIST §8.3	Checked
No.41	CheckRequest the retest inside the window. Get a record that ties each recheck to the original finding, with dates and the result.	Proof to getThe retest report.	WhoYou and provider	Applies toBoth	SourcePCI §4.3.2, §5.2.2; NIST §8.3	Checked
No.42	CheckConfirm the tester removed or kept your data and the evidence as the contract says.	Proof to getWritten confirmation.	WhoProvider	Applies toBoth	SourceNIST §7.4.4; PCI §5.3.2	Checked
No.43	CheckSend the report reader what they asked for in line 12, store the report somewhere safe, and note what change would call for a new test.	Proof to getTheir acknowledgment.	WhoYou	Applies toBoth	SourceOur guidance; PCI §2.6	Checked

Test type

Checklist choices are not saved or submitted as a form.

What does a filled-in checklist look like?

It names real targets, real counts and real proof, and that is what makes two offers comparable. Here is a made-up firm to show it. Every detail about the firm is invented. The provider prices and terms are real, published by the providers, and checked on October 10, 2026.

Say you run a 60-person accounting firm. You have one office, 14 public IP addresses, about 180 devices on two internal VLANs, and Active Directory. Your cyber insurance renewal form is due in ten weeks and asks for an external and an internal penetration test.

Table columns: Line; Your answer; Proof; Before the test.
Line	Your answer	Proof	Before the test
1	Insurer wants external and internal test evidence within ten weeks.	The renewal form.	Agreed
3	14 public IP addresses, including the VPN gateway.	Target list dated this month.	Agreed
4	Two VLANs, about 180 live devices, one directory domain.	Inventory export.	Agreed
7	Tester starts with one standard user account.	Written in the scope.	Agreed
9	Active Directory in. Wireless, phishing and physical entry out.	Scope, with a reason for each "out."	Agreed
10	Staff VLAN should not reach the backup server.	Boundary list.	Agreed
12	Insurer hasn't said whether a summary letter is enough.	None yet.	Open
17	Fixes will take about six weeks. Retest must still be available then.	None yet.	Open

Three lines get skipped more than any others: line 6 (targets you don't own), line 17 (the retest window) and line 26 (blocking tools). All three are cheap to settle now and expensive to argue about later.

What that scope does to a published price

Now hold two real published offers up to that scope. This is our Purchase Check: one buyer requirement at a time, against the exact terms a provider publishes. "Supported" means that one condition is supported by the page we read. It says nothing about testing quality, and we have not bought or run either service.

The firm has 14 + 180 = 194 host IP addresses, assuming each device is one address.

Table columns: Requirement in this example; Offer and published terms; Finding; Question to send.
Requirement in this example	Offer and published terms	Finding	Question to send
All 194 hosts covered	Synack SynackST: from $10,283 per test (US dollars), up to 100 host IPs, five-day assessment window.	Mismatch as a single test. 194 is more than 100.	"Can one test cover 194 hosts, or do we need a larger package?"
All 194 hosts covered	Synack Synack14: from $27,120 per test (US dollars), up to 250 host IPs, fourteen-day assessment window.	Supported for the host count. 194 is under 250.	"Do internal hosts count toward the same cap as external ones, and how do your testers get inside our network?"
A complete price	Synack states its platform is required and billed as a separate line item. It also says a Basic Platform is available at no cost.	Unresolved. Which platform applies to this purchase isn't stated. An unknown required charge is not zero.	"Is the Basic Platform eligible for this purchase? Please itemize the test and any platform charge."
Active Directory and the VLAN boundary tested	NetSPI internal network testing: the page names Active Directory vulnerabilities, offline password auditing of AD accounts, system and domain-level privilege escalation, and segmentation testing.	Supported as a stated capability. Price, retest terms and timing are not on the page: Unresolved.	"Please quote an internal test from a standard user account that includes our directory and the one boundary in our list."
External test of 14 public addresses	The NetSPI page we read covers internal testing only.	Unresolved from this page.	"Please quote the external phase separately."
Retest available six weeks after findings	No retest count or window is published on either page.	Unresolved for both.	"How many retests are included, and how long after the report can we request one?"

Sources: Synack pricing and NetSPI internal network testing, both provider-published, checked October 10, 2026. "From" prices are starting amounts, not quotes.

What this firm should do. Don't budget on $10,283. As published, that package stops at 100 host IPs and this scope has 194. Two of them would start at 2 × $10,283 = $20,566 and cover up to 200 hosts, but Synack's page doesn't say whether one scope can be split across two tests, so ask before you count on it. The comparison that fits as published is Synack14 from $27,120 plus an unsettled platform line, against a NetSPI quote.

Which one deserves the first call depends on what matters more to you. If you want a published starting price and a fixed fourteen-day window, start with Synack and send the questions above. If testing the directory in depth is the point, NetSPI's page says more about that work, and you'll need a quote to see the price. If your current IT security provider can meet lines 13 to 19 in writing, you may not need either.

One more thing to ask both: NetSPI's site says its merger with Synack closed in October 2026, that existing engagements are unchanged, and that the two remain different delivery models (NetSPI's merger page, checked October 10, 2026). Ask which company signs your contract. Our Synack and NetSPI pages track the rest of their published terms.

See Synack's published packages

Read NetSPI's stated internal network coverage

A request you can copy and adapt:

Please quote an external test of our public addresses and an internal test of our listed devices as separate phases. For the internal phase, confirm the starting account, directory coverage and the boundary checks we listed. Show what's excluded, the final report date, the full price including any required platform, and what the retest includes and when it expires. Mark anything you've assumed.

Do you need an external test, an internal test or both?

Pick the starting point that answers your question. An external test starts on the internet and shows what an outsider can reach. An internal test starts inside your network and shows how far someone could get once they're in. One does not automatically include the other (NIST SP 800-115, §2.4.1).

Table columns: Your question; Test to consider; What to agree.
Your question	Test to consider	What to agree
What can someone on the internet reach?	External	The public targets in line 3, and whether your blocking tools stay on.
How far could a stolen laptop or a dishonest insider get?	Internal	Where the tester sits, the starting account, and the targets in line 4.
Both, or the report reader asked for both	Both, as separate phases	Each phase written out on its own, external first.
Do our network walls hold?	Internal, with segmentation checks	The named boundaries in line 10.
We only need known weaknesses found and listed	Maybe a vulnerability scan instead	Ask the report reader whether a scan is enough.
The worry is our web app, its logins or its API	An application test	A network test alone won't answer it. See which type of test fits.

Two mix-ups to avoid. "Internal" describes where the tester starts, not who does the work. An outside company can run an internal test. And how much you tell the tester in advance (often called black box for nothing, grey box for some, white box for everything) is a separate choice from where they start. Write down what you'll hand over instead of relying on the label.

If your firm has no office network and no servers of its own, an internal network test may have very little to test. Ask the person who requested it which systems they mean.

What do you need to give the pen testers?

A target list, a way in for internal work, a few documents, and names to call. That's lines 24 to 29:

Your target and exclusion lists (lines 3 to 5).
For internal work, a test account made the normal way and a place on the network for their device or VPN (line 28).
A network diagram, the services you expect to be exposed, your last test report and recent scan results (line 29). The PCI guidance suggests the same set for card-data tests (§4.1.2, §4.1.6).
A call plan with a named contact who can say "stop" (line 24).

Get one thing from them too: the IP addresses they'll test from (line 25). NIST's guide says to record these so your team can tell test traffic from a real attack (§6.5).

Share passwords and keys only through the channel the provider sets up. Never put them in a checklist, a ticket or an email.

Should you whitelist the testers' IP addresses?

Decide what you're testing first. If the tester's traffic is let through your blocking tools, you learn how strong the systems behind them are. If the tools stay on, you learn how good the tools are at stopping this tester in the time you paid for. Both are fair questions. They're different tests.

The sources lean the same way and leave the choice to you. NIST says security staff can set monitoring tools to ignore the tester's addresses "if appropriate for the goals of the assessment" (§6.5). The PCI guidance says that for card-data tests, interference from blocking tools should be avoided, because the point is to test the services themselves (§4.1.7).

Our advice: write the choice down before the test (line 26), record every exception while it runs (line 35), and make sure the report says which results were found with help. A finding reached only after you opened a door is still worth fixing, but it doesn't prove an outsider could have opened that door. Then remove every exception afterward (line 39).

Who has to sign off before testing starts?

Someone with authority over every system on the target list, in writing, before any testing begins (line 22). NIST's guide says the plan should list the systems allowed and the systems off limits, and that when part of your network sits with a third party, that owner "usually must also consent in writing" (§6.5). It also suggests having your legal team review the plan and contract (§6.6).

Nothing on this page, and no scope checklist from us, is permission to test anything.

Do cloud systems need the provider's approval first?

It depends on the platform, the service and the activity, so read the current policy for yours. Two examples, both checked October 10, 2026:

Amazon Web Services says customers may run penetration tests against a published list of services without prior approval, except testing that includes command and control (C2). Denial-of-service testing is prohibited under this policy; DDoS simulations follow a separate policy. Covert adversarial simulations and phishing simulations need approval through a form. AWS policy.
Microsoft Azure says: "As of June 15, 2017, Microsoft no longer requires pre-approval to conduct a penetration test against Azure resources." Testers must follow Microsoft's Penetration Testing Rules of Engagement, and denial-of-service testing is prohibited. Azure guidance.

So "always notify your cloud provider first" is not a universal rule, and "never" isn't either. For a hosting company, a data center or a software supplier, check your contract. If it's silent, ask in writing (line 6).

Will a network penetration test take systems down?

It can, which is why the limits are agreed first. NIST's guide is blunt about it: systems "may be damaged or otherwise rendered inoperable" during penetration testing, and while experienced testers lower that risk, "it can never be fully eliminated" (§5.2). It also says leaving out tests known to cause outages reduces the risk (§2.3).

Four lines on the checklist carry the load here. Line 5 keeps fragile systems off the list. Line 23 bans denial-of-service testing and account lockouts, and sets the hours. Line 24 gives someone the power to stop the test. Line 31 makes sure you can restore if something breaks.

If one system worries you, say so by name. A tester who knows the old phone server falls over when scanned can go gently or skip it. One who doesn't know can't.

How do you check the report against the scope?

Put the scope and the report side by side and look for gaps between what was agreed and what was done. Then check that each finding has evidence and a fix you can act on (lines 37 and 38). The PCI guidance has a useful report review list in §5.4. It was written for card-data tests and isn't a score, but the questions travel well.

Here's what a mismatch looks like, using the made-up firm again:

Table columns: Agreed; What the report shows; So; Ask.
Agreed	What the report shows	So	Ask
Start from a standard user account	An administrator account was supplied on day three	Later findings may have come from a stronger starting point	"Which findings came before the admin account was added?"
Staff VLAN to backup server tested	A firewall diagram, no test record	A diagram shows intent. It isn't proof the path was tried	"Which source and destination did you test, and what happened?"
All 180 devices	One device never answered	The device was unresponsive. It is not clean	"What checks were performed, and which were blocked or not tested?"

Whether the report satisfies your insurer, auditor or customer is their call. Ask them (line 12) rather than the provider.

What should a retest include?

A recheck of each original finding, tied to its ID, with a date and a result. NIST's guide makes a point most buyers miss: a retest only confirms the fix if it repeats the original test (§8.3). A fresh scan that happens to come back quiet is weaker proof.

That's also the answer to "is a rescan the same as a retest?" The name doesn't tell you. Ask what gets rechecked, who does it, and what you receive. A retest record should look something like this (invented example):

Table columns: Finding; Original result; What you changed; Rechecked; Result; Still open.
Finding	Original result	What you changed	Rechecked	Result	Still open
F-03	Staff VLAN could reach the backup server's admin page	Firewall rule added	Same path tried again from the same VLAN, by the tester, 41 days after the report	Blocked	None

"Fix reported" and "fix verified" are different states. Only the second can be presented as a verified fix in what you send your report reader.

Sources and how we built this checklist

We wrote this checklist ourselves, from the guidance below, in the order a buyer needs it. Checks marked "Our guidance" are our own advice. We don't run penetration tests, we haven't bought the services named here, and the accounting firm is invented. None of the organizations below endorse this page. Read how our Purchase Check works and how we make money.

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008. Sections 2.3, 2.4, 4.4, 5.2, 6.5, 6.6, 7.4.4, 8.3 and the Executive Summary. Publication page. Read October 10, 2026. Guidance, not law. Its tool lists are dated; its planning advice is what we used.
PCI Security Standards Council, Information Supplement: Penetration Testing Guidance, version 1.1, September 2017. Document. Read October 10, 2026. Supplemental guidance written for PCI DSS version 3.2. It is not the text of the current standard.
Amazon Web Services, penetration testing policy. Page. Checked October 10, 2026.
Microsoft, Azure penetration testing guidance and Rules of Engagement. Page. Checked October 10, 2026.
Synack, pricing page: SynackST, Synack14, platform line item, Basic Platform. Provider-published. Page. Checked October 10, 2026.
NetSPI, internal network penetration testing page and merger page. Provider-published. Service page · Merger page. Checked October 10, 2026.

Budgeting for the test? See published penetration test prices. Writing the scope for something other than a network? Start with a filled-in penetration testing scope.