Skip to main content

GDPR compliance

Prepare your deployment of Piiano Vault for the European General Data Protection Regulation (GDPR)​

Background​

The General Data Protection Regulation (GDPR) is European Union regulation on data protection and privacy in the European Union (EU) and the European Economic Area (EEA). Implemented 2018, GDPR has drastically changed how companies treat privacy, and also has become a model for many privacy laws in other countries, for example, the California Consumer Privacy Act (CCPA) and the Japanese Act on the Protection of Personal Information (APPI).

GDPR and similar regulations impose many requirements on companies related to privacy. Some requirements are organizational in nature, for example, have a data privacy office (DPO). Other requirements are high-level - an organization should implement "Privacy by Design". Some are very specific and require concrete implementation - for example the "Right to be Forgotten" ("Right to Erasure").

Piiano Vault's relevance​

Vault can greatly assist in two aspects: the high-level technical requirements and the more specific technical requirements.

First, by using Vault for PII storage, you are guaranteeing the security of your PII data - Encryption, API safety, role based access control, and many more are all baked in. Every value stored in Vault is encrypted by default and every access is audited correctly with the particular reason for access.

Beyond data security, Vault allows you to implement specific features required by GDPR. As Vault was designed with privacy and privacy regulations in mind, all data subject rights are easily supported when designing your storage with Vault. Every record can either represent a person, or designate another record which is its person owner. With this design, implementing "Right to Erasure" or "Right of Access" is straightforward and simple.

Additionaly, when it is required to refer to the data-subject in other code in a privacy perserving manner, the relevant PII may be tokenized, or even tokenized in a format preserving manner. This makes use cases such as analytics easy to implement without sacrificing privacy.

Relevant GDPR articles​

Art. 5 Principles relating to processing of personal data​

Personal data shall be: [...] f. processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).

Vault is designed with data security and privacy in mind. As such, modern access control, encryption and cyber-security practices are used to ensure the security of personal data. For example, Vault is developed according to a secure coding standard, and Vault's code and architecture undergo regular security reviews by third party experts.

With regards to actual security features and privacy features, these include:

  • Encryption by default
  • Secure usage and storage of encryption keys and supporting external key storage e.g. AWS KMS
  • Role based access control and a configurable permissions mechanism
  • Data lifecycle and retention

Other features that are not neccesarily security related are still designed with security in mind. For example, in the implementation of tokenization, the related built in permissions are structured such that it is impossible to use tokenization to bypass read limitations.

  1. Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.

Vault supports requiring an access reason for each request. Using this access reason, various access policies may be set to limit or allow access to a user's data. Beyond that, Vault supports consent management by defining an appropriate column, and using custom transformations to limit access to various columns based on the reason in the request.

In the future, Vault will support consent management using a built in column and additional built in capabilities.

Art. 15 Right of access by the data subject​

  1. The controller shall provide a copy of the personal data undergoing processing. For any further copies requested by the data subject, the controller may charge a reasonable fee based on administrative costs. 3Where the data subject makes the request by electronic means, and unless otherwise requested by the data subject, the information shall be provided in a commonly used electronic form.

All data records in Vault can have an ownership relationship to an actual Person record, such that if a person asks for all their data, extracting all related records is simple and straightforward. As Vault is designed with an API first approach, getting the data in a machine readable format is simple and straightforward.

Art. 16 Right to rectification​

The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.

When designing your data architecture with Vault, all relevant PII are stored in Vault in an easily accessible manner and modifying them is straightforward when a rectification request is made.

Art. 17 Right to erasure (‘right to be forgotten’)​

  1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: [...]

All data records in Vault can have an ownership relationship to an actual Person record, and with built-in support for lifecycle and retention management. With this design, deleting an owner record will also delete all related data records. When implementing PII storage with Vault, all actual PIIs are stored in Vault while the external database only holds a non-PII reference to it (e.g. a UUID value). Therefore, when data is deleted from Vault, you can be confident that all related PIIs were deleted.

Art. 18 Right to restriction of processing​

The data subject shall have the right to obtain from the controller restriction of processing [...]

Vault supports providing an access reason to all data API calls. For instance, when trying to retrieve a user email, you can specify in your code if the request is in order to send a transactional email ("AppFunctionality"), marketing, or analytics. Then, you can use a coded transformation that checks the provided reason against the user's consent column to decide if that access is allowed or limited by the user.

Art. 19 Notification obligation regarding rectification or erasure of personal data or restriction of processing​

The controller shall communicate any rectification or erasure of personal data or restriction of processing [...] to each recipient to whom the personal data have been disclosed [...]

Using Vault, an application can record all 3rd parties with whom a certain data record was shared. Then, upon receiving a data erasure request, all recorded 3rd parties can be notified appropriately.

Art. 20 Right to data portability​

The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format [...]

Similarly to Article 15, since all data records in Vault can have an ownership relationship to an actual Person record, such that if a person asks for all their data, extracting all related records is simple and straightforward, and a machine-readable format support is built-in.

Art. 21 Right to object​

The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her [...]

A person who objects to processing essentially demands a restriction of processing which is supported by Vault, as written under the section of Article 18.

Art. 22 Automated individual decision-making, including profiling​

The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.

Similary to Article 18, Vault allows the application to limit processing of PII once a person demands a restriction of processing. In the case of article 22, that limit may apply to particular types of processing that may be specified as a different reason in the API access.

Art. 25 Data protection by design and by default​

The controller shall [...] implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. [...] The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.

Beyond storing PIIs in Vault and only the object ID in the main application data-store, Vault supports additional capabilities that are relevant for article 25:

  • Tokenization - Vault supports multiple types of tokens, including data tokens, pointer tokens, and format preserving tokens. All of these allow an application to implement various use cases such as analytics in a way that fully supports data privacy.
  • Encryption by default - all data in Vault is encrypted by default in a secure manner.

Art. 30 Records of processing activities​

Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility.

Vault maintains an audit log of all accesses to PII data, and each record contains information required by the GDPR, including:

  • The purpose of processing
  • The type of data being accessed

The audit log may be directed to the log collecter preferred by the application writer.

Art. 32 Security of processing​

[...] the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk [...]

Similarly to articles 5 and 25, using Vault allows an organization to build their data architecture according to their own data and security risk analysis, e.g. by making use of the various vault features such as tokenization and encryption.

Art. 87 Processing of the national identification number​

[...] In that case the national identification number or any other identifier of general application shall be used only under appropriate safeguards for the rights and freedoms of the data subject pursuant to this Regulation.

A national identification number is another type of PII that vault supports in a built-in manner. Vault allows the application to define a hierarchial permissions policy, such that a policy can apply to all national identification numbers and a certain country's numebr can adhere to a different stricter policy.

Beyond GDPR: Certification​

Since Vault has many necessary features required for the full implementation of GDPR and other related privacy regulations, passing various privacy certifications becomes significantly easier.

For example, a well integrated Vault would solve many of the requirements specified by ISO 27701 - the international standard for data privacy.

On this page