A critical CVE score does not tell you whether you can be attacked.
New exploits, changing attack surfaces and new campaigns do not wait for your next annual pentest. XPLT assesses what is actually relevant for your environment, validates exploitability under a pre-authorised mandate and gives you a defensible answer.
Exploitable, not exploitable, or only under clearly named conditions.
30 minutes with a senior operator · confidential · NDA before technical detail
- Event-driven
- Human-led
- Production-safe
- MITRE ATT&CK
- ISO 27001 on the basis of IT-Grundschutz
An alert is not a decision.
Vulnerability management produces scores, advisories and long lists. For the operational decision, three answers are usually missing.
- 01
Is this weakness actually exploitable in our environment?
- 02
Which attack path does it create in practice - and how far does it lead?
- 03
What has to be handled first when not everything can be handled at once?
The question in the boardroom is rarely "How many critical findings do we have?" but "Can someone actually do this to us - and what are we doing about it?"
A defensible statement on exploitability instead of a score interpretation.
Prioritisation by real attack path, not by the length of the findings list.
The time between two scheduled assessments does not stay untested.
Documented evidence for audit, board and supervisory reporting.
Continuous readiness, event-driven testing.
"Always-on" describes readiness, context and mandate - not permanent exploitation of your production. Active testing starts when one of these triggers fires.
Actively exploited vulnerability
A weakness in technology you run is demonstrably being attacked in the wild.
Campaign or new TTP
A campaign or technique relevant to your sector changes realistic adversary behaviour.
Attack-surface change
New external exposure: a service, domain, interface, cloud resource or supplier connection.
Internal drift
Permissions, configurations or identities move away from the agreed target state.
Client request
You request validation - ahead of a release, a migration or a board decision.
Between triggers we keep threat context, attack-surface awareness and testing readiness current. That is the continuous part of the mandate.
Six steps from signal to decision.
- 01
Detect
Capture the signal: exploit, campaign, exposure change or your own request.
- 02
Correlate
Assess relevance for your specific environment, technology and attack surface.
- 03
Authorise
Check the test against the pre-authorised mandate and rules of engagement.
- 04
Validate
Senior operators validate exploitability in a controlled, production-safe way.
- 05
Decide
Hand over verdict, attack path, impact and priority in documented form.
- 06
Re-test
Re-validate after your remediation and carry the status forward.
Three outcomes - no score puzzle.
The attack path was demonstrated under mandate. You receive evidence, impact and the recommended order of treatment.
Within the tested scope and window the path could not be exploited. We state what was tested and what was not.
Exploitable only under clearly named conditions - for example existing access, a specific configuration or user interaction.
Limits: "Not exploitable" is a statement about the tested scope, the tested position and the tested window. It is not a permanent guarantee and not proof of complete coverage.
One attack surface, four points of view.
External lens
What an attacker reaches from outside without prior access: exposed services, identities, misconfigurations.
Decision: what has to be closed at the perimeter first?
Insider lens
What is possible from a controlled endpoint or VDI with defined rights.
Decision: how far does a compromised workstation carry?
Attack-path prioritisation
Chaining individual weaknesses into the path that actually reaches a critical asset.
Decision: which single measure breaks the most paths?
Assurance cut
Documented evidence and status tracking for audit, board and supervisory reporting.
Decision: what do we show third parties as proof of effectiveness?
Testing close to production means testing under control.
Scope, positions and permitted techniques are authorised in writing before any testing.
We demonstrate exploitability without destroying data or deliberately taking services down.
Any running activity can be stopped at any time.
A small authorised group knows the mandate, the contact route and the escalation path.
Every test action is traceable with timestamp, target and technique.
Windows and blackout periods for critical systems are agreed in advance.
Access to production data only as far as the proof strictly requires.
Risk statement: testing against production systems is never risk-free. We reduce the risk through mandate, choice of technique, test windows and abort criteria - we do not claim to eliminate it.
SOC mode: activity can be openly coordinated as a detection opportunity, run with limited awareness, or kept covert for realistic measurement. The mode is agreed in advance.
What you receive - and when.
Exploitable, not exploitable or conditional, with a short rationale.
Reproducible proof: steps, artefacts, timestamps.
The chain from entry to impact, mapped to MITRE ATT&CK.
Order of treatment by path impact, not by score.
Confirmation after remediation, including remaining limitations.
Rolling view of attack surface, verdicts and open items.
- Continuous
- Threat context, attack-surface awareness and testing readiness.
- Event-driven
- Validation as soon as an agreed trigger fires.
- Monthly
- Short status review of exposure changes and open items.
- Quarterly
- Depth testing of an agreed focus area.
- Scheduled
- Fixed dates ahead of releases, migrations or audits.
Three shapes, one annual mandate.
Perimeter
External lens on exposed services, domains and identities.
- External attack surface
- Event-driven validation
- Re-test after remediation
Insider
Adds a defined internal test position via a controlled endpoint or VDI.
- Internal test position
- Attack-path prioritisation
- Drift observation
Full Mandate
External and internal lenses plus the assurance cut for audit and board.
- All four lenses
- Focused depth testing
- Assurance reporting
Scope before price: attack surface, internal test position, depth of testing, reporting and coordination effort define the mandate. We name a defensible range after scoping - not before.
What Always-On adds - and what it does not replace.
Penetration test
- Question
- Where are the weaknesses in a defined scope?
- Cadence
- Point in time, project based
- Result
- Findings report with recommendations
Red-team operation
- Question
- Does the defence detect and stop a realistic attack?
- Cadence
- Single operation over several weeks
- Result
- Objective outcome and detection assessment
Hybrid pentest
- Question
- How do we combine coverage with manual depth?
- Cadence
- Programmatic, recurring
- Result
- Coverage plus validated depth
Always-On Red Teaming
- Question
- Is what became relevant today exploitable here?
- Cadence
- Continuous readiness, event-driven testing
- Result
- Verdict, attack path and priority
From first conversation to a running mandate.
- 01
Discover
A 30-minute scoping call with a senior operator: goals, environment, triggers, frame. No commitment.
- 02
Baseline
A 90-minute delivery discovery workshop: attack surface, test positions, contacts, rules of engagement.
- 03
Operationalise
Mandate, trigger criteria, communication routes and reporting are fixed in writing.
- 04
Continuously validate
Readiness runs, tests start on triggers, status is carried forward.
Always-On Red Teaming - frequent questions
Related pages: Red Teaming · Hybrid Pentest · TIBER-DE / DORA TLPT
When a new exploit affects your stack tomorrow: will you have a score - or an answer?
Speak with a senior operator for 30 minutes. We will define relevant triggers, test position, guardrails and a realistic mandate range - before you commit to anything.
Not ready to talk yet? The Scope Check returns exercise type, tester-days and a budget range in two minutes - no email gate.