From Security-by-Design to Privacy-by-Design
inWebo’s business is identity protection. We design and implement cyber-security techniques to protect our customers’ user identities. PIIs (Personally Identifiable Information) are highly protected in our systems, using strong encryption, crypto-servers, firewalls, etc. GDPR requirements in terms of security are met and exceeded. However, GDPR is much more than that, therefore we had to figure out the journey from our “security-by-design” starting point to a “privacy-by-design” destination.
Here are the various topics we addressed and what our approach is:
- User consent to data processing purposes: as a B2B provider of authentication solutions, we do not collect data from the end-users of the solution, our customers do. We collect data from administrators when they create their organization account, for the sole purpose of creating that account and giving access to it.
- Minimal set of data: we only store in our systems the user data that is necessary for our customers to operate and monitor the authentication solutions we provide them, such as a username, an email address, and authentication usage data (time and date, IP address, authentication status). It is our customers’ responsibility to use anonymous aliases instead of usernames and to not store email addresses if they do not use features such as “Reset PIN with email” that need it.
- Data governance: that was a benefit of GDPR to have us design a data governance and a data retention policy. We have now standardized our data retention durations: by default, authentication and other usage data is kept one year. Also, all organization account data are deleted maximum 6 months after an organization account expiration. Customers who need a longer retention duration e.g. for long-term security analysis can subscribe to an archiving option.
- Access to data and traceability: since we operate the authentication platform and since we rely on service providers for some aspects of the solution (email service provider and hosting service provider among others), we needed to design and enforce policies for access to data, both for ourselves and for our service providers. Service providers have issued their own GDPR compliance statements and we have analyzed that they are compatible with our goals and practices. For ourselves, by default we never access user data unless a customer requires us to do so, for instance in order to troubleshoot an issue. We have formalized how our operational teams authorize and log such requests.
- Data protection: critical data such as authentication factors are encrypted with crypto-servers (HSMs) in our platform. Usernames are usually not critical information (if it is, it is our customers’ responsibility to use aliases instead) and they are needed in plain text e.g. to run search queries. Other identifiers such as email addresses or “trusted devices” names are usually not critical information but we have nevertheless decided to encrypt it at rest.
- Rights (to access, to modify, to be forgotten): we do not know the end-users of our customers and have no way to match a request that we would receive with an actual end-user in our platform, or to verify that such a request is legitimate. Besides, if one of our customers has created an authentication profile for a user in our platform, our responsibility is to not access it, not modify it, and not delete it. Therefore our role is to provide our customers with the tools and processes they need to answer their users’ requests, e.g. an API function to delete user data in the authentication logs in our platform. Nevertheless, we have created an email address for privacy and PII-related requests from end-users. We will limit our role to reply to emails advising the user to send his/her request to his/her organization or service provider.