iyarn data School Privacy and security Q&A’s

iyarn data School Privacy and security Q&A’s

Who owns the data?

We store data submitted by users for the purpose of check ins. This data is owned by the users, and as discussed below, can be removed at their request. 

We limit our collection and use of data to fulfill our core purpose. We don’t use your data for advertising purposes, and we don’t on-sell your data. 

iyarn is a data processor and steward of the data. We act on the instructions of users, be they individual or organisations. Individuals and organisations will define the type of data that is to be collected, the frequency with which it is collected and how this data is reported. 

What happens to someone’s data if a request is made to remove themselves from the system?

All data relevant to the user will be deleted. This includes their wheels, check ins, scores and comments. 

How long will the data be held for?

Data is held until a user requests deletion of the data. We may introduce policies for the removal of data after a period of time. 

Is the data encrypted at rest as well as in transit?

Yes, data is encrypted when it is at rest and in transit. 

Data at rest is encrypted using AES-256. Advanced Encryption Standard (AES) is a symmetric key cipher and is used in database encryption, in addition to VPN systems, password managers and the most popular messaging programs. AES-256 is the strongest level of encryption under AES. 

Data in transit is encrypted using SSL. We use the latest iteration of SSL, TSL. 

How do you anonymise the data at rest in case of a data breach?

Data at rest is encrypted, but we also separate personally identifiable data from data collected in a check in. Data related to a check in is stored alongside an anonymized identifier, rather than the personally identifiable information. 

Who has access to the data?

The platform enables data to be accessed by the user who submitted the data, and the administrator/s of the wheel. 

Data access by members of the iyarn team is limited to essential staff, typically our lead developer. The production database is one of several different environments we use, allowing for development and testing to occur by a larger team without needing to provide access to the main (user) database. 

In limited circumstances, we use analytical platforms to assist us to record and analyse data relating to the use of our platform. Typically this concerns the events relating to the usage of the system (for example, the occurrence of certain events like logging in, or clicking on a notification), rather than the sensitive user-submitted data (such as submitting a specific score or comment). 

What security do you put in place to limit iyarn staff’s access to the data? – eg never using personal logins to access the data, password policies, staff exiting procedures that ensure system access is revoked etc.

As mentioned above, access to the database is limited. 

Regarding the management of risks associated with staff use of our databases: 

  1. All staff have signed confidentiality agreements.
  2. Staff are regularly trained on the evolving legislation and requirements applicable to the data collected and held by our platform. 
  3. Databases are only accessed through company-issued accounts. Company-issued accounts are revoked at exit.
  4. We have a range of supporting policies relating to passwords, device usage and network usage. This includes the use of 2FA where available and monitoring for breached passwords. 

What backups of the data are in place? How has the restoration of the data been tested?

Data is backed up on a regular basis (at least every 6 hours) and we can restore any of the previous back ups. Data backups are encrypted. We use a highly popular and well supported database technology (Mongo DB) and provider (Mongo Atlas). Restoration has been previously tested. 

Have you had an audit done of your codebase and environment by security experts? Are you able to share their results? When was the last time you did a penetration/ white hat test?

We’ve internally assessed our codebase and vulnerabilities at several key points in our development. We’re approaching another major review, and we will be strengthening our approach with an external audit before 30 June.

Did you like this article? Share with world.