What Is Penetration Testing: Complete Business Guide

A pentest (or penetration test) is, put plainly, a controlled attack against your own systems to find security flaws before someone who shouldn't be there does. It's run by an authorised team with written permission, a clear scope and an agreed schedule, and ends with a report saying what fails, how serious it is and what needs to be fixed. The difference with an automated scanner matters: a professional pentest chains vulnerabilities, measures real impact and delivers reproducible evidence. The difference with a Red Team also matters: pentesting looks for flaws in specific assets; a Red Team measures whether your defence notices when someone is already inside.

In Spain it's also the technical test that evidences mandatory controls under NIS2, DORA, ENS, ISO 27001 and PCI DSS. This guide explains exactly what it is, the 5 phases, the scope types, the standard methodologies and how to choose a provider that adds value.

What pentesting is

Pentesting (penetration testing, also known as intrusion testing or technical security audit) is an authorised, time-bounded exercise. A team of offensive professionals tries to compromise specific assets in your organisation (a web application, an API, an internal network, a cloud environment, a mobile app) using techniques equivalent to those of a real attacker, and when they finish they deliver a report describing each finding, its impact, a proof of concept and the recommended fix.

The question a pentest answers is straightforward: what flaws are there and how serious are they if someone exploits them? That isn't the same question a Red Team answers (could we compromise the business undetected?) or a vulnerability scanner answers (what known vulnerabilities does an automated tool detect on first pass?). Pentesting sits deliberately between the two: the technical depth of a manual attack with a bounded scope so findings are actionable.

In practice, a professional pentesting project:

• Starts from a written scope: list of URLs, IP ranges, repositories, cloud identities, test accounts, allowed time windows and excluded techniques.
• Runs under written authorisation from the asset owner (the rules of engagement or ROE).
• Combines professional tools (Burp Suite, Nuclei, Nmap, Metasploit, BloodHound, custom scripts) with manual technique when automation no longer finds anything new.
• Chains findings when possible: an information leak exposing credentials, credentials granting access to an API, a misauthorised API allowing takeover of privileged accounts.
• Ends with an executive report readable by management and a technical report detailed per finding: CVSS severity, proof of concept, captured request/response, business impact and remediation.
• Usually includes a retest phase a few weeks later to validate that the fixes work.

Typical duration runs 1 to 4 weeks of active execution, depending on scope size and complexity.

What a pentest is for

Well executed and well leveraged, a pentest produces five concrete outcomes that an automated scanner doesn't:

1. Prioritised inventory of real risks, not long lists without context. A CVSS 9.8 vulnerability requiring prior admin access is less urgent than a CVSS 6.5 exploitable without authentication from the Internet, and the report reflects that.
2. Reproducible evidence so the development team can fix without guessing what happened.
3. Demonstrable regulatory compliance. NIS2, DORA and ENS demand periodic technical testing; the signed report is the auditable evidence.
4. Honest read on your security posture that you can present to the management committee, the board or a B2B client during a due diligence.
5. Measurable risk reduction after applying the fixes and passing the retest.

Seen from the other side: the average incident in a Spanish SME, according to INCIBE's panel, runs into tens to hundreds of thousands of euros between ransom, downtime and recovery. An annual pentest costs a fraction and, more importantly, prevents the incident when its findings get fixed.

Pentesting vs audit vs Red Team vs vulnerability scanning

The four terms often get used as synonyms in RFPs and proposals, and they aren't. Confusing them leads to buying a service that doesn't answer the question your organisation needs answered. The quick difference:

Vulnerability scanner. An automated tool (Nessus, Qualys, OpenVAS) runs checks against an IP or URL and returns a list of known vulnerabilities with assigned CVE. Takes minutes or hours. Useful as a first layer, but doesn't chain flaws or measure impact. The question it answers: what does a tool detect without judgment.

Security audit. Documentary and technical review to verify compliance with a regulatory framework (ENS, ISO 27001, GDPR). Combines interviews, policy review, evidence and sometimes an embedded pentest. Lasts weeks. The question it answers: does this organisation comply with a framework.

