Penetration testing in Greece: scope, cost and reporting

TRUST-IT · 1 October 2026

Define the business question before counting targets

An application with one hostname may contain multiple user roles, APIs, tenants and privileged workflows. A large address range may expose only a few services. Neither target count alone describes the work. State the decision the test should support: whether an external user can cross a tenant boundary, whether a supplier account can reach a critical system, or whether a privileged action is adequately controlled.

Describe production and test environments, data sensitivity, architecture, integrations and operational constraints. Identify asset owners and third-party dependencies. Where the work touches hosting or software operated by someone else, confirm the applicable testing permissions. A country-specific commercial engagement still needs explicit authority for each system in scope.

Choose coverage and access that fit the question

External infrastructure testing, internal network testing, web application testing, API assessment and cloud configuration review have different coverage models. Agree which are included and how results connect. A vulnerability scan can inform the work but does not, by itself, establish the same evidence as a scoped manual penetration test.

For an authenticated application, provide representative accounts for each relevant role and tenant, with safe test records. Distinguish unauthenticated reachability from authorisation between accounts. White-box access to architecture or code can improve the examination of selected controls; a black-box test answers a different question. Record the assumed attacker access and the limitations this imposes.

Understand the cost drivers in a proposal

Effort depends on application complexity, roles and trust boundaries, environment readiness, custom protocols, integrations, permitted test windows and the depth of validation. Reporting workshops, remediation support and retesting also take time. A proposal should identify its unit of work and assumptions, not hide materially different coverage behind a single headline price.

Ask what happens if accounts fail, an environment changes, an asset owner cannot grant access or testing reveals additional scope. Separate included work from optional extensions. Fixed-scope pricing can be useful when inputs are clear; time-based work needs priorities, reporting checkpoints and a stopping rule. TRUST-IT provides engagement-specific proposals after scoping rather than publishing a universal price unsupported by the environment.

Agree rules of engagement and operational safeguards

Document the approved assets, dates, source infrastructure, contacts, escalation route and stop conditions. Define permitted proof, data handling and excluded techniques. Availability-sensitive systems may need a maintenance window or a representative non-production environment, with the differences explicitly recorded. Agree how the tester reports a serious finding without waiting for the final document.

The test plan should account for cleanup, account expiry, evidence retention and access revocation after delivery. Destructive actions, social engineering or physical access require their own explicit scope; they are not implied by the phrase penetration testing. Define who can approve a scope change and retain that decision with the engagement record.

Demand findings that engineering teams can reproduce

A useful finding names the affected asset and version, prerequisite access, tested request or action, observed response, security boundary and evidence reference. Explain impact in the client’s environment, distinguish confirmed exploitation from an unverified condition, and describe a practical remediation path. Include sensitive evidence only in the agreed protected delivery channel.

Management needs a concise account of exposure, business consequence, priorities and untested areas. Engineers need enough detail to reproduce and verify the result without guessing. A severity score is an input to prioritisation, not a substitute for the actual access path or business context. A clean test result describes the agreed scope and time, not the absence of every possible vulnerability.

Specify retesting and acceptance before work begins

Agree whether a retest is included, its scope, timing dependencies and handling of material code changes. Define statuses such as resolved, partially resolved, unresolved and not retested. Link each retest to the original finding and record the tested version and evidence. Closing a ticket is an administrative event; verified remediation requires a technical result.

For an authorisation issue, test both the previously failing access path and the legitimate workflow that must continue to work. Consider related roles, tenants and delivery paths where the root cause is shared. If the deployment differs from the corrected test environment, make the remaining production verification explicit.

Prepare the information needed for a useful quotation

Provide a short system description, asset categories, user roles, hosting model, intended testing period and the assurance decision you need to make. Explain any contractual reporting format, language, workshop or retest requirement. The initial enquiry should not contain live credentials or sensitive customer records.

TRUST-IT can translate that brief into scope, assumptions, rules of engagement and deliverables. Use the proposal comparison checklist when assessing offers. For the next stage, our preparation guide explains how to make accounts, environments and stakeholders ready, while the authorisation-boundary technical example shows the depth of evidence a finding can contain.

Further reading

• NIST — technical guide to security testing and assessment
• OWASP — Web Security Testing Guide

Put the guidance to work

Find exploitable weaknesses in your networks, applications, APIs, and infrastructure before they become incidents.