PRIMA // BLOG

It is rare nowadays for IT services to be operated in-house and with a company's own IT infrastructure in their own server room. The reality for hosting data and operating applications today is the involvement of service providers and the use of services in the cloud. This has many advantages, such as saving internal resources for maintenance and operation, and can also improve IT security with the right partners. However, there are requirements for data protection-compliant commissioning, monitoring and integration of service providers. Read here what you need to bear in mind.

Service provider classification

If you use service providers to process personal data, this can basically be in the form processing, transfer or joint controllership. In order to take the right measures, you should first be aware of the role of your service provider.

• Processor: A processor is the most common case when you use third parties to process personal data. This is when a third party processes personal data on your behalf in accordance with your instructions, i.e. you determine how the processing is carried out. Classic use cases are the hosting of data and applications, but also the provision of SaaS or cloud software. We'll take a closer look at this case in a moment.
• Transfer: A transfer of personal data occurs when you process personal data yourself and pass it on to a third party who determines how it is processed. For the involvement of service providers, a transfer is particularly relevant for the commissioning of consultants who act with their own expertise and decision-making freedom, such as lawyers, tax consultants or auditors. In this case, you must ensure that you have a justification for transferring personal data to these service providers. This special case is not discussed in detail here.
• Joint controllership: If you and another controller jointly determine the purposes and circumstances of the processing, this constitutes joint controllership. A common case is the provision of your own content in a portal operated by a third party, such as the operation of a fan page on Facebook or activities in a network of companies in which, for example, a sales database is shared. If there is joint controllership, an agreement must be concluded in accordance with Art. 26 GDPR. This special case is not discussed in detail here.

Legal requirements

The requirements for the data protection-compliant involvement of a service provider as a processor are set out in Art. 28 GDPR. Careful selection of the service provider and monitoring of the technical and organisational measures, the conclusion of a processor agreement and regular monitoring of the service provider are important for this. If the service provider comes from a third country outside the EEA, there are additional requirements.

Careful selection of the service provider

The commissioning of processors is only permitted if the service provider is reliable because it offers sufficient guarantees that suitable technical and organisational measures are in place and that the processing complies with data protection regulations. In other words, the data processing must be carried out by the service provider just as carefully as by the controller itself. In practice, this check is carried out by monitoring the technical and organisational data protection concept.

This check must be carried out for the first time before a service provider is commissioned and must then be repeated regularly. The frequency and intensity of the check depends in particular on the sensitivity of the processed data. Annual checks of the concept for technical and organisational data protection are common. For less critical applications, this may mean requesting and checking the updated concept, while on-site checks may also be necessary for critical applications.

Technical and organisational measures (TOMs)

The technical and organisational data protection concept is the central document in which service providers document the measures they take to ensure compliance with data protection obligations and the protection of personal data. As the client, you should always look at this document and only commission a service provider if you are convinced that the documented measures are appropriate and will actually be implemented. The assessment is traditionally carried out by one or more of the following persons or departments.

• Data protection officer
• IT,
• IT security
• Information security

The content that a TOM concept should cover is set out in Art. 32 GDPR. These are in particular

• Pseudonymisation and encryption of personal data,
• Confidentiality, integrity, availability and resilience of systems and services,
• the ability to quickly restore the availability of and access to personal data in the event of a physical or technical incident,
• a process for regularly reviewing, assessing and evaluating the effectiveness of the technical and organisational measures.

Data processing agreement (DPA)

If the service provider appears to be diligent on the basis of the review of the technical and organisational data protection concept, it must be contractually obliged to comply with data protection law on the basis of Art. 28 GDPR. A processor contract must therefore be concluded to agree inter alia

• that personal data will only be processed on the documented instructions of the controller,
• which technical and organisational measures the service provider must take
• that the controller may monitor the service provider,
• which sub-service providers are involved and
• the conditions to involve further sub-processors.

Service providers in third countries

In practice, it regularly happens that service providers in third countries outside the EEA are commissioned, such as AWS or Microsoft for hosting and application services. In this normal case in IT reality, there are additional challenges under data protection law. In addition to the requirements described above, the controller must then ensure that there are appropriate guarantees for the protection of the data concerned for processing in the third country. The standard contractual clauses of the EU Commission, binding corporate rules or adequacy decisions of the EU Commission are often used for this purpose. However, it may also be necessary to take further technical measures or carry out a data transfer impact assessment.

