Skip to content
GlabIT
GlabIT

Offensive security · point-in-time

Penetration testing

Manual penetration testing in Romania for web apps, APIs, networks, cloud and mobile, using OWASP WSTG and PTES, with reports and an agreed retest.

Book an assessment

In one sentence

A manual, scoped, authorised test of your web applications, networks, cloud or mobile apps, run to OWASP WSTG and PTES, that ends in a report your engineers can act on and a retest of specified remediated findings within the agreed scope and window.

Who it is for

  • Product companies that must show a recent pentest to enterprise customers, auditors or partners
  • Organisations preparing for NIS2, DORA, ISO/IEC 27001 or PCI DSS evidence
  • Teams launching or materially changing a web application, API or cloud environment
  • Anyone whose last "pentest" was an automated scan with a logo on the cover

What we test

  • Web applications and APIs. Authentication and session management, access control, injection, business-logic abuse, file handling, third-party integrations; REST and GraphQL APIs; single-page applications. Methodology: OWASP Web Security Testing Guide (WSTG v4.2), with OWASP ASVS as the checklist for coverage.
  • External network. Your internet-facing footprint: exposed services, VPNs, mail, DNS, certificate hygiene, forgotten hosts. Methodology: PTES.
  • Internal network and Active Directory. What an attacker with a foothold or a malicious insider can reach: segmentation, credential hygiene, privilege escalation paths, lateral movement.
  • Cloud configuration. Identity and access, storage exposure, network paths, logging and secrets management on the major public clouds.
  • Mobile applications. IOS and Android apps and the APIs behind them, following the OWASP Mobile Application Security guides.

How we test

Manual first. Tooling (scanners, proxies, fuzzers) is used to save time on the obvious, and findings it produces are verified by hand before they appear in a report. We chain findings to demonstrate real impact rather than listing severities in isolation, and we stop and call you when we reach something that should not be touched further.

Rules of engagement are written and signed: written authority from the asset owner, scope, exclusions, allowed techniques, test windows, data handling, safety and stop rules, emergency contacts. No denial-of-service, no social engineering unless it is a red team engagement, no exploitation beyond what is needed to prove impact. Testing reduces risk; it does not guarantee that no vulnerability remains, and it does not remediate on your behalf.

After the test

Findings feed straight into remediation — ours if you use Secure Engineering or CaaS, or your team’s with our support. The retest verifies the agreed findings within the agreed window, and the test-completion statement gives procurement what it needs — it is not a certification or a regulatory attestation, and testing cannot show that no other issue exists.

Deliverables

What you receive

  • Executive summary

    Two pages for management — what we tested, what we found, business impact, and what to fix first.

  • Technical report

    Every finding with severity (CVSS and our own business rating), evidence, reproduction steps and a specific fix. Written for the developer or admin who will do the work.

  • Retest

    The agreed findings (critical and high by default) retested after you fix them, within the agreed window, with an updated report and a test-completion and retest statement you can share.

  • Debrief call

    A walkthrough with your team — questions, priorities, and what the findings say about the wider estate.

  • Test-completion and retest statement

    A one-page statement of scope, dates, methodology and the retest status of the specified findings, suitable for procurement questionnaires. It is not a certification, regulatory attestation, compliance opinion or independent assurance engagement.

  • Evidence handling

    Test evidence — requests, screenshots, exports — is kept only in the location agreed in the rules of engagement and is returned or securely deleted at the end of the engagement, so nothing sensitive stays with us longer than the scope allows.

Engagement model

How it runs

Model
Fixed-price per scope; rules of engagement, test windows and emergency contacts agreed in writing before day one.
Typical timeline
Set by the scope in the proposal — testing, reporting and the retest window are each agreed in the contract.
  1. 01

    Scope

    Assets, environments, credentials, exclusions, test windows and who to call if something breaks. Written authorisation from the asset owner.

  2. 02

    Test

    Manual testing following OWASP WSTG (web/API) and PTES (network), supported by tooling where it saves time, never instead of thinking.

  3. 03

    Report

    Draft report as agreed in the scope; we walk you through it, then finalise.

  4. 04

    Retest

    You fix, we verify the agreed findings within the window, and the report and statement are updated.

FAQ

Questions a sceptical CISO asks

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

A scan is automated and finds known signatures. A pentest is a person chaining what the scanner finds — and what it cannot — into actual impact, such as reading another customer's data or reaching your internal network. We run scanners as one input; the report is written by the person who did the testing.

Which methodologies and standards do you follow?

OWASP Web Security Testing Guide for web applications and APIs, PTES for network engagements, and the OWASP Mobile and LLM guides where relevant. Cloud reviews follow the provider benchmarks (CIS) and our own configuration checklists.

Are your testers certified?

We publish individual certifications only when we can evidence them, and we do not lead with badges. Ask us what we can show you — redacted examples and references where clients permit — and judge the work.

Will testing take our systems down?

We test production only with explicit agreement, in agreed windows, without denial-of-service techniques, and with a stop-immediately contact on both sides. Most web and API testing happens against staging with production-like data.

Can we see a sample report before we buy?

Ask us — where a suitably redacted example is available and cleared for sharing, we will show you the level of detail you will get.

Test it before somebody else does

Send us the scope — URLs, ranges, cloud accounts — and we return a fixed-price proposal with methodology and timeline.

Book an assessment

Often combined with

IT audit

Evidence-based review of your IT estate, operations and controls — findings, verified safeguards and a prioritised remediation roadmap.

Read more

Red team operations

Objective-based adversary simulation that tests detection and response, not just vulnerabilities.

Read more

Cybersecurity-as-a-Service

Fractional security team on subscription: vulnerability management, hardening, awareness, incident response retainer.

Read more