GDPR Challenge 5: Detect breaches and take appropriate action

Posted by Daniela Di Noi on 2/6/18 2:19 PM

Find me on:

In the previous posts, in collaboration with CDI-Partners, we have walked through the first GDPR challenges for unstructured data. As reminder, the drivers behind the GDPR are twofold. Firstly, the EU wants to give people more control over how their personal data is used. Secondly, the EU wants to give businesses a simpler, clearer legal environment in which to operate, making data protection law identical throughout the single market.

In case you missed them, let us to recap on the first 4 challenges: 

An important change introduced by GDPR is the obligation to report Personal Data Breaches.

Article 4 defines a Personal Data Breach as follows: “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.


A little quiz: What is not a personal data breach?

  • Someone accidentally deletes a document and there is no backup
  • Someone alters a document filled in by a client
  • A person sitting next to me on the train can see the screen of my laptop when I’m reviewing an employee file.

As you might have guested, all these could be Personal Data Breaches. And not all data breaches can be detected automatically. How would a system know a file is accidentally deleted or that you have left your laptop unattended without locking the screen? To minimize these types of risks, you need to set up internal policies and create awareness, by training and a lot of communication.


GDPR Personal data breaches.png


A lot of breaches can be detected. And you will have to take measures to detect these. The higher the likelihood of breaches happening and the higher the impact of a possible data breach, the more sophisticated breach-detection must be.

Modern security systems search for uncommon behavior: signing in from Belgium and 10 minutes later from Singapore, downloading files in large quantities, using an unknown device. These are just simple examples; more sophisticated statistical analysis will search for patterns. Behavior that doesn’t match these patterns is seen as suspicious.

Another technique is to use honeypot files: Files that only exist to be hacked. When such a file is touched, you know someone is in poking around in your system.

As mentioned in previous articles, documents or more general files on network servers or local disks are difficult to control. If they can be copied onto a USB Keys or sent by mail, there totally out of control.

To mitigate the risk of local and email copies of privacy related documents, Alfred GDPR promotes and facilitates collaboration by sending links. No need to make or send copies of documents, but share by link.





Alfred Edge, an intelligent gateway, is the core of the Alfred GDPR architecture. All access to Alfresco is centralized in the gateway. The gateway defines a very narrow and business driven interfaces, with strict rules about what data and what queries different (GDPR) user profiles are allowed to access. All other other access to Alfresco is blocked.

All requests are logged and retained (with proper protection of private information!). Customers can then define breach patterns and have the gateway in real time filter and monitor for such behavior.  Alfred Edge supports different interaction channels: intranet users, internet users, 3rd party systems. Using strong and positive identification, we then apply rules of expected behavior as defined by the customer.

Frequent access to private or sensitive documents can be detected and escalated. Searches on GDPR related meta-data (name, national id numbers) can be filtered, detected and blocked. If user x tries to access data about user y,  e.g. via a broad query on the repository, we log and escalate such requests. Obviously, standard access control and GDPR roles will hide any information users are not entitled to access, but breach detection will bring such attempts to the attention of GDPR officers and DPO.

When the system becomes aware of a breach, different actions can be taken. The access to the system can be blocked, an alert will be shown on a console, an entry will be written in a log file. Which actions are appropriate depends on the sensitivity of the information in the system. In all cases, the breach has to be reviewed by the Data Protection Officer if there is one, or someone with a comparable responsibility, if not. Depending on their assessment, the authorities must be notified.

Thanks for reading and keep a lookout to our next challenge: “How to keep track of the right time to delete documents and to permanently delete the documents so no backup copies exist". 

In the meantime, you can contact us for any specific request and we will glad to help you and provide our support.


The series is not legal advice for your company to use in complying with EU data privacy laws like the GDPR. Instead, it provides background information to help you better understand the GDPR. 


Topics: Alfresco, Metadata, GDPR, Compliance, personal data, Security, sensitive data, governance, breaches, Alfred Desktop, Alfred, document, Storing data, securing of processing

About Xenit 


Xenit is a Belgium-based IT company, focusing  on content services solutions, and covering all document-related business processes, from data migration to digital archive to hybrid/cloud hosting solution, to help organizations get control of their information. Premier Partner and System Integrator of Alfresco Digital Business Platform, Xenit has more than 10 years of experience in Alfresco Content and Process Services.


Subscribe to Email Updates

Recent Posts

Posts by Topic

see all