Definition
DPA (Data Processing Agreement) is an agreement between the data controller (customer) and the data processor (platform/service provider), specifying the purpose, scope, methods, security measures, subprocessors, audit rights, and more. In conjunction with SCC Standard Contractual Clauses, it meets the requirements of GDPR Article 28 for data processors and is the legal basis for compliant operation of cross-border IoT platforms.
GDPR requirements
Article 28 of the GDPR stipulates that when a data controller entrusts a data processor to process personal data, a written agreement must be signed specifying: the purpose and duration of the processing; the types of data and categories of data subjects; the obligations and responsibilities of the data processor; security measures; management of sub-processors; audit and compliance cooperation; and data deletion or return. The DPA is an essential legal document between clients and the platform, and its absence will lead to compliance risks.
Cross-border Transfer
When data processing involves cross-border transfers (such as EU data transferred to non-adequacy countries), the DPA should be combined with SCC (Standard Contractual Clauses). The SCC templates issued by the European Commission provide a compliance framework for cross-border transfers and can be included as an appendix when the platform signs a DPA with a client. The DPA and SCC together constitute the legal basis for cross-border transfers.
Practice in ICMP
SimtoLink ICMP provides a standard DPA template covering all clauses required by the GDPR; it supports SCC appendices; it specifies Data Residency, Audit Trail, security measures, and a list of sub-processors. Once the client signs the DPA, the platform's data processing activities have a lawful basis, meeting the compliance requirements of enterprise clients and regulators.
Purposes and subprocessors the agreement sets
A data processing agreement writes down, as instructions both sides share, which personal data the platform may touch, for what purpose, and who else receives it. The controller decides purposes and means. That is usually the enterprise buying connectivity. The processor processes on instruction. That is usually the party providing the platform. Purposes have to be specific to actions in connectivity management, such as provisioning, billing, troubleshooting, and security audit. “Providing IoT services” alone is not enough. Data categories should name which of SIM identifiers, device identifiers, usage, location, and contacts will be processed.
A subprocessor is someone the processor delegates to further: a cloud facility, an SMS route, or a payment institution. The list needs the name and the location. Before a name is added or replaced, the controller is notified as the agreement requires. A supplier the agreement does not list should not receive an export that can identify a person. Security measures should describe controls that are actually in place, such as access rights, encrypted transport, and logs, not a vague promise to “use advanced means.” The scope of audit assistance has to be written clearly as well, so a later request does not ask for material the platform does not keep.
Processing the platform starts only after signature
Where EU rules apply and the platform is a processor, it should not start processing the customer’s personal data without a written agreement. That includes importing production detail records, opening an account for the customer that carries personal contact details, and using location for diagnostics. Internal tests should use data that cannot identify a real person. Processing that happened before the effective date does not automatically become an instruction that already existed at the time, just because the agreement is signed later. How data already collected will be handled needs a separate explanation.
The agreement also limits how long data is kept, and whether it is deleted or returned at the end. Its relation to the General Data Protection Regulation is this: the regulation requires this written arrangement, and the agreement turns the arrangement into clauses that can be carried out. A transfer to a country without an adequacy decision needs more than the agreement itself. It also needs standard contractual clauses, or another lawful mechanism the controller has determined. A platform cannot use an agreement that covers only in-country processing to support analysis that has already left the country. A change of purpose, such as using billing data to train a model, needs a new instruction. It cannot be inferred from the old agreement.
Clauses that do not cover the actual cross-border path
A common gap is an agreement that says data stays in one region, while the architecture puts backups, logs, or support tools in another. When the path the clauses describe and the path the packets actually take disagree, the agreement does not cover the real processing. A second gap is a stale subprocessor list: object storage has moved to another provider, and the agreement still names the old one. A third is data categories that omit location and device identifiers, while engineering exports those fields in diagnostics. The export then falls outside the instruction.
A duration clause that says “for as long as the business needs it” becomes permanent retention in operations. Disabling the account at the end, and not deleting backups, also goes beyond the return or deletion clause. The wrong signing entity is equally serious: the contract is with a group company, and the actual processing happens in a subsidiary that was not listed. When the paths disagree, stop new outbound replication first, then amend the agreement or move the system back to the region the clauses describe. Do not change only a sentence in the privacy notice. Processing records should match an agreement version number. Without a version number, it is impossible to know which instruction allowed a particular export at the time.
The agreement version has to match the system configuration actually used for each processing activity. Adding an SMS provider, changing object storage, or handing a diagnostic export to another support desk is a subprocessor or path change. Amend the agreement before turning the traffic on. If emergency troubleshooting must let someone not on the list see data, limit the time, the fields, and the account, revoke access when it ends, and record the exception. One emergency view is not a reason to leave a shared directory open. If an instruction from the controller conflicts with the purpose in the agreement, the processor should stop and confirm, rather than process first to save time and file the paperwork later.