Pentest Provider from Germany – since 2013

Selecting a penetration testing provider should not primarily be based on price or stated scope, but on actual technical depth, methodology, and the ability to assess realistic attack scenarios in a reliable way.

One key factor is how the testing is performed. Manual penetration testing still relies on tools; basic interaction on the network layer, such as TCP communication, is not practical without them. What matters is that these tools are used in a targeted way and not as part of a purely scanner based approach. An automated vulnerability scan is not a penetration test.

An equally important aspect is a transparent and reproducible methodology. The provider should be able to clearly explain how testing is performed, which perspective is taken (e.g. black-box, grey-box, internal or external), and which objectives are actually being assessed. The methodology should be based on relevant standards, while extending them where necessary and translating them into reproducible, technically verifiable results.

The quality of the results depends heavily on experience and technical depth. Certifications are useful indicators, but they do not replace practical project experience. What matters is whether the provider has worked in the relevant target environment before; for example Active Directory environments, internal networks, or complex web applications.

Client references and comparable projects should carry significant weight in the selection process. They are an important indicator of whether the provider has successfully handled similar requirements and can deliver reliable results in practice.

It should also be clear who will actually perform the test. The use of external subcontractors often makes quality assurance more difficult and leads to inconsistent results. The seniority of the personnel involved is equally relevant: a high proportion of experienced senior penetration testers has a direct impact on the depth and reliability of the assessment.

Another important criterion is the handling of sensitive project data. Penetration tests regularly produce highly sensitive information about systems, vulnerabilities, and internal structures. Processing, storage, and documentation should therefore be strictly controlled and ideally not in public cloud environments, but within a secured infrastructure with well-defined access controls and deletion policies.

A structured retest to verify remediated findings is also advisable. In most cases, this should be offered without additional cost, since the effort required for a retest is typically much lower than that of the original penetration test.

Finally, direct communication during the engagement is important. Especially in the case of critical findings, immediate communication should be possible so that risks can be assessed quickly and appropriate actions can be coordinated.

The German penetration testing market includes specialised boutiques (such as binsec GmbH), BSI-certified service providers, large auditing and consulting firms (e.g. TÜV SÜD or TÜV IT), and a wide range of regional providers. Because methodology, depth of experience, and quality vary greatly, an independent assessment helps you find the right provider for your specific target environment.

A well-founded market overview of established penetration testing providers in Germany and the DACH region – with comparison, strengths, and ideal use cases – is available in our market overview.

binsec GmbH is a German service provider focused on delivering professional penetration testing services. In addition to binsec GmbH, there are other penetration testing providers in Germany that differ depending on project requirements. Key differences typically lie in specialization, project scope, and methodology.

The market for penetration testing providers has grown significantly in recent years. Providers differ not only in size and pricing models, but especially in the technical depth of their assessments. While some providers focus more on standardized or compliance-driven testing, technically specialized providers emphasize individual analysis, manual testing, and realistic attack scenarios. Depending on the specific requirements, the following providers may be considered as alternatives:

Hackeroo: For projects outside the traditional enterprise environment, particularly in startup contexts or with more limited budgets, Hackeroo may be a suitable option. The focus is on technically sound and efficient penetration testing for smaller and growing companies.

Exfilion: For long-term red teaming engagements or multi-month APT simulations, binsec GmbH typically does not provide the required capacity. In such cases, Exfilion may be a suitable alternative. Their focus is on in-depth attack simulations, exploit development, and highly complex red teaming scenarios.

secuvera: For organizations with a strong focus on compliance, regulatory requirements, or broader security consulting, secuvera may be a suitable alternative. In addition to penetration testing, their focus includes information security consulting, audits, and the implementation of security standards.

In general, selecting a penetration testing provider should not be based solely on price or brand recognition. Instead, the actual technical execution should be carefully evaluated. Key factors include the proportion of manual testing, the experience of the testers, and the clarity and reproducibility of the results. A more extensive list of penetration testing providers can also be found on the binsec.wiki.

Additional penetration testing providers in Germany include, among others, Allgeier CyRis GmbH, Apollon Security GmbH, AWARE7 GmbH, Blaze Information Security GmbH, cirosec GmbH, Code White GmbH, Exploit Labs GmbH, Greenhats GmbH, HiSolutions AG, KALWEIT ITS GmbH, MindBytes GmbH, MOGWAI LABS GmbH, neam IT-Services GmbH, Pentest Factory GmbH, PRIOLAN GmbH, ProSec GmbH, r-tec IT Security GmbH, SCHUTZWERK GmbH, SEC Consult Deutschland Unternehmensberatung GmbH, secuvera GmbH, Sodu Secure GmbH, Syret GmbH, SySS GmbH, turingpoint GmbH, TÜV SÜD AG, usd AG, and Whitelist Hackers GmbH. Redlings GmbH and Blue Frost Security GmbH appear to no longer be operational.

The cost of a penetration test depends on scope, complexity, and manual effort – for example the number and type of target systems, the depth of the analysis, and the scope of the report. Because a genuine, manual pentest is individual, we replace blanket hourly rates with a transparent fixed-price quote for your specific target environment.

A detailed, transparent breakdown by scope, method, and effort is available in our article on pentest costs.

Pentest costs in detail →

A penetration test provides more than just technical details. It establishes a reliable basis for understanding and developing IT security as part of overall corporate governance. Organizations benefit on several levels.

