Most digital signage never touches personal data, and the compliance work is a short paper exercise you can finish in an afternoon. Some of it does, and then the GDPR applies in full: a lawful basis, a record of processing, a written agreement with your vendor, and occasionally a full impact assessment. This checklist tells you which of the two you have, and gives you the questions to send any vendor before you sign.
One thing plainly, once, and then we will not repeat it. This is practical guidance from a vendor, not legal advice. We are DynamicDigital sp. z o.o., a Polish company operating under EU law and hosting inside the EU, not a law firm. Use this to prepare the paperwork and the questions. If your project involves health data, biometrics, children or anything that looks like workplace monitoring, take proper legal advice on top of it.
Step 1: does your signage process personal data at all
Start here, because the answer decides how much of the rest applies. A screen showing prices, opening hours and a clock processes no personal data. A screen announcing a named visitor does.
| Set-up | Personal data? | What follows |
|---|---|---|
| Menu board: prices, product photos, allergens | No | Normal supplier due diligence, nothing more |
| Corporate notice board: KPIs, weather, clock, notices | Usually no | Check the KPI feed is aggregated, not per-person |
| Team board with names, photos, birthdays, “employee of the month” | Yes | Names and images of identifiable people. Needs a lawful basis and a staff notice |
| Visitor welcome screen showing a guest’s name and company | Yes | Personal data on public display. Keep the display window short |
| Waiting-room or queue screen with initials tied to a person | Yes, and in healthcare often Article 9 special category | Highest care. Use non-identifying tokens where you can |
| Named shift or rota board | Yes | Employment context, so consent is rarely the right lawful basis |
| Camera-based audience measurement: age, gender, dwell time | Yes, and the hardest case in signage | Almost certainly a DPIA, entrance signage, possibly biometrics |
The working test is simple. If a person could be identified from what is on the screen, or from a file sitting in the CMS behind it, you are processing personal data. If not, the rest of this article is a procurement exercise rather than a compliance one, and you should still do it, because your data protection officer will ask.
Worth being clear about our own product: easyCMS has no camera and no audience-measurement feature. The widgets are images, video, audio, text, clocks, weather, calendars from an iCal feed, RSS, DataSets, webpages and the rest. An audience-measurement camera installed at a site is a separate product from a separate supplier with its own compliance burden. It does not become our processing because the screen beside it runs our software, and it does not become yours by accident either. Somebody has to own it in writing.
Step 2: where the CMS lives, and under whose law
Cloud signage means your content sits on somebody’s server. Two questions, both answerable in one sentence by any honest vendor. Which legal entity are you contracting with, and where is it established? And in which country does the CMS itself run, including its backups?
Our answers: you contract with DynamicDigital sp. z o.o., Warsaw, Poland, EU VAT PL5213678094, trading since 2014 and running easyCMS since 2016. The CMS is hosted by us in the European Union, at Hetzner in Falkenstein, Germany. The company details are on the about page, the hosting location is set out on security, GDPR and where your data lives, and we will put both in writing for procurement.
Do not over-read hosting location. EU hosting removes the international transfer question. It does not, by itself, make anything compliant, and it says nothing about how the data is handled once it is there. It is one line in the checklist, not the whole checklist.
Step 3: what you upload is the bigger risk
In most deployments the vendor is not the problem. The media library is.
People upload things to signage systems that they would never email: a staff photo directory, a spreadsheet of names exported for a leaderboard, an event guest list dropped into a DataSet because it was the quickest way to get it on screen. Each one is a processing activity you now own, in a system your marketing team runs day to day.
Two habits fix most of it. Import only the columns the screen actually needs, so a leaderboard carries first names and scores rather than full names, staff numbers and email addresses. And review the library on a schedule, because signage libraries accumulate. Our storage and uploads guide covers clearing out what you no longer use.
Step 4: are screenshots and proof-of-play logs personal data
This is where signage-specific judgement is needed, and where most generic GDPR checklists give you nothing.
On-demand display screenshots. The CMS can ask a player what it is currently showing, which is useful for diagnosing a fault without driving to site. A screenshot captures the screen output only: there is no camera and no view of the room. So the question answers itself. If the screen is showing a menu, the screenshot is a picture of a menu. If the screen is showing a visitor’s name, the screenshot contains that visitor’s name and should be treated accordingly. See display monitoring for what the feature does.
Proof-of-play records. Available on PRO and Enterprise accounts, these record what played, when, and on which display. That is content and device data rather than data about people. It becomes personal data in two situations: when a display maps one-to-one onto an identifiable individual, such as a screen at one named person’s desk, or when you join the log to something else that identifies people. There is more in proof of play for digital signage.
Display monitoring data. Last check-in time, connectivity state, player version. Device data, and across a large estate that is all it is. In a two-person office where one display sits in one person’s room, it starts to say something about a person’s working hours. Judge it by the deployment, not by the field name.
Good to know The useful reflex is to ask what the record would reveal if it leaked. A log saying “layout 14 played 96 times on display 7” reveals nothing. A screenshot of a waiting-room screen might reveal who was in the waiting room.
Step 5: retention, which nobody sets and everybody is asked about
Retention is the question auditors ask because it has no default answer. Decide it, write it down, stick to it.
| Data | Where it comes from | A defensible starting point |
|---|---|---|
| Media showing identifiable people | You uploaded it | Delete when the campaign ends. Review the whole library every 6 months |
| DataSets holding names | You imported it from a table or CSV | Refresh from source, keep no rows the screen does not display |
| On-demand screenshots | You requested them in the CMS | Take one to diagnose a fault, then delete it. Never build a screenshot archive |
| Proof-of-play records | PRO and Enterprise reporting | 12 months covers an annual reporting cycle. Longer needs a stated reason |
| Support correspondence | Emails between you and us | Your normal business correspondence policy |
Those periods are suggestions to argue about internally, not platform settings. easyCMS customers are not administrators of the CMS, so platform-level retention is not something you configure yourself. If you need a specific period documented for an audit, email info@myeasycms.com and ask for it in writing rather than assuming.
Step 6: the DPA, and when a DPIA is triggered
If personal data goes through the platform, you are the controller and your signage vendor is a processor acting on your instructions. Article 28 requires that relationship to be in a written contract. So yes, you need a Data Processing Agreement, and you need it before the data goes in, not after your first audit.
For easyCMS, email info@myeasycms.com and ask for the DPA. We answer Monday to Friday, 09:00 to 17:00 CET. Our privacy policy covers the standing position, and the DPA covers your specific processing. Even if you are certain no personal data will ever touch the system, a DPA is cheap paperwork and most data protection officers will want one on file.
A DPIA is a heavier instrument, required under Article 35 where processing is likely to result in a high risk to people. Ordinary signage does not meet that bar. Four things push you towards one:
- Systematic monitoring of a publicly accessible area, which is exactly what a face-counting camera is
- Special category data, most often health data, which is why healthcare deployments deserve their own review
- Vulnerable data subjects, including children, patients and in some readings employees
- Large-scale processing of anything identifying
Watch out If a supplier offers to add “audience analytics” to a retail or school project as a small extra, treat that as a new project with its own assessment. It changes the compliance profile of the whole installation, and the cost of doing it properly is usually larger than the module.
Step 7: the transfer question, and why EU hosting removes it
If your CMS, or its backups, or a sub-processor sits outside the EEA, personal data is being transferred to a third country. Chapter V of the GDPR then requires a transfer mechanism and documentation to match. That is not a scandal, it is a task, and thousands of organisations do it correctly every day.
Be fair about this rather than tribal. A US-headquartered vendor running a properly configured EU region with a valid transfer mechanism can be entirely compliant. “American company” is not a finding. What you need is a written answer to three questions: where is my instance, where are its backups, and which sub-processors touch my data. We will not characterise where any competitor hosts your data, because that changes and you should get it from them in writing.
What EU hosting does is delete the question from your file. Our CMS runs in Germany under an agreement with a Polish company, so there is no third-country transfer to assess and no mechanism to maintain. For some buyers that is worth very little. For public sector and healthcare buyers it is often the reason the shortlist looks the way it does.
Step 8: access control, and the shared login problem
Here is the finding we see most often, and it has nothing to do with the vendor.
One login, shared by a marketing team, two site managers, an agency and whoever was on shift when the screen needed changing. The password lives in a chat thread. Nobody can say who published the wrong price list last Tuesday, and when someone leaves, nothing is revoked because there is nothing to revoke. Article 32 asks for appropriate technical and organisational measures, and accountability asks you to demonstrate them. A shared credential fails both, quietly, until the day it matters.
Our honest limit: users, user groups, roles and permissions are an Enterprise feature at 1290€ per year. On the 49€ account and the 299€ PRO account there is one login. For a single café or a single school reception, that is proportionate. For a multi-site organisation where a dozen people touch content, it is a governance problem, and the answer is Enterprise, or another vendor whose plan gives each person their own login. Compare the tiers on the pricing page and read users and permissions first.
Two more limits while we are being honest. easyCMS has no SSO or SAML, so if your policy mandates single sign-on for every business system, we do not meet it and some larger platforms will. And we hold no SOC 2 attestation and no ISO 27001 certificate. We will not imply otherwise with vague language about “enterprise-grade security”. If procurement requires a certificate, ask every vendor on your shortlist for theirs and score us honestly on the gap.
Step 9: the players on the wall
Security assessments tend to stop at the CMS and forget there are computers screwed to the back of your screens.
Three facts about easyCMS players shorten most security reviews. Player-to-CMS traffic runs over an encrypted connection. Players pull content from the CMS and accept no inbound connections, so no inbound port needs opening and no player needs to be reachable from the internet. And every display must be authorised in the CMS before it receives anything at all. The detail is in network requirements and display licences and authorisation.
What is left is physical and organisational, and it is yours. Lock the enclosure if the player sits in a public corridor. Do not leave a keyboard plugged in behind a screen in reception. De-authorise a display when the hardware is retired, sold or stolen, rather than when someone remembers. And the screen itself is an output device in a public space: if it shows names, everyone in the room is a recipient of that data, which is a design decision more than a technical one.
The questions to send any vendor
Copy this into an email. Any vendor worth buying from will answer all of it without a call.
- Which legal entity would we contract with, and in which country is it established?
- In which country does the CMS run, and in which country are the backups stored?
- Who are your sub-processors, and where is that list published?
- Do you offer a Data Processing Agreement? Send it before we buy.
- If any data leaves the EEA, which transfer mechanism do you rely on?
- What retention periods apply to screenshots, playback logs and monitoring data, and can you state them in writing?
- Are screenshots limited to screen output, or can any camera or microphone be enabled on the player?
- Is player-to-CMS traffic encrypted, and does any inbound port need opening at our sites?
- Can we create separate user accounts with roles, and at which price tier?
- Do you support SSO or SAML? If not, say so.
- Do you hold ISO 27001, SOC 2 or any other certification? Send the certificate or say you have none.
- How quickly will you notify us of a personal data breach, given we are under a 72-hour obligation?
- If we leave, how do we export our content and how quickly is our data deleted?
Our answers to all thirteen are either in this article or one email away at info@myeasycms.com. If a vendor is slow or vague on questions 2, 3 and 11, that tells you something before you have spent anything.
The short version
Decide first whether your screens process personal data, because most do not and the honest answer saves weeks. If they do: get the DPA, write down where the platform runs, set retention periods you can defend, stop sharing one login across an organisation, and treat cameras as a separate project with their own assessment.
Our position, stated flatly: EU company, EU hosting in Germany, encrypted player traffic, authorised displays only, DPA on request, no certifications claimed. Ask every shortlisted vendor the same thirteen questions and compare the answers side by side.
Related reading: digital signage for healthcare, internal communication screens for offices and getting help and support options. Our own position is set out on security, GDPR and where your data lives.