Methodology

How we work

Last updated October 17, 2026

The method is the product. A client should be able to tell, before the work starts, what will be touched, what will not, how we will talk, and what “done” means. Every service on this site uses the same sequence. The target changes. The sequence does not.

Principles

We test only what you authorize. We prefer evidence over volume. We write for the people who have to fix the issue and for the people who have to decide what to fund. We would rather close five real items than hand you a hundred unread ones.

Scoping

Scoping names the assets, the objectives, the environment, the accounts, the time window, and the success criteria. It also names a person on your side and a person on ours. If the scope is ambiguous, we stop and correct it before testing starts. A wider target is a new agreement, not an improvisation. Choosing between a web application test, an API test, a network test, and a vulnerability assessment happens here, while it is still cheap to choose the smaller one.

Rules of engagement

The rules cover source addresses, hours, emergency contacts, and the checks that are forbidden. Denial of service, destructive testing, and social engineering are out by default. They are in only when the rules say so, with the constraints written next to the permission. A red team does not get a quieter version of this rule. It gets a stricter one, because the objective is broader.

If we find something that is actively exploitable and serious, we tell the named contact then. We do not wait for the final report to mention it.

Testing

Tooling is used to cover ground. Conclusions come from what we can demonstrate. We stay inside the roles and networks you gave us. When a path would leave the scope, we record that it exists and we do not follow it.

Published methods are a checklist of coverage, not a logo. Web testing is organized against the OWASP Web Security Testing Guide, and application requirements are read against the OWASP Application Security Verification Standard when you want that mapping. API work uses the OWASP API Security Top 10 as the index. Mobile work uses the OWASP MASVS and MASTG. Infrastructure testing follows the shape of PTES and NIST SP 800-115. Where a path is an adversary technique, we may name the MITRE ATT&CK technique so a detection team can look it up. None of these names means we are accredited to them.

Severity

Findings are rated Critical, High, Medium, Low, or Informational. The rating is a judgment about impact and how reachable the issue is in your environment. CVSS is a useful reference when a number helps a program compare items. It is not a substitute for that judgment, and a high score on an unreachable host will not be written as if the host were on the internet.

Reporting

You receive a technical report and a short summary. The technical report includes, for each finding, where it is, what it allows, how it was confirmed, and what to change. The summary says what matters, what to do first, and what will still be true after the obvious fixes.

Evidence is the minimum required to reproduce the issue. We do not attach piles of personal data to prove that personal data was reachable. There is no sample report on this site pretending to be a client deliverable. The documents are these ones: the rules you signed, the technical findings, the short summary, and the retest note.

Retest

After you remediate, we retest the items in the agreed window. Fixed items are marked fixed. Items that still work are marked open, with what we saw. A ticket moving to done is not, by itself, a fix.

Data we hold during an engagement

Credentials you share are used for the test and discarded when the engagement ends, unless a contract says otherwise. Evidence is kept only as long as the engagement and any agreed dispute period require. If you have a channel you want us to use for files, we use that channel.

What we will not do

We will not test a system you do not own or cannot authorize. We will not pretend a subscription to a scanner was a penetration test. We will not hide a material limitation of the test in a footnote. We will not certify you. Offices in Doha and Marseille follow this page. If you want to start, the contact page is the place.

Frequently asked questions

What are the phases of a penetration test?

Scoping, rules of engagement, testing, reporting, and a retest. Scoping names the assets and the objective. The rules name what is forbidden and who can stop the work. Testing stays inside that writing. The report separates a technical account from a short one for leadership. The retest checks the fixes you shipped and says what still works.

What is in the report?

For each finding: where it is, what it allows, how it was confirmed, and what to change. Evidence is the minimum required to reproduce the issue. A short summary says what matters, what to do first, and what will still be true after the obvious fixes. The report is not a certificate, and a ticket moving to done is not a fix.

How do you rate severity?

Critical, High, Medium, Low, or Informational. The rating is a judgment about impact and how reachable the issue is in your environment. CVSS is a reference when a number helps a program compare items. A high score on an unreachable host is not written as if the host were on the internet.

Can we start before the rules are signed?

No. If the scope is ambiguous, we stop and correct it before testing starts. A wider target is a new agreement, not an improvisation. Denial of service, destructive testing, and social engineering are out by default. They are in only when the rules say so, with the constraints written next to the permission.