Altova GDPR Compliance Database

The Altova GDPR Compliance Database's working mechanism can be thought of as being a user interface that provides functionality to deal with relevant aspects of the meta-information pertaining to the personal data that an organization collects. In the framework of the Compliance Database, this meta-information can be grouped into the following inter-related components:

•Metadata: This is information about personal data held by the organization, and it can be of two kinds. (A) Descriptive information about the data (for example: source of data, whether data is encrypted, etc.); (B) Information about how the data is related to physical aspects of the organization (for example: what is the storage medium of the data, who in the organization is responsible for the data, etc.). Note that while data refers to the personal data collected by the organization, metadata refers to GDPR-related information that describes the personal data.

•Approvals: An internal approvals system for changes made to key metadata. For example, if a user of the compliance database assesses that the encryption level of a data category needs to be changed, then that person can create an approval request directly in that data category. When a person authorized to make the change approves the request, the change is applied to the data category. Furthermore, these changes—in our example case, to the data category—are logged and can be read subsequently in the change log of that metadata item—in our example, the data category.

•Reports: Functionality to generate various types of reports about the metadata contained in the compliance database. For example, a report that lists the processing activities, or one that lists all the pending approval requests.

•Administrative: Functionality to conduct database-internal discussions of issues that may arise, and to track changes to metadata. For example, if a user has a question about the protection level of data in the Billing Address data category, then the user can initiate a discussion from within the Billing Address data category and invite selected users to participate in the discussion. The invited participants can be automatically notified by email. Discussions are grouped under their respective metadata items and can be viewed subsequently. Note also that a discussion about, say, a data category, will not only be listed under that data category; it will also be listed at higher levels: (i) under all data categories, and (ii) all metadata items of the compliance database.

The Altova GDPR Compliance Database implements these goals through a network of pages that serve as input and/or display mechanisms for metadata or for the other functionality listed above.

Metadata input and display

A number of the compliance database's pages provide an interface for entering and displaying metadata. The metadata that is entered in these pages builds a network of relationships across pages, and this provides the metadata with an internally coherent structure. Consequently, a major part of the work related to the compliance database is to enter the relevant metadata; the internal linkages are built automatically.

The following metadata is used to build up the compliance database

•Company Information

oDepartments: The departments in the company that process personal data. Within each department, roles are created. For example, within the Accounting department, two possible roles are Salaries and Sales revenues. A role can be associated with one or more persons. A role is also associated with one or more processing activities. A department role thus builds a relationship between a processing activity and a person. In order to specify that a certain person is involved in a certain processing activity, the person is assigned to the relevant department role. In this way, personnel changes are easily accommodated.

oPersons: Contact data and description of company personnel who are involved in processing personal data. Each person is assigned to a department and to a role in that department.

•Data information

oData Classifications: These are the criteria that you will define and that will be used across the system to describe data. For example: the encryption level of a piece of data can be a data classification. In a specific data category, the encryption data classification is given a specific value (for example: No encryption required).

oData Usage Classifications: These are criteria that specify how a data category will be used by a processing activity. For example: a data usage classification might specify the location where a certain processing activity processes a certain data category (for example: in-house or externally). Multiple data usage classifications are defined at the system level. When defining how a processing activity processes a data category, each relevant data usage classification of the processing activity is given a value. These values describe aspects of how that processing activity processes a given data category.

oData Controllers, Processors, Receivers: Contact information and description of external entities with which the company shares collected data in any way. If the external entity processes data for the company, it is linked to the company via the relevant processing activity.

•Data properties and relationships

oData Categories: A data category defines the data that is collected. For example, you can define a data category that describes customer address data. The data category definition consists of the data classifications of the system, with each data classification being given a specific value. For example, the data category for customer addresses can be defined so that the data classification that describes the source of this address data is set to a value of something like Online customer submission.

oData Storage Entities: This metadata is applied to a data category and defines the type and location of the physical data storage facility that is used to hold data that belongs to the specified data category. For example, a data category of customer address can specify that the data storage entity of this category's associated data is a file at a specific URL.

oDefine Processing Activities: A processing activity typically processes multiple data categories. For each of these data categories, the values of the system's data usage classifications describe how this data category is processed. For example, consider that (i) there exists a processing activity named Frequent Buyer, which processes a data category named Customer's Monthly Income, and (ii) there exists a mandatory data usage classification in the system named Purpose of processing. This data usage classification, since it is mandatory, will appear in the definitions of all data categories that are assigned to any processing activity, and will need to be given a specific value in each data-category definition. For example, the Purpose of processing data usage classification of our example could be given a value of EU law. This indicates the purpose of processing of the Customer's Monthly Income data category, when this data category is processed by the Frequent Buyer processing activity.

For a description of how to enter metadata, see the section GDPR Metadata.

Approvals

The most important meta-information about a processing activity (that processes personal data) is the data category of the data that is processed. When a change is made to a data classification of a data category, the change can be submitted with an approval request. The approval request is logged within the compliance database, and can be approved by an authorized person.

The Approvals mechanism enables oversight, as well as keeps track of changes made to the structure of the metadata. See Approvals for a description of the Approvals system.

Reports

The compliance database enables the following reports to be generated: (i) about metadata, on the basis of processing activities, and (ii) about approval status of a category's classifications. See the section Reports for information.

Administrative

The compliance database provides functionality to track changes to metadata and to search for text on compliance database pages. These are described in the section Additional Features.