Separating IT When a Polish Group Company Is Sold or Spun Off

“We need to sell a subsidiary. How long will it take to separate the IT?" — “Two weeks." — “And how long will it really take?" — “Three months, if you start with the inventory you have never conducted and the data processing agreements you have never signed."

In corporate groups, IT is not a service. It is a habit. For years, no one signs any agreements because companies within the same group “trust each other." The facts outpace the legal arrangements, and no one has a problem with that—as long as the group stays together. The problem arises on the day when something that was never consciously woven together has to be untangled: the sale of a subsidiary, a spin-off, a change of ownership, or making an entity independent.

If you run a corporate group with centralized IT, are planning a spin-off, or are preparing a company for sale, this article explains the legal, tax, and operational risks you must address when exiting intra-group IT. You will learn what steps to take before signing any agreement, how to secure the GDPR layer, and what to do with licenses that do not transfer automatically between companies.

Key concepts you need to know before starting the separation

Before moving on to specific steps, it is worth clarifying the terminology. Separating IT within a corporate group involves several legal regimes at once—and each uses its own concepts.

Why separating IT within a corporate group is a legal rather than a technical problem

Most management boards treat IT separation as a task for the technical department: “hand over the passwords, transfer the domains, carry out the migration." But a handover is not simply about providing a password. It involves changing a party to an agreement or establishing an entirely new legal relationship from scratch.

Four areas you need to address in parallel

1. Contractual matters. Agreements with cloud providers contain clauses restricting assignment. The Google Workspace terms prohibit the transfer or assignment of any part of the agreement without the other party’s written consent—except for an assignment to an affiliate that agrees in writing to comply with the terms of the agreement. The assignor remains liable for obligations arising before the assignment. Any other attempted transfer is void. It is the provider—not an agreement between the companies—that determines the actual schedule.

2. Regulatory matters. DORA (Regulation 2022/2554) requires financial entities to maintain a documented and tested exit plan for every ICT agreement supporting critical functions. NIS2 (Directive 2022/2555) introduces analogous requirements for managing risks associated with ICT providers. Check whether either party is subject to these regulations—if so, ending the relationship with an ICT provider (even an intra-group one) requires a formal exit strategy.

3. Tax matters. Gratuitous IT services between related entities generate income under Article 12(1)(2) of the CIT Act for the beneficiary. The amount of income is determined based on prices charged to other customers or market prices for comparable services (Article 12(6) of the CIT Act). Questions about costs must be asked BEFORE signing, not afterward.

4. Data protection matters. Years of personal data processing by the company administering the IT without a data processing agreement (Article 28 GDPR) constitute a breach that does not disappear on the day the parties separate—that is precisely when it becomes visible. A transfer of data within a group does not have a separate legal basis merely because the companies are related. Recital 48 GDPR (legitimate interest) is an argument, not an exemption from obligations.

IT asset inventory—what to do before signing any agreement

Before you sign an IT handover agreement, you need to know what you are handing over. It sounds obvious. It is not.

Three questions for every item

For every IT asset (cloud systems, email, security, hosting, domains and their registrant details, network and server equipment, licenses, hardware), answer three questions:

Assets that are easy to overlook

1. Service and shared accounts (not assigned to any individual)
2. Access credentials stored in the private password managers of individual IT employees
3. API tokens, SSH keys, SSL certificates
4. MFA configurations linked to private phones
5. Email archives
6. Ticketing systems containing customer data from both companies
7. Monitoring systems and security logs
8. Backups (including copies held by external providers)

Compile a list of ALL privileged accounts—including unofficial ones. If the answer to the question “who has access" is “I don’t know," that in itself is a sign that an inventory must be conducted before taking any further steps.

Contact us

The GDPR layer—a breach that only comes to light upon separation

Why the absence of a data processing agreement is a problem now, rather than “sometime in the past"

If the answer to the question “do we have a data processing agreement with every data controller in the group" is “we never thought about it," this means that the processing was in breach of Article 28 GDPR throughout the entire period of cooperation.