Pentesting. Manual, authorised attack against specific assets over 1 to 4 weeks. High technical depth, findings with reproducible proof of concept. The question it answers: what real flaws does this asset have and how serious are they.

Red Team. Full adversarial simulation of 6 to 16 weeks, without warning the SOC. Business objectives (domain control, exfiltration, reaching the CEO), detection evasion, OSINT, phishing and lateral movement. The question it answers: could a motivated attacker compromise us without us noticing.

If you want to go deeper into the difference between pentesting and Red Team, there's a dedicated piece in Penetration Testing vs Red Team. And if your organisation is a financial entity designated under DORA, the test you need is called TLPT, covered in TIBER-EU and TLPT.

Pentesting types by scope

"Pentesting" is an umbrella. What changes from one to another is what gets attacked and, therefore, what tools, methodology and technical profile are needed.

• Web pentesting. HTTP/HTTPS applications, admin panels, e-commerce, SaaS platforms. Covers OWASP Top 10 (injection, broken authentication, XSS, IDOR, SSRF, deserialisation), business logic and authorisation errors. Most demanded and the cornerstone of any security programme in the SDLC.
• Mobile pentesting iOS and Android. Applications reviewed against OWASP MASVS criteria: binary analysis, local storage, backend communication, obfuscation, jailbreak/root detection and permissions. There's a practical case on lab setup in Root an Android AVD for Burp Suite pentesting.
• Infrastructure pentesting, internal and external. Internal: attacker with LAN access or assumed breach on an endpoint. Active Directory, segmentation, patching, lateral escalation. External: what an attacker sees from the Internet (exposed services, forgotten panels, VPN without MFA, orphan subdomains, certificate leaks).
• Cloud pentesting (AWS, Azure, GCP). IAM, bucket configuration, secrets in repositories, virtual networks, containers, serverless functions. The attack surface has shifted: you no longer attack a server, you attack identities and policies.
• API pentesting (REST, GraphQL, gRPC). Focus on authentication, object and function-level authorisation, rate limiting, mass assignment, injection and data exposure. The OWASP API Security Top 10 is the standard.
• IoT/OT pentesting. Devices, firmware, industrial protocols (Modbus, S7, OPC UA), segmented OT networks. Requires operational caution: many tests aren't run in production.
• Social engineering pentesting. Targeted phishing, phone pretexting, in-person physical tests. Contracted when the human factor is the most likely vector.

A mid-sized organisation usually needs web, perimeter and internal pentesting once a year, plus a specific one (mobile, cloud or API) depending on its business. SMEs with a single digital product start with web and API.

White box, black box and grey box

Regardless of type, the information model handed to the offensive team changes the outcome. Three models:

• Black box. Public URL or IP only. No credentials, no source code. Useful to measure what an external attacker sees with no prior context.
• Grey box. User credentials with limited role. The most common model because it balances realism and efficiency.
• White box. Source code, architecture, privileged credentials. For maximum technical coverage on critical applications.

For a more detailed explanation with examples, see differences between white, black and grey box audit.

The 5 phases of a professional pentest

Almost every formal methodology converges on five phases. Names change; the order and logic don't.

1. Reconnaissance (recon)

Gather information about the target without touching it yet. Externally, OSINT: Shodan, Censys, public GitHub, leaks in combolists, TLS certificates, passive DNS. Internally, network mapping, host discovery, service enumeration. The goal is to build a map: what's there, where it sits and what version is running.

2. Analysis and enumeration

Identify technologies, versions, endpoints, parameters, users and permissions. Here the recon data gets crossed with known vulnerability databases (CVE, exploit-db) to anticipate what might work before touching anything.

3. Exploitation

The most visible phase. The techniques the first two phases suggested get tried: SQL injection, deserialisation, broken authentication, JWT token abuse, RCE on an outdated component, AWS token theft via SSRF. It's not throwing an exploit and seeing what happens: every attempt gets documented with its request, its response and its impact.

4. Post-exploitation

After initial access, the team evaluates what can be achieved from there: pivot to another network, escalate privileges, persist, exfiltrate sensitive data, access management committee mailboxes. Without post-exploitation, the report minimises real risk because it only tells the first step.

