CRTO Certified Red Team Operator

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.