We attack your systems before someone else does

You have a firewall, passwords with capital letters, and a supplier who says everything is fine. Still, nobody knows whether an outsider could get in, because nobody has ever tried. Meanwhile an insurer asks for proof, or a large client does, or a tender you are entering. Penetration testing gives an honest answer, for the simple reason that we actually try.

What a penetration test is and is not

An automated scan runs through a list of known vulnerabilities and produces hundreds of alerts, most of which do not matter in your situation. A penetration test is different. We combine that scan with manual work and chain small flaws together until they become dangerous. A forgotten test environment, an API that returns slightly too much, and the account of an employee who left last year are harmless on their own. In a row, they are a way in.

The result is a recorded snapshot of what was possible on the day of the test, in a report you can show to a client or an auditor. If you want to work toward a standard, that falls under ISO 27001 & NEN 7510.

How we work

We start with the scope, and we take our time with it. Which domains, which servers, which applications? Can the test run on your production environment, or do we set up a copy? What do we do once we are really inside: do we stop there, or see how far we get? We put that in writing, together with the days we test and a phone number in case something breaks.

Then we test. First the outside: your website, your mail server, your VPN, and the ports that are open without anyone remembering why. Next the application itself, on the things that go wrong in practice, such as input that is not checked, sessions that stay alive far too long, and users who can see another user's data. If you want, we also test from an ordinary workstation inside the network, because most real damage starts with one account in the wrong hands.

The report you keep

You do not get an export file from a scanner. You get a report where every finding is described in plain language: what we did, what we saw, what an attacker could do with it, and roughly what it costs to close. Everything is ranked by risk, so you start at the top and do not have to search an alphabetical list. At the front is a two-page summary that your management or your client can read without technical knowledge.

If we find something during the test that lets someone in today, we do not wait for the report. We call you the same day and tell you right away, with a temporary measure you can take at once. We keep the rest for the report, so your team can pick it up in one go instead of through scattered messages.

What happens after the test

A report that disappears into a drawer has helped nobody. We go through the findings with your team, so your administrator or your software supplier knows exactly what has to happen and why it is in that order. Where a finding touches our own code or infrastructure we manage, we fix it ourselves. Where it sits with a supplier, we write the report so they can start on it without extra steps.

Once the fixes are done, we test again what we found and record what now works and what no longer does. That retest is the part you show to an auditor or your insurer. If your organization falls under NIS2, or you use models covered by the EU AI Act, we adjust the testing rhythm to what those rules ask of you. From the report to the evidence we collect along the way, you are the owner, and we keep nothing you do not want us to keep.