The danger of cyber risks is constantly increasing. In addition to the threat to IT security, IT security incidents are always relevant in terms of data protection law. Read here how to react correctly and what preparations you can make in the event of an emergency.

What is a data breach?

According to Art. 33 (1) GDPR, a data breach is "a personal data breach", i.e. an incident that violates the security of personal data so that unauthorised persons can access it. Classic cases are

• Accidentally sending the wrong emails or having too large an open mailing list
• Access to IT systems as a result of hacking or phishing attacks
• Theft or loss of data carriers, laptops, etc.
• Security gaps in IT systems
• Hidden but not deleted information in Excel documents

What needs to be considered for data breaches?

The top priority with data breaches is to quickly identify and eliminate the cause in order to minimise or eliminate the consequences for data subjects and prevent the data breach from spreading.

If the data breach results in risks to the rights and freedoms of the data subjects or if this cannot be ruled out, the data breach must be reported to the competent supervisory authority immediately and, if possible, within 72 hours. This happens relatively frequently.

If the data breach is also likely to result in a high risk to the rights and freedoms of the data subjects, the data subjects must also be informed immediately. This happens, but is less common than reporting to the competent supervisory authority.

Measures for internal detection and reporting

In order to be able to react appropriately to a data breach, it is particularly important that data breaches are quickly recognised internally and reported internally immediately. This requires that all employees know what a data breach is, to whom it must be reported internally and how it should be reported. It makes sense to create an instruction, guideline or similar document that describes the process. However, this process must also be communicated to employees so that they are aware of it and can follow it. The motto for this is: train, train, train.

Internal treatment - countermeasures and decision on the report

After the internal report, people should immediately come together and take action who can take technical countermeasures, evaluate the process and decide on further (legal) steps. The composition of the data breach team is made up of several or the following stakeholders:

• IT department
• IT securityInformation securit
• Cyyber insurance
• Data protection officer
• Legal department
• External legal and IT and IT security consultants
• senior management

The first priority of the data breach team should always be to take countermeasures, then clarify the extent of the incident and then decide on the next steps. Further steps are usually

• Deciding whether to notify the relevant data protection authority (mandatory for all companies if the requirements are met)
• Decision to report to the BSI (mandatory for KRITIS companies, voluntary for other companies)
• Decision on whether to file a criminal complaint with the cybercrime unit of the competent state criminal investigation office (not mandatory)
• Decision on informing the data subjects
• Implementation of the measures

Notification of data breaches to data protection authorities

If there is an obligation to report under Art. 33 GDPR, the report should be submitted within 72 hours of the incident being discovered. To be on the safe side, the first internal knowledge should be used to calculate the deadline. A later notification is possible and, in case of doubt, still makes sense after 72 hours; however, reasons must then generally be given as to why the 72-hour deadline was not met.

Art. 33 GDPR does not provide for a special form of notification. However, the supervisory authorities have online notification forms for this purpose and it is advisable to use these because the supervisory authorities receive the notification in a form that enables it to be processed quickly and, ideally, dealt with. This must be the aim of the notification.

Information of data subjects

Pursuant to Art. 34 (1) GDPR, data subjects must be informed if there is a high risk to the rights and freedoms of the data subjects. In this case, the data subjects must be informed about the incident in clear, simple language. The information should contain at least this information

• Description of the nature of the personal data breach
• where possible, the categories and approximate number of data subjects and data involved
• the name and contact details of the data protection officer or other contact point for further information
• Description of the likely consequences
• Description of the countermeasures taken or proposed

There are exceptions where personal information does not have to be provided. However, these should be treated with caution.

• You have taken appropriate technical and organisational security measures to prevent access to the data, in particular through encryption.
• You have taken measures to ensure that, in all probability, the risk to the rights and freedoms of the data subjects no longer exists.
• Notification would involve a disproportionate effort. In this case, a public announcement or similar measure must be made instead, through which data subjects are informed in a comparably effective manner.

Does reporting make you free and what are the consequences of failing to report?

The question of whether to report an incident is often discussed intensively in the data breach team. The concern that management, legal department and IT controllers in particular often have is that they could bring the data protection supervisory authority and thus many problems into the company or possibly provoke conditions and sanctions. Attempts are then often made to minimise the incident or the consequences in order to avoid a report.

