Offensive PenTesting Policy
1. Objective
This policy defines the requirements for the execution of offensive penetration tests (PenTesting) as a component of the organisation's security validation programme.
Automation is fundamental to a sustainable security posture - SAST, DAST, SCA and fuzzing provide continuous and scalable coverage. However, automated tools only detect what they were programmed to detect: isolated vulnerabilities, known patterns, code heuristics. An experienced penetration tester simulates an attacker's reasoning - chains apparently minor vulnerabilities into exploitation paths that no individual scanner can identify, exploits business logic, abuses configurations that are correct individually but insecure together, and empirically validates exploitability. PenTesting does not replace automation - it complements it by validating the controls where automation has inherent limits.
The objective of this policy is to ensure that:
- PenTesting is carried out with a defined scope, formal authorisation and documented rules of engagement
- The results produce reproducible and traceable technical evidence
- Findings are handled through the same centralised process as the other security tests
- The retest of critical and high findings is carried out after remediation
- The PenTesting cadence is proportionate to the risk level of the application
2. Scope and applicability
| Level | Applicability |
|---|---|
| L1 | Not applicable in general; may be carried out on an ad hoc basis by decision of the Tech Lead |
| L2 | Annual (section 9); mandatory after significant architectural changes or the introduction of relevant attack surface; for financial entities (DORA), mandatory at least yearly on the ICT systems and applications supporting critical or important functions (Article 24(6)) |
| L3 | Mandatory; at least once a year; mandatory before the first production release of new applications |
3. Test modalities
| Modality | Description | Applicability |
|---|---|---|
| Black Box | The tester receives no prior information about the application. Simulates an external attacker without internal knowledge. | L2 ad hoc; L3 as a complement |
| Grey Box | The tester receives partial technical context: endpoints, test credentials, API documentation, previous SAST/DAST findings. Allows targeted exploration with greater effectiveness. | L2/L3 - recommended modality by default |
| White Box | The tester has full access: source code, architecture, credentials, infrastructure configuration. Maximum coverage. | L3 for high-risk applications or those in preparation for certification |
The choice of modality must be justified in the scope document and approved by the AppSec Engineer before the test begins.
4. Authorisation and rules of engagement
No penetration test may be started without formal authorisation and documented rules of engagement.
4.1 Scope and authorisation document
The scope document must be signed by the Tech Lead or equivalent with authority over the systems under test, and must include:
| Field | Description |
|---|---|
| Systems in scope | Explicit list of the applications, endpoints, environments and infrastructure included |
| Systems out of scope | Explicit list of what is excluded (e.g. third-party systems, production if staging only) |
| Test environment | Staging (preferred) or production (with additional mitigations and a defined window) |
| Test modality | Black Box / Grey Box / White Box |
| Execution period | Start and end dates; permitted time window |
| Point of contact | Technical owner available during the test for clarifications and emergencies |
| Data provided to the tester | Test credentials, documentation, previous findings (Grey/White Box) |
| Emergency procedure | Protocol for immediate stoppage if the test causes unexpected impact |
4.2 Rules of engagement
| Rule | Description |
|---|---|
| Priority test environment | PenTesting must be carried out in staging, unless an approved justification exists. Tests in production require additional approval from the CISO or equivalent. |
| Prohibition of real data | The tester must not access, exfiltrate, modify or retain real user data or regulated data, even if technically accessible during the test |
| No destruction or persistence | The tester must not delete data, install persistent backdoors, or modify configurations without documented reversal |
| Communication of critical discoveries | Findings of Critical severity must be communicated immediately to the point of contact, without waiting for the final report |
| Confidentiality | The results are confidential; the report may only be shared with authorised recipients |
| Qualified tester | PenTesting must be carried out by a qualified professional - internal (with OSCP, CEH, GPEN or equivalent certification) or external (specialised firm with an NDA and contractual security clauses) |
Carrying out offensive tests on systems without formal authorisation, even systems internal to the organisation, is considered a policy violation and may have legal and disciplinary implications. Explicit authorisation is a non-negotiable requirement.
5. Mandatory test areas
The scope of the test must, in proportion to the risk level, cover the following areas:
| Area | Examples of vectors to test | L2 | L3 |
|---|---|---|---|
| Authentication and authorisation | Authentication bypass, privilege escalation, IDOR, broken access control | Mandatory | Mandatory |
| Session management | Session fixation, token predictability, CSRF | Recommended | Mandatory |
| Injection | SQL injection, SSTI, command injection, XXE | Mandatory | Mandatory |
| Input validation | XSS, path traversal, malicious upload | Recommended | Mandatory |
| Business logic | Abuse of transactional flows, limit bypass, state manipulation | Recommended | Mandatory |
| Configuration and exposure | Security headers, TLS, CORS, exposed information, undocumented endpoints | Mandatory | Mandatory |
| APIs and integrations | API authentication, per-endpoint authorisation, rate limiting, data exposure | Recommended | Mandatory |
| Infrastructure (if in scope) | Network, exposed services, cloud configuration | Not applicable | Recommended |
6. PenTesting report
The report is the primary artefact of PenTesting. It must be delivered within the agreed deadline after the tests are completed and meet the following minimum requirements:
6.1 Minimum report structure
| Section | Content |
|---|---|
| Executive summary | Overview of the test, scope, methodology and conclusion on security posture - accessible to non-technical readers |
| Methodology | Approach used (e.g. OWASP Testing Guide, PTES, OWASP WSTG), tools used, execution period |
| Findings inventory | Complete list of findings with unique ID, title, severity (Critical/High/Medium/Low/Informational), CVSS score where applicable |
| Detail per finding | For each finding: technical description, evidence (screenshot, payload, response), demonstrated exploitability, potential impact, remediation recommendation |
| Proof of concept (PoC) | For Critical and High findings: reproducible PoC with detailed steps sufficient for validation by the development team |
| Mapping | References to CWE, CVE (where applicable), OWASP Top 10 |
| Conclusion and residual risk | Overall assessment of residual risk; areas that could not be tested |
6.2 Severity and classification
The severity of findings must be assigned on the basis of real, demonstrated exploitability, not only theoretical scoring:
| Severity | Criterion |
|---|---|
| Critical | Remotely exploitable without authentication, with direct impact on the confidentiality, integrity or availability of data or systems |
| High | Exploitable with minimal authentication or with additional steps, with significant impact |
| Medium | Requires specific conditions or combination with another finding; moderate impact |
| Low | Information exposure, misconfiguration without immediate exploitability, good practices not followed |
| Informational | Observations without direct security impact; improvement recommended |
7. Integration with the findings process
PenTesting findings are handled through the same centralised process as SAST, DAST and SCA findings:
- Findings imported or recorded in the centralised findings management platform (e.g. DefectDojo)
- Findings classified and triaged by the AppSec Engineer
- Each finding associated with an owner, a status (Open/In progress/Resolved/Accepted/Deferred) and a deadline
- Critical and High findings block promotion to production if not remediated (unless an exception is approved)
- Acceptance or deferral decisions documented with justification and approval proportionate to severity
The applicable remediation SLAs are those defined in the Test Strategy Policy:
| Severity | Remediation SLA (L2) | Remediation SLA (L3) |
|---|---|---|
| Critical | ≤ 7 days | ≤ 3 days |
| High | ≤ 30 days | ≤ 15 days |
| Medium | ≤ 90 days | ≤ 45 days |
| Low | ≤ 180 days | ≤ 90 days |
8. Retest
After remediation of Critical and High findings, a retest must be carried out to confirm that the vulnerability has actually been fixed:
- Retest carried out preferably by the same tester or by a tester with access to the original PoC
- Retest documented with its result (Remediated / Partially remediated / Not remediated)
- If the finding is not confirmed as remediated, the remediation cycle restarts with a redefined deadline
- Retest result archived as compliance evidence
The retest is not optional for Critical and High findings. Declared remediation without empirical validation is not considered auditable evidence - the finding remains open until a positive retest.
9. PenTesting cadence
| Level | Minimum cadence | Additional triggers |
|---|---|---|
| L1 | Not applicable | - |
| L2 | Annual (if there are no other triggers) | Significant architecture change; new exposure surface; relevant security incident |
| L3 | Annual | First production release; major release; significant architectural change; security incident; regulatory change that broadens the compliance scope |
These cadences are the minimum recommended by the Manual (the Manual's choice). The most demanding prevails: for financial entities, «at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions» (DORA, Article 24(6)) and, for the entities identified by the authority, TLPT «at least every 3 years» (Article 26(1)); supervisory guidance and sector expectations — see the precedence clause of Policy 29 §7.
For L3 applications going into production for the first time, PenTesting must be completed and Critical/High findings remediated before the production release.
10. Responsibilities
| Role | Responsibility |
|---|---|
| AppSec Engineer | Define scope and modality; approve rules of engagement; coordinate with the tester; triage and manage findings; validate the retest |
| Tech Lead | Sign the formal authorisation; ensure that the team prioritises remediation within the SLAs; take part in the retest if necessary |
| DevOps / SRE | Provide access to the staging environment; configure test credentials; support any reversal of configurations during the test |
| GRC / Compliance | Manage contracts with external PenTesting firms; verify the tester's qualifications; archive reports; audit the cadence |
| CISO / Management | Approve PenTesting in production; analyse executive summaries; take residual risk decisions |
11. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- A significant change in the type of applications or in the attack surface of the portfolio
- A security incident caused by a vulnerability that should have been detected in PenTesting
- A regulatory change that imposes new requirements for offensive testing
12. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 10 - Security Testing | US-08: risk-based offensive PenTesting |
Test Strategy Policy (19_policy-estrategia-testes.md) | Remediation SLAs; centralised findings management |
Secure Release Policy (20_policy-release-seguro.md) | Pre-production PenTesting gate |
| OWASP Testing Guide (WSTG) | Reference methodology for web application pentesting |
| PTES - Penetration Testing Execution Standard | Reference framework for executing PenTesting |
| OWASP ASVS | Application Security Verification Standard - test areas |
| NIST SP 800-115 | Technical Guide to Information Security Testing and Assessment |
| CVSS v3.1 | Common Vulnerability Scoring System - basis for severity classification |
| CWE | Common Weakness Enumeration - classification of vulnerabilities |