• Transparency: Clear visibility into existing vulnerabilities, the attack surface, and the actual security posture.
• Prioritization: Structured assessment by risk and impact, enabling targeted allocation of resources.
• Effectiveness check: Verification of whether existing security controls such as firewalls, WAFs, or endpoint security function as intended.
• Strategic planning: A solid basis for investment decisions and for further developing the security strategy.
• Compliance and assurance: Support in meeting regulatory requirements (e.g., ISO 27001, TISAX, NIS2, PCI DSS) and providing objective evidence to customers, partners, or auditors.
• Response capability: Insights into how quickly and effectively internal teams react to simulated attacks.

The essential benefit is that organizations can assess their security posture not only in theory, but in practice and in a verifiable manner. This enables realistic risk evaluation and well-founded prioritization of mitigation measures.

A common question from clients is: Why does binsec GmbH consistently uncover vulnerabilities in penetration tests that other providers have missed?

The answer is PTDoc – our internal tool for the structured execution and documentation of penetration tests. Developed by binsec systems GmbH and maintained within the binsec group, it was created to address a central challenge: How can quality remain consistently high as the team grows and individual testers have different personal focus areas? And how can we ensure that results are always identical and reproducible, regardless of which senior penetration tester performs the assessment?

PTDoc provides the solution: standardized methodologies for different targets – from Active Directory to mobile applications to networks. Established standards such as the OWASP Testing Guide, MASVS, and OSSTMM are continuously integrated. At the same time, the experience of our testers is embedded in the test steps: new checks are regularly added and made immediately available to the entire team.

In practice, this means:

• binsec uncovers vulnerabilities that others miss. Over the past years, we have repeatedly identified findings that were overlooked in previous tests.
• PTDoc relieves binsec’s testers: They can fully focus on executing the test, while documentation, evidence management, and report generation are handled efficiently in the background.
• Reports are fast and multilingual: PTDoc supports both German and English reporting – and can deliver results in both languages if required.

This is the secret behind binsec pentesting: a systematic approach that combines standards and experience, ensures quality and repeatability – and delivers the decisive difference for clients. One client summarized it this way: “Since working with binsec, I don’t even consider the previous tests from other providers to have been real penetration tests.”

Before a penetration test is conducted, it may be necessary to establish contractual agreements addressing data protection requirements. This ensures compliance with legal regulations (e.g., GDPR) and clearly defines the responsibilities and obligations between the client and the penetration tester. The scope of personal data processing during a penetration test largely depends on the specific objectives of the engagement. The following types of personal data may be processed during a penetration test:

• Personal Data of One or More Client Contacts

  This typically includes the first name, last name, business email address, business phone number, and position within the company. These personal details are usually stored and processed in email clients, on mail servers, within phone systems, in calendar entries, and in the final penetration test report. It may sound trivial – and in this case, it is – but this information is necessary for communication between client and tester. Such data is always processed and is often publicly available anyway.

• Personal Data of Other Employees

  When the objective of the penetration test targets the corporate network, contact with employee personal data is often unavoidable. For external penetration tests, this is less common, but for internal tests, especially those involving Active Directory, it is almost inevitable. At a minimum, tester may obtain the names of employees. A common part of internal testing involves attempting to escalate privileges or gain access to additional accounts and systems. If successful – which becomes more likely as the number of employees increases – the tester may obtain valid passwords or at least password hashes. To conduct the test, at least this data must be processed locally on the tester's device. Further escalation, such as account compromise or bypassing access controls, may expose even more information. In the worst-case scenario, such as a full compromise of Active Directory, a large volume of personal data could become accessible. However, it is not necessary to copy this data to the penetration tester's systems – quite the opposite: it should be avoided wherever possible. There is no operational need to do so.

• Personal Data of the Client’s Customers

  Personal customer data may be encountered when production systems are tested. A straightforward example is an online store. Securing customer data in such systems is a primary goal of penetration testing. Part of the test is to determine whether it is possible to gain unauthorized access to customer records. If successful, individual customer data entries may be temporarily displayed and thus processed locally on the tester’s device.

In the latter two cases, it may be advisable to conclude a data processing agreement (DPA). The focus should always be on the principle of data minimization. A penetration tester is – obviously – not a malicious attacker, and there is no need to process significant volumes of personal data. Only for reporting purposes is it necessary to find a reasonable compromise between anonymization and pseudonymization. For example, if login credentials are successfully obtained during the penetration test, they must be included in the report to provide the client with the relevant information. However, these credentials should not be linked to specific individuals.

Penetration tests generate sensitive information: technical details about systems, configurations, vulnerabilities, user accounts, and internal structures. It is therefore essential to define not only where but also how this data is processed.

All processing takes place within a controlled, self operated infrastructure in Germany. Operations run from a data center in Frankfurt am Main and are complemented by a physically separate hot standby location to ensure redundancy and high availability. Project data is not processed in public cloud environments and is not transferred to unspecified third countries.

Own IPv4 and IPv6 address space is operated. As a Local Internet Registry, an independent network and routing infrastructure is maintained using enterprise hardware including Juniper networking components. Hypervisor and storage systems are fully operated under direct technical control.

Project data is handled exclusively within dedicated, segmented systems. Access is strictly role based and limited to the senior penetration testers involved in the respective engagement. Collected data typically includes:

• technical test notes and analyses
• screenshots and evidences
• draft and final reports

All laptops used are fully encrypted. Project data is deleted locally from tester systems after completion. Central documentation and management of all findings takes place exclusively within PTDoc as the controlled core system. This combination of self operated infrastructure, strict access separation, encrypted endpoints and structured documentation processes ensures that data processing remains controlled and traceable.