These concerns are generally unfounded. Section 43 (4) BDSG contains a prohibition on the utilisation of evidence for the contents of the report, which we believe is observed by the data protection authorities despite criticism of the provision under European law. In this respect, the following applies: What is reported cannot be used against the controller.

In addition, the reactions of the data protection authorities to reports are generally much more harmless than is often feared. You often receive an acknowledgement of receipt, occasionally queries, and also occasionally the notification that the process has been checked and finalised. It is possible that a report will be followed by a supervisory process, but this is rather rare in relation to the number of reports submitted.

Data subjects have a number of rights in relation to data controllers. When you receive requests from data subjects, it is important to handle them correctly to prevent them from becoming a major problem for your company and your data protection organisation. Read here about the points to bear in mind.

How must the request for information be submitted?

There are virtually no formal requirements for data subject requests. Data subjects can submit them in writing, electronically or verbally. It is important for the handling of the request to understand what the data subject is concerned about. This sounds logical, but in practice can be the first challenge. You should ask yourself what the data subjects really want. If requests from data subjects are not clear, you need to be able to interpret them. The following requests regarding data subjects' rights are particularly suitable for this purpose

·       Access in line with Art. 15 (1) GDPR

·       Provision of a copy of the data in line with Art. 15 (3) GDPR

·       Rectification pursuant to Art. 16 GDPR

·       Erasure pursuant to Art. 17 GDPR

·       Restriction of processing or blocking of their personal data (Art. 18 GDPR) or

·       Data portability (Art. 20 GDPR)

It is also possible, and in practice a frequent case, that data subjects request the restriction of their email or telephone number for web emails or calls.

The right interpretation of the data subject's request is the first step towards a good response. In order to avoid misunderstandings, it makes sense to inform the data subject of the result of the interpretation when replying. One possible phrasing could be:

"Thank you for your email. We understand your request as a request for information in accordance with Art. 15 (1) GDPR."

Let's take a closer look at the highly relevant cases of access pursuant to Art. 15 (1) GDPR and the provision of a copy of data pursuant to Art. 15 (3) GDPR.

Identity check

To ensure that the response to the access request does not itself become a compliance boomerang, it is important to only provide the information to the data subject. This is also required by Art. 12 (6) GDPR. In practice, it happens from time to time that divorced spouses, the ex, other family members or complete strangers make requests for information. Answering these without verifying your identity can easily lead to a disaster.

You should always check who you are dealing with on the other side. This is not a problem for requests from your own employees, customers you know personally or other people you know personally. If you do not know the requesting party personally, you must ask yourself whether there are reasonable doubts about their identity. This may be the case, for example, if an enquiry is sent from an email that you do not know, or if an email suggests that it is a different person because, for example, a data subject enquiry is sent from the email account sue.miller @ for the data subject Jack Russel Brown.

If there are reasonable doubts, the identity must be verified. The principle here is that the more sensitive the information to be disclosed, the higher the requirements for identification. In particular, the following can be considered

·       Requesting additional information (birthday, adress etc.)

·       Registration and confirmation via a verified account or

·       Post-/Video-Ident and sending identification documents for particularly sensitive information.

Power of attorney for access requests handled by lawyers

In practice, it is relatively common for requests for information to be made by lawyers. This is permissible. The data controller should then ensure that a power of attorney exists for making the request for information and for receiving the information. If no original power of attorney is submitted, but only a fax or similar, the information can be rejected "immediately" in accordance with Section 174 BGB (see Regional Court Stuttgart judgement of 31.03.2021 - 9 U 34/21). The information period (see below) then only begins with the submission of an original power of attorney.

If the power of attorney does not contain a clear indication that the information may also be provided to the lawyer, in case of doubt the information should not be sent to the lawyer, but directly to the person concerned.

Information to be provided

When requesting information, the first question to be answered is always whether the data subject's personal data is being processed. This must either be confirmed or denied.

If personal data is processed, the content of the information depends on what the data subject requests. Information in accordance with Art. 15 (1) GDPR, handing over copies of data in accordance with Art. 15 (3) GDPR or specially specified information. Data controllers can request/ask data subjects to specify which information is to be provided or to which processing operations the request relates. This can help to ensure that information is provided quickly and in accordance with the wishes of the data subject. However, it does not mean that data subjects are entitled to less information than originally requested.

