The pentest report is in, and nobody is fixing the findings.

The moment

The report arrives with a management summary that management reads and a sixty-page appendix nobody reads. The high findings go to the development team, which puts them on the backlog below the features already promised to customers. The infrastructure findings go to the administrators, who fix two and push the rest to "after the migration". Three months later the customer who required the pentest asks for the retest, and it turns out four of the six high findings are still open. That's the moment someone from outside, who fixes findings instead of managing them, makes the difference.

Why findings stay open

Not because they're unimportant, but because they're paid in a different currency than the rest of the work: they deliver no feature and no uptime, only the removal of a risk that hasn't materialised yet. On top of that, a pentest report describes what is wrong, not how to fix it in your codebase or your infrastructure without breaking something else. An engineer who has done this before translates the findings into concrete changes, works through them with the team, and meanwhile builds in the controls that prevent the same category of findings from coming back next year: dependency scanning, secrets out of the code, secure default configurations, a security review in the pipeline.

What needs to happen now

1. Prioritising on real risk. Not every high finding is equally urgent in your context, and some mediums together are worse than one high. The engineer, with the pentester and the team, in the first week.
2. Fixing with the team. Turning the findings into changes the development team and the administrators can implement, and building along where needed. The AppSec or security engineer.
3. Preventing repeats. Building in the controls that catch the category of findings: dependency scans, secrets management, secure configurations, a light security review at every release. DevSecOps engineer with the team.
4. Preparing the retest. Evidence per finding, so the retest is short and the report to the customer is clean. The engineer.
5. Handing over. A way of working the team sustains on its own, and honest advice on what security capacity is needed structurally.

Who leads this

Organisations here look for an application security engineer if the findings are mainly in the software, a security engineer for hardening infrastructure and cloud, and a DevSecOps engineer if the goal is to get the controls into the pipeline. Which of those roles it is for you depends on the report; that's where the intake starts. If you need someone permanently, say an AppSec engineer who stays in the development team, that's simply permanent recruitment; for working through the findings it's interim. We've been doing both for years.

Interim: within two days, and what it costs

Fast doesn't mean sloppy. We start with a proper intake: what's in the report, which technology, when the retest is, who this person needs to bring along. Then we search a network of interim professionals we have usually known for years, which is how, for an interim assignment, you'll have your first candidate interviewed within two days. If you need someone permanently, it works differently and takes longer. The best permanent candidates are rarely actively looking: they're settled somewhere and only move for the right arguments, from someone who knows them and what drives them. That is exactly our work, and it produces the best match, but not within two days. Interim professionals are entrepreneurs: more commercial, more flexible in both directions, and therefore faster to propose from the network we actively maintain. If we don't have someone who truly fits, we'll say so. You always see the professional's rate and our margin separately, and that margin is never more than €15 per hour on a full-time assignment. You can contract the freelancer directly or through your own broker, in which case we invoice only our margin, or entirely through Gruzzy with a single invoice. Who is available right now, and in which rate band, is listed anonymously with the available interim professionals.

Freelance, and the Dutch DBA Act

Working through findings and building in controls before a retest is an assignment with a clear beginning and end: there's a result, the professional decides how the work gets done, and there's no employer-style line of authority. That is what the Dutch tax authority wants to see now that enforcement on false self-employment has resumed since 2025, so freelance fits well here, with a model agreement. If it turns out the development team structurally needs an AppSec engineer, we'll say so. Usually that's a permanent role through recruitment; if you really want someone temporarily on payroll, secondment is possible, although it isn't our core business. We're happy to advise on this before you sign.