Technical testing · Penetration testing and vulnerability assessment

Web and network security audit

Penetration testing carried out by the same people who investigate real incidents. We test the way an attacker would work, on an approved scope, and report in a form your developers and your board can both use — then retest the fixes.

AuthorisationApproved scope, in writing, first
MethodManual testing, not a scan
OutputTechnical report + executive summary

What we test

Components can be commissioned separately or together. The depth of each is set once the scope is defined.

01 · Applications

Web application testing

Websites, portals, internal applications, SaaS platforms, online shops and administration systems.

  • authentication and password policy
  • sessions and access control
  • role separation
  • injection vulnerabilities
  • cross-site scripting
  • file upload handling
  • sensitive data exposure
  • input validation
  • password reset flows
  • configuration errors
  • vulnerable components
  • business logic and account takeover
02 · API

API testing

APIs can expose sensitive information or critical functionality when they are not configured correctly.

  • authentication and authorisation
  • object and function level access control
  • token validation
  • session handling
  • rate limiting
  • excessive data exposure
  • tenant separation
  • unprotected endpoints
  • data integrity
  • exposed administrative functions
03 · External

External infrastructure

Systems reachable from the internet, assessed from the position of an attacker with no internal access: exposed assets and services, ports and protocols, vulnerable versions, TLS configuration, remote access services, mail servers, exposed administrative interfaces, filtering rules, subdomains and forgotten assets.

04 · Internal

Internal network

Simulates the situation where an attacker already has network access or an internal device is compromised — the practical way to measure what a successful phishing email would actually cost you.

  • network segmentation
  • insecure services and protocols
  • internal authentication
  • file shares
  • exposed credentials
  • privilege escalation
  • lateral movement
  • critical systems reachable without justification
05 · Wireless

Wireless networks

Access points, security protocols, authentication mechanisms, separation of staff and guest networks, client isolation, rogue access points, and access from wireless into internal resources.

06 · Configuration

Security configuration audit

A significant share of incidents is enabled by misconfiguration, unnecessary services or default credentials.

  • Windows and Linux servers
  • workstations
  • network devices and firewalls
  • cloud services
  • web and database servers
  • virtualisation platforms
  • authentication systems
  • remote access, backup, mail
07 · Identity

Active Directory security

Active Directory controls identity, authentication and access to resources: domain structure, privileged accounts, groups and permissions, authentication and group policy, dormant accounts, delegations and trusts, privilege escalation paths, and separation of administrative accounts.

08 · Retesting

Verifying remediation

After fixes are applied we retest, so you can demonstrate remediation rather than assert it — confirming what was closed, identifying incomplete fixes, and producing the evidence audits ask for.

How it runs

No technical activity begins before the scope and the rules of engagement are approved in writing.

STAGE 1

Scope

Authorised systems, permitted methods, limits, testing windows and contacts.

STAGE 2

Reconnaissance

Inventory of assessed assets, exposed services, the real attack surface.

STAGE 3

Testing

Manual testing supported by tooling, with controlled validation of findings.

STAGE 4

Report

Findings ranked by realistic impact, with evidence and a prioritised fix plan.

STAGE 5

Retest

Confirming remediation and updating the status of each finding.

What you receive

A report that separates what is exploitable today from what is theoretical, with evidence for each finding and a fix specific to your stack rather than a copied recommendation. We say so plainly when something a scanner rated high is not actually reachable.

Executive summary
The principal risks in language a board can act on, with the potential impact on the organisation
Methodology
Systems assessed, methods used, testing windows and applicable limitations
Classification
Findings ranked by severity: critical · high · medium · low · informational
Technical detail
For each finding: affected system, description, exploitation conditions, reproduction steps, potential impact, recommended fix and remediation priority
Plan of measures
Findings translated into a remediation plan, prioritised by risk and by the effort each fix requires
Related deliverables
Test plan · rules of engagement · asset inventory · results walkthrough · technical clarification support · retest report
Scope

Who it is for

Any infrastructure connected to the internet can become a target. The service is as relevant before launching something new as it is for verifying what is already in place.

A vulnerability assessment identifies and classifies what exists. A penetration test goes further and validates, under control, whether those findings can actually be exploited and what that would cost. The two can be commissioned separately or together.

Organisations
Private companies, public institutions, entities in scope of NIS2, operators of essential or important services
Technology
Application developers, IT and cloud service providers, e-commerce platforms
Sensitive data
Organisations handling personal data, financial institutions, healthcare providers
Infrastructure
Industrial operators and companies with distributed infrastructure

When testing is worth commissioning

  • Before launching an application or platform
  • After significant infrastructure changes
  • After a cloud migration
  • After introducing new services
  • After remediating an incident
  • Ahead of a compliance audit
  • After changing IT provider
  • After a system integration or acquisition
  • Before connecting to a partner’s infrastructure
  • Periodically, as part of risk management
  • When compromise is suspected
  • Annually, as a baseline

Safety and authorisation

Penetration testing is carried out only on the basis of explicit authorisation and a clearly defined scope, agreed before any activity begins.

Agreed in writing first

Rules of engagement

Authorised systems, permitted methods, technical limits, approved dates and windows, points of contact, escalation procedure, stop conditions, how information is protected and how results are retained.

What we do not do

Potentially destructive activity

Denial-of-service testing, data destruction, uncontrolled modification of information and other potentially destructive activity are not performed unless expressly requested, formally approved, and safe to carry out.

NIS2 relevance
Testing supports the requirement to assess the effectiveness of your security measures and provides evidence of the actual state of the infrastructure. It does not replace the compliance process itself — that is covered by NIS2 consulting and audit.
Cadence
One-off audits · pre-launch testing · annual assessments · retests after remediation · recurring vulnerability management programmes · post-incident assessments

Frequently asked questions

01What is the difference between a vulnerability scan and a pentest?

A vulnerability assessment identifies and classifies what is present, using automated scanning, manual checks and configuration review. A penetration test validates, under control, whether those findings can actually be exploited, what level of access an attacker would gain, and whether several weaknesses can be chained. A pentest is not the output of a tool.

02Can testing disrupt production systems?

Testing is carried out under control, within the approved scope, with stop conditions agreed in advance and an escalation path to your points of contact. Potentially destructive activity is performed only on express request, with formal approval, and only where it can be done safely.

03What do you need from us to start?

The scope — which systems, applications or address ranges are in play — and written authorisation for them. Everything else (permitted methods, testing windows, contacts, stop conditions) is agreed in the rules of engagement, before the first technical activity.

04Is retesting included?

Retesting is included in the way we work: it confirms whether findings were actually closed, identifies incomplete fixes, and produces the evidence audits and compliance reviews normally ask for. It is scoped with the engagement.

05How often should testing be repeated?

A single assessment describes the state at the time of testing. Applications change, new services appear and new vulnerabilities are published, so an annual cadence plus testing at every major change is a reasonable starting point for most organisations.

Contact

Describe what you want tested. We will come back with a scope, a timeline and a price.

Nothing starts before you have all three in writing. The initial scoping conversation costs nothing.

Response time
One working day at most
Request form
Full name
Confirmation
Form data is used to answer your enquiry, under Article 6(1)(b) GDPR. Details: prodefence.ro/en/privacy-policy/

Skip to content