Intrusion test: what it means and which test you need
By The PenTest Index · Sources checked October 9, 2026
An intrusion test usually means, in cybersecurity, a penetration test: authorized testers try to get past your systems' security and report what worked. The phrase translates the French test d'intrusion. The name alone doesn't say what gets tested, so confirm the systems, the starting access and the report before you buy.
The table below turns the phrase into the test you'd order. After it come the questions that settle a vague request and a worked check on two real packages.
Which intrusion test do you need?
Pick the test by the question the person who asked wants answered. That question matters more than the label on the document.
| What they want to know | What to ask for | The detail that changes what you buy |
|---|---|---|
| Could someone break into our public systems from the internet? | External penetration test | Name the hosts and services. Say whether your web app and API are included. |
| Could a signed-in user reach another person's or customer's data? | Web app and API penetration test with supplied accounts | Name the accounts, user roles and customer boundaries to test. |
| What could someone do once they're inside our network? | Internal penetration test | State where the tester starts and with what account. |
| Would our alarms notice an attack? | A detection and response exercise, or a penetration test with that goal written into the scope | Say what should be detected and what evidence you want. |
| Which known weaknesses do we have? | Vulnerability scan | Ask whether the requester also wants proof that weaknesses can be exploited. A scan report may not show that. |
| Could someone walk into our office or server room? | Physical intrusion test | Name the building, what's allowed and what's off limits. |
Three scope choices are separate, and suppliers often blur them: what is tested (a network, an app, an API), where testing starts (outside or inside), and what the tester is given (nothing, test logins, documentation, source code). An app that anyone can reach from the internet can still be tested with logins you supply. Ask each provider to spell out the access instead of trusting words like "black box" or "gray box."
Two quick exits. A "water intrusion test" or "vapor intrusion test" is building or equipment testing and has nothing to do with this page. And if you think someone is in your systems right now, follow your incident response plan. A planned test looks for weaknesses; it doesn't investigate a live break-in.
Already sure you need a web app or API test? Compare the published offers for that work.
Is it the same as a penetration test?
Usually, but not always. In an IT contract, questionnaire or quote, "intrusion test" can describe the same work as a penetration test. "Penetration test" is the term NIST defines, and it's the one you should use when you ask for quotes.
Here's the evidence:
- NIST, the US standards agency, defines penetration testing as "security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network." (NIST glossary, from SP 800-115)
- The same glossary lists "penetration" as a synonym of "intrusion." (NIST glossary, from CNSSI 4009-2022)
- Quebec's language office lists "intrusion test" as an English equivalent of test d'intrusion, next to "penetration test," "pentest" and "pen test." (Office québécois de la langue française)
We did not find "intrusion test" as a defined term in NIST's penetration testing entry or in the PCI Security Standards Council glossary. The PCI glossary instead defines "intrusion-detection system," which is the alarm, not the test. That's where the confusion starts. A document translated from French means "try to break in." An English reader may hear "check the alarm."
You'll see the French usage on vendor sites too. ITrust, a French security firm, sells an "external intrusion test" and an "internal intrusion test" on its English pages.
So the name doesn't decide anything. The person who asked decides what they'll accept.
What should you ask if a customer requested one?
Ask them to name the systems, what the test must show, and the report they need. If the request only says "intrusion test," clarifying comes before shopping.
Send this to whoever wrote the requirement:
Your request mentions an intrusion test. To make sure we get the right thing, can you confirm:
- Which systems and environments must it cover?
- Do you expect people actively trying to break in, a vulnerability scan, or a check that our monitoring detects an attack?
- Are there conditions on the tester, such as independence or a specific qualification?
- What must the report contain, and when do you need it?
- We already have [a report / a test included with another service / a provider / nothing]. Would that meet the need? If not, what is missing?
What each answer changes:
- "People trying to break in." You need a penetration test of the systems they named. Use the table above to pick the type.
- "Proof your monitoring caught it." Add a detection goal to the scope. A standard penetration test may not include one.
- "A scan is fine." You may already own what you need. Check before you buy anything.
Say you run a 25-person software company in Ohio. A customer in Lyon sends a security annex that says "the supplier shall perform an annual intrusion test of the platform." You send the five questions. They answer: the web app and its API, human testers, a report within 90 days, no special qualification. That's a web app and API penetration test. Nothing exotic, and now it's in writing.
Can a test or report you already have be enough?
Yes, if it covers what this requester needs and they say so in writing. Compare your existing report with their answers: same systems, recent enough for them, the right kind of testing, and no open findings they care about. Send it and ask. Some security questionnaires only ask what testing you already do. They aren't always an order to buy a new test.
Is an "automated intrusion test" a vulnerability scan?
Sometimes. A vulnerability scan is software that checks your systems for known weaknesses. It's useful. But the label alone doesn't show whether the product only scans, attempts exploitation, or performs the attack your customer is worried about.
| What you buy | What it gives you | What to check |
|---|---|---|
| Vulnerability scan | A list of hosts and likely weaknesses. NIST: "a technique used to identify hosts/host attributes and associated vulnerabilities." (NIST glossary) | Whether the requester also wants weaknesses exploited and the impact shown. |
| Penetration test | Attempts to get past your security, within agreed limits, with a report on what worked. | Which attack scenarios were tried and what was left out. |
| Intrusion detection | Ongoing monitoring that watches for signs of an attack. | It's an alarm you run, not a test you commission. |
The names get borrowed. HTTPCS, a French vendor, describes its scanner as "the easy-to-use, daily automated intrusion test" on its own page. That's the company's wording for a scanning product. We haven't tested it, and a scanner can be the right purchase. Just don't assume a product with "intrusion test" in its name is what your customer meant. Ask them, using question 2 above.
Software also helps human testers, and some newer services lean heavily on AI. Neither a product label nor the presence of a person tells you what was covered. The scope and the report do. Our guide to penetration testing vs vulnerability scanning goes deeper.
What if the real request is to test your alerts?
Then write that goal into the scope. The UK's National Cyber Security Centre notes that scenario-driven tests can be set up so that "the aim is to also gauge the detection and response capabilities your organisation has in place." (NCSC guidance) A penetration test can include this. It doesn't by default, and buying one doesn't give you ongoing monitoring.
Does an external test include logged-in users?
Only if the offer says so. "External" tells you where testing starts. It doesn't tell you whether the tester signs in with accounts you supply or checks that one customer can't see another's data.
Here's that difference on two real packages. The buyer is made up. The packages and prices are what Pentest-Tools.com published on its web app testing page when we read it on October 9, 2026.
The made-up buyer: a document-sharing software company. Its customer wants proof that a normal member can't read or change another member's private documents, including documents that belong to a different customer organization. The company will supply three test accounts, all with the same "Member" permission level: two in one customer organization and one in another.
Our finding: ask for the gray-box package with this scenario written into the scope. The black-box package doesn't fit this buyer as advertised.
| Package, as published | Published price | Fit for this buyer | Why | What's still open |
|---|---|---|---|---|
| Black box web app pentest | $3,400 fixed price. 3 working days, best effort. Report on the 4th day. | Mismatch on starting access | The listed scenario is "anonymous attacker." This buyer must start with supplied member accounts. | Whether the provider would add signed-in testing in writing. Don't assume it. |
| Grey box web app pentest | Starting from $3,400 + $900 per user role. 4+ working days, best effort. Report "when ready." | Supported on starting access. The rest is unresolved. | The listed scenario is "both anonymous & authenticated user." | Whether the two customer organizations, the document actions and the API are covered, and how the provider counts roles. |
The published formula for one user role gives $3,400 + (1 × $900) = $4,300 as a starting amount. That's our arithmetic, not a quote. It holds only if the provider counts three Member accounts as one role, and it doesn't price the API, the cross-customer checks or anything else the provider adds after scoping. The provider's services page says it prices on "the specific complexity of your target (e.g., number of user roles, API endpoints)."
Two things worth knowing here. Three accounts are not three roles. And one role doesn't prove both customer boundaries get tested. Security testing guidance treats "can this user call this function?" and "can this user reach this particular record?" as different checks (OWASP API Security Top 10). Your scope should name both.
"Mismatch" here is about advertised scope against one requirement. It says nothing about how good the testing is, and we haven't bought either package. Read more about how we check offers.
The question that settles it:
Will the statement of work include three supplied Member accounts across two test customer organizations, attempts to read or change another member's private documents within and across those organizations, and those actions through both the browser and the listed API endpoints? Will the report name the boundaries tested and anything excluded? Please confirm how the accounts and organizations affect the price, plus the full commitment, report date and retest terms.
If this is the work you need, ask the provider to confirm that exact scenario in its offer.
View the managed web app testing service
If the answer leaves out a boundary or the API, send the same question to another provider. Compare published offers.
What should you send to a testing provider?
Send every provider the same written request. Same question in, comparable answers out.
Fill in the brackets in your own document. If you don't know something, write "unknown." Don't leave it blank.
Please quote a penetration test for [purpose and who will receive the report]. The targets are [systems and environment], roughly [size and how you counted it].
Testing should start from [outside / inside our network] using [accounts, roles and information we will supply]. The scenarios that matter are [key actions and permission boundaries], including [named API scope, if any].
Please list what is included and excluded, who or what does the testing, the evidence you provide, and the complete price and contract commitment. We need [deliverables] by [date and time zone]. Please state the retest scope, how many rounds, what starts the retest window, whether the deadline applies to requesting or finishing the retest, and any extra charges.
We already have [existing test or provider, or none]. Please say what gap your work would fill. This is a request for scope and price. It is not authorization to test.
https://thepentestindex.com/intrusion-test/
That last line of the request matters. A quote request or a scope brief doesn't give anyone permission to test. Before testing starts, you need written authorization that covers the actual targets and activities, from whoever has the right to give it. Paying for hosting or software doesn't, by itself, let you attack that supplier's systems.
Need help with the brackets? Find My PenTest Match asks why you need the test and what needs testing, then gives you the questions to settle and a scope checklist to copy or print. It's free, with no email or sign-up, and nothing is sent to providers. It compares web app and API offers. For networks, devices or buildings, it gives you the questions to take to a specialist.
For a longer brief with a filled-in example, see our penetration testing scope template.
How much does it cost, and how long does it take?
The phrase doesn't set a price. The scope does. A real quote names what's tested, the access, and the report date.
For one published reference point: Pentest-Tools.com lists a black-box web app test at $3,400 with three working days of testing, and a gray-box test from $3,400 plus $900 per user role with four or more working days (provider-published, read October 9, 2026). Those are prices for one web app from one provider. They aren't a market average, and other providers may require a quote.
When you compare quotes, ask each provider to separate these:
- what's included, and what adding a role, an API or another environment costs
- any required platform fee or subscription
- when testing starts, how long it runs, and when the final report arrives
A stated testing window is not a booked start date or a report deadline. If you have a deadline, get the report date in writing. See published penetration testing prices and what they include.
What should the report and retest show?
The report should show what was tested, what was found, and what to fix. Look for the targets and dates, the scenarios tried, each finding with evidence and a severity you can follow, practical fixes, and anything that was left out. If your customer needs something specific in it, agree on that before you book.
A retest is the provider checking that your fixes worked. Whether it's included depends on the offer. Pentest-Tools.com's services page, for example, says "we include a free re-testing phase to validate your remediation efforts" and describes a manual check followed by an updated report. Its solution brief describes the free retesting as same-scope. We didn't find a number of rounds or a deadline on those sources, so ask. For any provider, confirm which findings are covered, how many rounds, what starts the clock, and what happens if your fixes take longer.
A report describes what was tested, on those dates, under those limits. It doesn't promise you're secure next month. And only your customer or auditor can tell you whether they'll accept it.
Can testing disrupt a live system?
It can. Good planning lowers the risk, but no provider can promise zero impact. The NCSC puts it plainly: testers should avoid undue impact, yet "it's impossible to guarantee that no unexpected reactions to testing will occur." (NCSC guidance)
Before testing starts, agree in writing on the environment and targets, anything that's off limits, the hours testing may run, who to call if something breaks, and when testers must stop.
Sources
Checked October 9, 2026. Provider pages show what the provider publishes. We haven't bought or tested any service named here.
- NIST Computer Security Resource Center glossary: penetration testing, intrusion, vulnerability scanning
- Office québécois de la langue française: test d'intrusion (record last updated 2020)
- PCI Security Standards Council: glossary
- UK National Cyber Security Centre: Penetration testing
- OWASP: API Security Top 10 2023, API1
- Pentest-Tools.com: web app penetration testing, services and offensive security services brief (printed p. 4)
- HTTPCS: Black Box and Grey Box
- ITrust: Intrusion test – Pentest
None of these organizations endorses this site. The PenTest Index does not perform, authorize or certify penetration testing.