A penetration test, or pentest, is an authorised security test in which a tester tries to find and exploit weaknesses in a system the way a real attacker might, then reports what they found and how to fix it. For a business running a website, online shop or web app, it answers a practical question: if someone tried to break in, how far could they get?
Pentest vs vulnerability scan
The two are often confused, but they do different jobs.
- A vulnerability scan is automated. A tool checks your systems against a list of known issues, such as outdated software versions, missing security headers or exposed services. Scans are quick and can run often, but they can report false positives and they do not usually understand how your application is meant to work.
- A penetration test is led by people. The tester uses scanners as one input, then checks findings by hand, chains small weaknesses together and tests business logic, for example whether one customer can view another customer's orders by changing a number in the URL.
Scans are good for regular hygiene. A pentest gives a deeper view at a point in time. Most organisations benefit from both.
Types of penetration test
Tests are usually described by how much the tester knows in advance:
- Black box: the tester starts with little more than a URL, much like an outside attacker.
- Grey box: the tester gets test accounts or some documentation, so time goes into what logged-in users can reach.
- White box: the tester has architecture details and sometimes source code, which allows the most thorough review.
They are also described by target: a web application test (login, forms, sessions, access control), an API test (authentication, authorisation and data exposure on each endpoint), a network test (servers, firewalls and exposed services) or a mobile app test (the app, local data storage and the APIs it calls).
Scope and written authorisation
Security testing should only happen with the system owner's permission, so a proper pentest starts with written authorisation from someone who has the authority to give it. If your site runs on a hosting or cloud provider, check its policy too, because some providers set rules on security testing. Before testing starts, both sides agree the rules of engagement:
- which domains, IP addresses, apps and environments are in scope, and which are not
- testing dates and hours, and whether production or a staging copy is used
- which techniques are excluded, such as denial-of-service attempts
- emergency contacts and what happens if the tester finds a serious issue mid-test
The typical process
- Scoping: agree goals, targets, test type and timing.
- Reconnaissance: map the attack surface, including subdomains, pages, APIs and technologies in use.
- Testing: look for and try to exploit weaknesses, within the agreed rules.
- Reporting: document findings with evidence and recommended fixes.
- Remediation: your team or developer fixes the issues, highest risk first.
- Retest: the tester confirms the fixes work and have not opened new gaps.
What a good report contains
The report is what you pay for, so it should be usable by both managers and developers. Look for:
- a short summary in plain language of the overall risk
- each finding with a severity rating and an explanation of the business impact
- clear reproduction steps and evidence, so developers can confirm the issue
- specific fix recommendations, not just generic advice
- the scope and dates tested, and anything that was not tested
Illustrative example: a finding might read "High: a logged-in user can download other users' invoices by changing the invoice ID in the API request", followed by the exact request used, the affected endpoint and a recommended server-side permission check.
When and how often to test
Common points to test are before a new website or app launches, after major changes such as a new payment flow, login system or hosting move, and on a regular schedule for systems that handle customer or payment data. Some industries, customers or contracts may require testing at set intervals. Check with your advisers what applies to you.
How it fits with your other controls
A pentest is a check, not a replacement for good day-to-day practice. Automated security checks in a CI/CD pipeline catch some issues on every release, and regression testing makes sure a fix stays fixed. Multi-factor authentication limits the damage from stolen passwords, and a zero trust approach limits what any single account can reach. Pentest findings often show where these controls have gaps.
To plan security testing alongside other safeguards, see technine.io's cybersecurity and compliance service.
Frequently asked questions
Is a vulnerability scan enough on its own?
For routine checks it is useful, but it can miss logic and access-control problems that need a person to find. A pentest covers that gap.
Will a pentest take my website down?
It should not, if the rules of engagement exclude disruptive techniques and the timing is agreed. Some teams test a staging copy first to reduce risk.
Does passing a pentest mean my site is secure?
No. It shows what the tester found within the agreed scope and time. New code, new features and newly discovered vulnerabilities can change the picture, which is why retesting and ongoing checks matter.