5. Documentation and report

The deliverable. A good report contains:

• Executive summary readable by non-technical stakeholders, with conclusions and priorities.
• Detailed findings: title, CVSS v3.1 severity, technical description, reproducible proof of concept, business impact and mitigation recommendation.
• Annexes with logs, captures and, where applicable, exploitation chains documented step by step.

Weeks later, the optional but highly recommended retest phase verifies that the applied fixes work and closes the cycle.

Is pentesting legal? Framework and authorisation

Pentesting is legal when there's express authorisation from the asset owner and execution stays within the agreed scope. Without that authorisation, the same techniques would constitute a crime under articles 197 to 197 bis and 264 to 264 ter of the Spanish Penal Code (unauthorised access to information systems, damages and disclosure or revelation of secrets).

The four elements every professional pentesting project must contain:

1. Contract and NDA between client and provider.
2. Signed rules of engagement (ROE): scope, time windows, allowed and excluded techniques, emergency contacts, agreements on sensitive data found.
3. Asset owner authorisation when the owner isn't the client itself. In multi-tenant SaaS, for example, the provider's authorisation is needed in addition to the client's.
4. Personal data handling aligned with GDPR: if the test accesses personal data, the contract must describe its handling, retention and destruction.

No serious provider starts without these four elements in writing. If anyone offers to "start tomorrow" without signed ROE, that's a direct signal not to contract.

Standard methodologies: OWASP, OSSTMM, PTES, NIST 800-115

The sector works on four main standards. A professional provider declares which one it follows and how it adapts it.

• OWASP Web Security Testing Guide (WSTG). The de facto standard for web applications. Covers from information gathering to cryptography, authorisation, session management, business logic and APIs.
• OWASP MASVS and MASTG. Equivalent for mobile applications. Defines L1 (standard) and L2 (high risk) levels plus resilience requirements.
• OSSTMM (Open Source Security Testing Methodology Manual). Focused on measurable operational testing. Useful when the client demands reproducible metrics.
• PTES (Penetration Testing Execution Standard). Execution-oriented, with emphasis on pre-engagement, threat modeling and post-exploitation.
• NIST SP 800-115. The US guide many public RFPs use. Orthodox but clear.

In practice, most providers combine OWASP WSTG + PTES for web and API, MASVS + MASTG for mobile and NIST 800-115 + own criteria for infrastructure.

Pentesting and compliance: NIS2, DORA, ENS, ISO 27001, PCI DSS

Pentesting is one of the technical tests evidencing mandatory controls in the frameworks applying to companies and administrations in Spain and the EU.

• NIS2 (article 21.2). Requires periodic technical testing as part of risk management measures. Frequency: annual minimum and after significant infrastructure changes.
• DORA (TIBER-EU). Designated financial entities need accredited TLPT every three years; the rest, advanced annual pentesting.
• ENS (Royal Decree 311/2022). Penetration tests and vulnerability analyses in medium and high categories, annual frequency.
• ISO 27001 (control A.8.29). Technical tests in information systems with frequency defined by the ISMS risk analysis; annual is reasonable.
• PCI DSS v4.0 (requirement 11.4). Annual internal and external pentesting and after significant changes in the CDE network (cardholder data environment).

A single well-designed project simultaneously covers technical evidence for several frameworks. That's exactly what a professional provider should articulate in the proposal.

How to choose a professional pentesting provider

Four criteria separate a provider that adds value from one that delivers an automated Nessus report painted blue. There's a dedicated guide with concrete RFP questions, boutique vs big-four vs MSSP comparison and warning signs before signing in how to choose a penetration testing company.

1. Verifiable technical team. Ask for names of the people who will run the project, their certifications (OSCP, OSWE, OSEP, eWPT, eCPPT, CRTO, GPEN) and references from similar projects. A serious team answers without hesitation.

2. Own research and published CVEs. Providers that discover vulnerabilities in commercial software and publish CVE advisories demonstrate real technical capability. On Secra's research page we list the CVEs we've discovered.

3. Explicit methodology. The proposal must declare which standard it follows (OWASP WSTG, MASVS, PTES, NIST 800-115) and what it adapts from it. If the document doesn't say so, there's probably no methodology.

