GDPR

European Union General Data Protection Regulation

Definition

GDPR (General Data Protection Regulation) is a data protection law of the European Union that came into effect in May 2018 and applies to any organization processing personal data of EU residents. GDPR requires platforms to have compliance capabilities such as Data Localization, Data Residency, DPA, SCC, Audit Trail, and violations may result in heavy fines (up to 4% of global revenue or 20 million euros).

Core Principles

The core principles of GDPR include: Lawfulness, Fairness, and Transparency — data processing must have a lawful basis and the data subjects must be informed transparently; Purpose Limitation — data may only be used for explicit and lawful purposes; Data Minimization — only necessary data should be collected; Accuracy — data must be accurate and kept up to date; Storage Limitation — delete or anonymize after expiry; Security — take appropriate technical and organizational measures to protect data; Accountability — data controllers must demonstrate compliance.

Requirements for ICMP

As a data processor, ICMP needs to sign a DPA with the client (data controller); cross-border transfer to non-adequacy countries requires using SCC; supports Data Residency to store EU data in the EU region; provides Audit Trail to demonstrate compliance with processing activities; supports data subject rights (access, rectification, deletion, portability, objection, etc.); data breaches must be reported to the supervisory authority within 72 hours. The platform must implement GDPR requirements in architecture, processes, and documentation.

Practice in ICMP

SimtoLink ICMP meets GDPR compliance requirements: provides standard DPA and SCC; supports Data Residency deployment in the EU region; Audit Trail records data processing activities; supports process for handling data subject rights requests; conducts regular compliance audits and risk assessments.

Processing activities and roles the regulation covers

The regulation covers processing of personal data of people in the European Union. It is not limited to where the servers sit. In international connectivity, account contacts that can be tied to a person, SIM and device identifiers, usage records, location, and diagnostic exports may all be personal data. The role is what matters. The party that decides why data is collected and how long it is kept is the controller, usually the enterprise using the connectivity service. The platform that processes that data on the other party’s instructions is the processor. Touching the data does not let the platform decide on its own to train a model with it or promote it to a third party.

The lawful basis is determined by the controller and told to the data subject. The processor’s duties are to process only within the instructions, help the controller answer individual rights, notify a security incident under the agreed conditions, and make sure anyone it delegates to is bound as well. Location data is especially sensitive, because it can tie a SIM to a specific person. Saying “we process SIMs, not people” does not hold once a SIM is already bound to the person who uses it.

Conditions a processor must have in place

As a processor, the platform needs a written data processing agreement before processing starts. A transfer to a destination without an adequacy decision also needs standard contractual clauses, or another mechanism the controller provides. Technically, it must be able to place a customer’s data in the agreed region, export the fields that concern one person or the SIMs in that person’s name, and delete or de-identify them after the retention period. Access must be auditable. These are conditions of cooperation. A privacy notice does not replace them.

The clock for notifying a security incident starts when the platform discovers it, so logs and alerts have to be able to judge whether personal data is involved and which controllers are affected. Without that classification, notifications are either missed or every unrelated fault is reported. A subprocessor change has to be something the customer can be told about. Personal data in backups has to be inside the deletion scope. Otherwise the primary database is deleted and the data returns on restore. The entrance for a rights request is the controller. The platform provides search and execution. It does not decide, in the controller’s place, to refuse the person’s request.

Storing data in an EU region does not mean a rights request is finished

Putting the database in the European Union solves only part of the question of where data sits. When a data subject asks for access, correction, or deletion, the system still has to find every copy: the primary database, backups, logs, export files, and support tickets. Deleting only the primary database does not finish the request. If a correction changes only the contact name, and not an invoice already generated and kept as an accounting record, distinguish which fields may be changed and which are kept under a legal duty, and record the reason for keeping them.

Another mistake is treating regional compliance as a substitute for purpose limitation. Data in the European Union still cannot be used beyond the controller’s instructions. Syncing detail records to an analytics service that is not listed in the agreement is still outside the processing scope, even if that service is also in the European Union. When a deletion request conflicts with an invoice that is not yet closed, keep the minimum accounting record the law requires, and remove location and contact details that are no longer needed. Do not keep the whole invoice forever, and do not physically wipe the whole invoice at once. The reply to the customer should say which systems were acted on, and which were kept because of a duty. “The data is already in the European Union” cannot be the reason a request is closed. The processing record itself should also be able to show the role, purpose, and region at the time.

The search scope of a rights request should be listed in advance: primary database, backups, logs, export files, tickets, and message receipts. Each time a request is handled, tick where the search actually looked, what was deleted, and what was kept for an accounting duty. A retained item keeps only the minimum fields, for example the amount and period an invoice needs, and drops precise location and contact details. The controller verifies the requester’s identity. The platform does not delete production data on the strength of one forwarded email. A SIM that spans tenants must not be deleted along with others because the identifiers look similar. When the work is done, return the result to the controller, and let the controller reply to the data subject. The platform does not promise the person directly that no other system still holds a copy.

Related Terms

Return to International IoT Cloud Platform Terminology