How does a second opinion stay genuinely independent?
Through our structure and our approach. Our audit practice is separate from our app development practice: the senior engineer who carries out your audit has no sales target tied to a follow-on project and is not assessed on one. We are also transparent about potential conflicts of interest: if we have ever worked with your current supplier before, or if we are a direct competitor of that supplier for other clients, we disclose this before the engagement starts. In practice, for many clients the audit leads to an improvement plan with the current supplier rather than a switch. That is fine by us, and in fact the most common outcome.
Which frameworks and standards do you use?
It depends on the scope. For mobile security we use the OWASP MASVS (Mobile Application Security Verification Standard), and the ASVS for the backend. For general information security we use ISO 27001 as a framework. For healthcare apps we use NEN 7510 and the related DPIA requirements. For AI components we apply the relevant articles of the EU AI Act, in particular Art. 9 (risk management), Art. 10 (data governance), Art. 13 (transparency) and Art. 14-15 (human oversight and cybersecurity). For app store readiness we follow the current Apple App Store Review Guidelines and Google Play Policies. We update these for each audit, as they change several times a year.
What do you need from us to get started?
Read access to the Git repository containing the app and backend code, any architecture documentation, access to the CI/CD environment (read-only is sufficient), visibility into the App Store Connect and Google Play Console accounts or an export of these, and, for projects still in development, access to the backlog and the latest sprint overviews. For security work we also ask for any previous penetration test reports or security audits, to avoid duplicate effort. We sign an NDA before the engagement starts; many clients use our NDA template, others use their own.
Can the current supplier know that we are looking?
That is up to you. Some clients inform their supplier openly and actively ask for cooperation. This gives us access to context we would otherwise have to reverse-engineer, and it often speeds up the work. Other clients prefer to keep the audit confidential at first, particularly where they are weighing up a decision or are still deciding on further investment. Both routes work, with different implications for pace and depth. We will discuss which route suits your situation during the introductory conversation.
Can you also audit projects that are still in development?
Yes, that is a common question. For an in-development audit we look not only at the code that exists, but also at the backlog, the architectural choices still to be made, the sprint cadence and the agreements between you and the supplier. We often identify early risks that would otherwise only surface later: a scalability choice that works for ten users but not for ten thousand, a security architecture that cannot withstand the type of integration that is coming, or a release pipeline that is not ready for the first store submission. The earlier in the project, the cheaper the correction.
What if we find that the current supplier is indeed underperforming?
That is what we say: with reasoning for each finding, and a prioritised list of what needs to change to move forward. Sometimes that is an improvement trajectory with the same supplier, for example bringing in a senior architect, changing the sprint cadence, or introducing a quality gate that we describe. Sometimes it is a change of supplier or a hybrid set-up. We do not make a recommendation to pull your follow-on project towards us; we describe what needs to happen and you choose who does it. In a number of cases, incidentally, the finding is that the supplier does good work but that scope or communication is the problem. We see that often too.
Do you also do pen tests or certifications?
We do not carry out pen tests ourselves. For those we work with specialised Dutch pen-testing firms that we have known for some time. We can include one in the remediation roadmap, or integrate the outcome of an earlier pen test into our audit. Certifications (ISO 27001, SOC 2, NEN 7510) are handled by accredited auditors. We deliver the preparatory work and the remediation approach that make a certification achievable, but not the certification itself. That is a deliberate separation, so that independence is preserved.
What about AI Act compliance in an app?
For apps with AI components, we look at the risk level of the application (prohibited, high-risk, limited-risk or minimal-risk under the AI Act), the set-up of risk management under Art. 9, the data governance under Art. 10, the transparency requirements towards end users under Art. 13, and the requirements for human oversight and cybersecurity under Art. 14–15. For a recommendation app in a retail context, the picture differs from a diagnostic-support app in healthcare, so we determine the applicable regime per use case. For the strategic side of AI decisions, we often refer you on to our
AI consultancy.
Do you also work for parties outside the Netherlands?
We mainly work for clients in the Netherlands and the Benelux, because we value short physical distance for the final discussion and any on-site sessions. For pan-European clients with a Dutch entity we do carry out audits; we deliver our reports in Dutch or English, depending on who will read them. For assignments entirely outside the EU, we refer you to partners who specialise in those markets.
Who sits at the table for the final discussion?
Basically: you, or the stakeholder who requested the audit. If you want your internal team involved, such as the CTO, lead engineer or product owner, of course. If you would like the current supplier present for a joint improvement plan, that is also possible; we then moderate the conversation so that it stays constructive. For investor due diligence, an investment committee or deal team is often in attendance. We adapt the tone of the discussion to the audience: a conversation with technical people looks different from one with a board.
