GDPR and NIS2 in Nearshoring: Compliance Checklist for Clients

GDPR compliance in nearshoring is an ongoing task throughout the entire project lifecycle. Simply checking a box once during the bidding process is not enough. Anyone who outsources software development to a team in Poland, Romania, or Bulgaria remains responsible to supervisory authorities and—since NIS2—also to customers in their own supply chain.

What Actually Happens During an Incident

An example illustrates the scope of the problem. A nearshore developer accidentally opens a malicious attachment; his work computer is compromised, and the attack spreads to the client’s systems via a VPN connection. Without a documented reporting chain, the client may not find out about this until days later, when its own monitoring systems flag unusual data traffic.

Why NIS2 Expands Responsibilities in Nearshoring

NIS2 explicitly holds contracting entities responsible for the security of their suppliers. Article 21, paragraph 2, subparagraph d requires risk management measures that explicitly cover supply chain security and relationships with suppliers (Center for Compliance, 2026). In this context, a nearshore partner counts as a supplier. Anyone who outsources software development cannot, in the event of a security incident at the partner’s site, rely solely on the partner’s responsibility but must demonstrate that the selection and monitoring were carried out with due care. The Post by the Center for Compliance describes how closely business management and supplier management are now intertwined.

What Should Be Included in a Nearshoring Contract

The Data Processing Agreement under Article 28 of the GDPR forms the contractual basis. For transfers to a third country outside the EU, the 2021 EU Standard Contractual Clauses are also applied (ComplyCheck, 2026). For partners within the EU—such as those in Poland or Romania—this additional step is not required because a uniform data protection framework applies. This is precisely what makes nearshoring legally easier to manage than offshore locations in many cases.

Checklist for a Supply Chain Audit in Nearshoring

According to the Center for Compliance (2026), a comprehensive supply chain audit covers three areas that can be effectively implemented even by smaller clients: a documented chain of command for reporting security incidents, a background check for employees with access to sensitive systems—expressly including developers—and a technical assessment of the systems in use.

Minimum Requirements for Technical Maturity

A set of minimum requirements has been established for technical validation. These include a recognized security certification such as ISO 27001 or compliance with the BSI IT-Grundschutz standard, a requirement to report security incidents within 24 hours, a contractually stipulated right to conduct audits, and clear rules for the use of sub-processors (WarDek, 2026). A partner who does not meet any of these criteria deserves, at the very least, some critical questioning before the contract is signed.

At first glance, these requirements may seem challenging for smaller nearshore providers. In practice, however, established partners with several years of experience working with German companies usually already meet these criteria because their existing clients require the same documentation. The situation becomes more difficult for smaller, specialized providers that have primarily worked for clients without strict compliance requirements up to this point. Such providers may still be suitable, but they require the client to conduct a more detailed review of how these requirements are actually implemented.

Don't forget about intellectual property

In addition to data protection and IT security, the protection of intellectual property belongs on every checklist. A work-for-hire clause makes it clear that the code developed belongs to the client, not to the developer or the nearshore company. In addition, the developers involved must expressly waive their own rights of use, and there must be a defined open-source compliance framework to prevent licensing conflicts arising from integrated third-party libraries (Devilink, 2026). These three points are often missing from standard contracts and must be actively requested. Particularly with regard to open-source compliance, it is worthwhile to specifically inquire about the verification software used, because a mere assurance without a technical tool has little evidentiary value in the event of a dispute.

This article describes how to recognize general warning signs in collaborative work, even beyond the realm of compliance. Warning Signs with Nearshore Partners.

Contract structure and responsibility at torck

The checklist above shows how much depends on the provider’s structure when it comes to nearshoring. At torck, the contracting party is always the German company torck GmbH, regardless of where development takes place. German law applies. Responsibility under the GDPR lies with this German company, not with a subcontractor at the development site.

Development is carried out by our own teams in Maxhütte-Haidhof, Vienna, and Rabat. Rabat is a torck subsidiary—not an intermediary partner agency with its own subcontractors in the background, whose contractual relationships would still need to be clarified during an audit. Project management and point of contact personnel are based in Germany and Austria and serve as designated contacts throughout the entire project duration. The same quality standards for reviews and CI/CD apply at all three locations, documented and traceable for an NIS2 audit. This structure does not automatically answer every question on the checklist. However, it simplifies the clarification of reporting chains and responsibilities.

Frequently Asked Questions

Does NIS2 also apply to smaller contracting entities?

The direct scope of application of NIS2 depends on a company’s size and industry. Even outside the direct scope of application, many larger customers now require comparable evidence from their own suppliers as a contractual condition, meaning that the requirements effectively extend beyond the legal framework alone.

What must be included in a data processing agreement?

In addition to the standard clauses set forth in Article 28 of the GDPR, every data processing agreement with a nearshore partner must include specific details regarding the location of processing, the reporting deadline for incidents, the client’s right to audit, and provisions governing subprocessors.

Is an ISO 27001 certificate sufficient as proof?

A certificate sends a strong signal, but it does not replace contractual provisions regarding reporting obligations, audit rights, and subprocessors. Only the combination of a certificate and specific contractual clauses provides robust proof of compliance. A certificate without accompanying clauses merely shows that a system met certain standards at the time of the audit; it does not indicate how the partner actually operates in a specific project.

The Next Step

It is easier to work through this checklist if the contract structure is clear from the start. At torck, the contracting party is always the German company torck GmbH, which has a designated contact person and bears GDPR responsibility as a German company. In the Initial Consultation Let's go through the items on the checklist together for your project.