Priverion GRC Platform overview

The Priverion Platform is built for Privacy, Data Protection, and Information Security Management. All elements of such a management system are interlinked. The Priverion Platform offers the possibility to interlink elements, allowing for smart searching and notifications.

We have created an overview to better understand the interconnections between the different element types of the mentioned management systems. We know it can be a lot initially, but focusing on one use case at a time makes it more transparent.

Privacy Management

The core of any Privacy Management System is the Record of Processing Activities (ROPA). This documentation contains all processes in your organization that touch personal data (this definition can differ depending on the applicable law). The ROPA describes the processes starting with the Data Collection Point (DCP).

This is the interface from which personal data flows into your organization. It can be, for example, a web form, a contract, or a talk at a conference. At any DCP, the information requirements under the law must be fulfilled. This usually means that the Privacy Notice must be shown.

Once the data is collected, it flows into assets. This can be software, database, piece of paper, etc. The assets can be self-owned (for example, your server) or provided by a vendor, such as a CRM provided by Salesforce.

Depending on the type of vendor/external, a specific contract, for example, a Data Processing Agreement (DPA), must be signed. The vendor guarantees specific security measures called Technical and Organizational Measures (TOM). Based on the vendors's criticality, your company should assess the vendor's TOM in more detail. The first step is to review the vendor's TOM documentation and compare it to your own TOM. Are there any gaps? Is there information missing?

If yes, you can send out an Assessment to fill the gaps or receive more information (for more on assessments, go here). Now that the data flow and Information Security are documented, it comes to the legality of the processing. What is your legal basis for processing personal data?

You can document this directly in the ROPA, as well as the expectations and risks for the data subjects (the people whose personal data you are processing). Finally, the last step of data processing is deletion. Most privacy laws have a so-called data minimization principle (see cheat sheet for more info). This means that data should be deleted or anonymized if the purpose for which it was collected has been fulfilled and there is no legal obligation to retain the data.

For this, we use the Deletion & Retention Periods library. Having documented all of this in the ROPA fulfills many of the requirements in various privacy laws. From experience, while creating the ROPA, many other things pop up. For example, missing Privacy Notices, missing Data Processing Agreements, or necessary Technical and Organizational Measures. For this, there are many supporting modules in the Priverion Platform. For example, the Tasks or the Projects and the Meetings & Activities section to document your work.

InfoSec Management

Information Security is about protecting information (not only personal data) from loss of confidentiality, integrity, or availability, in short, the CIA criteria. Most Information Security (InfoSec) Management Systems focus on protecting the assets on or in which information is processed, which is why it is called an asset-based approach. Various standards, such as the well-known ISO27001 or NIST Frameworks, use this approach.

The assets that need to be protected are identified based on a list of the assets (the so-called Asset Register). The next step is identifying the risk scenarios that can affect the assets. For example, a power outage or fire, as well as human-based errors such as misconfigurations or missed updates. Based on the risk model, the Priverion Platform calculates the asset risk. The risk can be reduced depending on the existing or to-be-implemented TOM/Controls. A risk scenario on an asset always has a base risk (before mitigation) and a risk after mitigation, which means the risk after the TOM/Controls have been implemented. TOM/Controls can either impact the likelihood that it comes to the incident in the scenario, or it can affect the damages that arise from the incident. As a result, IT Security Managers can apply risk-based measures and manage risk over the whole organization.