This content has been extracted from the IEEE Access article:
- C. Badii, P. Bellini, A. Difino, P. Nesi, "Smart City IoT Platform Respecting GDPR Privacy and Security Aspects", IEEE Access, 2020. 10.1109/ACCESS.2020.2968741 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8966344
The demonstration that a platform is GDPR-compliant is a very complex task, and there is lack of official tools for the verifications. On the web and market there are a number of checklists that can be adopted for the verification that a data management process is GDPR-compliant and only a few that may help the developers to test if their Web solution is GDPR-compliant. It should be noted that, some of the GDPR aspects may be evident from the user interface, UI, and thus they can be verified by external testers, while others (such as encryption, security level, etc.) can only be tested by code inspection and/or performing the penetration test (pentest) as described in Section VII-B. Interesting proposals have been suggested as a partial checklist on [60] and [61]. The list reported in Table 3 reports the approach adopted for verification of GDPR compliance of Snap4City. In particular, it takes into account the UI aspects, source code access and demonstrations, as it was requested by Select4City to assess the platform.
Moreover, in Table 3, each major feature to be compliant with GDPR has been related to the proposed requirements of Section III. The detailed verification report would likely encompass some hundreds of pages and thus could not be accommodated to the space constraints of this article.
The set of GDPR features is not strongly related to the application domain of the smart city platform in terms of mobility, energy, home, etc., while it is mainly related to the usage of the platform, so that it refers to the applications. In all of the smart city domains mentioned, the user may be involved or not. An application on mobility for managing traffic without providing personalized services would not need to collect personal data; neither would it need to have citizens registered on the platform. The same can be stated for energy: the reporting of building energy consumption in an aggregated manner is not personal data. Therefore, the mapping of GDPR aspects vs domains would be very difficult to be realized without describing the applications. In Snap4City, the applications may all involve final users, in any domain. This implies that personal data have to be treated as described in the paper, disregarding the application domain. It is also very restrictive to think that the application would be domain-oriented for the data. For example, parking predictions are based on historical data of parking but also on traffic and environmental data, and events of people. This is the strong point of Big Data.
GDPR Compliance Verification Feature |
Verif. |
Reqs. |
Signed consent |
UI |
R8 |
User profile management and control |
UI |
R13 |
Data Type private as default |
UI |
R8 |
Rights to access per element |
UI |
R9 |
Rights to transfer per element |
UI |
R10 |
Rights to erase per element and total |
UI |
R13 |
Rights to revoke/change per Data Type |
UI |
R10 |
An interface for Right management for Data Type |
UI |
R9 |
Clear Terms of Use and Privacy Policy |
UI |
-- |
Auditing Tools for Data Type |
UI |
R14 |
Publish as Anonymous |
UI |
R9 |
Encrypt personal users’ data |
Code |
R12 |
Secure Authentication and Authorization |
Code |
R3 |
Data protection by Design |
Code |
R17 |
Secure connection |
Code |
R6 |
Security Control, data breach control, anonymization, etc. |
PEN Test |
R15, R16, R18 |
TABLE 3: CRITERIA FOR GDPR COMPLIANCE VERIFICATION FEATURES VS VERIFICATION APPROACH (VERIF.) AND MAIN REQUIREMENTS OF SECTION II (REQS.)
[60] Siemens MidSphere, https://new.siemens.com/global/en/products/software/mindsphere.html, accessed on: Jan. 20, 2020
[61]https://www.privacypolicies.com/blog/gdpr-compliance-apps/, accessed on: Jan. 20, 2020