Privacy by Design and Default

Privacy by
Design & Default

The General Data Protection Regulation brought a lot of important changes in 2018. One of the changes was the need for privacy by design. Privacy (and Data Protection) by design and default is written into Article 25 of GDPR.

GDPR

What it means

Privacy by Design states that any action a company undertakes that involves processing personal data must be done with data protection and privacy in mind at every step. This includes internal projects, product development and much more. In practice, this means that any department that processes personal data must ensure that privacy is built into a system during the whole life cycle of the system or process.

Privacy by Default means that once a product or service has been released to the public, the strictest privacy settings should apply by default, without any manual input from the end-user. In addition, any personal data provided by the user to enable a product’s optimal use should only be kept for the amount of time necessary to provide the product or service.

For more information, please visit Privacy and Data protection in Visma. All questions should be directed to the Data Protection Officer (DPO) at privacy@visma.com.

1. Purpose

  • Only process (collect, store etc.) personal data that are necessary to fulfill the purpose of the service. Eg.: In a salary system, you need to know if a person has a right to parental leave. As a consequence you may need to design a software that collects the birthdate of the child, but not the full social security number or the name.
  • Only show the personal data that is needed for the purpose, in screenshots, interfaces/APIs, reports etc.
  • Only process the data that is agreed with the customer. Eg.: as a provider of salary systems we could have the possibility to make detailed statistics on salary levels combined from all our users and sell this. That is not according to the agreement with the customers. See figures 1-3.

2. Default Settings

  • The most privacy friendly setup shall be the default one, Eg. if fields can be ticked on/off by default, or you have default input values like Yes/No, ensure to configure the most privacy friendly as default, restrict menu options to a minimum.

3. Data minimization

  • Data should only be collected, stored and made available when needed. Eg.: Is it needed to make data fields with sensitive or confidential data visible on all screen pages, interfaces/APIs and in standard reports? Earlier we gathered as much info as possible on a page, now we must think the other way around – only show what is needed to limit exposure. See figures 1-3.

4. Extra protection

  • Sensitive personal data and confidential data such as social security number shall have extra protection and be hidden unless necessary to show. Use pseudonymized data instead, ex an employee number (then you need access to some other info to identify the person). See figures 1-3.
  • Sensitive personal data should be kept separated from the rest of the data with stricter access, if possible.
  • Data about children, a group of persons with the right to special care, should also be kept separated, if possible.
  • Social security number shall not be used for logon.
  • Social security number shall not be visible on envelopes or on payslip.
  • If encryption of the whole database is not implemented, encrypt sensitive personal data and social security numbers.
Purpose

Figure 1: Not showing full name of end-user (Visma Opic)

Purpose

Figure 2: Information personal collapsed (Visma Opic)

Purpose

Figure 3: Personal information expanded (Visma Opic)

5. Free text fields

  • Only process (collect, store etc.) personal data that are necessary to fulfill the purpose of the service. Eg.: In a salary system, you need to know if a person has a right to parental leave. As a consequence you may need to design a software that collects the birthdate of the child, but not the full social security number or the name.
  • Only show the personal data that is needed for the purpose, in screenshots, interfaces/APIs, reports etc.
  • Only process the data that is agreed with the customer. Eg.: as a provider of salary systems we could have the possibility to make detailed statistics on salary levels combined from all our users and sell this. That is not according to the agreement with the customers. See figures 1-3.

6. Deletion

Visma has to act according to the GDPR and the DPA with the customer, and any specific terms in agreement.

  • During our relationship with the customer, our products must give the customer the ability to delete data that is no longer relevant, if not forbidden by law. Deletion means complete removal of data, so just hiding data or pseudonymizing it is not good enough.
  • When the customer terminates its contract with Visma, Visma shall by default delete customer production data from databases, backups and other systems that contain production data like support systems etc, according to corporate policy. Confirmation shall be sent to the customer when deleted, and evidence of deletion should be stored. If data cannot be deleted from backup, they are to be anonymized (where re-identification is impossible). If the data needs to be archived even after the termination of the contract, the customer must request a copy of the data for transfer to its own systems. Visma cannot keep this data without a contract. If Visma are to keep these data, a new contract and DPA need to be signed.
Free text fields

Figure 4: Information about how to use free text fields (Visma Opic)

7. Access

  • In some cases, products must comply with specific rules regarding logging of access to data, query to data etc, like the Norwegian Normen. See figure 5.
  • The user shall have easy access to all personal data about herself, unless prohibited by law or other similar documented reasons.
  • Make personal data available only for selected roles, or selected people, to minimize the exposure of the personal data to a need to know basis.
  • Visma’s access to the personal data shall be limited to authorized Visma personnel, documented and reviewed regularly.
  • Secure sharing data only with agreed and communicated parties or subprocessors. You need a DPA with sub processors. Interfaces should be encrypted and transported in a secure manner.

8. Other

Visma has to act according to the GDPR and the DPA with the customer, and any specific terms in agreement.

  • If you need production data for test purposes, ensure you follow this routine.
  • Temporary files should exist at a minimum and with a strict retention period.
  • Logging is good and enables us to be better at incident handling. Log files must have a retention date. Make sure not to enter any sensitive data in any logs.
  • Advise the customer of any risks or any control measures they need to be aware of
  • Work continuously to increase security and privacy in the product, to reduce the risks of the freedom and rights of the users
Access

Figure 5: Information about the latest logins of an end-user (Visma Opic)

Published: 2020-04-15 Updated: 2020-04-15

This site saves certain data to enhance the user experience. By using ux.visma.com you approve this. More info

This site uses cookies, which collect information about how you interact with the site. In combination with the information you provide, we create a profile so that we can show relevant content just for you.

By accepting, you allow us to collect and process your personal data as described.

Close