4. Quality of the sample report. Ask for a sample report with anonymised data. Look at whether findings are prioritised, whether there's reproducible proof of concept, whether CVSS severity is justified and whether the executive section speaks business. Everything else is just words.

Something that shouldn't be a criterion: lowest price. A low-cost pentest usually means an automated scanner with a template. The difference shows up when an incident hits and you discover the attack path wasn't in the report.

When and how often to run pentesting

The four situations that trigger a pentesting project are easy to identify:

1. Before going live with a new application or major change.
2. Annually at minimum, to maintain compliance evidence.
3. After an incident or near miss, to validate that the root cause is closed and the attacker left no traces.
4. Under contractual requirement from a B2B client during due diligence or renewal.

As a quick heuristic: if your organisation publishes software externally, once a year is the floor. If you handle sensitive regulated data (health, financial, critical infrastructure), twice a year is more realistic.

Frequently asked questions

How long does a pentest take?

Between 1 and 4 weeks of active execution depending on scope size. A mid-sized web application is covered in 5 to 10 working days. A corporate internal infrastructure can require 2 to 3 weeks. The final report typically arrives 3 to 7 days after the technical phase closes.

What's the difference between pentesting and penetration testing?

None. They're synonyms: pentesting is the English contraction of "penetration testing". The same applies to "technical security audit" when it refers to an offensive test with bounded scope.

Can pentesting break production systems?

A professional pentest minimises operational risk: written ROE, agreed time windows, potentially disruptive techniques excluded or run in pre-production and emergency contacts available. Risk isn't zero, but it's controlled, and the alternative (discovering the flaw when a real attacker exploits it) is much worse.

Which is better, pentesting or Red Team?

They answer different questions. Pentesting measures what flaws exist on specific assets. Red Team measures whether your defence would detect a real, complete attack without warning. The logical order: pentesting first until you have acceptable hygiene; Red Team afterwards to evaluate detection capability under pressure. If your Blue Team is immature, a Red Team probably wastes budget.

How much does a pentest cost?

Price depends on scope, type (web, mobile, infrastructure, cloud), required methodology and duration. The industry in Spain works in broad ranges: a mid-sized web application can run from a few thousand euros to tens of thousands depending on complexity. The most useful exercise isn't comparing price in the abstract but comparing proposals with the same scope between providers and looking at the team, methodology and sample report.

Do I need pentesting if I already have EDR and a SOC?

Yes. EDR and the SOC defend and detect; pentesting finds the flaws first before the attacker exploits them. They're complementary layers, not alternatives. In fact, pentesting results often feed SOC detection rules with scenarios your defensive team hadn't considered.

Which certifications should the pentesting team hold?

The most recognised in the industry are OSCP, OSWE and OSEP (Offensive Security), eWPT and eCPPT (eLearnSecurity / INE), CRTO (Zero-Point Security) and GPEN (SANS / GIAC). A certification doesn't guarantee quality on its own, but its total absence in the team assigned to the project is an alarm signal.

What happens to sensitive data the pentester finds during the test?

It must be handled per what the contract and ROE establish. The norm: minimisation (no more exfiltration than necessary to prove the finding), encryption in transit and at rest, retention limited to the minimum period needed to draft the report and verifiable destruction at closure. If unforeseen personal data appears, the procedure must be agreed in writing.

How we run pentesting at Secra

At Secra we run pentesting on web, mobile, internal and external infrastructure, cloud and APIs following OWASP WSTG, MASVS and PTES, with a team that publishes its own research (CVE-2025-40652 in CoverManager, CVE-2023-3512 in Setelsa ConacWin CB) and delivers reports with reproducible proof of concept, justified CVSS severity and an executive summary separate from the technical one. The scope gets designed so the same test serves as evidence in NIS2, DORA, ENS, ISO 27001 or PCI DSS audits where applicable.

If you want a concrete proposal for your scope, get in touch via contact or check the services for web and mobile audit, infrastructure audit, cloud audit and IoT/OT audit. If you want a full-spectrum adversarial exercise, the next read is the Red Team business guide.