Pentesting – Intrusion Testing

A penetration test is not running a scanner and handing over the PDF it produces. It is genuinely trying to get in, with an agreed scope and under control, and showing how far we got. The difference shows in the report: we do not tell you there might be a problem, we show you how we exploited it.

What we do and what we do not

Yes
We exploit
We chain vulnerabilities until they produce real impact: access to data, control of a system, privilege escalation. With a reproducible proof of concept.
Yes
We prioritise by impact
Every finding carries a criticality reasoned in your context, not the generic score from a database.
No
Deliver noise
A list of 400 findings where 380 are informational is not a service, it is handing the problem back to you.

Types of engagement

External perimeter: everything you expose to the internet, including what you did not know was exposed.
Internal: what an attacker already inside achieves, whether from a compromised laptop or a disgruntled employee. Active Directory, segmentation, lateral movement and escalation.
Web applications and APIs: business logic, authentication, authorisation and everything an automated scanner does not find.
Mobile applications: static and dynamic analysis, local storage, communications and client-side controls.
Cloud: identity and permission configuration, service exposure and escalation paths inside the provider itself.
Black, grey or white box: chosen with you depending on what you want to test. White box finds more; black box looks more like a real attack.

How we work

1
Scope and rules of engagement
What is in and out, time windows, emergency contacts and stop criteria. In writing and signed before anything is touched.
2
Reconnaissance
Real exposure surface, technologies, versions and entry points. This is usually where forgotten assets turn up.
3
Exploitation
We verify every vulnerability by exploiting it. Anything that cannot be demonstrated is flagged as such, without padding the report.
4
Post-exploitation
How far it goes from there: escalation, lateral movement, access to data. That is what turns a technical finding into a business risk.
5
Report and walkthrough
Two documents and a meeting: the executive report for management and the technical one for whoever has to fix it.
6
Retest
We test the fixes. Included, because a report without closure verification is worth little.

What you get

Executive report: the real business risk, in management language and without jargon.
Technical report: every vulnerability with evidence, reproduction steps, impact and a concrete fix.
Prioritisation by criticality and by ease of exploitation in your environment.
Walkthrough session with your technical team to resolve remediation questions.
Retest of the fixed findings and a statement of the final position.
Who does the work. The same team that audits, not an account manager. Governance, risk and compliance: CISSP, CISM, ISO 27001 Lead Auditor, ENS and Risk Analysis (CCN), certified DPO, CCSP and CDPP (ISMS Forum) and PMP (PMI). On the technical side: OSCP, CRTO II and eWPTX, ranked in the top 1% of the CCN-CERT Atenea platform. We have run compliance projects for crypto exchanges, universities and public administrations.

Questions we get asked

Will you take production down?
No, and that is why rules of engagement are agreed beforehand. Some tests only run in pre-production or within an agreed window, and some techniques we simply do not use against live systems. If anything could affect availability, we flag it and decide together.
How long does it take?
It depends on scope: number of assets, application complexity and depth. Once the scope is agreed we give you a fixed duration and price, not an open range.
Penetration test or Red Team?
A pentest is about coverage: how many vulnerabilities exist within a defined perimeter. A Red Team goes after a specific objective and also measures whether you detect it. If you have never run a pentest, start with the pentest: a Red Team against a surface full of known holes is money badly spent.
How often should it be repeated?
Annually at minimum, and always after a significant architecture change or major release. Between pentests, periodic vulnerability assessment covers the drift.
Does it help with compliance?
Yes. ISO 27001, the ENS, DORA, PCI DSS and NIS2 all require periodic technical testing. We issue the report in the format and with the traceability an auditor expects.
Scope it in half an hour
We tell you which type of test answers the question you actually have, and what scope makes sense for your budget. No forms: phone, email or calendar.

Book 30 min with an auditor

Phone: +34 686 250 244 (Mon-Fri, 9:00 to 18:00 CET)  ·  Email: info@jaymonsecurity.com
We reply within 2 working hours.
ENES