Pentesting & Red Team: we uncover real gaps before an attacker does
We assess your exposure the way a real adversary would, but with clear rules: agreed scope, controlled windows, reproducible evidence and an impact-prioritized report. We cover technical audit, pentesting of applications, APIs, infrastructure, cloud and Microsoft 365, and adversary simulation (Red Team) aligned with MITRE ATT&CK and frameworks such as TIBER-EU. Every finding comes with a PoC, real risk rating, actionable recommendation and a retest that closes the loop.
Scope
Agreed in writing
objectives, windows and ROE
Method
OWASP · PTES · ATT&CK
TIBER-EU where applicable
Closure
Report + retest
validation of the fixes
Built for regulated and demanding environments: governance, execution and defensible evidence.
Execution quality
“Security that runs”: operations + governance + auditability. We don’t stop at diagnosis: we close gaps, verify, and produce defensible evidence.
Model
Black · Grey · White
driven by the objective
Coverage
App · Infra · Cloud · AD
plus adversary simulation
Outcome
Real risk reduction
with defensible evidence
What Pentesting & Red Team covers in practice
- Technical audit of infrastructure, network and configuration against best practice.
- Web application and API pentesting aligned with OWASP (WSTG, ASVS).
- External and internal infrastructure, Active Directory and segmentation pentesting.
- Offensive review of cloud (Azure, AWS, GCP) and Microsoft 365 / Entra ID.
- Red Team and adversary simulation (MITRE ATT&CK, TIBER-EU where applicable).
- Impact-prioritized report with reproducible PoC and retest of the fixes.
We work the offensive side with traceability and business context: we set the objectives, agree the rules of engagement, execute within the window and deliver a report useful for leadership, technical teams and audit. We don’t conflate “we ran a scanner” with “we pentested”: the value lies in controlled exploitation, vulnerability chaining and post-fix validation.
Deliverables (for management, technical teams and audit)
Executive summary
A one-page read for leadership and committee: impact, residual risk, status by area and decisions required.
Technical report with PoC
Reproducible detail per finding: evidence, CVSS, exploitation path, real impact and a specific remediation recommendation.
Prioritized remediation plan
A backlog ordered by real risk and effort, with suggested owners, dependencies and quick wins that can move on day one.
Retest and closure letter
Validation of the fixes, closure evidence per finding and an updated report with the accepted residual risk.
Typical use cases
Public-facing web app or API
Pentest aligned with OWASP WSTG / ASVS: authentication, authorization, business logic, injections, IDOR and dependencies.
Perimeter and internal infrastructure
Exposed-surface discovery, service review, lateral movement and Active Directory privilege escalation.
Cloud environment and Microsoft 365
Review of identities, permissions, secrets, public exposure, Conditional Access and abuse of tokens or OAuth consents.
Adversary simulation (Red Team)
Scenario with concrete objectives, techniques aligned with MITRE ATT&CK, initial access, persistence and Blue Team detection validation.
Post-incident validation
Confirm that remediation after an incident actually closes the vector and leaves no residual access or backdoor.
Regulatory driver
Pentest as evidence for DORA, NIS2, ENS, ISO 27001 or PCI-DSS, with a report useful both to auditors and to close prior findings.
Methodologies and reference frameworks
We work with the sector's reference methodologies, but with our own judgement: the framework is the baseline, not the objective. Each engagement is grounded in the standard that fits the scope and the threat model, and the team's experience is what turns a checklist into a defensible finding.
OWASP WSTG, ASVS and MASVS
Web Security Testing Guide as coverage baseline for web pentesting, and ASVS/MASVS as a level-based verification reference. Lets us size the engagement (L1 exploratory, L2 standard, L3 high assurance) and explain to engineering which controls to implement beyond the individual finding.
OWASP API Security Top 10 (2023)
BOLA, broken authentication, data exposure, unrestricted resource consumption, function-level authorisation issues, SSRF and misconfiguration. These seven families concentrate most of the real risk in externally exposed REST and GraphQL APIs today.
PTES (Penetration Testing Execution Standard)
Pre-engagement, reconnaissance, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. PTES provides the structure for infrastructure, internal network and Active Directory pentesting with repeatability and traceability of the attack path.
MITRE ATT&CK
Common taxonomy of adversary tactics and techniques for Red Team. The full path — initial access, persistence, lateral movement and exfiltration — is documented with ATT&CK IDs, letting the Blue Team validate detection and coverage against a shared vocabulary.
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming)
ECB and national central bank framework for threat-intelligence-based Red Team exercises at critical financial entities. We align with TIBER-EU where applicable (DORA references it for advanced testing), coordinating with the supervisor, TI provider and internal control.
DORA, NIS2, ENS, ISO 27001, PCI DSS
Pentesting and Red Team are technical evidence for several frameworks: DORA (Art. 26 Threat-Led Penetration Testing), NIS2 (security measures Art. 21), ENS (periodic audit and testing), ISO 27001 A.12.6 and A.8.29, PCI DSS req. 11.3 and 11.4. The report is structured to serve both the auditor and the board.
Audit, pentesting and Red Team — when to choose each
These three are frequently confused. They aren't substitutes; they are three different offensive-maturity layers. Choosing correctly is the first decision worth making: a Red Team exercise on an organisation that hasn't done a structured audit yet rarely delivers more value than a well-scoped pentest.
| Criterion | Technical audit | Pentesting | Red Team |
|---|---|---|---|
| Objective | Structured snapshot of the security state against best practice or a framework. | Prove real impact by exploiting vulnerabilities within an agreed scope. | Reach a business objective the way an advanced adversary would, with no technical restrictions. |
| Scope | Broad, framework-defined (CIS, ENS, ISO 27001, DORA). | Bounded: application, API, infra, cloud, M365. | Objective (data, critical system); the whole surface. |
| Methodology | Structured checklist and configuration review. | OWASP WSTG / ASVS · PTES · MITRE ATT&CK. | MITRE ATT&CK · TIBER-EU (regulated). |
| Stealth | Not applicable. | Low; the defensive team is usually informed. | High. Only management and the white team know. |
| Typical duration | 1–3 weeks. | 1–4 weeks per target. | 6–12 weeks. |
| Key deliverable | As-is report + improvement roadmap. | Prioritised report with PoC + retest. | Full attack path + assessment of Blue Team detection. |
| When to choose it | When the map isn't clear yet or a baseline is needed for budget and roadmap. | When the asset matters and you need to prove real impact, not just list CVEs. | When the Blue Team is mature and detection/response capability needs to be measured for real. |
Our honest recommendation: if it's the first time you evaluate offensive security, start with a technical audit of the most critical scope and a pentest aimed at the same. Red Team pays off when a SOC/MDR is already in operation and you want to measure real detection.
How much does a pentest cost — indicative ranges (Spain)
Market ranges observed for mid-market and large organisations in Spain during 2025-2026. Useful to size internal budget and to avoid comparing apples to oranges. Not an offer or a commercial commitment: real price depends on scope, complexity and window agreed in writing.
Small or mid-sized web app
€4,500 – €7,000
One app, authenticated + unauthenticated, basic roles, no complex integrations.
Corporate web app
€12,000 – €22,000
Multi-module, several roles, SSO/federation, critical integrations or multi-tenant.
API pentesting (REST/GraphQL)
€3,500 – €9,000
Depends on endpoint count, authentication tiers and business-logic complexity.
External perimeter
€4,000 – €8,000
Discovery and validation of exposed surface, services and configuration.
Internal + Active Directory
€12,000 – €25,000
Lateral movement, privilege escalation, segmentation review and AD hardening.
Offensive M365 / Entra ID audit
€5,000 – €10,000
MFA, Conditional Access, OAuth consents, privileged roles and mailbox persistence.
Source code audit
€8,000 – €20,000
Depends on LOC, stack, criticality and objective (broad review vs focused on critical component).
Full Red Team (4-8 weeks)
€35,000 – €70,000+
Specific objectives, stealth, coordination with the white team and a wider window. TIBER-EU is quoted separately.
BAS (Breach & Attack Simulation)
Subscription model
Annual cost + initial integration. Complements — does not replace — pentesting/RT.
What raises the price
- Real volume (number of apps, endpoints, locations, AD size).
- Complexity (SSO, federation, multi-tenant, microservice architecture).
- Required stealth (avoiding detection extends and increases cost).
- Extensive retesting or additional iterations after remediation.
- Regulatory report format (DORA TLPT, TIBER-EU) with additional validations.
What we don't charge separately
- Executive and technical prioritised report — included in the engagement.
- Kick-off and closure meetings with the technical team and leadership.
- Retest of critical and high findings after remediation (within the engagement).
- Reproducible PoC, IoCs and attack path for the defensive team.
Methodological note: ranges reflect quality projects delivered by teams with certifications and demonstrable experience. Below the lower bound there are usually concessions (fewer days, no retest, no reproducible PoC) that translate into a superficial report. The best way to adjust budget is to tighten the scope, not to lower the rate.
Knowledge models: black, grey and white box
The model is agreed before the engagement, not during it. It determines the level of information the offensive team starts with and, therefore, the coverage, the time and the type of findings that will surface.
No prior information
We simulate what an external attacker with only public information would see. Prioritises attack-surface discovery and perimeter validation. Lower coverage per unit of time, but useful as an exposure baseline.
Pick it when: you want to measure the real external surface or test the resilience of your perimeter.
Standard user credentials
We start with the information and access a legitimate user would have (employee, customer, partner). Optimises coverage and time. Default model for application pentesting, internal infrastructure and M365 in mature organisations.
Pick it when: you want useful coverage in a reasonable timeframe and to prove the impact of a compromised account.
Full access
Source code, architecture, configuration, documentation and elevated access. The model with the highest depth per unit of effort — finds what grey box would miss and what SAST alone doesn't catch. Ideal for critical applications or pre-launch.
Pick it when: the system is critical and you need maximum coverage before a launch, migration or certification.
FAQ (Pentesting & Red Team)
What’s the difference between audit, pentesting and Red Team? ↓
An audit reviews configuration, architecture and controls against best practice (a structured “as-is”). Pentesting exploits vulnerabilities within a defined scope (web, API, infra, cloud) to demonstrate real impact. Red Team goes further: it simulates an adversary with concrete objectives — for example, reaching a critical asset — combining technical and human vectors. They’re not substitutes; they’re different layers of maturity.
Do you work black-box, grey-box or white-box? ↓
All three, depending on the objective. Black-box when we want to see “what an outside attacker without information would see.” Grey-box (the most common) when we need to optimize coverage and time using standard user credentials. White-box when the goal is maximum depth: access to code, configuration and architecture. We agree on this up front, not mid-engagement.
What methodology do you follow? ↓
We use OWASP (WSTG, ASVS, MASVS) as a reference for applications, PTES for infrastructure, and MITRE ATT&CK as the tactics-and-techniques taxonomy for Red Team. In regulated financial contexts we align with TIBER-EU where applicable. Methodology is the baseline; experience is what turns a checklist into a real finding.
Will the report be useful for audit and for my teams to fix things? ↓
Yes — and they’re two layers of the same deliverable. The executive summary translates risk into business impact (for leadership, audit or committee). The technical detail includes a reproducible PoC, evidence, CVSS, exploitation path and a specific recommendation per finding. That’s what the remediating team uses.
Is retest of the fixes included? ↓
Yes. The retest is included and it’s where most of the value lands: we verify that critical and high findings are actually closed, capture evidence of the closure and update the report. Anything still open is documented as residual risk.
How often should a pentest or Red Team exercise be repeated? ↓
It depends on the change and on the applicable framework. As a reference: a pentest at least annually and after significant changes (major release, cloud migration, architecture change). Red Team at a lower cadence (12–24 months) or tied to regulatory milestones (TIBER-EU, DORA, NIS2) or post-incident to validate the new posture.
What’s included in this service area
- Technical audit of infrastructure, network and configuration
- Web and API pentesting (OWASP WSTG / ASVS)
- Infrastructure, Active Directory and segmentation pentesting
- Offensive review of cloud (Azure/AWS/GCP) and Microsoft 365
- Red Team and adversary simulation (MITRE ATT&CK, TIBER-EU)
- Impact-prioritized report with PoC and retest included
How we work (from assessment to evidence)
-
Step 1
Scope & rules
Exercise objectives, model (black/grey/white), windows, ROE, in-scope assets, contacts and stop criteria.
-
Step 2
Execution with evidence
Reconnaissance, controlled exploitation and chaining of vulnerabilities, with reproducible PoC and measured impact.
-
Step 3
Prioritized report
Executive summary plus technical detail: PoC, CVSS, attack path and actionable recommendation per finding.
-
Step 4
Retest & closure
Validation of the fixes, closure evidence and report update with the accepted residual risk.
Services in this area
Talk to an expert →Core offensive services
Base of work: tailored pentesting and ethical hacking with clear rules of engagement. Starting point for most organisations.
Core offensive services
Pentesting
Pruebas de seguridad priorizadas con reporte accionable y remediación guiada.
Core offensive services
Ethical hacking
Offensive audit with clear rules of engagement and contractual consent. We identify exploitable vulnerabilities, prove real-world impact and prioritise remediation by risk, not abstract CVSS.
Specialised technical audits
In-depth reviews by technology or attack surface: web, API, source code, infrastructure, network and Microsoft 365.
Specialised technical audits
Cybersecurity audit
Structured review of architecture, configuration and controls against best practice. Complete as-is picture, risk-based prioritisation and actionable improvement roadmap.
Specialised technical audits
Web application security audit
Web pentesting aligned with OWASP WSTG and ASVS: authentication, authorisation, business logic, IDOR, injections and vulnerable dependencies. Report with PoC and retest.
Specialised technical audits
API security audit
Offensive review of REST and GraphQL APIs against the OWASP API Security Top 10: BOLA, broken authentication, data exposure, unrestricted consumption and misconfiguration.
Specialised technical audits
Source code security audit
SAST and manual code review: insecure patterns, vulnerable dependencies, hard-coded secrets and the real attack surface derived from the codebase. Prioritises exploitable flaws.
Specialised technical audits
Infrastructure and network security audit
Offensive review of perimeter, internal and network infrastructure: discovery, exposed services, lateral movement and privilege escalation in Active Directory.
Specialised technical audits
Microsoft 365 security audit
Offensive review of M365 and Entra ID configuration: MFA, Conditional Access, OAuth consents, forwarding rules, privileged roles and tenant compromise surface.
Advanced exercises
Adversary simulation aligned with MITRE ATT&CK when the Blue Team is already in operation and real detection and response must be measured.
Geographic coverage
On-site and remote pentesting for organisations based in the main Spanish metropolitan areas.
Geographic coverage
Penetration testing in Madrid
On-site and remote pentesting for organisations based in Madrid: applications, infrastructure, cloud and Microsoft 365. Agreed scope, reproducible evidence and retest included.
Geographic coverage
Penetration testing in Barcelona
Technical pentesting for organisations based in Barcelona with regulatory rigour: OWASP, PTES, MITRE ATT&CK, NIS2 and ENS. Impact-prioritised report with reproducible PoC.
Comparisons and decision support
Comparative content to help you choose the exercise that actually fits your objective, maturity and regulatory demand.
Related terms
Concepts from our cybersecurity glossary that connect directly with this service.
Is this service area a fit for your case?
We’ll run a short assessment to define scope, priorities, and a realistic roadmap.