Treating GDPR compliance for SMS hardware as a property of the box you buy is the mistake most teams make. Teams often assume that moving a messaging stack onto their own premises removes the compliance question, when it usually moves the question one step closer to them and leaves every obligation intact.
This article maps where personal data actually sits in a gateway deployment, what changes when the equipment is yours, and the three questions that decide whether a compliance claim will survive a review. The focus is the data flow around the hardware rather than messaging law in general, and the reference points are the regulation itself and the guidance published by the bodies that interpret it.
What does the regulation actually govern in a messaging deployment?
It governs personal data processing, not the hardware.
GDPR is technology-neutral: it applies to any operation performed on personal data, so the relevant question for a gateway deployment is what data the deployment handles and why, not which device handles it.
The regulation is published in full on EUR-Lex, and the European Commission maintains an overview of how it operates in practice at its data protection portal. Two features of the text matter more than any summary. First, the definition of personal data is broad and includes any information relating to an identified or identifiable person, which in a messaging context includes mobile numbers, message content that identifies someone, and often the metadata around a delivery. Second, the obligations attach to roles rather than to devices, so the same hardware creates different duties depending on who determines the purpose of the processing.
Hardware does not create a compliance category. A multi-SIM gateway is not exempt because it processes traffic locally, and it is not automatically compliant because it is installed inside a customer’s building. What changes between architectures is which organisation performs which processing operation, how many parties are involved, and where the data travels. Those three variables are the substance of any review.
Where does personal data actually sit in a gateway architecture?
It sits in more places than the message body.
A messaging deployment touches personal data in message content, recipient numbers, sender identity, delivery logs, SIM identifiers and the account records held by the carrier.
Mapping these surfaces is the exercise that most deployment teams skip. The message body is the obvious one. The recipient number is personal data in almost every case, because it identifies a subscriber. The sender identity, when it is a number rather than a short code or an alphanumeric string, identifies a subscriber too. Delivery reports create a record linking a recipient to an event at a time. Device logs add the operational layer: which slot sent what, when, and whether it was delivered.
The counter-intuitive part is that aggregate operations data is usually not personal data at all. A count of messages sent per day, per port, or per route does not identify anyone, and treating it as if it did makes the compliance scope larger than it needs to be. Drawing the line carefully in both directions is what keeps the analysis manageable.
| Surface | Typically personal data? | Why it matters |
|---|---|---|
| Message content | Yes, when it relates to an identifiable person | Carries the highest sensitivity and the strongest retention pressure |
| Recipient number | Yes | Identifies a subscriber and links directly to a person |
| Numeric sender identity | Yes | Identifies the sending subscriber rather than only the sender brand |
| Delivery and device logs | Often, because they link a number to an event | Determines retention, deletion and access-request effort |
| Aggregate port or route statistics | Usually no | Keep it outside the scope instead of over-collecting |
What on-premise hardware changes, and what it does not
Running the equipment yourself changes the shape of the data flow. Instead of sending a request to a messaging provider that processes the message and returns a status, the deployment holds the SIM, performs the submission, and stores the resulting record locally. The number of parties involved in a single message falls, and the data that leaves your environment can be limited to what the carrier requires for delivery.
That is a real architectural difference, and for teams whose concern is the number of processors in their chain, it is a meaningful one. It is not, however, an exemption. The organisation operating the gateway is processing personal data, and the obligations that follow depend on its role rather than on the location of the equipment. On-premise deployment also creates obligations that a hosted service would otherwise absorb: log retention, access control, backup handling and secure deletion all become local responsibilities.
Two consequences deserve early attention. First, the device log becomes a record of processing, so its retention period has to be a decision rather than a default. Second, the carrier relationship gains a data dimension, because the operator processes subscriber data as part of delivering the message. Neither is solved by placing the gateway behind a firewall.
Which three questions decide whether you can claim GDPR compliance for SMS hardware?
Purpose, role and location decide the claim.
If you can answer what personal data you process and why, which organisation is the controller, and where the data goes and for how long, you have the basis of a defensible position.
The first question is purpose. Every processing operation needs a reason that can be stated in a sentence and, where the lawful basis depends on consent, evidence that consent was obtained and can be withdrawn. In messaging, that means the consent record has to be linkable to the number being messaged, which is a data model requirement rather than a legal one.
The second is role. The European Data Protection Board guidelines set out how the concepts of controller and processor are applied, and the analysis turns on who determines the purposes and means of processing. A supplier that only provides hardware and has no access to the traffic is in a different position from a supplier that routes messages on the customer’s behalf.
The third is location and duration. Where does the data go, which jurisdictions are involved, and how long does each record live? Answering this one honestly usually reveals a gap between the written policy and the actual configuration: logs kept indefinitely because nobody set a retention window, or backups that outlive the deletion commitment. The EDPB guidance library is the reference point when the answer has to be defended.
How do retention and deletion work when the device keeps a log?
Set the retention window first, then make deletion real.
A gateway log that is never deleted turns every retention promise into an inaccuracy, so the practical sequence is to decide the window, configure it, and keep evidence that deletion happens.
Retention answers a different question from archiving. You keep a delivery record because you need it to settle disputes about whether a message arrived, and that need has a natural horizon. Beyond that horizon the record is a liability with no operational value. Deciding the horizon per data type works better than one global figure: delivery status records and message content rarely need the same window, and content can often be dropped much earlier than status.
Deletion has to reach three places. The live database is the obvious one. Backups are the one that is usually missed, and they are also the one a reviewer will ask about. Export files created for reporting are the third, and they are the most common accidental long-term store, because a spreadsheet copied for a quarterly review becomes a shadow archive.
Access and erasure requests add a design constraint. If an individual exercises a right of access or erasure, the deployment has to be able to find every record that relates to their number. That is materially easier when numbers are normalised on entry, because a free-text field makes a complete search impossible and an incomplete search is not a defence.
Are you a controller or a processor in your messaging chain?
It depends on who decides the purpose.
A company sending its own notifications is normally the controller; a platform processing traffic on behalf of senders normally acts as a processor, with the corresponding contractual obligations.
The distinction is not determined by the equipment. Buying a gateway does not make a company a controller, and providing traffic capacity does not automatically make a supplier a processor, because the analysis follows the decisions: who chooses the recipients, who sets the purpose, and who determines what happens to the data afterwards.
In practice, messaging chains often contain more than two roles. A sender determines purpose, a traffic provider routes, a hardware supplier maintains equipment, and a carrier delivers. Each relationship that involves processing needs to be documented in a way that reflects the actual role, which is why the data-flow map in the next section matters more than a template contract.
Where a supplier has no access to personal data at all, the analysis is simpler, but that simplicity is a factual claim rather than a default. It has to be true of the configuration, including remote support access and diagnostic exports.
Producing a data-flow diagram that survives review
A diagram that survives review names systems rather than functions. It shows where the data enters, which component stores it, which component transforms it, and where it leaves, with the retention period attached to each store rather than to the diagram as a whole. It also shows the boundaries: which systems are operated by your organisation and which by another party.
Two additions turn a sketch into something usable. The first is a data inventory keyed to the diagram, so that a reviewer can move from a box to the fields it holds. The second is a change log, because the practical failure mode is not a missing diagram but a diagram that described last year’s architecture. The NIST Privacy Framework offers a structure for organising the inventory, and the control families in NIST SP 800-53 Rev. 5 are a workable reference for the access and logging controls that sit around it.
Where the deployment has a contractual duty to demonstrate accountability to a supervisory authority, the diagram is usually the first artefact requested. Producing it from the configuration rather than from memory is what makes it accurate, and accuracy is the only property that helps.
Scope note: this article describes engineering data flows and the structure of the obligations; it is not legal advice, and the specific duties of a controller or processor depend on the deployment, the market and the applicable national law. Confirm the position with the data protection authority or counsel for each market you operate in.
Map your data flow before you map your hardware. Send your deployment topology, port count and retention requirements to service@telarvo.com, or review the published configurations on the SMS gateway solution page and the about page. Telarvo publishes the SK-SMS gateway range, the TYH modem pools and the TGW SMS machine on its product pages, and the configurations referenced above come from those listings.
FAQ
Does GDPR apply to a company outside the EU that sends SMS into it?
It can. The regulation follows the processing rather than the company address, so offering services to people in the EU or monitoring their behaviour can bring an operator outside the EU into scope. The territorial chapter of the regulation on EUR-Lex is short and worth reading directly; the applicable national implementation still has to be checked market by market. Where a market has its own supervisory guidance, that guidance is the reference to cite.
Is there an official list of seven GDPR requirements?
No. The regulation is organised in chapters and articles rather than a numbered list of obligations, and summaries that reduce it to seven items are editorial rather than official. For a messaging deployment, working from the article text and the supervisory guidance produces a defensible position; working from a listicle does not. The practical approach is to map each article onto a specific step in your message flow and record who owns that step.
Does GDPR apply to processors as well as controllers?
Yes. Processors carry their own obligations, including acting only on documented instructions and supporting the controller with records and security measures. The EDPB guidelines on controller and processor concepts explain how the roles are determined, which is the analysis that decides which set of obligations your organisation holds. Write the determination down before the deployment, because the same equipment can sit in either role depending on who chooses the purpose.
Does on-premise hardware remove the need for a data processing agreement?
Not by itself. Where a supplier processes personal data on your behalf, an agreement is normally required regardless of where the equipment sits. If the supplier genuinely has no access to personal data and only supplies hardware, the position is different, but that has to be true of the configuration, including remote support and diagnostic data flows. Remote assistance and error logs are the two areas where that assumption most often fails.