What is a penetration test (pentest) and what does a website security audit include?

A penetration test (pentest) is a security test in which a specialist, with your written permission, mimics real attacks on your website to find the flaws before an attacker does and to show how far an attacker could get. A website security audit is broader: on top of the pentest it reviews configuration, documentation and processes. Both end with a report listing each flaw, how serious it is and how to fix it, and should finish with a retest that confirms the fix.

What exactly is a pentest?

A standard reference is NIST SP 800-115, from the US National Institute of Standards and Technology. It was published in September 2008 and is still current: its page carries no withdrawal or revision notice. It defines penetration testing as security testing in which assessors mimic real-world attacks to find ways around the security features of an application, system or network. It often means launching real attacks on real systems and data, with the tools and techniques attackers use.

What sets it apart is that it does not stop at a list of possible flaws. It looks for combinations: one small flaw that gets a user account, another that turns it into an administrator, a third that opens the database. According to NIST, it also tells you how well the system stands up to a realistic attack, how skilled an attacker would need to be, and whether your team spots the attack and responds.

OWASP's testing guide (OWASP is the foundation that publishes the best-known open web security guides) notes that a pentest is also called ethical hacking. It sets two limits: a pentest only finds a small representative sample of all the risks, and it comes too late if it is all you do, because a bug caught during development is fixed faster and more cheaply.

How is it different from a vulnerability scan or an audit?

The three get mixed up all the time, and they neither cost nor prove the same thing. At a glance:

	Vulnerability scan	Pentest	Security audit
What it does	A tool compares your services against databases of known flaws	A person tries to exploit the flaws to confirm they exist and see how far they lead	Reviews configuration, documentation and processes, and usually includes tests such as a pentest
What it proves	That a flaw may exist	That the flaw exists and what damage it allows	Whether your security measures do what they should
Business logic	Cannot see it	Yes	Yes, if it includes manual testing
Typical frequency	Regular and automated	Regular, less often	As set by your plan or the standard you follow

NIST puts it simply: a scanner only checks whether a vulnerability may exist; the attack phase of a pentest exploits it to confirm it. In NIST's terms, a security assessment combines three methods: testing, examination (of documents and configurations) and interviewing people. A full website audit uses all three; a pentest is mostly the first.

OWASP is just as clear about automated tools: they have their place, but they do not think creatively and cannot replace an in-depth assessment. On business logic flaws, its guide says a vulnerability scanner cannot detect them and they have to be tested by hand. A scanner does not know that your shop should not accept the same discount code twice.

What are the phases of a pentest?

NIST describes four phases and says this is one of many acceptable ways to group them. The PTES methodology, which OWASP also lists, splits the work into seven. In practice, for a website, it goes like this:

1. Planning and authorisation. Scope, rules and goals are agreed, and management approves the test in writing. No testing happens in this phase.
2. Discovery. Information gathering (domains, servers, versions, the application's entry points) and vulnerability analysis, using scanners and the tester's own knowledge.
3. Attack. Each possible flaw is tried: gaining access, escalating privileges, browsing the system and, where needed, going back to discovery with what has been learnt. You can agree that testing stops before an action would cause damage.
4. Reporting. According to NIST, this runs alongside the other phases: logs are kept and updates are given during the test, and at the end a report sets out the flaws, a risk rating and how to fix them.
5. Fixing and retesting. You or your supplier fix the issues and the tester checks again. NIST warns that a fix can only be verified if the original test is repeated exactly.

Black box, grey box or white box? External or internal?

The label depends on how much the tester knows before starting:

Type	What the tester knows	What it is for
Black box	Nothing beyond the website address	Seeing what an outside attacker sees
Grey box	Some things: for example, test users with different roles	Checking whether one user can see or change another user's data
White box	On top of that, the source code	Finding flaws that cannot be seen from outside

OWASP describes the classic pentest as black box testing, grey box as testing where the tester has partial knowledge of the application, and white box as testing that includes source code analysis. If your website has a customer area, a pure black box test falls short: without test accounts, nobody can check what one customer can see of another.

NIST adds two more distinctions:

• External or internal. External testing attacks from the internet, like a stranger. Internal testing starts inside your network, like an employee or an attacker who is already in. If you do both, the external test usually comes first, so the tester does not use information an outside attacker would not have.
• Overt or covert. In an overt test your IT team knows and helps. In a covert test only senior management knows, and the point is to see whether your team detects the attack. NIST says covert testing is slower and more expensive and misses many vulnerabilities; overt testing is cheaper, carries less risk and is the more common.

What gets tested on a website? The OWASP checklist

The OWASP Web Security Testing Guide (WSTG) is the reference checklist. The stable version is 4.2, released in December 2020, and version 5.0 is in development. It sorts the tests into twelve categories:

WSTG 4.2 category	What is checked (examples from the guide)
Information gathering	What search engines reveal about you, which server and framework you run, files such as robots.txt, entry points
Configuration and deployment	Forgotten backups and files, exposed admin panels, HTTP methods, HSTS, file permissions, subdomains that can be taken over, cloud storage
Identity management	Roles, user registration and provisioning, whether account names can be guessed or enumerated
Authentication	Credentials sent over an encrypted channel, default credentials, lockout after failed attempts, bypassing the login, password reset
Authorisation	Privilege escalation, insecure direct object references (seeing another customer's data by changing a number in the URL), directory traversal
Session management	Cookie attributes, session fixation and hijacking, CSRF, logout and session timeout
Input validation	SQL injection, reflected and stored XSS, command injection, SSRF, server-side template injection
Error handling	Error messages that expose stack traces or internal details
Cryptography	Weak TLS, sensitive data sent unencrypted, weak encryption
Business logic	Forged requests, skipping steps in a workflow, usage limits, uploading unexpected or malicious files
Client side	DOM-based XSS, CORS, clickjacking, browser storage, WebSockets
API	GraphQL testing (what version 4.2 covers)

If your website has an AI chatbot, ask for prompt injection to be tested too: it is not on this 2020 list.

What about the OWASP Top 10?

The OWASP Top 10 is something else: a list of the ten most critical security risks to web applications. The current edition is the 2025 one, replacing the 2021 list. The top three are broken access control (A01), security misconfiguration (A02) and software supply chain failures (A03). According to the 2025 introduction, that last one expands the old vulnerable and outdated components category (A06 in 2021) to cover any supply chain failure, not just known vulnerabilities.

OWASP itself says the Top 10 is primarily an awareness document: used as a testing standard, it is the bare minimum and just a starting point. For a verifiable standard it recommends the ASVS (Application Security Verification Standard), whose version 5.0.0 was released in May 2025. It also discourages any claim of full Top 10 coverage. If a quote promises "complete OWASP Top 10 coverage", ask what testing sits behind it.

What should the written authorisation say?

It comes first, and it is not red tape. The Spanish Criminal Code (Código Penal) punishes with six months to two years in prison anyone who, by getting round security measures and "sin estar debidamente autorizado" (without being duly authorised), accesses an information system or stays in it against the will of whoever has the right to exclude them (art. 197 bis.1). It punishes with six months to three years in prison anyone who, without authorisation and seriously, obstructs or interrupts the working of someone else's computer system (art. 264 bis.1). The difference between a pentest and a crime is permission from the right person.

NIST says the test plan should answer five questions: what the scope is, who is authorised to do it, how it is organised, how sensitive data is handled and what happens if there is an incident. As a checklist for a small business:

1. Exact scope. The domains, URLs, IP addresses and environments that are in, and those that are out. NIST recommends listing what is excluded as well.
2. Third-party systems. If your website sits on hosting or a service you do not control, NIST says the owner of that network usually must also consent in writing. In the cloud, check your provider's rules (table below).
3. Dates, hours and the tester's source IP addresses, so the test can be told apart from a real attack.
4. What is off limits, spelt out plainly. NIST suggests leaving out tests known to cause denial of service or other disruption. It also warns that a pentest can damage a system or knock it out, and that this risk can never be fully removed.
5. Emergency contacts on both sides, and what happens if a real intruder turns up: does testing stop, and who decides when it resumes?
6. Data. How it is stored, sent and destroyed afterwards. If the tester can see personal data about customers or staff, they are handling it on your behalf: the GDPR (RGPD in Spain) requires a contract with the data processor (art. 28.3).
7. Confidentiality. NIST mentions non-disclosure agreements and recommends that legal advisers always be involved in intrusive tests such as pentests.

If the test shows that someone has already got in and reached personal data, that is a personal data breach: the GDPR requires you to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people (art. 33.1).

What if your website is in the cloud?

AWS and Google Cloud say plainly that you do not need permission to test your own resources, and Microsoft's rules do not ask for advance notice. All of them set conditions:

Provider	Do you need to tell them?	What is not allowed (among other things)
AWS	No, for its list of permitted services (EC2, RDS, CloudFront, Lambda, Lightsail, Elastic Beanstalk and others). Testing that includes command and control (C2) does need prior approval	Denial of service, including simulated (covered by a separate policy); port, protocol or request flooding; DNS zone walking on Route 53; S3 bucket or subdomain takeover
Google Cloud	No, as long as you follow its Acceptable Use Policy and terms and only affect your own projects	Testing other customers' applications
Microsoft	Its rules ask for no advance notice. Testing must stay within your own tenant or assets you are explicitly authorised to test	Denial of service; testing tenants you do not own; phishing Microsoft employees

What should the report include?

The WSTG has a chapter on the report and says it offers suggestions, not strict rules. It proposes:

• Introduction: team, agreed scope, limitations (such as lack of access or credentials) and timeline.
• Executive summary for management, with strategic recommendations to stop the issues happening again.
• Findings summary table with a risk level for each finding.
• Finding details: reference ID, title, exploitability, impact, risk, description and steps to fix it.
• Appendices: the test methodology and how severity was rated.

For severity, OWASP suggests five levels (informational, low, medium, high and critical) and notes that some engagements require a CVSS score. CVSS v4.0, published by FIRST on 1 November 2023, maps scores like this: 0.0 none; 0.1 to 3.9 low; 4.0 to 6.9 medium; 7.0 to 8.9 high; 9.0 to 10.0 critical.

NIST stresses something people forget: a test is worth far more if it ends in a fix plan. Each finding should come with its root cause and with technical recommendations (apply a patch) and non-technical ones (change the patching process). For a retest, OWASP suggests summarising the earlier findings so you can see what has been closed.

How often should you have a pentest? Is it mandatory?

The GDPR, which applies to almost any website that handles personal data, does not mention pentests. But its article 32.1.d calls, according to the risk, for "un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento" (a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing). It sets no frequency, but a documented security test is one way to show that you do check.

On frequency, NIST says that, given the cost and impact, a pentest once a year may be enough, alongside regular vulnerability scans, which take less work. It makes sense to bring it forward when you change something important, such as user accounts or payments. And because a pentest comes at the end, OWASP recommends looking at security from the design and code stages, not just before launch.

How do you choose who does it?

Six questions that separate a serious test from a scan with a logo on it:

1. Which methodology do they follow? They should name the OWASP WSTG, NIST SP 800-115 or PTES.
2. Can they show you an anonymised sample report, with a summary for management and technical detail?
3. Do they give you an authorisation document with scope, exclusions, hours and contacts before they start?
4. How do they handle and delete your data, and will they sign a data processing contract if they will see it?
5. Is a retest of the fixes included?
6. Do they test by hand, including your business logic, or only run tools?

Be wary of anyone who guarantees your website will be "100% secure". OWASP points out that a pentest only finds a sample of the risks, and NIST that testing does not give a complete picture of security.

If you would like us to look at your website, at Quantum Nova we do the work ourselves, without subcontracting, at a fixed price after a free assessment. See security audit and penetration testing.

Frequently asked questions

Is penetration testing legal in Spain?

Yes, if it is authorised in writing by whoever has rights over the system. Without that authorisation, getting into a system by getting round its security measures is a crime (art. 197 bis of the Spanish Criminal Code, six months to two years in prison). That is why the authorisation should set the scope, the dates and what is off limits, and cover third-party systems too.

What is the difference between a pentest and ethical hacking?

In practice, none: OWASP uses both names for the same thing, testing a system the way an attacker would to find its flaws. What makes it ethical is written permission, an agreed scope and a report so the flaws get fixed.

Can a pentest take my website down?

It can happen. NIST warns that a pentest can damage a system or make it unusable, and that the risk never disappears completely. You reduce it by leaving out denial of service tests, agreeing testing hours and having an emergency contact on hand.

How often should I have one?

NIST considers a pentest once a year may be enough, combined with regular vulnerability scans. It is worth repeating when you change something important on the website, such as user logins or payments.

What is the difference between a pentest and a security audit?

A pentest tries to exploit the flaws to show how far an attacker could get. An audit is broader: it also reviews configuration, documentation and processes, and usually includes a pentest among its tests.

Sources

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008), CSRC page
• NIST SP 800-115, full text (PDF), sections 2.4, 5.2, 6.5, 6.6, 8.1 and 8.3
• OWASP Web Security Testing Guide, project page
• OWASP WSTG 4.2, test categories
• OWASP WSTG 4.2, introduction
• OWASP WSTG 4.2, penetration testing methodologies
• OWASP WSTG 4.2, reporting
• OWASP WSTG 4.2, introduction to business logic testing
• OWASP WSTG, version 4.2 release (December 2020)
• OWASP Top 10:2025
• OWASP Top 10:2025, introduction (changes since 2021)
• OWASP Top 10:2025, Establishing a Modern Application Security Program
• OWASP ASVS 5.0.0 (May 2025)
• FIRST, CVSS v4.0 Specification Document
• Spanish Criminal Code (Código Penal), consolidated text (BOE), arts. 197 bis and 264 bis
• Regulation (EU) 2016/679, GDPR (BOE, Spanish text), arts. 28, 32 and 33
• AWS, Penetration Testing policy
• Google Cloud, penetration testing notice
• Microsoft Security Response Center, Security Testing Rules of Engagement