A breach of Article 28 GDPR (absence of a data processing agreement) is subject to an administrative fine of up to EUR 10 million or 2% of annual turnover (Article 83(4) GDPR). A breach of the obligation to report a personal data breach (Articles 33–34 GDPR) is subject to a fine of up to EUR 10 million or 2% of turnover.

Moreover, Article 82(5) GDPR provides for recourse between jointly liable entities. No limitation of liability clause can exclude this. Article 47(2)(f) GDPR also establishes the principle that a group entity with an establishment in the EU is liable for breaches of corporate rules by another group member.

What you need to do about GDPR before the separation

1. Determine the roles. Establish who was the controller and who was the processor throughout the entire period of shared IT. This is not a matter of declarations—what counts is who actually determined the purposes and means of processing.

2. Enter into the missing data processing agreements. Do so no later than the date on which the agreement is signed, separately with each controller. A data processing agreement entered into after years of processing without one will not undo the breach—but it will put matters in order going forward.

3. Negotiate a written statement on the status of data processing. Require the transferring party to provide: a list of systems and data categories, a list of sub-processors and the countries in which processing takes place, information on transfers outside the EEA, a history of breaches and reports, and confirmation of authorizations and confidentiality obligations.

4. Set a deadline and define the scope for permanently deleting data after the handover is complete. Article 28(3)(g) GDPR requires data to be returned or deleted after processing ends. Explicitly list the locations that are easy to overlook: backups, email archives, ticketing systems, password managers, monitoring systems, and logs. Require written confirmation of deletion.

5. Maintain the mutual obligation to report breaches. Set a short notification deadline and keep this obligation in effect for a specified period after the handover is complete—for events originating during the period of shared IT.

Licenses that do not transfer automatically

Software licenses do not transfer automatically between companies. A transfer requires the licensor’s consent or an explicit basis in the license agreement (Article 74 et seq. of the Copyright Act).

Verify whether each license is transferable. Where a license cannot be transferred, plan and price the purchase of a new license by the receiving party before signing the agreement. Using software without a valid license after the separation constitutes copyright infringement.

Procedures for changing the contracting entity with cloud providers—what you need to know

Polish law does not contain a statute specifically governing cloud computing. Whether cloud agreements may be assigned is assessed under the general provisions of the Civil Code, the GDPR, and sector-specific guidelines (KNF, CSIOZ). This means that the actual restrictions arise from the providers’ terms and conditions.

Google Workspace

1. The terms prohibit assignment without written consent—the exception is an assignment to an affiliate that agrees in writing to comply with the terms of the agreement
2. Domain Transfer requires at least 7 days to implement retention rules in Google Vault, 48 hours to convert the primary domain into a secondary domain, and 24 hours for a test run
3. The primary domain cannot be transferred while it remains the main domain—it must first be converted into a secondary domain
4. The administrators of both environments must expressly authorize the domain transfer team

Microsoft 365 / Azure

1. Transferring ownership of Azure subscription billing requires acceptance by the future owner—after the transfer, role assignments must be reviewed and updated
2. Changing an Azure subscription’s directory requires an account with an owner role in both the current and new Microsoft Entra directories—after the operation, it may take several hours for all data to become visible
3. Migrating OneDrive and Exchange Online between tenants requires establishing a relationship between the administrators of both tenants—the migration time depends on the number of users and the volume of data
4. Microsoft’s technical documentation does not require corporate documents (e.g. an extract from the National Court Register) as a condition for the operation—the entire process is based on administrative permissions

Conclusion: the schedule agreed between the companies must account for provider procedures. Companies planning a handover within 2 weeks may discover that the provider needs 8 weeks to change the contracting entity.

Phased handover—how to avoid gaps and overlaps

A gap means an outage—after the separation, no one manages critical systems, leading to operational downtime. An overlap creates a security risk—both parties have full administrative permissions to the same systems, and if an incident occurs, neither can demonstrate whose actions caused it.

Three handover phases

Handover mechanism for each asset

Design a two-stage mechanism:

1. Provision of credentials—the transferring party provides passwords, keys, and tokens through a secure channel (password manager, one-time link, encrypted channel)
2. Confirmation of receipt—the receiving party confirms receipt within a specified period; failure to respond by the deadline constitutes tacit confirmation

Link the transfer of responsibility to the date of confirmed receipt, not to the date on which the agreement is signed.

After confirming receipt of each asset, the receiving party changes the passwords, keys, tokens, certificates, and MFA configuration. The transferring party deletes its copies of the credentials. Keep an up-to-date register of the access credentials handed over—including the handover date and the date of confirmed receipt for each item. It is both an operational tool and a record of evidence.

No-objections statement—why you should not sign it blindly

Any general no-objections statement made on the date the agreement is signed is a statement made blindly. The receiving party confirms the quality of IT support that it had no way of verifying—because it did not have administrative access to the systems.

How to limit the risk

Limit the no-objections statement to disclosed and verifiable circumstances. Exclude the following from its scope:

1. Security configurations (e.g. whether MFA was enabled or backups were working)
2. Access history (who had administrative permissions and when)
3. Personal data breach events (incidents of which the receiving party is unaware)
4. Compliance of data processing with the GDPR

Supreme Court case law confirms that a waiver of future claims is permissible—but only if the legal relationship from which the future claims are to arise is defined with sufficient precision (Supreme Court judgment I CSK 125/08). A waiver of “uncreated" claims may be effective if the clause expressly covers claims “that may arise in the future" (Supreme Court judgment II CSKP 1361/22 of 24 April 2024)—but this does not mean that you should accept such a clause without limitations.

What cannot be waived

Exclude from the waiver clause anything that cannot be waived:

1. Claims by data subjects (individuals whose data is processed)
2. Recourse under Article 82(5) GDPR
3. Liability toward the Polish Data Protection Authority
4. Personal data breaches predating the handover
5. Breaches of the agreement itself
6. Liability for damage caused intentionally (Article 473 §2 of the Civil Code—liability for intentional damage cannot be excluded)

Tax considerations—the free-of-charge transfer of IT between related entities

A free-of-charge transfer of IT between group companies is a controlled transaction within the meaning of the transfer pricing regulations. Ignoring this aspect may result in an upward adjustment of income.

What the law says

Under Article 12(1)(2) of the CIT Act, income includes the value of items or rights received, as well as the value of other gratuitous or partially paid benefits. In resolutions FPS 9/02 and II FPS 1/06, the Supreme Administrative Court defined a gratuitous benefit as any economic event resulting in a benefit obtained at another entity’s expense without equivalent consideration and having a specific financial value.

As a rule, the free-of-charge provision of IT infrastructure, ERP systems, server licenses, or IT support services by a related entity generates income for the beneficiary.

Documentation obligations

The paradox is that the statement under Article 11m of the CIT Act declares that the terms of a transaction are at arm’s length when the transaction is inherently free of charge. Have the free-of-charge nature of the transfer reviewed from a tax perspective before signing the agreement—not afterward.

The transitional period—using another company’s network without obligations

During the transitional period, the receiving company often uses the transferring company’s network infrastructure. The network goes down on Friday evening—and no one is obliged to repair it because permission to use it did not include any service terms.

What to regulate in the agreement

1. Prohibition on accessing the content of communications. The confidentiality of electronic communications regulated by the Electronic Communications Law (Act of 12 July 2024, Journal of Laws of 2024, item 1221) covers traffic data and location data. The prohibition on processing applies to all persons other than the sender and recipient—including internal network operators.

2. Restrict the processing of traffic data to security purposes, with a specified retention period.

3. Obligation to provide notice of requests from public authorities and of planned work or disconnection—with reasonable advance notice.

4. Service terms—even minimal ones: response time, contact person, and escalation rules in the event of an outage.

Subsequent disclosure mechanism—what about assets discovered after signing

An inventory is rarely complete on the date of signing. Therefore, include a subsequent disclosure mechanism in the agreement: an obligation to provide, free of charge, access to assets discovered after the process begins, within a specified period from signing.