If information is requested in accordance with Art. 15 (1) GDPR, information must be provided in accordance with the catalogue of Art. 15 (1) GDPR on

·       purposes of the processing,

·       categories of personal data being processed,

·       recipients or categories of recipients of the personal data (in doubt, at the choice of the data subjects)

·       planned retention or the criteria for determining retention

·       data subject rights and the right to lodge a complaint with a supervisory authority

·       the origin of the data,

·       the existence of automated decision-making, including profiling.

If copies of data are requested in accordance with Art. 15 (3) GDPR, copies of the data must be provided. If the request relates to documents, a copy of the document itself must also be provided in accordance with ECJ case law, insofar as this is necessary for the control of data processing.

If less than the content of Art. 15 (1) GDPR or Art. 15 (3) GDPR is requested, correspondingly less information must be provided.

Timeline and form of the information

Pursuant to Art. 12 (3) GDPR, the time limit for providing information is one month from receipt of the request for information. The deadline can be extended to up to three months in the event of particular complexity or a high number of requests. In practice, it is advisable to send a confirmation of receipt immediately after receiving a request and to announce that you will get back to us within one month in order to manage expectations and avoid complaints to data protection authorities. Of course, this is especially true if data subjects themselves set shorter deadlines.

It is important to choose a secure channel for the transmission of the information so that the content of the information is protected. The more sensitive the content, the higher the requirements. In the frequent case of transmission by email, appropriate encryption should be provided in case of doubt.

Depending on the type of communication with the data subject, the information must be provided in writing, electronically or verbally. In case of doubt, the channel chosen by the data subject or the channel that is recognisably desired should be used. As a rule, copies of data must be provided in a commonly used electronic format.

Is it possible to reject access requests?

There are cases in which access may be rejected or made subject to paying a fee. These are

·       obviously unfounded requests and

·       excessive requests.

These exceptions are rare and are applied very cautiously in case law. It is therefore a very blunt sword to defend yourself against requests for information.

What happens if you do not provide information?

Unanswered requests for information are the breaking point of any data protection organisation and should be avoided. Especially if there is already a conflict with data subjects, unanswered requests for information often end up with the data protection authorities. You should then have a good justification - or excuse - ready, otherwise you could face fines of up to EUR 20 million or 4% of the company's turnover. Those affected can also claim material and immaterial damages. The first judgements have been handed down in which claims for damages for late information have been awarded, e.g. EUR 10,000 by the Oldenburg Labour Court in its judgement of 9 February 2023 - Ref. 3 Ca 150/21.

Record of processing activities, Art. 30 para. 1

The record of processing activities is the controller's documentation of processes under data protection law. It makes sense to take some time when creating the record  of processing activities and to create an intelligent system that maps the company processes in appropriate detail in order to create a sensible basis for further data protection organization and documentation beyond the fulfillment of documentation obligations. A good record of processing activities captures all company processes like a network and contains information that is compressed in such a way that the record of processing activities can be kept up to date with reasonable effort.

What is a processing activity? Examples included
The creation of the record of processing activities is a legal obligation resulting from Article 30 (1) GDPR. The record of processing activities consists of the documentation of individual processing activities. Processing activities are processes, i.e. a sequence of individual activities in which personal data are processed. How many individual activities are combined into one processing activity can be defined relatively freely. It is therefore possible to combine processes into one large processing activity or to map them separately. The classic example of a processing activity is personnel data processing - but more on that below.

Who needs a record of processing activities?
In principle, every controller must keep a record of processing activities, i.e. every company and every public authority. There are exceptions to the documentation requirement for small companies with fewer than 250 employees, but these should be treated with caution and rarely become relevant as a result. This is because there are fall-back exceptions, i.e. cases in which these small companies must also keep a record of processing activities, namely when small companies

• carry out regular processing operations that pose a risk to the rights and freedoms of data subjects (this is more often the case than one might suspect);
• carry out processing operations on special categories of data (e.g., health data) (this is also the case in most companies);
• perform processing operations on criminal convictions and offenses (this is likely to be rare).
  

As a result, virtually all companies and public authorities are required to maintain a record of processing activities. Even if this should not be the case, they are obliged to comply with data protection law and must also document this because of the accountability in Art. 5 (2) GDPR. In any case, it makes sense to keep a record of processing activities for this purpose, because it is the usual documentation that a data protection authority knows and expects.

