Area of service02 / 05
Technical testing.
You learn which technical findings matter and where uncertainty remains. Pentest Light is an agreed deepening and proceeds only with authorisation.
The situation
What is visible from the outside. What matters to you.
What does your company look like from the outside? The assessment views your company from the perspective of a potential attacker: domains and subdomains, reachable systems and services, technologies and versions in use.
A reachable remote access point is, at first, an observation. An affected software version is a second. Compromised credentials for the same domain are a third. On their own, these pieces of information say little about the actual exposure. What matters is finding them, attributing them correctly and connecting them.
A match does not automatically become a fact. Every statement carries its level of evidence: observed, plausible, reliably attributed to the company or, where explicitly approved, technically validated. That is the difference from an automated scan: whether an observation is a risk in its specific context is judged by a person, not a tool.
Not tested means unknown.
What pleXcreen delivers to leadership
- 01
What actually affects you
Prioritised findings instead of yet another long list of technical alerts.
- 02
How certain each statement is
Source, time, attribution and test status remain traceable for every statement.
- 03
What to do now
What should be fixed immediately, and when it will be retested to confirm the exposure has gone.
A remote maintenance access, reachable from outside.
Fictitious example · Sample Ltd- 1Observation Login page reachable from the internet. Identified passively, day 2.
- 2Approved test Version query within scope, no login attempts. Active testing only after separate approval.
- 3Assessment Reachable: confirmed. Exploitability: open until tested.
- 4Management decision Whether and how to respond is decided by the executive board on this basis.
Technical detail · optional · fictitious sampleEvidence, test status and mandate limits for the example
A remote maintenance access reachable from outside.
Reachable. Exploitability open.
01Observation
The login page of a remote maintenance service is reachable from the internet without an upstream safeguard.
- Source
- Public service directories, passive
- Time
- Day 2 of collection
- Target
- Subdomain of Sample Ltd
02Test
Agreed test step
Version query of the login service. Approved in scope, no login attempts. The result is a hint, not proof of exploitability.
- Service reachable from outsideobservedconfirmed
- Version hint pointing to potentially affected softwareobservedobserved
- Actual exposure or exploitabilityobservedopen
03Assessment
A finding requiring review. Whether the vulnerability is exploitable in this system is not established.
Decision
Restrict the access until clarified, verify the running version internally, validate in a targeted way once explicitly approved, then reassess.
Open question
Until clarified, actual exposure remains explicitly open.
Assessed by: analyst, pleXcreen
Method, scope and limits
What is examined
The subject of testing is the external attack surface of the agreed scope: exposed systems and services, known and relevant vulnerabilities, misconfigurations, indications of compromised credentials and possible attack paths that emerge from combining individual findings.
Collection is initially passive: we analyse what can be observed without interacting with your systems. Only where the scope provides for it and you have explicitly authorised it do targeted active validations follow, test steps that interact with a system to confirm or discard an assumption. External collection concerning operational technology (OT) remains passive; active testing of production environments takes place only with separate authorisation.
What you receive
The result is not a raw export but an interpreted picture: which findings are observed, which connections are actually supported, which assessments are derived, and what remains open. An indication of historical credentials, for instance, does not prove successful access, it justifies a check, not a conclusion. That distinction is part of the result, not a footnote.
On this basis you receive prioritised next steps: what to verify first, what to decide and what to implement. Prioritisation follows the significance for your organisation, not technical severity alone.
How scope and depth are set
Scope and depth of testing are agreed in advance. Before any assessment we agree in writing which entities, domains and systems are examined, which steps are purely external and which require authorisation. Further exploitability and in-depth testing is agreed separately.
Whether Pentest Light forms part of an engagement depends on the agreed scope. It is not automatically part of the Schlaglicht and not automatically part of every entry. The free initial conversation contains no assessment; it serves to clarify the question and a sensible scope.
Who this is for
Technical testing is aimed at executive management, CIOs, CISOs and risk owners who need a reliable statement about their external attack surface, ahead of an investment decision, in the course of NIS2 or critical-infrastructure requirements, after an acquisition, or as an independent second view alongside the in-house team or an existing provider.
What the testing is not
- Not a complete test catalogue and no promise of completeness: the agreed scope is tested.
- No promise of freedom from damage; active steps take place only after explicit authorisation and with an agreed procedure.
- Not a replacement for internal security processes, but an independent outside view that complements them.
- No exploitation of vulnerabilities beyond the authorised extent.
Frequently asked questions
- Is Pentest Light automatically part of the Schlaglicht?
- No. The Schlaglicht is a passive outside-in view of your organisation. Whether technical testing with active validation is added is agreed in the scope and authorised separately.
- What does “active validation” mean in practice?
- A targeted test step that interacts with a system to confirm or discard a suspicion, for example checking whether a suspected vulnerability is actually reachable in the specific context. Such steps take place only after explicit written authorisation.
- Are production environments and OT systems tested?
- Externally, only passively. Active testing of production environments and operational technology takes place solely after separate authorisation and with a procedure agreed with the operations owners.
Next step
Arrange an initial conversation.
Free of charge, with no assessment. Getting in touch triggers neither an engagement nor any technical testing. Scope and depth are agreed only afterwards.
Adjacent areas of service