This applies in particular to:

1. Service accounts known to only one administrator
2. Backups stored in locations not included in the original inventory
3. API integrations with external systems of which the receiving party was unaware
4. SaaS subscriptions paid for through the transferring company’s account but used by the receiving company

NIS2 and DORA—additional requirements for regulated entities

If either party is subject to NIS2 (Directive 2022/2555) or DORA (Regulation 2022/2554), ending the relationship with an ICT provider—even an intra-group one—requires a formal exit strategy.

Article 28(2) DORA requires financial entities to maintain a documented and tested exit plan for every ICT agreement supporting critical functions. The plan must address contingency scenarios, the migration schedule, and business continuity.

NIS2 introduces analogous requirements for managing risks associated with ICT providers. The PolishCloud 2.0 and 3.0 standards specify the elements of an exit plan for the Polish market.

An intra-group provider is subject to the same requirements as an external provider—there are no separate regulations for IT services provided within a corporate group.

Checklist: 12 steps before signing an IT handover agreement

Separating IT within a group—when to start and who to involve

Separating IT within a corporate group is not a two-week project. It is a process that requires lawyers, the IT department, the finance department, and the management board to work in parallel. The sooner you start, the lower the risk that on the day of the transaction you will discover that your company’s domains are registered to another entity, MFA was never enabled, and no one reported two security incidents to the Polish Data Protection Authority.

We prepare agreements for transferring IT functions between companies, conduct legal inventories of IT assets within corporate groups, negotiate separation terms, and secure the GDPR layer when systems are separated. We combine IT law, data protection, contract law, and corporate law in a single model—because IT separation involves all of them at once.

Are you planning a spin-off, sale, or separation of a group company? Before you start negotiating the price, find out how much it will cost to untangle the IT. Contact us.

Frequently asked questions

We have centralized IT within the group, but nothing is documented—where should we start?
Start with an inventory of IT assets. For each item (cloud systems, email, domains, licenses, equipment), answer three questions: who owns it, who is the party to the agreement with the provider, and who administers it. Only after completing the inventory will you know what actually needs to be transferred—and how long it will take.

Can we simply hand over the system passwords and consider the matter resolved?
No. Handing over a password does not change the party to the agreement with the provider, transfer licenses, resolve GDPR issues, or protect against liability for incidents occurring during the period of shared IT. The handover requires changing the party to an agreement or establishing a new legal relationship—and that requires the provider’s consent and takes time.

Who is liable for a GDPR breach that occurred 2 years ago, when one company processed another company’s data without a data processing agreement?
Liability depends on the parties’ roles under the GDPR. Article 82(5) GDPR provides for recourse between jointly liable entities. Article 47(2)(f) GDPR establishes the principle that a group entity with an establishment in the EU may be liable for breaches by another group member. Entering into a data processing agreement after the event will not undo the breach—but it will put matters in order going forward.

How long does it realistically take to separate IT between companies?
In Polish practice, a typical TSA period ranges from several weeks to three months. But this applies only to the provision of transitional services. A complete separation—from the inventory and assignment of provider agreements to the deletion of data from backups—may take longer, especially when cloud provider procedures require a separate process on their side.

Does a free-of-charge transfer of IT between group companies have tax consequences?
Yes. Gratuitous IT services between related entities generate income under Article 12(1)(2) of the CIT Act for the beneficiary. The transaction requires transfer pricing documentation (if it exceeds the materiality thresholds) and submission of the statement referred to in Article 11m of the CIT Act. False certification in this statement is punishable by a fine of up to 720 daily rates (Article 56c of the Fiscal Penal Code).

Our company is subject to NIS2—does ending the relationship with an internal IT provider require additional documentation?
Yes. NIS2 and DORA require a formal exit strategy for ICT agreements supporting critical functions. An intra-group provider is subject to the same requirements as an external provider—there are no separate regulations for IT services provided within a group. The exit plan must address contingency scenarios, the migration schedule, and business continuity.