Who creates the record of processing activities?
The obligation to create the directory of processing activities lies with the controller, i.e. the natural or legal person who manages a company or with a public authority. According to the internal organization, the management or the authority management must ensure that a directory of processing activities is created. These persons may, of course, delegate the creation. This makes sense and is common practice. Management or authority leadership must then only check or be told that a record of processing activities has been created and is regularly maintained.

In practice, the creation of the record of processing activities is often delegated to data protection officers or a data protection department. They coordinate the creation by creating the corresponding document and triggering the collection of information by the departments by inviting them to interviews, providing information in questionnaires or entering it directly into the document. Software support makes sense for this process, of course, in order to gather and consolidate information efficiently.
​
What belongs in a directory of procedures?
The contents of the record of processing activities are derived from Article 30 (1) GDPR. They are:

• Name and contact details of the controller;
• The purposes of the processing;
• A description of the categories of data subjects and the categories of personal data;
• The categories of recipients, including recipients in third countries or international organizations;
• Transfers of personal data to a third country or international organization;
• Time limits for erasure;
• A general description of the technical and organizational measures referred to in Article 32(1).

Depending on how one uses the record of processing activities for data protection organization and documentation, it is appropriate to collect further information there, such as

• ​IT infrastructure used;
• software used;
• result of the check whether a data protection impact assessment has to be carried out;
• etc.

Are there "standard procedures"?
There are "standard procedures" that play a role for all or most data controllers. These are, for example, procedures for processing customer data, for accounting or for operating a website. A classic processing activities is, of course, personnel data processing. It can be found in practically every company and in every public authority. In smaller companies with few staff and little activity and complexity, it may make sense to define a "personnel data processing" processing activity and map it in the record of processing activities. In larger companies with more complex personnel processes, on the other hand, it makes sense to split the topic and map it separately, for example in processing activities for "Recruiting", "Payroll", "Personnel Development", etc.

In many cases, meaningful documentation can be mapped with approximately 15 processing activities. Significantly more or significantly less processing activities can be an indication of documentation that is too complex or not detailed enough.

You can find useful standard procedures for your directory of processing activities in our free template.

What does a sample list of processing activities look like?
Templates for the creation of the inventory of processing activities contain the mandatory information according to Art. 30 (1) GDPR (see above). Good templates also contain additional information that is required for a meaningful data protection organization and documentation.

​Click here to download our template.

The GDPR requires that certain measures are taken to protect personal data when it is processed - also known as technical and organizational measures (TOM). These measures are intended to ensure that, in particular, the integrity and confidentiality of personal data are maintained and processing is secure.

What is the importance of TOMs?

Companies that process personal data are required to implement technical and organizational measures to protect the data and comply with data protection law. These include measures such as:

• Anonymization and encryption of data.
• Ensuring the integrity and availability of data and related systems.
• Continuous monitoring and evaluation of implemented measures.

Goals of the TOMs in data protection

The aim of the TOMs is to ensure appropriate data protection in line with current technological developments. A thorough risk assessmentshould therefore be carried out when implementing the TOMs so that measures appropriate to the risk can be taken. For example, if a server or network drive fails, it must be possible to restore the data from backups.

​Explore PLANIT // PRIMA now.​

How can data protection be improved through TOMs?

• Physical access control: Prevent uncontrolled access to places where IT systems are located.
• System access control: Ensures that it is possible to track who has had access to IT systems.
• Access control: Restricted ensures that only authorized persons can access personal data.
• Transport control: protection of data during transfer.
• Input control: Ensures that every data input can be traced.
• Job control: Ensures that contractors only handle personal data in a controlled manner.
• Availability control: Ensures that personal data is available and not permanently lost in the event of IT failures.
• Separation according to the purpose of processing: Ensures that personal data are processed separately for different purposes.

The specific measures required for your company should by all means be determined on the basis of an individual risk analysis.

The Data Protection Impact Assessment (DPIA) is the central and mandatory instrument for risk assessment of data processing operations. The purpose of the DPIA is to identify data protection risks at an early stage and to take appropriate measures to reduce them.

What is a Data Protection Impact Assessment?

