Every time a company collects, stores, consults or sends personal data it is doing something that the GDPR regulates precisely: a processing of personal data. The concept is broader than it seems and encompasses operations that many organisations do not even perceive as "processing data". But where the real doubts usually arise is the moment that data leaves the organisation: when it is shared with another company, when it is processed by an external provider or when it travels to servers outside Europe.
These three movements —communicating data to a third party, entrusting its processing to a provider and transferring it internationally— respond to different legal rules and are frequently confused. This guide clarifies what processing is exactly under art. 4.2 GDPR, how a disclosure differs from a processing arrangement, and what mechanisms make an international transfer outside the European Economic Area lawful.
In short
- Processing (art. 4.2 GDPR) is any operation on personal data: collect, store, consult, alter, disclose, erase…
- A disclosure is a communication of data to a third party that acts as a controller in its own right, with its own purposes.
- The data processor (art. 28 GDPR) processes data on behalf of the controller, following its instructions and without purposes of its own. It is not a disclosure.
- International transfers outside the EEA are only lawful with one of the mechanisms of arts. 44–49: adequacy (art. 45), appropriate safeguards / SCC (art. 46) or derogations (art. 49).
- For US SaaS providers, the usual basis is the provider's certification under the Data Privacy Framework (DPF), not just the standard contractual clauses.
What the processing of personal data is (art. 4.2 GDPR)
Art. 4.2 GDPR defines processing as "any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means". The definition is deliberately broad: the European legislator wanted no manipulation of data to fall outside the reach of the rule.
The article itself lists, by way of example, a very varied range of operations: collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure and destruction.
Two practical ideas worth internalising follow from this:
- Storing data is already processing it. There is no need to actively "use" the information: the mere retention of a customer database on a server constitutes processing and triggers all the GDPR obligations.
- The medium matters little. Processing exists whether the data is in a computer system or in a structured paper file. Automation is not a requirement for the rule to apply.
All processing must rely on one of the legal bases of art. 6 GDPR (consent, performance of a contract, legal obligation, legitimate interest, etc.). And, even though the processing does not require consent because it is based on a contract or a legal obligation, the organisation is never exempt from its duty to inform (art. 13 GDPR): the privacy notice must be provided or made accessible at the first contact. Transparency is non-negotiable, regardless of the basis that makes the processing lawful.
Disclosure of data versus processing arrangement: the key distinction
When data leaves the organisation towards another entity, the first question to answer is always the same: who decides what that data will be used for? The answer separates two figures that are constantly confused but that have opposite legal consequences.
The disclosure or communication of data to a third party
There is a disclosure (or communication of data) when an organisation reveals personal data to a third party that goes on to process it as a controller in its own right. The recipient does not follow the discloser's instructions: it incorporates the data into its own files and uses it for its own purposes, under its own responsibility.
Common examples of disclosure are the communication of data to the Tax Administration in compliance with a tax obligation, the sending of a worker's data to Social Security, or the communication of a customer's data to a financial institution that autonomously decides what to do with it. In a disclosure, each party is accountable for its own processing and both must have a legal basis of their own.
By its very nature, the disclosure of data to third parties is subject to a demanding analysis: it requires identifying the legal basis that covers it, informing the data subject of it and assessing whether the communication is really necessary and proportionate. It is not an operation that can be taken for granted.
The data processor (art. 28 GDPR)
The data processor, by contrast, processes the data on behalf of the controller and following its instructions, without deciding what it is used for. Here there is no disclosure: the data does not change "decision owner", it is simply processed by an external provider on behalf of the company. The accountancy firm that prepares your payroll, the cloud CRM where you keep your customer base or the IT company that maintains your servers are processors, not recipients of a disclosure.
Art. 28 GDPR requires this relationship to be governed by a written processing contract with a specified minimum content (art. 28.3): subject matter and duration, nature and purpose of the processing, types of data, confidentiality obligations, security measures, the regime for sub-processors, and the fate of the data at the end of the service, among others.
That last point deserves an important clarification. At the end of the contract, the processor's priority obligation is not to "destroy" the data without further ado: it is to return it or allow its full export to the controller —in a structured, commonly used format— so that the controller can meet its own legal retention periods. Final deletion comes only afterwards, once the controller has the information. Confusing this and accepting automatic deletion at the end of the service can leave the company without data that the law requires it to keep.
To go deeper into this figure, its regime of obligations and the content of the processing contract, you can consult our guide on the data processor under the GDPR.
| Criterion | Disclosure / communication to a third party | Processing arrangement (art. 28) |
|---|---|---|
| Role of the recipient | Controller in its own right | Processor: acts on behalf of the controller |
| Who decides the purposes | The recipient, autonomously | The controller; the processor only executes |
| Legal instrument | Own legal basis + duty to inform | Written processing contract (art. 28.3) |
| Examples | Tax Administration, Social Security, banking institution | Accountancy firm, cloud CRM, hosting, external IT |
| Own use of the data | Yes, for its own purposes | No; prohibited from using it for its own purposes |
"The question is not who you share the data with, but who is in charge of it once it leaves your company. If the provider follows your instructions, it is a processor and you need an article 28 contract. If it decides on its own, it is a disclosure and the analysis changes completely. Whoever does not distinguish those two figures signs the wrong papers."
Mario P. Talamillo · Managing Partner, Certix®
International transfers: when data leaves the EEA
There is an international transfer when personal data is made available to a recipient located in a third country outside the European Economic Area (EEA) —the EU States plus Iceland, Liechtenstein and Norway— or to an international organisation. This happens far more often than is perceived: contracting software with servers in the United States, using a foreign email marketing tool or hosting data in the cloud of a global hyperscaler are, all of them, international transfers.
Chapter V of the GDPR (arts. 44 to 49) starts from a principle: data may leave the EEA, but the level of protection may not be degraded. To ensure this, every transfer must rely on one of the mechanisms the rule provides. Without one of them, the transfer is not allowed.
Valid international transfer mechanisms
The GDPR orders these mechanisms in a practical hierarchy running from the most solid to the most exceptional:
| Mechanism | What it involves | When it is used |
|---|---|---|
| Adequacy decision (art. 45) | The European Commission has recognised that the destination country offers an adequate level of protection. The transfer does not need additional safeguards. | Countries with recognised adequacy (e.g. the United Kingdom, Switzerland, Japan, Canada for the private sector) |
| Appropriate safeguards — SCC (art. 46) | In the absence of adequacy, the transfer relies on appropriate safeguards. The most common are the standard contractual clauses (SCC) approved by the Commission. | Providers in third countries without an adequacy decision |
| Binding corporate rules — BCR (art. 47) | Internal data protection policies approved by the supervisory authority, for transfers within the same multinational group. | Business groups with subsidiaries outside the EEA |
| Data Privacy Framework — DPF (art. 45) | Specific adequacy decision for the US. It covers transfers to US providers that have formally certified under the framework. | US SaaS and cloud providers certified under the DPF |
| Derogations (art. 49) | In the absence of the above mechanisms, only for specific situations: explicit and informed consent, performance of a contract with the data subject, important public interest… | One-off and exceptional use, never for mass or habitual transfers |
The US case: the Data Privacy Framework (DPF)
The United States concentrates much of the SaaS tools, cloud platforms and digital services that European companies use daily. That is why it deserves a rule of its own. The main route to make a transfer to a US provider lawful is its certification under the Data Privacy Framework (DPF), the specific adequacy decision the European Commission adopted for the US.
This has a very practical consequence: if the provider appears certified under the DPF, the transfer is directly covered by an adequacy decision and it is not essential to sign additional standard contractual clauses for that flow. That is why the correct analysis of a US SaaS always starts by checking its DPF certification, and not by assuming that the SCC are enough.
The verification is simple: the list of certified entities is public and can be consulted in the official register of the framework. If the provider is not certified, the transfer will have to rely on another mechanism of art. 46 —typically the standard contractual clauses, accompanied where appropriate by the supplementary measures that prove necessary after assessing the flow.
This is one of the most frequent analysis mistakes: contracting a US tool and signing SCC "by default" without first checking whether the provider is in the DPF, or the other way round, assuming that any US provider is covered without verifying it. Each international flow requires reviewing the specific mechanism that covers it.
Checklist to process, disclose and transfer data in an orderly way
This operational summary gathers the points every organisation should review before sharing or moving personal data:
| ✓ | Item | Reference |
|---|---|---|
| □ | Each processing operation relies on an identified legal basis | Art. 6 GDPR |
| □ | Privacy notice provided at the first contact | Art. 13 GDPR |
| □ | Documented distinction between recipients of disclosures (controllers) and processors | Arts. 4.7, 4.8 and 28 GDPR |
| □ | Processing contract signed with every provider that processes data on your behalf | Art. 28.3 GDPR |
| □ | Own legal basis and necessity analysis for each disclosure to third parties | Art. 6 GDPR |
| □ | Inventory of international flows: what data leaves the EEA and to where | Arts. 44–49 GDPR |
| □ | Transfer mechanism verified (adequacy, SCC, BCR or DPF) | Arts. 45–47 GDPR |
| □ | DPF certification checked for each US SaaS provider | Art. 45 GDPR (DPF) |
| □ | Return or export of data ensured before any deletion by the processor | Art. 28.3.g GDPR |
These three planes —processing, disclosure and international transfer— are part of the general framework of the Regulation. If you want an overview of the whole rule, its principles, rights and obligations, you can consult our complete GDPR guide.
Frequently asked questions
What is considered processing of personal data under the GDPR?
Art. 4.2 GDPR defines processing as any operation performed on personal data, whether or not automated. It includes collection, recording, storage, consultation, alteration, use, disclosure by transmission, dissemination, interconnection, restriction, erasure and destruction. Practically anything an organisation does with a piece of personal data —even keeping it without using it— is processing subject to the GDPR.
What is the difference between a disclosure of data and a data processor?
In a disclosure (communication of data to a third party) the recipient becomes a controller in its own right: it uses the data for its own purposes. In a processing arrangement (art. 28 GDPR), the provider processes the data on behalf of the controller, following its instructions and without purposes of its own. Your accountancy firm or your cloud CRM are processors; an entity to which you disclose data so that it uses it for its own purposes is a recipient of a disclosure.
When is an international transfer of data outside the EEA lawful?
Only if it relies on one of the mechanisms of arts. 44 to 49 GDPR: an adequacy decision by the European Commission (art. 45), appropriate safeguards such as the standard contractual clauses or binding corporate rules (art. 46), or, exceptionally and on a one-off basis, one of the derogations of art. 49. Without one of these mechanisms, the transfer to a third country is not allowed.
Can I use a US SaaS provider with data of European customers?
Yes, provided the transfer is covered by a valid mechanism. For US providers the main route is the provider's certification under the Data Privacy Framework (DPF), the specific adequacy decision for the United States. Before hiring the tool it is advisable to check that the provider appears certified under the DPF; if it is not, you will have to resort to the standard contractual clauses of art. 46 or another safeguard mechanism.
Mapping your data flows, distinguishing processors from disclosures and verifying each international transfer requires an individual analysis of your organisation. At Certix a data protection expert attends to you directly.
Data protection consultancy →This content is purely informational and educational; it does not constitute specialised legal advice in any case. Applying the regulations to each specific case requires individual analysis. For an assessment of your organisation's situation, contact a data protection specialist.