Penetration testing

Yes, because it is commissioned work. We act solely at the request of the system owner, holding a written authorisation and a contract that names scope and hours. A third party system never gets touched, however convincing the claim of a right to it, until the document carries the signature of its genuine owner. Having your legal adviser read that authorisation is a sound habit.

Caution is the rule and nothing destructive is run, yet nobody can promise zero risk. Hence the preference for a duplicate environment. Where the scope has to cover production, we insist on agreed hours, a recent backup that has been checked, and somebody reachable throughout.

Scanners match your system against known signatures, and outdated components are exactly what they catch. Flaws of logic escape them: reaching documents belonging to another customer, stacking discounts that were never meant to combine, skipping an approval step. Those need a person. Serious work uses both.

No, and none is promised. What arrives is a report stating the scope, the method, the dates and the findings, followed by a statement confirming the re-test after repair. That is the document you show an auditor, a demanding customer, or your own risk assessment file.

Once a year as a floor, plus after any significant change: a fresh payment module, an API opened to partners, a move to a different host, a rebuilt sign-in flow. For organisations in scope of NIS2 that rhythm folds naturally into the risk management ANSSI expects to see.