The DPIA is the central measure of the risk-based approach of the GDPR. Companies must check for each processing of personal data whether it has high risks for the rights and freedoms of the data subjects. For processes where this is the case, the actual DPIA is then carried out; a detailed description and assessment of the data protection risks. The main objective of the DPIA is to assess particular risks to the rights and freedoms of data subjects and to take appropriate protective measures.

When should a DPIA be performed?

The GDPR provides that a DIA must be carried out whenever data processing operations, in particular data processing operations using new technologies, pose a high risk to the rights and freedoms of individuals. Article 35 GDPR also contains regulatory examples that make the performance of a DPIA mandatory, such as the systematic and comprehensive assessment of personal aspects or the processing of special categories of data. In addition, supervisory authorities have published so-called positive lists containing processing operations for which a DPIA is mandatory.

How do you perform a DPIA?

To properly implement legal requirements to perform a DPIA, it is critical to identify and then thoroughly review data processing operations that pose potential risks. The GDPR sets out minimum requirements for the content of a DPIA. These include a systematic description of the processing operations, an assessment of their necessity and proportionality, and a risk assessment for the data subjects. In addition, companies must define measures to mitigate risks and ensure data protection and seek the advice of the data protection officer. If there is still a high risk after the DPIA, there must even be consultation with the data protection authority.

Conclusion

The DPIA is a legal obligation and an essential tool for assessing and mitigating data protection risks when introducing new processes or technologies in companies. On the one hand, this serves to protect the data subjects, but also to protect your company. Especially in times of digitalization and the introduction of new technologies, it is essential for companies to address the potential risks and the necessary protective measures.

"We don't process any personal data ourselves" or "Our customers know what we do with their data - so we don't have any special data protection requirements" Do statements like these sound familiar? Then you need to be extremely careful. Data protection law applies to every company - including you. If you have contact details from customers, have employees or a website and you must comply with the strict requirements of the General Data Protection Regulation. Here are 12 typical mistakes you should avoid when it comes to data protection.

1. Unclear privacy policy on the online presence: A website without a comprehensive and understandable privacy policy is a privacy violation. Is your privacy policy secure and does it include information about analysis tools? Make sure that you provide transparent information and have a contact person for privacy-related questions.
2. Carelessness with documents: Documents or notes often end up in the trash without being checked for content. However, personal data does not simply belong in the trash, but must be destroyed in compliance with data protection regulations.
3. Errors in the cloud: SaaS Services such as Google Drive are practical and, when used correctly, can even provide added security. However, an unmanaged cloud service can also be a gateway for data breaches.
4. Poor communication: Unintentional disclosure of personal data, whether on the phone or in an e-mail, but should not happen, but still happens quickly. Awareness on the part of employees is required here. Data protection training provides a remedy here.
5. Carelessness in the workplace: An unlocked office or a computer without a screen lock can lead to data loss and data breaches. This is especially true for areas where visitors also have access.
6. Sloppy password practices: Using too simple or identical passwords across different platforms and applications can be a gateway for cyberattacks. Good password management is therefore mandatory.
7. Capacity issues: Data protection issues are complex and constantly changing. A reactive approach is not enough. Companies must be proactive and constantly adapt. This requires that there are people who have enough resources and appropriate know-how.
8. Ignorance of the requirements of the GDPR: Do not trust that the GDPR does not apply to you. This is certainly wrong. Get an overview of the legal requirements and make a plan on how you will deal with these risks.
9. Risks in communication: E-mail addresses are personal data. When sending e-mails to large distribution lists, use the "BCC" function so that your mailing does not become a data breach.
10. Video surveillance without labeling: If you use video surveillance, strict requirements apply. In any case, video surveillance must be clearly marked and you must provide detailed information about it. Simple signs with pictograms are not sufficient for this.
11. Lack of employee training: In data privacy, too, people are often the greatest risk factor. Training is essential to educate employees about data protection risks and correct behavior. Among other things, this can help prevent accidental data leaks or phishing attacks.
12. Mixing private and business: The use of apps such as WhatsApp on company devices is problematic. This is especially true if such apps have access to the address book.
    
    

It is your responsibility to take the necessary steps to ensure that they comply with and implement data protection in your company. The good news: efficient data protection is easier than you think: PLANIT // PRIMA is a data protection software that not only stands out with its browser-based and intuitive user interface, but also combines all the essential building blocks for a seamless data protection organization.

Equip your company for the data protection challenges! Book your free, personal tour of the tool now.