Privacy Assets secondo EN 18031: cosa sono e come identificarli
Lo standard EN 18031-2 parla di privacy assets come se fossero un concetto ovvio, ma nella pratica le definizioni ufficiali sono vaghe e prive di esempi concreti. Il risultato è che molti produttori si bloccano già nelle prime fasi della documentazione, senza capire bene da dove iniziare.
24 febbraio 2026
Introduzione
Lo standard EN 18031-2 parla di privacy assets come se fossero un concetto ovvio, ma nella pratica le definizioni ufficiali sono vaghe e prive di esempi concreti. Il risultato è che molti produttori si bloccano già nelle prime fasi della documentazione, senza capire bene da dove iniziare.
In questo articolo spieghiamo cosa sono i privacy assets, come trovarli nel vostro dispositivo e come RedComply automatizza gran parte di questo lavoro.
Gli asset privacy sono una delle quattro categorie di asset EN 18031. Per il quadro completo, consulta la nostra panoramica di tutti i tipi di asset.
Cosa sono i Privacy Assets?
I privacy assets sono tutte le componenti del vostro dispositivo che trattano dati personali degli utenti.
Lo standard EN 18031-2 li divide in tre categorie, che non vanno viste come elementi separati ma come anelli di una stessa catena.
1. Informazioni personali
Tutti i dati che identificano o possono identificare un utente: nome, email, posizione GPS, pattern di utilizzo, cronologia delle attività. Se un dato è personale ai sensi del GDPR, è un privacy asset ai sensi di EN 18031-2. Il confine è lo stesso.
2. Funzioni di privacy
Le funzionalità del dispositivo che elaborano quelle informazioni: raccolta, archiviazione, trasmissione, modifica, cancellazione. Qualsiasi operazione su un dato personale viene svolta da una funzione di privacy.
3. Configurazioni delle funzioni di privacy
I parametri che definiscono come si comportano quelle funzioni:
Con quale frequenza sincronizzano i dati?
Per quanto tempo li conservano prima di cancellarli?
L'utente può modificare questi parametri?
La relazione tra i tre elementi è quello che lo standard richiede di documentare. Non basta elencarli: bisogna mostrare come si connettono. Le informazioni personali vengono elaborate dalle funzioni di privacy, il cui comportamento è definito dalle loro configurazioni.
Come identificare i Privacy Assets nel vostro dispositivo
Il punto di partenza è sempre la stessa domanda: quali dati personali transitano attraverso il mio dispositivo?
Una volta definita la lista, per ogni dato personale tracciate il percorso completo:
Da dove arriva? Sensore fisico, input utente, API esterna?
Come viene elaborato? Sul dispositivo, sul cloud, su entrambi?
Dove viene memorizzato? Memoria locale, database remoto?
Chi può accedervi? Solo l'utente, il produttore, terze parti?
Questo esercizio è spesso più rivelatore del previsto. Molti team scoprono flussi di dati di cui non erano consapevoli:
SDK di analytics che raccolgono dati comportamentali
Librerie di crash reporting con stack trace contenenti informazioni personali
Integrazioni con servizi terzi che trattengono i dati oltre il previsto
Questi flussi "nascosti" sono spesso i più critici dal punto di vista della compliance, proprio perché nessuno li ha progettati con la privacy in mente.
Una volta mappati i flussi, identificate le funzioni che li gestiscono e documentate per ciascuna:
Cosa fa esattamente con quei dati (raccolta, trasformazione, trasmissione, archiviazione)
Le dipendenze con altri componenti del sistema
Le configurazioni: valori di default, range consentiti, modificabilità da parte dell'utente
Lo standard EN 18031-2 non impone un livello di granularità specifico, quindi potete raggruppare elementi simili.
Ma raggruppare troppo è uno degli errori più frequenti: la granularità deve essere sufficiente a far capire al Notified Body che avete analizzato il sistema davvero, non in superficie.
Facciamo un esempio pratico di compilazione della tabella di Privacy Assets
La tabella Privacy assets è come se fosse una sorta di inventario dei dati che hanno un impatto di privacy trattati dal dispositivo (dati personali, identificativi, log che possono identificare, immagini/video/audio, ecc.) e delle loro proprietà. Tra questi ad esempioi il fatto di chi può accedervi, se sono dati "special category", dove sono memorizzati, se viaggiano in rete oppure se sono protetti da crittografia.
Come compilare campo per campo
1) Privacy Assets (asset_name)
Qui devi dare un nome chiaro a questo dato. Ti conviene usare un nome univoco e descrittivo.
Ad esempio: `PA01UserEmail`, `PA02DeviceSerialLinkedToAccount`, `PA03AccessLogsWithIP`.
Evita nomi generici
2) Is it accessible by an entity / third-party? (accessible_by_entity)
Questo campo chiede se un'entità (utente/admin), oppure una terza parte (cloud/app/fornitore), o un possibile attaccante può leggere,ottenere o modificare quel dato tramite qualche percorso (UI, API, file, debug, rete).
Yes: se esiste almeno un percorso di accesso (anche legittimo, es. l'utente vede i suoi dati).
No: se non è accessibile a nessun soggetto (caso raro; dato solo interno e non esposto).
3) Is it a personal information of special category? (special_category)
Questo campo serve per classificare che tipo di dato personale si tratta, e devi scegliere tra:
Personal information: se è un dato personale "normale" (email, nome, IP associabile, identificativi account, log utente, ecc.).
Special category: se è un dato per categorie particolari (in senso GDPR art. 9: salute, biometrico per identificazione, etnia, opinioni politiche, religione, vita sessuale, ecc.). In molti prodotti IoT è raramente applicabile.
Not applicable: se non è un dato personale (es. un valore tecnico non riconducibile a persona).
Regola pratica: se il dato può identificare direttamente o indirettamente una persona → almeno Personal information.
4) Is persisted on the device? (persisted_on_device)
Questo campo chiede se l'asset è memorizzato in modo persistente sul dispositivo.
Yes: se si tratta di file, database, log su disco, config che resta dopo reboot.
No: se si tratta solo in RAM o temporaneo (es. un token effimero, frame video non registrati).
5) Is it sensitive personal information, or confidential personal information? (confidential)
Qui devi scegliere tra:
Sensitive: se è un dato personale che merita protezione elevata ma non è necessariamente un "segreto" (es. log con IP/azioni utente, identificativi, metadata).
Confidential: se è un dato che, se divulgato, abilita accesso o causa impatto grave (es. password, token di sessione, segreti 2FA, chiavi di recupero, dati altamente riservati dell'utente, registrazioni private).
Regola pratica: credenziali/token/2FA → Confidential.
6) Potentially impacted via external interfaces? (impacted_external_if)
Se il dato può essere letto, estratto o modificato tramite interfacce esterne non di rete (USB, UART/seriale, accesso fisico a storage, console, ecc.).
Yes: se con accesso fisico o tramite quelle porte puoi arrivare a log/file/config che lo contengono.
No: se non c'è un percorso realistico via interfacce esterne.
7) Is communicated over a network interface? (communicated_over_network_if)
Se il dato viene trasmesso in rete (LAN/Internet) in qualche forma:
verso app/web browser,
verso cloud,
verso un servizio remoto,
oppure come parte di un protocollo. Yes/No di conseguenza.
8) Is communicated via network interfaces? (accessible_via_network_if)
Questo campo serve per capire quanto il l'asset sia la "raggiungibile via rete" e se può esser esser accessibile o modificabile:
Yes: il dato è accessibile/recuperabile via rete (API/WebUI/streaming/download).
No: via rete non è ottenibile (anche se magari esiste localmente).
9) Cryptography used to protect the asset? (`crypto_used`)
Chiede se l'asset è protetto con crittografia:
in transito: TLS/HTTPS, SSH, VPN.
a riposo: filesystem cifrato, database cifrato, keystore/secret storage. Metti Yes se almeno una protezione crittografica è applicata dove serve, altrimenti No.
Mini‑checklist per compilare bene (senza ambiguità)
Per ogni privacy asset, devi annotare mentalmente i seguenti punti:
Che dato è e se identifica una persona.
Chi lo vede (utente/admin/terze parti).
Dove è localizzato (RAM o disco/log).
Come comunica con l'esterno (rete? interfacce fisiche?).
Come lo si protegge (TLS, cifratura a riposo, access control).
Gli errori più frequenti
Errore #1: Granularità insufficiente
Scrivere "l'app gestisce dati utente" non basta. Lo standard richiede specificità: quali dati, dove, come, perché.
Ogni tipo di dato personale va identificato separatamente, perché ogni tipo ha il suo livello di sensibilità e richiede misure di protezione diverse.
Errore #2: Ignorare i flussi verso terze parti
La maggior parte dei produttori si concentra sui dati che raccoglie direttamente, dimenticando:
SDK di analytics
Librerie di crash reporting
CDN e servizi di notifiche push
Integrazioni con payment processor o assistenti vocali
Tutti questi elementi raccolgono dati per conto proprio. Anche quelli sono privacy assets da documentare. Spesso sono i più problematici, proprio perché nessuno li aveva considerati durante il design.
Errore #3: Documentazione statica
Documentazione perfetta al lancio, poi il prodotto evolve e la documentazione resta ferma.
Un nuovo firmware introduce una funzionalità che raccoglie dati in modo diverso, ma nessuno aggiorna la compliance. Risultato: dopo sei mesi il prodotto sul mercato non è più conforme alla certificazione ottenuta.
È un rischio legale e commerciale reale, non un problema teorico da sottovalutare.
Errore #4: Nessuna evidenza concreta
Scrivere "i dati sono crittografati end-to-end" è inutile senza prove. I Notified Body vogliono vedere:
Screenshot delle configurazioni
Estratti di codice
Report di penetration test
Senza evidenze, la documentazione è una lista di intenzioni.
Come RedComply gestisce tutto questo
Fare questo lavoro manualmente richiede settimane di coordinamento tra team diversi (sviluppo, security, prodotto) ed è facile perdere qualcosa.
Fatto manualmente, richiede settimane.
Con la nostra piattaforma, ridurrai i tempi di compilazione di questa normativa di oltre il 90%!
Questo perchè RedComply automatizza le parti più pesanti del processo.
Mappatura automatica
Caricate la documentazione tecnica esistente (specifiche, diagrammi, codice sorgente) e il sistema identifica automaticamente i privacy assets. Il risultato è una lista di privacy functions organizzate per categoria.
Analisi dei rischi
Per ogni privacy asset identificato, la piattaforma valuta:
Adeguatezza della crittografia in transito e a riposo
Configurazioni predefinite rischiose
Flussi verso servizi terzi non documentati
Lacune rispetto ai requisiti specifici di EN 18031-2
Tracciamento delle versioni
A ogni aggiornamento firmware, RedComply confronta automaticamente la nuova versione con la precedente e rileva:
Nuovi privacy assets introdotti
Modifiche alle configurazioni esistenti
Variazioni nel profilo di rischio
La documentazione rimane allineata al prodotto reale, senza dover ricominciare da zero a ogni release.
Esportazione della documentazione
La documentazione finale viene generata nel formato richiesto da EN 18031-2, pronta per il Notified Body. Nessun template da compilare a mano, nessuna formattazione manuale.
Il legame con Security e Network Assets
I privacy assets non sono un capitolo isolato di EN 18031. Sono strettamente legati agli altri due tipi di assets, e ignorare queste relazioni è un errore costoso.
- I security assets proteggono i privacy assets: la crittografia TLS protegge i dati in transito, i meccanismi di accesso controllato limitano chi può leggerli a riposo. Senza security assets adeguati, i privacy assets restano esposti a prescindere da quanto siano ben documentati.
- I network assets trasportano i privacy assets: i dati personali viaggiano attraverso le interfacce di rete del dispositivo. Un canale di comunicazione non protetto è un problema sia per EN 18031-1 che per EN 18031-2.
Per una guida dettagliata sull'identificazione degli asset di sicurezza che proteggono i dati privacy, consulta il nostro articolo sugli asset di sicurezza.
Da dove iniziare
Dal 1° agosto 2025, la conformità RED è diventata obbligatoria per i dispositivi IoT con interfacce radio. I privacy assets vanno identificati prima di poter valutare qualsiasi requisito di EN 18031-1.
RedComply velocizza di oltre il 90% il tempo di compilazione dei security e di tutta la normativa RED.
Caricate il firmware e ottenete una prima mappatura automatica dei privacy assets in pochi giorni.
Richiedi una Demo e verrai contattato al più dal nostro team per aiutarti!
RedComply riduce i tempi di compliance EN 18031 di oltre il 90%. Scopri di più su redcomply.com.