e-security.dev shared logoe-security.dev / pentesting
Authorization / evidence / risk control

A penetration test should challenge security controls,
not the client's patience.

Penetration testing combines an attacker's technical perspective with a defender's responsibility. Every action has an approved objective, boundaries, and stop conditions. The result is evidence, priority, and a clear path to remediation.

Define the test scope See the methodology
Diagram of the authorized scope, attack surface, and controlled testing path
Authorized onlyWritten scope and Rules of Engagement before testing begins.
Controlled impactNo destructive, out-of-scope, or unapproved high-risk actions.
Evidence of remediationThe report drives action, and the retest confirms the result.
Scope matched to the objective

Not every system needs the same test.

We first establish what needs to be verified and which impact the organization wants to reduce. Only then do we select the techniques.

01 / WEB + API

Web applications and services

Business logic, authentication, authorization, sessions, data validation, APIs, and the configuration of the public-facing layer.

  • manual and tool-assisted testing
  • alignment with the OWASP WSTG
  • impact assessment, not signatures alone
02 / INFRASTRUCTURE

Exposure and infrastructure

Internet-facing services, configurations, access controls, and paths that can lead deeper than a single open port.

  • external attack surface
  • internal networks and services
  • segmentation and permissions
03 / WIRELESS

Wireless networks

An assessment of Wi-Fi security, isolation, authentication mechanisms, and device exposure in the agreed environment.

  • configuration and encryption
  • user isolation
  • controlled access scenarios
04 / IDENTITY

Identity and access

Verification that roles, sessions, password resets, and additional authentication factors actually protect critical operations.

  • privilege escalation
  • boundaries between roles
  • resilience of recovery processes
05 / HUMAN LAYER

Controlled social engineering

Scenarios conducted only with separate authorization, with employee protection and a clearly defined process for handling results.

  • simulated phishing
  • procedure validation
  • training findings without blame
06 / RETEST

Remediation verification

Retesting distinguishes a declared change from a security control that actually works.

  • confirmation of closure
  • detection of bypasses and regressions
  • a clear status for decision-makers
The scope must be confirmed. Specific techniques, environments, testing windows, and prohibited actions are agreed individually. No explicit authorization means no test.
Methodology

Six stages. One controlled chain of accountability.

Six penetration testing stages: authorization, reconnaissance, validation, risk assessment, reporting, and retesting
AuthorizationObjective, owner, systems, exclusions, testing window, and emergency contact.
ReconnaissanceExposure mapping and hypotheses kept within the approved boundaries.
ValidationControlled confirmation of vulnerabilities and their potential impact.
AssessmentTechnical risk connected to the consequences for the organization.
ReportEvidence, priority, recommendation, and material for the technical team.
RetestVerification of the fix and evidence-based closure of the finding.
Example finding

A report should remain useful after the test ends.

The example below is fictional. It illustrates the information structure and contains no data from any organization.

More about reporting →
HIGHremediation priority
WEB-04 / login attempt controls

Ineffective restriction of automated authentication attempts

Repeated requests can be submitted without progressive rate limiting, adaptive lockout, or sufficient detection.

Impact
Increased risk of account takeover using passwords exposed in previous breaches.
Evidence
A controlled series of requests during the approved window without exposing user data.
Remediation
Risk-based rate limiting, anomaly detection, MFA, and monitoring of authentication attempts.
Retest
Confirmation that the system responds as intended and the control cannot be easily bypassed.
REFERENCE STANDARDS

Methodology instead of a random tool list

The scope may draw on the OWASP Web Security Testing Guide and NIST SP 800-115. Tools help collect evidence, but they do not replace contextual assessment.

SAFE START

Do not send secrets in your first message

An objective, environment type, and expected outcome are enough to begin. We agree on a secure way to transfer material only after the scope has been qualified.

Describe your need