WO2019130024A1

WO2019130024A1 - Encrypted data access

Info

Publication number: WO2019130024A1
Application number: PCT/GB2018/053775
Authority: WO
Inventors: Tristan SHERLIKER; Alexander ARBUTHNOT; Thomas Andrews; David Guy JOHN
Original assignee: Information Requests Limited
Priority date: 2017-12-30
Filing date: 2018-12-28
Publication date: 2019-07-04
Also published as: GB2569950A; GB201722299D0

Abstract

Embodiments of the invention relate to methods, systems and architectures for improving efficiency, security and other critical aspects of requests made under data protection laws. In an exemplary design, the system receives an input electronic data protection request intended for a data controller from a subject over a network; retrieves an electronic address of the data controller and a type of the data controller; validates the request against a plurality of stored rules; and, only if the request satisfies the stored rules, creates an output electronic request depending on the type of data controller; and, forwards the output request to the data controller by: sending information relating to the output request to the electronic address of the data controller; and, sending the output request to the data controller using protected data communication.

Description

ENCRYPTED DATA ACCESS

BACKGROUND Data protection legislation such as the European Union’s General Data Protection Regulation (REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC) (‘GDPR’) sets out various rights and freedoms of individual persons whose data are provided to organisations such as companies, institutions and governmental bodies to ensure the freedom of the data subjects and their right to privacy.

The GDPR sets out the right of Subjects to make requests of Controllers, including for example to:

request access to (or copies of) data pertaining to them that is held by a Controller (a‘Subject Access Request’ or‘SAR’);

request that data pertaining to them that is held by a Controller be deleted from the Controller’s databases (the‘right to be forgotten’ or right to make‘erasure requests’);

request that data pertaining to them that is held by a Controller be corrected (‘rectified’;“data rectification requests”);

request portability— i.e. in appropriate circumstances, that data pertaining to them is delivered to them in a machine readable format for transmission to other service providers;

make requests relating to amendment or removal of marketing preferences; and,

make requests relating to or limiting use of data for purposes such as statistical analysis or algorithmic processing.

Any of the above requests may also be partial, that is, limited in their scope, or may be hybrid requests, that is, one communication combining two or more requests or partial requests. The process of such requests is adversarial: companies do not want to receive data requests and such requests are unwelcome burdens. It is not a collaborative process that might allow for efficiencies to be realised. Furthermore, compliance is a time-sensitive process with serious penalties for non-compliance. The process is so burdensome that subject access requests may be used to deliberately cause burden to business. For example, a UK magazine for the Human Resources industry,“Personnel Today”, described in 2016 that subject access requests can be used as“a useful weapon” that“can cost a business significant time and money”.

What is more, the GDPR also requires that Controllers engage in“privacy by design” and that data is kept confidential to the greatest extent possible. This includes for example, requiring that sensitive or private data is only disclosed to internal Controller personnel on a need-to-know basis. However, the process of a subject access request (for example) requires the involvement of many disparate personnel, all of whom will be granted access to sensitive data merely by reason of being involved in handling such a request. Therefore, the mere making of such a request by a Subject has the effect of negatively affecting the privacy of such a subject, at least from the perspective of exposure of that information to the personnel of the Controller or to malicious third parties. Nevertheless, this problem is not simple to avoid because the handling of such a request requires input from multiple personnel with different specialist requirements, which is further explained below.

Typically, the process of making such a request involves the Subject crafting an email or written letter including all the information they believe to be necessary for the Controller to respond to the request. If the Subject wishes to make a request of multiple Controllers, an individually tailored piece of correspondence is sent to each one. Each Controller will then manually review this information and respond with any further information necessary such as requesting to see copies of a Subject’s personal identification documents so as to manually validate the request. Once the identity has been confirmed the Controller must manually interrogate structured and unstructured data stored in multiple data sources and then must reply to the request in a machine readable form which will typically be a large volume of highly sensitive unsorted data.

In an example, it was shown in an article by the Guardian newspaper in 2017 that a subject access request to an online dating app returned over 800 pages of highly sensitive information including factual data such as the location from which messages have been sent and inferred data such as words used the most and personal preferences inferred from behaviour using the app.

Such highly sensitive data is typically returned via the same communication method from which the request was made. For example, if the request was sent by email, the reply is sent by email. Email is often hacked, manipulated or intercepted. Although email can in theory be encrypted, in practice this is not feasible because to do so requires knowledge of the encryption technique by both the sender and receiver; all of which is impractical for the typical user especially when sending requests to many different Controllers and to generic company email addresses which may be received or operated by many persons.

The regulations and the conventional means by which Subjects can communicate with Controllers presents several technical challenges, not least ensuring security of the personal data transmitted between Subject and Controller.

For example, unstructured, requests operate within parameters defined by law, and are written in human language; therefore they are not readily understood in a technical manner. Additionally, checking compliance of the request with the law is difficult both for a Subject and for a Controller, and is not easy to do in a technical manner.

Further, as the information requested may be requested by various means, verification of Subject identity difficult. Certain requests may require that the identity of the Subject is validated by the Controller using personal identification documents. Making such documents available over unsecure electronic means or to multiple individuals creates a security problem for Subjects. Additionally, actually providing those documents to the Controller is logistically challenging. Finally, the law requires that some information must sent back to the Subject in a machine-readable format but this can be difficult to achieve. Large volumes of data are unsuitable for email where volume limits typically apply and providing data volumes in any other format (e.g. physical media via post or online data access) is unrealistic for small businesses.

At the data controller, a subject access request is typically dealt with by multiple people whose specialties do not overlap.

Assessing a Request from a legal perspective, and corresponding with the Subject, is a legal function dealt with by a lawyer or data protection specialist. This is normally a non-technical individual. The lawyer may not yet know whether the Controller actually holds any data about the particular Subject. When it comes to obtaining the data to be sent, a records manager will extract this from company records. This person is a technical or administrative function and will not know about the law, so cannot check whether the data being sent is the right kind of data. The lawyer will then need to check the data before it goes out. The data may be provided in a format that is inappropriate and would not be compliant with the law (it may have sensitive information that needs redacting; or it may be encoded or abbreviated in some way; or it may not be machine readable in an appropriate way). The lawyer may not be able to repair these issues which involve editing data while maintaining it in a machine-readable format— either through lack of technical ability; or lack of knowledge of what to redact or how do decode the information. This may involve a third person (a technical person) to un-encode the data, edit it, redact it etc. It may also involve a fourth person to supply requisite knowledge such as the meaning of abbreviations. Only then can the request be dealt with.

Importantly, the data protection process is fundamentally one of information asymmetry, that is, a transaction where one party has more or better information than the other. When seeking to provide for efficiencies, this asymmetry prevents optimisation and is obstructive. For example: the sender likely to be unaware of law; the sender is likely to be unaware of the technical architecture of the company’s system; the sender is likely to be unaware of the precise data or categories of data held; and, the recipient may be unaware of the sender’s system.

To alleviate some of these concerns, it is known in the field for agents to act on behalf of Subjects. Agents provide a manual review of the data and translate the information into required legal and technical terms that can be understood by the Controllers to facilitate retrieval. Agents may provide a web portal to receive the requests and aggregate the data retrieved but such a web portal is simply a means to receive and present data.

There remains a need to address the issues of privacy and efficiency in data protection request handling and processing.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, there is provided a method for electronically processing data protection requests between a subject and a data controller. The method comprises: receiving an input electronic data protection request intended for a data controller from a subject over a network; retrieving an electronic address of the data controller and a type of the data controller; validating the request against a plurality of stored rules; and, only if the request satisfies the stored rules, creating an output electronic request in a specific format depending on the type of data controller; and, forwarding the output request to the data controller by: sending information relating to the output request to the electronic address of the data controller; and, sending the output request to the data controller using protected data communication.

The method provides for the protection and data formatting of requests so as to improve the security and efficiency of data protection requests made in accordance with the GDPR. The method does not replicate, simulate or automate human behaviour but rather enables efficient subsequent human steps utilising technical means. In some embodiments, there may be no human interaction whatsoever in the steps performed once the Subject has made a sent a request. Data protection requests may also be understood as data request, data protection request, data privacy request or subject rights request. The output electronic request may be any form of request for utilisation at the data Controller to comply with a requirement of the GDPR. For example, the request may be in the form of a database query, human readable request complying with the requirements of the GDPR or machine readable request for simplified processing by a machine such as XML format.

A contribution of the invention may therefore be considered to be an improved method for protecting the highly sensitive personal information of a Subject across a network where the request could be directed to multiple, disparate data Controllers. There is improved data protection and data presented appropriately according to the data Controller to enable direct processing by a computer without significant human involvement.

Electronic address may refer to any known mechanism by which the data Controller can be contacted electronically such as email address, telephone number, IP address or other HTTPs message, for example.

Preferably the method may further comprise: retrieving a unique identifier of the subject; querying a selected identity verification service using the unique identifier, the service selected in dependence on the type of data controller; and, forwarding the output request only if the identity verification service returns a successful indicator.

In this way, the system may validate the Subject on behalf of the Controller so that the Controller has a trust in the requests being received. This is an improvement over normal ID checks used by legal staff who will typically verify ID by reference to copies of ID documents, which is an unreliable process and less secure. From the perspective of the Controller, a more secure ID check protects the Controller from the risk of accidental disclosure of sensitive information to an unauthorised party. From the perspective of the Subject, this speeds up the process of obtaining a response to the request and allows the Subject to evidence that they have provided required information for ID purposes compliant with any legal obligations to do so. Additionally, the same considerations may apply in respect of other documents that may be required to be transmitted in connection with a request, such as proof of change of name, or other evidence that might accompany a rectification request; which may be treated as identification documents for the purposes of the system.

Accordingly, the system is operable to provide to secure transport and verification of a user without exposing the highly sensitive data of the user.

Optionally, the identity verification service may be selected from a group comprising: 3D-Secure; OAuth; and, a two-factor authentication service. In this way, the system is able to accurately check identity for its own purposes but is also able to accurately identify to the Controller that the Subject has been verified without having to release personal identification documents.

The method may further comprise: receiving an electronic copy of a personal identification document from the subject; securely storing the electronic copy; and, sending an indication of the personal identification document with the output request based on the type of data controller and a type of the output request. Thus the sensitive data is not transmitted over a vulnerable communication medium but securely held and released only to authorised users. Additionally, the files could be stored for use in future requests without needing to repeat an upload. (The indication may for example be a hyperlink to securely retrieve the document; a copy of the document itself; a redacted or masked copy of the document or an indicator that the document has been received and/or authenticated separately; it could refer to any such known indication regarding identity that is useful in that it facilitates, or fulfils wholly or partially the intended purpose of supplying an identification document, namely to check identity of the sender of a request. In one example of an indication, the system could scan an uploaded passport photo and send a redacted version of the passport or the number in order to show to the data controller that the passport was correct without revealing the whole number which could be intercepted.) Optionally, the step of creating an output electronic data protection request further comprises performing a machine-translation on the input request to translate the input request into a different language. Thus the system allows requests to be structured along common lines regardless of language spoken, it facilitates the automatic translation of a request without risk of loss of information.

In certain embodiments, the information relating to the output request is a hyperlink to a secure data repository from where the output request can be retrieved by the data controller. Thus where the Controller does not have a bespoke protected data communication method available to the system, the Controller is able to use a standard protected data communication method to protect the transmission of the data. The data is not made vulnerable through the use of email to transmit sensitive data.

The method may further comprise: receiving a response to the output request from the data controller; and, sending confirmation of receipt to the data controller including a time stamp. This is advantageous as it allows the Controller to demonstrate that it has discharged its obligations to respond without relying on unreliable mechanisms such as email receipt-tracking functionality, which may not be implemented consistently on different browsers.

In one embodiment the protected data communication is a Secure Sockets Layer session. Thus the data can be exchanged in a method that has been shown to be secure. Alternatively or additionally, the output request may be hashed using a cryptographic hash function prior to sending to further increase security of the private data.

In an alternative embodiment the protected data communication may be an encrypted communication channel. Some data controllers may have an encrypted link arranged between the system and their servers so as to ensure the data transmitted is secure.

Forwarding the output request may further comprise sending the output request to a plurality of electronic addresses of the data controller. Accordingly, the check can be performed not just from the perspective of one company, but of the entire corporate group in a way that is not normally available, as a Subject is unlikely to have an understanding of the corporate structure a company. Moreover the request can be sent to the correct multiple personnel within a corporation such as legal and technical.

Creating or forwarding the output request may further comprise aggregating multiple data protection requests. In this way where a large corporation receives many requests, these can be managed on their behalf.

The step of creating may preferably further comprises modifying content of the input request based on instructions received from the data controller. Thus the information can be given in a manner which pertains to the person receiving it.

The step of sending the output request may optionally comprise providing access to the output request using a secure web interface, the interface being configurable to display the request in a plurality of different formats based on instructions received from the Controller so as to display information relevant to the reader to enable efficiency in processing.

The step of creating may further additionally comprise creating the output request in a specific format based on comparing the input request against a series of stored criteria representing rules for legal and technical compliance of the input request. Thus if the request is not compliant or is inadequate, the request is presented to the Controller with this information to enable them to efficiently make a decision on how to process the request.

Preferably the method further comprises: receiving a reply from the data controller in response to the output request, storing the reply in a secure data repository; and, sending secure access information for the repository to the subject. In this way the Subject can access the response without exposing the data. The secure repository can be securely accessed whereas in the conventional method the data is sent by post or email which is insecure and makes the data vulnerable to malicious or fraudulent activity. Preferably the reply is received using the protected data communication to ensure the data is kept secure and it can be easily handled.

Optionally, the method may further comprise comparing the received reply against a previously stored reply to identify any inconsistencies. The solution will be able to identify disparities between information held by different Controllers about the subject, highlight this to the subject, so they could generate sufficient right to rectification requests.

In this embodiment, the method may preferably comprise applying a unique tag (a form of identifier not to be confused with other identifiers referred to herein) to allow identification of to the received data. Tagging of the data received from the Controller can ensure that further requests, such as deletion or rectification, can find the data mentioned in subsequent requests in an efficient manner. Such a tag may be any type of identification that allows for efficient retrieval: for example, adding a line to a database entry with information to indicate that the associated data was sent pursuant to a previous request; or tagging by storing a copy of the data in a separate database or a separate part of the same database from which it was originally retrieved; or storing a table indexing the data (for example by reference to its location in the controller’s databases); or by other means. Tags may be useful in many ways, for example to demonstrate compliance; to allow data to be identified efficiently by a Controller if future requests are made in respect of the same data; or they may be used to cross-reference between different data controllers who have shared subject data in order that they might keep track of any other sharing of data with other controllers.

The step of validating the request against a plurality of stored rules further comprises selecting a predetermined response from a set of responses based on the outcome of the validation. If the information within the request fails the validation the user is given proper feedback on this so that a successful request can be submitted in future. The Controller does not have to deal with incomplete responses or back and forth communication with inexperienced users. The method may further comprise: retrieving an identifier of the Subject; and, checking the identifier against a third-party database to identify if the identifier is potentially malicious or fraudulent. The identifier may be an email address for example; alternatively, an identifier may include a telephone number, name, address or pseudonym. The Controller Client may also supplement the normal ability of a human to check data by interfacing with other third-party databases in a way that a human may not be able to do. For example, known databases exist that may be queried to ascertain whether user information associated with a particular email address has been disclosed by reason of past data security breaches

In certain embodiments the output request may include at least one database query. Optionally, the method may further comprise executing the database query on a database of the Controller; receiving a dataset from the database; formatting the dataset; and, storing the formatted dataset in a secure data repository accessible to the Subject. Thus in certain embodiments the method may safely and securely receive a request, identify the information, receive the request and present that to the user without human interaction despite the user making the request of multiple data controllers.

The method may further comprise checking a part of the query against the database to predict an expected result; and, forwarding the expected result. In this way the result can be checked without performing a full query.

Additionally, the method may comprise comparing a part of the output request against an extract of a database to predict an expected result. Thus the expected result can be predicted without allowing access to the secure database.

In certain embodiments the method may comprise comparing the output request against a plurality of rules and, based on the comparison, predicting a response. For example, the user can be presented with a predicted result so as to modify the request or the request may not be sent if there is no data to be retrieved or that can be deleted. According to a second aspect of the invention, there is provided a method for electronically processing data protection requests between a subject and a plurality of data controllers, the method comprising: receiving an input electronic data protection request intended for a plurality of data controllers from a subject over a network; retrieving an electronic address of each of the data controllers and a type of each of the data controllers; validating the request against a plurality of stored rules for each data controller; and, only if the request satisfies the stored rules for each of the data controllers, creating an output electronic request for each data controller in a specific format depending on the type the relevant data controllers; and, forwarding each output request to the relevant data controllers respectively by: sending information relating to the output request to the address of each data controller; and, sending the output request to each data controller using protected data communication.

According to a third aspect of the invention, there is provided computer readable medium comprising instructions which when executed by a computer cause the computer to perform the method of any of the first and second aspect of the invention.

According to a fourth aspect of the invention, there is provided a system for electronically processing data protection requests between a subject and a data controller, the system comprising: a Subject Client configured to receive an input electronic data protection request intended for a data controller from a subject over a network; a processing module configured to: retrieve an electronic address of the data controller and a type of the data controller; validate the request against a plurality of stored rules; and, only if the request satisfies the stored rules, create an output electronic request in a specific format depending on the type of data controller; and, forward the output request to the data controller by: sending information relating to the output request to the address of the data controller; and, sending the output request to the data controller using protected data communication.

The Subject Client may be further configured to retrieve a unique identifier of the subject and forward the unique identifier to the processing module, wherein the processing module may be configured to: query a selected identity verification service using the unique identifier, the service selected in dependence on the type of data controller; and, forward the output request only if the identity verification service returns a successful indicator. The identity verification service may be selected from a group comprising: 3D-Secure; OAuth; and, a two-factor authentication service.

The Subject Client may be further configured to receive an electronic copy of an personal identification document from the subject and securely forward the copy to the processing module, wherein the processing module is configured to: secure storing the electronic copy; and, send an indication of the personal identification document with the output request based on the type of data controller and a type of the output request.

The processing module may be further configured to perform machine-translation on the input request to translate the input request into a different language. The information relating to the output request may be a hyperlink to a secure data repository from where the output request can be retrieved by the data controller. The processing module may be further configured to: receive a response to the output request from the data controller; and, send confirmation of receipt to the data controller including a timestamp. The protected data communication may be a Secure Sockets Layer session. The processing module may be configured to hash the output request using a cryptographic hash function prior to sending. The protected data communication may be an encrypted communication channel.

The processing module may be further configured to send the output request to a plurality of electronic addresses of the data controller. The processing module may be further configured to aggregate multiple data protection requests prior to sending.

The processing module may be further configured to modify content of the input request based on instructions received from the data controller. The system may further comprise a Controller Client, wherein the Controller Client may be configured to provide access to the output request using a secure web interface, the interface configurable to display the request in a plurality of different formats based on instructions received from the Controller. The processing module may be configured to create the output request in a specific format based on comparing the input request against a series of stored criteria representing rules for legal and technical compliance of the input request.

The processing module may be configured to: receive a reply from the data controller in response to the output request, store the reply in a secure data repository; and, send secure access information for the repository to the subject. The reply may be received using the protected data communication.

The processing module is further configured to compare the received reply against a previously stored reply to identify any inconsistencies. The processing module is further configured to applying a unique identifier to the received data.

The processing module may be further configured to validate the request against a plurality of stored rules and select a predetermined response from a set of responses based on the outcome of the validation.

The Subject Client may be further configured to retrieve an identifier of the Subject and forward the identifier to the processing module, wherein the processing module may be configured to check the identifier against a third-party database to identify if the identifier is potentially malicious or fraudulent.

The output request may include at least one database query. The system may further comprise a Controller Database Integration System, configured to: execute the database query on a database of the Controller; receive a dataset from the database; format the dataset; and, forward to the formatted dataset to the processing module for storage in a secure data repository accessible to the Subject. The Controller Database Integration System may be configured to: check a part of the query against the database to predict an expected result; and, forward the expected result. The processing module may be configured to compare a part of the output request against an extract of a database to predict an expected result. The processing module may be configured to compare the output request against a plurality of rules and, based on the comparison, predicting a response.

DETAILED DESCRIPTION OF THE DRAWINGS

An example of the present invention will now be described in detail with reference to the accompanying drawings, in which:

Figure 1 shows a high-level architectural diagram of a system according to an embodiment of the present invention;

Figure 2 shows a schematic illustration of modules of a system for implementing aspects of the present invention;

Figure 3 illustrates an exemplary process flow for a non-participating Controller; Figure 4 illustrates an exemplary process flow for a participating Controller;

Figure 5 illustrates an exemplary process flow for a timer module; and,

Figure 6 illustrates an exemplary user journey process flow for a Subject interacting with a Controller.

DETAILED DESCRIPTION

Concepts described herein aim to permit or otherwise enable unstructured data requests to be dealt with in a technical manner; to speed up their processing by recipient data controllers; to prevent duplication of work by employees of the recipient data controller; to maintain better privacy of the subject and confidentiality of requested data during such processing; to save time and money of the company; to provide technical means to improve the ability of data controllers to comply with data protection law; to improve the ability of data controllers to demonstrate compliance with the law; to enable data subjects to generate data requests more efficiently; to enable responses to such data requests be received by data subjects in a technical manner; to enable more efficient communication between a data subject and a data controller; and to enable and promote better compliance. Further, they allow requests to be created formed from multiple sources rather than relying purely on a Subject’s input data.

The following is terminology that will be used throughout the description (including the Background and Summary above):

Subject: The data Subject— the person making a request to a Controller.

Controller: The person receiving the request from a Subject. The word ‘controller’ is used for simplicity but this may be a data Controller or a data processor within the meaning of the law and it may be any valid recipient such as a company, partnership, government body, institution or other legal person.

Relationship (between a Subject and a Controller): The Subject and Controller may have any relationship that gives rise to the responsibilities of the Controller to the Subject. For example as the case may be, the relationship could be that of employer to employee; customer to service provider; or there may be no direct relationship save for the relationship of the data Controller to the data Subject.

Request: A Subject Access Request, request for the deletion of data, or any other request as enabled by the relevant data protection legislation in the relevant country. A Request can also variously be known as“data protection request”,“data request”,“data privacy request” or“Subject rights request” or by the names of the specific requests including the various requests referred to above hereinafter “request” is used to mean a request generated and/or Processed via the system described below, unless context indicates the contrary.

Validation: checking that a request is valid in law and has provided all necessary information to allow Processing. This may include authenticating the Subject by validating ID.

Processing: In the normal context of a normal data protection request seen from the perspective of the Controller, once validated, processing of a request by a Controller involves obtaining, vetting, and delivering the candidate data set pertaining to the request back to the Subject (i.e. all the steps involved in fulfilling the request). It may also include other processing steps such as redacting the data if appropriate. The description of the invention herein refers to the processing of requests from the perspective of a Controller to describe a particular stage of the handling of a request. However, outside that context (and as used in the claims herein), the‘processing’ of data protection requests using the concepts described herein may refer to the carrying out of any aspect of the proposed methods and systems from start to finish.

Types of data controller: Data controllers may be typified into types in a number of ways. Primarily, the system will categorise data controllers by referecce to whether they are subscribed to the system (Participating) or not (non participating) as described elsewhere herein. The system may further keep track of data controllers in other ways, such as the industry or type of business of the controller (such as“a bank” or“an e-commerce company”); whether a request has been sent to the Controller via the system previously; how a Controller has interacted with the system previously (if at all); whether the system has been adapted to interface with / make requests of a particular Controller; and by other means by which various Controllers may be contrasted with each other in various ways described throughout this document.

Data / Information: Unless context otherwise requires,“data” refers to data about a Subject, which is the target of a request. On the other hand“information” could be any information as the context permits. This may also include information contained within or about a request such as the identification documents provided by a Subject to validate their identity. These terms are not mutually exclusive and may overlap: some items of information, such as the Subject’s name and email address, may also be data items.

Figure 1 shows a high-level architectural view of the described system. A Subject 10 may interact with a personal computer or other terminal connected to the internet. The Subject 10 may then interact with a processing system 12 to communicate Requests and retrieve Responses. The processing system 12 may in turn communicate with a series of Controllers 14, 15, 16 and store the responses in a secure file store 17. Identification examples 14a, 15a and 16a are described below.

At a high-level, the Subject 10 interacts with the system 12 to raise a Request. The system formats that Request and passes that Request to one or more of the Controllers 14, 15, 16. The Controllers may be integrated with the system or may not. In the conventional web ordering paradigm, each of the entities are signed up to the system (also called‘participant’ as defined below). This may not be the case in the present process and the Data Controller may not be fully aware of the system in order to receive a formatted Request.

In certain embodiments, depending on whether the Controller has signed up to the system, or not (i.e. is or is not a participant controller), they may receive a different message type from the system. As will be described in detail below, in a first example, a signed up Controller may receive the Request in an encrypted message form. A Controller that has not signed up may receive an indication of the request with a link to receive the Request from a secure data repository to ensure protection of the message data. The Response received by each Controller can be sent using the same protected communication channel and subsequently securely stored by the system for later secure retrieval by the Subject. Thus, the system 12 breaks the conventional web paradigm, for example hotel ordering, where typically entities are signed up to the system and are able to understand and receive the messages received.

Figure 2 illustrates an expanded illustration of the modules of the processing system 12.

Requests may be sent from the Subject 10 using a Subject Client 21 , Dashboard 22 or by email. A Subject Client 21 is Public access client for members of the public (Subjects) to generate and manage requests. The Client may be a cloud- hosted, a web app, or native app etc. A Subject may manage data using a dashboard 22 which may be integral with the Client 21 or may be standalone. This could be for example the Subject’s account data, data pertaining to their requests, or a visualisation of data received from requests.

To receive Requests via email, the system 12 may include an email management server 23. Requests may be transmitted by Subjects using integrated email and responses received from Controllers by replying to emails. The email management server 23 handles this and allocates received emails appropriately. A messaging server 24 may be provided in which requests and responses may alternatively be transmitted by the system’s own communication methods. These are handled by the messaging server 24.

To facilitate interaction with Controllers, a Controller Client 25 may be provided. Requests sent using the system’s own messaging protocols may be transmitted to a Client 25 used by the Controller. This may be on-premise software or cloud- hosted software.

In certain embodiments, as will be described below, a Controller Database Integration Subsystem (“CDIS”) 26 may be provided which facilitates the system to integrate with the Controller’s own information databases.

One or more data stores may also be provided such as a system file store 27 and system database 28. The system may handle files containing user data, to be saved in the file store 27. The system may keep track of details pertaining to how it is used such as requests, in a database 28.

An event management module 29 may be provided as a logical function to control timers and events. Additional encryption/decryption functional blocks, user interfaces and other modules may also be included but are not shown for brevity. The functionality of modules will be described below.

Returning to Figure 1 , there is shown a series of Controllers 14, 15, 16. Controllers may be considered as“participant” or“non-participant” in the architecture of the system (as defined and explained further below).

If a Controller is non-participant, they deal with requests sent via the system as if they were any other request and may not even be aware that the request has been sent via a specialised system.

If a Controller is a participant, they have decided to cooperate with the system architecture and adapt their systems to take fuller advantage of the system. They will therefore be expecting to receive requests via the system, although they will not know anything about the requests to be expected (since these could come from any member of the public, i.e. any Subject or even any person that is not in fact a data subject, but may suspect that they are).

Cooperating in this manner is a significant difference to the normal way of handling data requests. The Subject and Controller have a relationship that is adversarial (because the Subject is exercising legal rights over the Controller in a manner that is normally unwelcome and may be resisted). Despite this, by jointly agreeing to use the system to process the request, the Subject and Controller can work together to their mutual benefit even though the relationship between them may not be a relationship of cooperation.

Accordingly a participant Controller may receive and handle requests significantly differently to a non-participant Controller, for example—

Controllers may receive requests directly within the architecture of the system.

Controllers may use a Controller Client to receive and process a request. This may be installed on-premise or cloud-hosted. The use of a Controller Client enables efficient handling of the request, prevention of errors, and automation of some or all processing tasks.

Controllers may respond to requests directly within the system

The Controller Client may be adapted to interface with the participant Controller’s own information stores / databases using a Controller Database integration subsystem (“CDIS”).

Controllers may use the system to keep track of their compliance with their legal obligations.

The above discussion illustrated the high-level components of the proposed system and described the interaction between each of the components. The following description focusses on the process undertaken by the system and the detailed functionality of the modules. This is a description of the process of sending a request from a Subject to a Controller and will be explained from the perspective of a Subject access request. It will be understood of course that the request could be of any nature described above and the Subject access request is an illustrative example only.

A system is proposed to enable the generation of legally-compliant requests from Subjects to Controllers and to enable Controllers to efficiently receive, assess, validate, and respond to such requests in a manner that is compliant with the law.

As mentioned above, the Subject Client is a public access client used for generating requests. In certain examines this may be a form or series of questions answered by Subject e.g. via app, web form, interface with other system, etc.

The system initially collects data from the Subject for the request. The data may include the identity of Controller and identity of Subject, the relationship of Subject to Controller (if any) and the type of request being made.

The system allows the Subject to select or indicate the information or categories of information being requested, if that is known. This is useful because it enables the user to tailor the request to what is desired and avoid data that is not desired. Some data may be particularly sensitive, or the Subject may already have copies of it.

The Client allows the subject to request information about how their data has been handled or dealt with.

The system then formats the data obtained into an output request that is legally compliant and can be understood by Controller.

In certain examples the system may be able to perform checks on the input data to ensure that it is compliant with the rules set out in the legislation. For example, that all relevant information has been provided and that the Subject is entitled to make the request.

Prior to the submission of a request, it may be able to predict for the Subject what sort of response is likely to be received, based on the information that has been input and/or types of information that had been returned in response to previous requests made via the system. This could enable the Subject to go back and amend the information for example by entering more information; or deciding to abandon the request; or to submit the request in the knowledge of what sort of response is likely to be received. This prediction may be based on pre-configured rules - or, if many requests are sent to one Controller by different Subjects, it may be possible to make this prediction based on a machine learning algorithm that evolves over time.

The system may also make checks on the current request being made in the context of previous requests that have been made by that Subject and may operate differently according to the outcome of those checks.

Since repeated or excessive requests to the same Controller may be treated differently in law compared to isolated/single requests, the system may check to see whether the Subject has made previous requests to the same Controller and suggest to the Subject if such requests may be treated differently for that reason (e.g. the law may provide that a fee could be required). In the case that e.g. a fee is required, the system may offer a fee payment service.

Similarly, the system may interface with company structure databases to make the same check not just from the perspective of one company, but of the entire corporate group in a way that is not normally available, as a Subject is unlikely to have an understanding of the corporate structure a company.

The system may check whether any previous request made by that Subject using the system has been refused, and the reason for any such refusal. If the circumstances of the previous refusal match the circumstances of the existing request the system may encourage or require the Subject to amend the request, for example by amended the information provided.

The system may refuse to submit requests from a Subject and/or to a Controller based on information about past abuse or improper conduct. It was mentioned above that in the conventional Request mechanism, the Subject sends an email to myriad different data Controllers, each data Controller processing the email in a manual manner. At the data Controller end, there is no guarantee that the user is correct or honest, rather than being a malicious third party. Nevertheless, by law, the data Controller must respond to each request. A Controller may in certain circumstances ask to see identification documents. It may be highly undesirable for the Subject to release these documents to a Controller, for example because this may have the effect of disclosing further personal information to a Controller that was not already known to them; yet the data Controller must be able to accurately guarantee the identity of the individual Subject.

The invention proposes a technical solution to this problem. The solution is for the system to identify the Controller and provide an identification technique based upon the nature of the Controller. As will be described below, the system is able to identify if the Controller is a participant or non-participant and also identify different identification techniques based on the Controller. For example, a bank or social network makes available identification techniques using application programming interfaces that enable third parties to check identity.

In this way, the system is able to accurately check identity for its own purposes but is also able to accurately identify to the Controller that the Subject has been verified without having to release personal identification documents.

The system first identifies from the Request and the Controller, the identification requirements and then takes different steps depending on the type of Controller. A series of example options will now be described, referring once again to Figure 1.

In a first example, the client interface may obtain identifying information to validate the identity of the Subject. This can be done by uploading photos of ID documents (e.g. passport scan), which can be sent to Controller 16 in the normal way. The upload may be accomplished by a secure (encrypted) communication channel. The documents are stored in a secure repository 17. The communication from the system 12 to the Controller may be an email 16a with a hyperlink to the secure repository 17 so that documents are not sent directly to the Controller 16. Where identification is required, the Controller may optionally retrieve the documents. Such an example is particularly useful for non-participant Controllers.

Unlike normal request functions, the system could also do some ID checks itself. For example, a request made through the system could include a certification that the relevant email address has been verified in a known way. For example by use of verification email. A Controller receiving the request may already have a record of the relevant email address associated with the identity of the Subject and the relevant information being requested. The processer has likely already performed their own validity checks on that email address in the past at the time that the Subject originally signed up or provided data. The fact that the same email address has been verified at the sender end and the recipient end is a strong indicator that the identity of the Subject is accurate. Thus, the system may optionally only send data to a Controller of this type if the email address has been verified by the system. A trusted relationship between the Controller and the system may indicate at the Controller is then able to release the data as it can trust the system has verified the email address.

In another particularly preferable option, the system may also be able to interface with third-party ID verification systems. This would enable the request to be sent with a certification of the identity of the individual. In an example, the system of the invention may also be able to interface directly with the authentication systems of the Controller which would enable identity of the Subject to be verified to a standard set by the Controller, even prior to the Controller having received or being aware of the request.

As illustrated in Figure 1 , the identification service 14a may be separate from the interface for sending the request information to the Controller 14. Alternatively, the same interface 15a may be used to authenticate the identity and transmit the data to the Controller 15, for example in the HTTP paradigm. Where the Controller operates in the field of financial transactions (e.g. a bank) the verification of ID could be managed using the bank’s verification systems such as the system known as 3D-Secure. Where the Controller operates an online service such as a social media service, the verification may be managed by allowing access to the Subject’s online account operated by the Controller, by using token authentication (for example, OAuth is a well-used implementation to enable such token authentication). Where the Controller operates a two-factor authentication system (2FA) such as RSA SecurlD or some other 2FA that could be used instead.

It will be understood that the operation of the system in this way allows it to take advantage of many technological processes to validity identity including other digital identity services or standards that may arise from time to time.

This is an improvement over normal ID checks used by legal staff who will typically verify ID by reference to copies of ID documents, which is an unreliable process and less secure. There may be a much higher rate of false positives and false negatives when documents are checked by human personnel compared to checking by technical means. In the case of handling a data request neither is acceptable: a false positive result may have serious consequences as it may result in disclosure of potentially sensitive data to an unauthorised individual. A false negative may result in non-compliance with data protection law, leading to sanctions such as a fine. From the perspective of the Controller, a more secure ID check protects the Controller from the risk of false positives and false negatives. From the perspective of the Subject, this speeds up the process of obtaining a response to the request and allows the Subject to evidence that they have provided required information for ID purposes compliant with any legal obligations to do so.

In further improvements, with the consent of the Subject, the system may save identifying information for future use. Normally, n requests sent out to up to n different Controllers would require each Controller to perform their own independent ID checks, which is inefficient and may lead to expense and delay. Even if two or more Controllers are part of the same corporate group, it is possible or even likely that the request would not be handled by the same person employed by the Controller, so potential efficiency would be lost. By centralising the ID checks the same verification can be made efficient.

In certain examples, the system could associate the ID validation information with the user’s personal details. Where those match for future requests, the same ID can be used (but if the name or contact details used for a second request were different, it would not be used).

In the case that verification using one set of information has been accepted in a first request, any later request using the same verification information could include a certification that the verification has been successful in the past. Depending on the circumstances the extent of information may include e.g. details of the past successful verification or verifications such as date, industry of the Controller who checked it, and/or identity of the Controller who checked it.

If ID is verified by uploaded document files (e.g. scans of passport) for a first request, these files could be stored for use in future requests without needing to repeat the uploading step.

If third-party verification is used for a first request, there would not be a need to repeat that step for any later request (saving money) and preventing the relevant Controllers from needing to pay a third party identity check service.

During the process of creating a request, the Subject will be able to save / resume / delete / send the request from this client interface and the system will store the details of the request in a database store and prepare the request to be sent.

Unlike the normal communication channels where what is written by one party is received in identical form by the recipient: once a request has been input by a Subject, it may be delivered to a Controller in a different output request format depending on the requirements of the Controller. Generally in the various embodiments described herein, the initial input of information by a Subject may be regarded as being processed to generate an input data request; and the processing of that input request and transmission may be regarded as generating an output data request, which may be generated in one or a variety of forms according to the circumstances. This process of creating an output request from an input request may operate in a variety of manners: for example, it may relate to the substance of the request (such as the example of translation below); in other embodiments, the output request may contain additional information such as information pertaining to verification or processing steps such as verification of subject’s identity.

Data protection law operates internationally and a Subject may be of a different nationality to a Controller and/or may speak a different language. The internet does not operate along such national lines; nor does the GDPR which operates at a European-wide level and even globally. In the conventional request mechanism, the Subject must send written correspondence to data Controllers who may operate in different countries and be staffed by those understanding a different language. This prevents effective communication.

The system allows requests to be structured along common lines regardless of language spoken, it facilitates the automatic translation of a request by computerised means (machine translation). Since both the input request and the output request are handled by the same system, the parameters for the input are known and the use of machine translation does not bear the same risk of loss of information as would occur with normal machine translation of arbitrary data.

For example, a request generated in the Subject’s mother tongue could be translated by the system automatically and delivered to a Controller in a different language. Alternatively when accessing a request from the Client in one language, the Controller may decide to view the request in a different language and the system may enable on-the-fly translation to that effect. Additionally, a Controller may choose to respond to the request in a language different to that of the Subject; yet the Subject may receive that request in their own mother tongue. In certain other examples, the system may translate only certain parts of the request that are intended to be human-readable. Certain others may remain in a common format suitable for all Controllers, including a machine-readable format.

Above it has been described how an output request may be generated by blending information obtained from various sources including for example the input of a Subject with information obtained from other sources such as ID checking information. In this way an output request is generated that is richer than can otherwise be generated by an individual Subject in the ordinary way without use of the system. The information blended into the output request is not limited to identification information but may include information obtained from other places such as translation information; corroborative information such as information about the Subject’s computer system or origin; information about the methods used to generate the request e.g. the fact that two-factor authentication was used by the Subject to log in to the system interface; information about compromised login details (e.g. obtained from third party sources such as the well-known service “Have I Been Pwned”) that may be sourced from a third party system; and any other information that may be complementary to the request itself and enable it to be understood and processed more efficiently.

In addition, the system disclosed here may advantageously blend into an output request information generated from the user’s past use of the same system. For example, if a user has made a previous request or requests and these have been deemed valid (and for example, their identification documents approved) by other Controllers, the output request may contain a statement to inform the Controller receiving the new request that the Subject has been deemed reliable in that way. This may be indicated for example by reference to details of previous requests (whether using full details (e.g. naming the previous controller and indicating a date of the previous request(s)) or partial details (e.g. naming the type of Controller such as“a bank” or“an e-commerce company” and a general indication of the date of the previous request(s))), or by communicating a user‘rating’ or‘feedback score’ (such as a percentage rating) to indicate reliability in a way that does not disclose private information. In a fictional example, an output request may indicate that the Subject who generated the request had made ten requests in the previous year, of which 9 were deemed valid by other controllers; and that the controllers had included trustworthy controllers such as patent attorneys, firms of solicitors, government agencies and financial institutions. This provides an advantage to the Controller because it indicates reliability of the source of the request, reducing the potential for a Controller to disclose information as a result of a fraudulent request. Similarly, once the account has been verified by a particular Controller, that particular Controller may be happy to process further requests from the same Subject without proof of ID required, so long as they are generated via the same system; and this fact could therefore be included on an output request also.

A detailed process of the journey for a Request from the Subject to the Controller will now be described. Preferably, the system has verified the identity of the subject.

The method of sending depends on whether the request is sent to a Participant Controller or a Non-Participant Controller. A Participant Controller will adapt their computer systems to accept requests sent via the messaging protocols of the system in an agreed format such as described below and derive a benefit from doing so, whereas a Non-Participant Controller will not have adapted their systems to accept requests other than by standard communication means as described below.

After it is sent the Subject will be able to view the request in the form of correspondence or details of the progress in a suitable format via the user interface of the system.

The Request journey will first be described for a Non-Participant Controller with reference to Figure 3.

As illustrated above, the Subject 10 may provide information to the system for the request. The type of request wanted and an indication of the Controller are at least required. Preferably, the information is provided over SSL connection over HTTPS to ensure protection for the personal information which will inevitably be uploaded (step 31 ). The system 12 will then identify that the intended recipient is not a participating Controller and will identify an address of the Controller. The system will then transmit the request to the Controller 16 (step 32).

In the case of a Non-Participant Controller, the request may be sent by email or post or any other communication method. Email is preferred to allow for electronic information exchange. Although the email may be encrypted, that is impractical because the request process is adversarial whereas encryption by email usually requires prior agreement or collaboration between the sender and recipient. Decryption of encrypted email may be a technical process that is difficult for a non technical recipient to achieve; since legal personnel in the Controller company are typically recipients, this is rarely practicable. The email may therefore be unencrypted and not secure.

To partially overcome security issues when using email, particularly sensitive information contained in identification documents (if required) may be included as password-protected attachments to the email request or they may be hosted on a secure cloud storage space for download. In either case, information to access the files may be provided by other means.

When using email, the Subject’s Request will be sent to a suitable electronic address of the Controller. An electronic address may be an email address, but could equally be any other designator allowing the Controller to receive electronic communication through any other communication means for example an Internet Protocol (IP) address, a system identifier, a telephone number, a username or some other designator. For illustrative purposes, hereinafter a contact email address at the Controller is used as the example of an electronic address; however references to“email address” hereinafter may equally apply to any other type of electronic address. The request email they receive will appear to be sent from a unique email address associated with the Subject (for example in the form, SUBJECT_NAME@data-requests.com). Alternatively the email address may be unique not just to the Subject but also to the particular request being made, and include a unique reference in the email address (for example in the form, SUBJECT_NAME_REQUESTREFERENCE@data-requests.com). The use of unique email addresses in this way will allow replies to the email to be allocated automatically by the System.

Alternatively the system may integrate with the Subject’s normal email account or email client to allow requests to be sent directly from the email address used by the Subject. In this case, requests sent by email and replies to those requests may be tagged, filed or otherwise allocated automatically to allow them to be identified and handled separately from other email traffic. This may be done by, for example, the use of unique references in the body or header of the email.

The request may be formatted in text as a normal email, but the particular text used will set out the extent and nature of the request generated automatically from the data entered by the Subject in the previous steps. This is an example of an output request being generated from input data. The Subject may preview the generated text and approve it or amend it prior to sending.

As indicated above, a non-participant Controller will receive requests by normal communication methods such as email, post or fax, and may process them in a known way, and need not behave differently for a request generated via the system compared to any other request generated without the use of the system, if they so choose.

Alternatively a non-participant Controller may have specified a format in which it prefers to receive requests in the ordinary course of business. The system may be able to tailor requests for the Controller and provide request information in the Controller’s preferred format (for example, by email attachment) in order to assist the Controller’s ability to Process the request. This is an example of an output request being formatted according to the requirements of a Controller without a Subject having to alter the way they would otherwise create a request using the system.

A non-participant Controller may (upon receiving a request from the system) decide that they derive advantage from becoming a participant Controller and may begin to participate. At that point the any existing and future requests may be treated as if they are participant Controllers.

Even non-participant Controllers may take advantage of many useful aspects of the system. These including the benefits of ID check procedures explained above; timing and event management; and other benefits described herein.

On receipt the Controller may acknowledge receipt via the system, for example by clicking on a unique “acknowledgement” hyperlink. This logs an acknowledgement on the system database and may generate a notification to the Subject. Optionally the Controller may be prompted to fill in further information at the time of acknowledgement such as an estimated time for response and an indication of whether any further information may or may not be required. This allows the Controller to manage the expectations of the Subject and to provide reassurance that the request has not been waylaid in a time- and cost-efficient manner but without appearing to invite unnecessary communications from the Subject (which may be undesirable).

After processing the request in the way of the prior art, the non-participant may respond (step 33). The response may comprise simply a message to the Subject (such as refusing to provide data, or asking for more information) or it may comprise a message with additional data pertaining to the Subject in response to the request. The non-participant may be presented with the option of responding in two ways.

In the illustrated example, the Controller 16 responds by email (step 33). The Controller may respond by replying to the email address from which the request was sent. If a unique email address was used pertaining to the request, responses can automatically be allocated to the relevant record in the database of the system. If data is attached as an attachment, the attachment can be stored in the system’s file store in a secure manner. The fact that a message has been received can be communicated to the Subject as a prompt, a notification message or an email. The system may be adapted to determine the nature of the communication received by reference to the text of the communication to provide the user with a summary of the communication.

Alternatively, the Controller may reply using a web form and SSL to protect the secure data and provide a mechanism to upload a large volume of data. The Controller may respond by replying via a platform provided by the system (such as a secure form provided by the system via a cloud-hosted version of a Controller Client accessible via a unique hyperlink).

By replying via the form the Controller may save time because the form may pre populate relevant information. The Controller may also rely on the information being transmitted in a secure manner, even though the original request was not able to be transmitted in a secure manner.

The Controller may also be provided with a mechanism to download a copy of the response at the time of submission for its records in a useful format, such as PDF.

The Controller may be provided with the option of uploading files containing any data being provided pursuant to a request. The Controller can rely on these being uploaded directly into secure file store and does not pass through any unknown or untrusted servers. The ability to upload a file to a server instead of responding by email may allow for higher volumes of data to be sent compared to the use of email attachments, which may have practical limits on the size of attachments that may be transmitted.

The response platform may prompt the Controller to enter metadata (tagging information) about any files uploaded to indicate to the system what the data in the files pertains to and the relevant format, allowing the system to process the data accordingly if required in later steps.

The response platform may provide additional functionality. For example, it may check the input of a Controller against one or more rules and indicate to the Controller whether responses in this form are likely or unlikely to comply with their legal obligations. For example, in the case where the Controller indicates that identification documents are insufficient, the response platform may in real time check the information provided with the request and provide feedback to the Controller. For example, if the same ID information has previously been deemed adequate by another Controller answering a previous request, this may be indicated to the current Controller with a suggestion to double check the identification requirements.

In either case the system 12, and Messaging Server 24, may send an automatic confirmation email to the Controller confirming that the request has been received together with information pertaining to the response such as a time stamp and, if known, the nature of the response. This is advantageous as it allows the Controller to demonstrate that it has discharged its obligations to respond without relying on unreliable mechanisms such as email receipt-tracking functionality, which may not be implemented consistently on different browsers.

During the time that the Controller 16 is processing the request the system’s Email Server 23 may generate and send reminder emails and prompts for the Controller at predetermined intervals. Alternatively, reminder emails and prompts may be customised by the individual Controller, or set up by the Controller manually; and the appropriate reminders and level of customisation may be different depending on the different type of request being processed by the Controller.

Upon receipt of the response (step 33) from the Controller 16, the system 12 may store the response data in a secure file store (step 34). The system 12 then notifies the Subject 10 that a response is available on the system 1 (step 35). This notification may take place by email so that the data is not sent using this medium. The Subject 10 can then access the Client Dashboard 22 and retrieve the response from the file store (step 36a) for subsequent access using a secure session (step 36b). In this way the data is kept secure and transmitted only using protected communication methods.

The above describes the user journey for a request being sent to a non-participant Controller. A participant Controller is one which is integrated with the system. Alternative examples are proposed depending on the level of integration between the Controller and the system 12.

If the Controller is a Participant Controller, a message may be sent directly within the system using the Messaging Server 24. This provides advantages over the normal way of sending a data privacy request, including the following.

Since the request may itself contain sensitive or even highly sensitive information, the Messaging Server may automatically use encrypted channels of communication. The encryption may be automatic because the system will handle it in a known way, as opposed to the use of an email, which may be handled via diverse clients that cannot guarantee support of encryption even using known systems. This is an advantage over normal communication methods and derives from the fact that the Controller is cooperating with the requesting system chosen to be used by the Subject. This can be used even though the Controller was not expecting to receive any communication from any particular Subject, requiring no prior arrangements but for the fact that the system has been chosen for use of the request.

In this way, by directly encrypting messages between the system and the Controller, the system is able to provide an end-to-end protection for the user data. The data is uploaded using a secure session and forwarded using an encrypted data channel to any number of a multiple of different Controllers. Thus the data is protected from the Subject to the Controller and the use of email is obviated.

Although encryption per se is known, it is not really known in this context (a) because the normal recipient of a request is not a technical person (b) the requests are not cooperative things and (c) there is not usually any agreement about messaging protocols, which is a requirement of secure encryption.

In the conventional methods of transmitting requests to a plurality of unknown parties, it is not possible to provide for such secure transport of data. Additionally, since the request is sent via the Messaging Server to a Controller Client the integrity of the message may be checked in a way that’s unavailable using normal methods, preventing risk of corruption using email or fax for example.

As described above, a Controller Client 25 may be provided to interface between the Controller 16 and the system 12. The Controller Client may be in the form of a web app, native app or other cloud-based solution. The Controller Client may be software installed and managed by the Controller which interfaces with the system or may be a solution managed by the system 12 and accessed directly by the Controller over the internet.

In one example, the request may be sent to the Controller Client 25 by means of a push request— for example, the Messaging Server informs the Controller Client 25 that a request has been submitted and prompts the Controller Client 25 to download the request. Alternatively, the Controller Client 25 can periodically connect to a Messaging Server 24 or system Database 28 or some other suitable aspect of the system to check to see if any requests have been submitted and are waiting to be downloaded. The checks could be done according to an arranged schedule, for example once every 12 hours, or they could be done at unpredictable times, for example a random distribution with an average waiting time of 12 hours between checks. This is especially useful when the Controller Client 25 software is installed on the Controller’s premises because it limits the amount of time that the Controller Client is connected to the internet, reducing potential vulnerability of the Controller Client to malicious access and thereby increasing security.

Also beneficial is that the request may be received to a user interface. The fact that the arrangement has been used enables the user interface to be configurable in how it presents the data request to the Controller. For example,

the interface may present it in legal prose that emulates a request sent in the normal way, which may be familiar for lawyers. Alternatively it may be configured to present the request in bullet points, summary information, or by presenting the information in an order that the Controller considers most important or by highlighting the key points or by highlighting points that are not checked. Certain metadata about the request can be presented in the same place as the request itself to assist in the handling of the request. These and other options are configurable in the user interface.

Such an interface is different to the normal way of presenting request information because normally communications are written from the perspective of the writer. For example, from the perspective of a Subject, as an individual, the most important information is their identity. But for a recipient, it is the relationship and an indication of the types and amount of data stored that is more important. Due to the technical arrangement of the system, the information can be interpreted in a way that pertains to the person receiving it— rather than being fixed in the form of written prose. The request is a live document that can be viewed in a range of ways. The request can be provided in a user interface which is configurable in response to information received from the Controller.

In this way, the technical architecture enables unusual and adaptable display of the data, that is, there a technical advantage over display for aesthetic reasons.

The Controller Client may also provide a user interface to enable other requests to be entered into the Controller Client manually as if they had been generated. Requests sent by Subjects who do not use the system (for example, sent by post or fax) could then be treated for all purposes (or some purposes) as if they had been received via the system. In this way the Controller is able to manage all GDPR requests using a centralised system.

Thus the provision of a Controller Client 25 which has a secure communication channel to the system 12 and in turn to the Subject 10 provides for secure end to end communication between Subject 12 and Controller 10 for both requests and responses. The Client 25 provides an adaptable, secure interface to enable both the interface and Controller to modify the information displayed to a user at the Controller to enable the data processing to be more efficient. For example, the user may be able to download a machine-readable formatted query for use in a subsequent technical search of a database. The client interface is also operable to present different views based on the indicated action.

It has been described that in the case of a Participant Controller, the request will optionally be received to a Controller Client user interface in the manner described above instead of being received via normal communication methods like email or post.

A Controller Client may be installed on the premises of the Controller and within their controlled network architecture. This may enable additional security for the Controller Client, which will be handling sensitive data. It allows the Controller Client to be set up to access the Controller’s information databases directly (or via a database lookup service) in a trusted environment. Allowing the Controller Client to interface with the Controller’s information databases and by setting up the Controller to process the request in part automatically upon receipt means that processing of requests can be handled as a technical matter rather than a legal matter in the ways described below.

When validating and processing a request, the Controller Client used by a Participant Controller may offer all or any of the features of the alternative “response platform” client described in the context of a Non-Participant.

In the following sections the process of a Participant Controller will be described in two stages or‘phases’: first, the validation of a request (the process of checking that a request meets the required criteria and determining whether a Controller will respond) and second, the processing and response to that request (e.g. obtaining the data to be disclosed pursuant to a SAR, checking the data, and responding to the Subject).

The problems that the Controller Client overcomes are diverse. For example, in the ordinary way of processing without the invention of the system, legal personnel may initially spend time checking the legal validity of a request before processing it any further. This can be a time-consuming process that is not readily adapted for technological assistance because rather than being governed by rules of logic or physics for example, it is governed by rules of law.

It may also be that different Controller personnel handle different requests differently depending on the Controller’s relationship with a Subject: for example, the data of a subject who is an employee of the Controller may contain considerably more sensitive data than otherwise, for example including the salary data of the employee and information about any disciplinary procedures.

Further it may be inappropriate for ordinary legal, technical and/or records staff to be given access to such data. But it is impossible to properly direct such requests initially because the Company may not initially know what they know about a Subject, for example because any given Subject may be an employee, a customer, or unrelated to the Controller. A Subject may be more than one of these: for example, an employee who is also a customer. Legal personnel may decide the request is incomplete or inadequate and may request further information to be provided. This may be provided by the Subject after some time and additional delay. Once legal personnel are satisfied that the request is adequate for further processing, they may then provide instructions to the records Controller to obtain copies of any data required. This is inefficient because it requires legal personnel to communicate legal requirements to (administrative) records personnel who may not understand its significance.

At this point, the records administrator may discover that the Controller holds no data about that Subject. Thus, the time of the legal personnel, the records personnel and the Subject have been wasted. Nevertheless, even though time is wasted by this approach the approach of the legal personnel doing the initial verification before passing on information may still be overall the most efficient way that a company or other Controller could implement it, because there is significant overhead in more than one person reading and understanding the request or for one person to communicate with another person about the scope and nature of a request. Therefore, from the perspective of a Controller, even though the time of one or more individual employees may be wasted by the inefficient approach described in the preceding paragraphs, it would be even more inefficient to bring several personnel up to speed about a request only to find that it is legally invalid and may require no response at all.

Verification of identification by humans is a Subjective and not an objective process. Furthermore, ordinarily legal personnel may not be trained at identification verification, which is a specialised process. Therefore the initial validation of identification is error-prone and may require involvement of yet further personnel. The consequences of inadequate identification verification processes is severe because in the case of a fraudulent or malicious request, false-positive identification decisions may result in the disclosure to an unauthorised party of highly sensitive information relating to a Subject.

Finally, the involvement of many human links in a chain of communication is prone to error, particularly where different links in the chain have very different training and understanding and may not all understand the significance and sensitivity of the request. This may therefore result in otherwise avoidable non-compliance due to communication error.

As mentioned, in the first phase the system receives a request, checks the request will be acceptable to the Controller, that is the system or Controller Client validates the request. The participation and use of a Controller Client brings many additional advantages as follows.

In contrast to the problems above, the Controller Client may perform all or part of the function of legal personnel and the records administrator and the technical personnel and the identity validation personnel, all of whom may otherwise be tasked with performing individual elements of the wide range of processes required to respond properly to a request. Therefore, in the process of validating a request this enables a much more efficient workflow and reduces bottlenecks that may otherwise be present in the system.

Additionally, the phases of processing and responding may be blended with the phase of verification of the request. The Controller Client may initially query the Controller’s database(s) to determine the information that has been requested; or part of the information that has been requested; or certain metadata about the information that has been requested (for example, whether it exists, the size of the information, the databases in which it is stored, the date of creation of the information, any labels or‘tags’ attached to the data that might be useful (such as labels or security designations) or any other metadata that the controller may find useful) or all of these; and may present this data (or data about this data) at the time of validation to enable the Controller personnel to make more informed judgments about any future handling or processing of the request.

The initial queries referred to above may be accomplished by automatically querying the database of the Controller. However it may not be advantageous to allow automatic querying of the Controller’s database due to the need for such a database to remain secure. Therefore, a master list may be maintained on the Controller Client that indexes the Controllers’ information database(s). The master list may contain excerpts of the information stored in the database to allow initial checks to be accomplished in the initial stages of verification described above, without the whole database needing to be copied. The master list may contain extracts of lower-sensitivity information (e.g. customer names) and not higher- sensitivity information (e.g. customer financial details), particularly since it is the information of lower sensitivity that may be most useful in performing initial validity checks. The information in the master list may be stored in the same format as the information in the database(s) from which it is obtained; or it may be stored in an encrypted or hashed format; validity checks may then be formed by creating hashes of information in the request and comparing hashes, maintaining the security of the information in the master list. The master list may be updated at regular intervals and a‘valid as of date may be stored against the list (to ensure that initial validity checks do not return false information merely due to the master list being out of date). The use of a master list in this way maximises efficiency and effects the principle of ‘privacy by design’ as it minimises the need to query database(s) that store sensitive information; only the system is able to read it; there is no direct access from external systems; and the master list may itself be hashed or encrypted. Additionally, the Controller Client may initially query the Controller’s database(s) to determine the relationship of the Subject to the Controller (for example, employee/former employee/customer/litigant/no relationship) in order to determine which Controller staff would be best to handle the remainder of the request, avoiding the potential for sensitive data to be exposed to inappropriate personnel.

It is also proposed herein to provide a Controller Database Integration Subsystem (“CDIS”). The CDIS is a bespoke interface which securely communicates with the system and also securely interfaces with the databases of the Controller. The CDIS may translate instructions received from the system 12 into a database query to automatically and responses with a database at the Controller side.

As illustrated above there are many reasons that a request could require no or only a very short response. For example, it may not be legally compliant, it may contain inadequate identification information, it may contain insufficient information, or it may be that the information about a subject is of the type that need not be disclosed, or it may merely be that the Controller holds no data about the Subject concerned. Although each of these examples demonstrates a trivial reason for a request to fail, it may be necessary to check all of them before deciding how to respond to a request; or the order of checking that makes efficient sense for staff may not disclose one of these trivial reasons until all of the have been checked. Since each of these examples is handled by a different person at a different time of the process it therefore requires the time of several people to check even these trivial examples. Further, even an attempt to efficiently organise a system of human checks among such a team that ranks the‘most common’ reasons for failure and checks these in order is doomed to fail, due to the overhead of personnel time required for each person to get up to speed with the detail of a request (described above).

On the other hand, the Controller Client may check all of these points and any other suitable questions automatically - before the request is even viewed by a single person at the organisation. This enables the Controller Client’s user interface to display not just the request to the Controller personnel, but also to flag up, from the very moment it is first read, any non-compliance issues, allowing a speedy decision to be made without further human analysis being required.

The Controller Client may additionally take advantage of the ability to test technical, legal, records and identification matters at the same time to make automated decisions. Advantageously, given this initial information it may be possible for the Controller Client to make or propose decisions even without accessing the sensitive data stored in the Controller’s information store or databases. This increases security by limiting access to such a database only to circumstances where it is absolutely necessary. Similarly, the system may make partial checks of the Controller’s database(s) to ascertain certain information items pertaining to the request without querying all databases.

The system may also automate some processes that would otherwise be carried out by humans in the same manner. For example, the Controller Client may propose all or part of a suitable response to the request rather than requiring a human to write a response.

With the above automation there is a real difference in the processing efficiency that this system enables that is not otherwise available, as opposed to simply automating processes.

The Controller Client may therefore pre-validate Subject ID, types of information being requested, types of information likely to be disclosed, the relationship of the Subject to the Controller, and any other aspect of the Request that may lead to increased efficiency in processing, at the time of receipt and before the request is even viewed by a human.

That is, the system may for example automatically reject a request where the Controller does not hold valid data for the Subject. Where the request is for deletion for example, the Controller database may mark the data as being held for the purposes of completion of a contract and therefore being validly held by the Controller such that deletion is not appropriate. The system may automatically detect such a flag and return a negative response without the input of a human in the decision making process, thereby improving efficiency. This may further be detected at an early stage during processing, removing entirely the need for some processing stages (e.g. legal validation) that would ordinarily be carried out before initial checks, thereby removing work that would ordinarily be required.

The Controller Client may also supplement the normal ability of a human to check data by interfacing with other third-party databases in a way that a human may not be able to do. For example, known databases exist that may be queried to ascertain whether user information associated with a particular email address has been disclosed by reason of past data security breaches (such as the service known as Have I Been Pwned). The Controller Client software (or some other aspect of the system at any other time in the process) may interface with such a database to determine whether the information provided to identify the Subject in the Request is public by reason of such an unauthorised disclosure, in which case it may notify this to the Controller (and/or to the Subject). In such a case it may be prudent for the Controller to distrust the authenticity of the information and to request further authentication information from the Subject. If any password information is included with the request or used as part of the request, it may be prudent for the system to check that the password does not match any passwords publicly disclosed for that Subject as a result of any data breach. A system can make such a check securely without any human becoming aware of the sensitive data that comprises a password, in a way that a human cannot. Other databases may be employed in a similar manner to provide disparate information automatically that would not normally be available but which may increase efficiency or enable better or more precise validation or processing by the Controller.

Since the Subject Client and the Controller Client software are both parts of the same system, they may advantageously interface with each other to allow the Subject to receive information about and/or monitor the progress of the validation and/or processing of the request by the Controller. This sort of information may include for example, confirmation that the Controller has received and is dealing with the request; has taken the step of validating identity; or has taken the step of checking the Controller’s databases. This is mutually advantageous to the parties during the time limit for processing the request (which may be several weeks). For the Subject, it provides confirmation that progress is being made with the request, which may otherwise be invisible to the Subject who may otherwise be unaware of the number of steps and complexity behind such a request. For the Controller, it provides an efficient way of communicating with a Subject personally but without requiring any personnel resources. Similar functionality could be provided to a lesser extent for a Non-Participant Controller via a response interface.

Based on the pre-validation, the Controller Client software may make a decision as to whether the request is valid and should be responded to by the disclosure of data. Decisions may be‘hard’ (binary choices) or‘soft’ (likelihoods based on assessing weighted factors). Such a decision could be presented to the Controller personnel to assist with decision making during the validation and processing phases. If a decision is taken that the request is valid (or likely valid) the Controller Client software may automatically proceed to the processing phase of the request such that at the time of first viewing the request the Controller personnel may efficiently review as much information at once as is likely to be pertinent rather than requiring to review the information in multiple stages.

If the request is deemed invalid the Controller may respond using the Messaging Server to notify the Subject that the request is being refused or that further information is required. This may be handled by any input method (for example the use of a simple-to-use multiple-choice form directly within the Controller Client) which may then be sent to the system Database and trigger suitable actions to the Subject Client.

As described above, the process of request/response is split into two for the purposes of this description. The following describes the second stage of the participant Controller processing data and responding to the request.

Once the Request has been deemed valid, the Controller will process the data requested in the request and provide the data to the subject in a response. The CDIS allows the Controller Client to interface with the database of the Controller to enable this. Information pertaining to one subject may exist in more than one database owned or controlled by the Controller. The CDIS may interface with all relevant databases to enable requests to be processed by one entity. The CDIS and Controller Client together may gather all relevant data required to be disclosed into one place and enable it to be viewed and considered at the same time as a candidate data set for disclosure to the Subject.

The Controller Client may cross-check to ensure that all data collected in this way is consistent (i.e. relevant data items all match each other). If they do not, inconsistencies may be flagged to enable checking prior to data being sent. An example of an inconsistency could include two email addresses or dates of birth being associated with the candidate data set. It may be that such inconsistencies could stem from database errors in the Controller’s databases, which would normally be difficult or impossible for a Controller’s personnel to notice when responding to a request, especially if the candidate data set is large or if formats of the data obtained from the different databases differ so as to prevent easy comparison, as may often be the case. However, failure to notice such inconsistencies could lead to the data of a second subject being disclosed to the subject making the request— which could itself be a breach of data protection regulation. The system allows such inadvertent breaches to be avoided.

If candidate data is obtained by the CDIS in disparate formats to create one candidate data set, the CDIS or Controller Client (or other aspect of the system) may convert all the data, or some of the data, into one format to provide ease of access to the Subject.

If candidate data is obtained by the CDIS in a format that is not widely recognisable or readable by members of the public, the CIDS/Controller Client (or other aspect of the system) may convert it into a more useful or commonly readable format before delivery to the Subject, facilitating understanding by the Subject and/or understanding by the Controller personnel reviewing the data. It is a requirement of the law that data be readily intelligible, including that codes, jargon and/or abbreviations that may mask meaning are avoided. However, such codes, jargon and/or abbreviations may commonly be employed in data sets originally compiled for internal use only. While it would be necessary to“interpret” such terms to enable Subject understanding, data is likely to be reviewed by legal personnel of the Controller and it may be difficult or impossible for the legal personnel of the Controller to interpret the code, jargon and/or abbreviation if that is known only to technical personnel. The interpretation task could therefore be impossible to achieve efficiently, particularly in a large data set with disparate data items. The system could therefore be adapted to automatically interpret such code, jargon and/or abbreviations to enable Subject understanding, enabling the legal personnel to check the rules pertaining to the interpretation rather than the interpreted data itself. Such interpretation may be handled in the Controller Client, the CDIS, or (after data is transmitted) in other parts of the system, removing from the Controller’s responsibility an otherwise onerous task. In addition, the rules pertaining to the interpretation function could be updated from time to time, customised, and could also‘learn’ from new data order to improve its ability to interpret future data.

A candidate data set may contain information that ought not to be disclosed, such as confidential information enabling the identification of third parties or information that the Controller desires to keep secret. The system may be adapted to detect such confidential information automatically and to flag up to the human reviewer where it exists. It may recommend automatic redactions to the candidate data set to preserve confidentiality. Such an approach is desirable as it may not be apparent to Controller personnel reviewing the candidate data set precisely which aspects of the data are confidential, leading to required redactions being missed. It also eliminates or dramatically reduces the opportunity for human error arising in other ways. This is particularly desirable in the context of confidential information, because once disclosed (even if such disclosure was accidental) it may be difficult or impossible to undo such disclosure and preserve confidentiality.

The various aspects of processing in this manner have the additional advantage that fewer personnel are exposed to or view sensitive data of a Subject, narrowing the pool of personnel to whom sensitive data are disclosed within the Controller’s organisation and increasing privacy for the Subject concerned.

Figure 4 illustrates an implementation of this latter process from end to end. The process enables a Subject to interrogate a Controller database automatically without exposing the data to malicious third parties, humans or other third parties where the data can be exposed. The data is protected throughout its journey.

The user first raises a request using the Subject Client interface with the system 12. The system 12 then pre-validates the request using and updates a service dashboard to reflect the request. The request is then passed to the Controller Client dashboard. The request is optionally hosted on premise or in the cloud depending on user preference. The Controller Client optionally returns a message that the request has been accepted. The Controller Client then securely passes the request to the CDIS which in turn queries the target database.

The Figure illustrates the query using the notation SVC. SVC represents the ServiceHost instance hosted by Internet Information Services from Microsoft and is an example of how the database query may be effected and would be understood by the skilled person.

Once the target data is retrieved from the database it is returned along the same path to the system 12. An ingestion application programming interface (api) intercepts the data retrieved from the Controller Client and formats the data set received for integration into the system 12 and subsequent view by the Subject. The data is stored in a secure file repository by the ingestion api and a notification sent to the Subject that the data is available for view.

In this way, the data is not made publically available and the Subject is able to efficiently identify the data which is held by the Controller relevant to him without exposure of the data to third parties.

Figure 5 illustrates an aspect of the system in which events may be managed by the system. At the time of transmission, the system may log the date and time of sending a request and may keep track of timely progress of the request. It may identify key times at which events might be expected to occur, for example: the deadline for the Controller to respond to the request; suitable times for reminders to be sent; and prompts for any other actions that are appropriate. These may be set up by the system to generate reminders for the Subject or for the Controller. The suitable times may depend on the type of request being sent. Alternatively these may be customised by the Subject or set up manually by the Subject, for example by interaction with the Subject Client.

They may also be set up in the form of digital calendar appointments for the Subject or for the Controller to allow the parties to keep track of the progress of the request and to encourage and facilitate compliance with the law for the mutual benefit of both parties. It is not therefore necessary for the Subject or the Controller to have knowledge of deadlines set by the law as these will be managed for them.

In the case of a participant Controller, the event management may be integrated with their own systems in a preferred way. In the case of a non-participant Controller, relevant deadlines may appended to the request email, for example as calendar appointments attached in known formats such as i-cal or Microsoft Outlook formats.

The Controller may additionally set a delay timer, to allow requests to be Processed in advance of the Controller’s deadline for fulfilling them but withheld from being completed (i.e. data is not sent back to the Subject) until close to the deadline for doing so. This may allow the Controller an extra level of security and control of their response to a request and an opportunity to alter or review the data to be sent back before it has been sent out from the Controller.

Turning to Figure 5, a process flow is shown in which the system may monitor timings and take action based on those timings. The process may take place at the system 12 or the Controller Client. At step 50 the request is received. At step 51 a notification is generated to the Controller business. A timer is then started (step 52).

If the request is accepted (step 53), the process of data extraction takes place (step 55). If the request is not accepted, a reason is supplied (step 54a) and the user is notified automatically (step 54b).

If no reply is received and the timer expires (step 56), a reminder may be sent to the Controller (step 56a) and the timer continued or restarted. If timeout is reached the system consults its default action (step 57). If the default is set to deny the request a non-compliance warning is sent (step 58). If the default is set to accept then using the automatic data extraction method described above, the system may extract a data set from the Controller database and make it accessible to the Subject (step 59).

Accordingly, the system described herein is operable to enforce compliance with the regulations and provide efficiencies at the Controller site.

If the Controller refuses to provide data in response to a request or is unable to do so until further information is presented by the Subject, the response from the Controller will be logged and notified to the Subject in an appropriate form.

Alternatively, the Controller may indicate that it has no data to disclose for example because it knows no data about the Subject other than that which was included in the Request, or the Subject is entirely unknown to the Controller.

In the case that remedial action is possible to enable the request to be processed / validated further, the Subject Client may provide suggestions as to the remedial action to be taken and/or prepopulate a suitable response for the Subject.

In such a case, timers and event management data will be reset to begin again at a suitable time such as when the remedial action is taken.

If the system cannot identify any remedial action to be taken or the conduct of a Controller seems to be non-compliant with the law, the system may suggest to the Subject to contact a regulating body for advice. In such a case the system may detect the location of the Subject and provide contact details pertaining to the Subject’s local relevant regulating body. The system may also provide a full print out set of information pertaining to the request in a format that allows the local regulating body to easily ascertain the steps taken.

In some cases, a Controller may identify a positive reason that a request ought not to be fulfilled or even processed; for example, they may suspect identity theft. This would be a significant problem for example in the case where an imposter, posing as a Subject, knows enough information to substantiate a subject access request but no more information. Such an Impostor may for example increase the amount of information they (unlawfully) known about a Subject by making a subject access request and benefitting from the additional information received in response. Therefore the use of requests by unauthorised persons is a severe security concern. In some cases, a Controller (for example a bank) may receive a request substantiated with data that it knows to be false or stolen (for example, because the Subject is a customer of the bank and has reported such information stolen). In the case that a Controller distrusts or suspects the identity of a Subject, the Controller may notify the System of this. The System may then take appropriate action including for example limiting the relevant Subject (or as it may be, the impostor) from making any further requests; restricting access to data provided in response to previous requests; and taking further steps to authenticate the user to discover whether or not they are the Subject. The system may also take appropriate actions in respect of any other requests previously made by the same user, for example reviewing any earlier requests that have been made and either cancelling them; or preventing (withholding) access to any subject data that is or will be or has been sent back by a Controller in response; and/or contacting each of the Controllers to whom that user of the system has sent requests and notifying them of the potential of fraudulent activity. Other or different steps to ensure the security of data and authenticity of the subject’s user account may be appropriate.

In the case of a refusal of a request (for example, a deletion request) for reasons that are due to timing (for example, deletion is refused because a Controller requires to process the relevant data for a particular time period), the system may in response to that automatically generate or prompt reminders or calendar appointments for the Subject to receive once the time limit has expired. The system may additionally be configured to generate requests automatically (for example, to repeat a refused request at an appropriate time automatically). This would enable the Subject to have better control of their data. Similar scheduling and reminder systems could apply to any type of request, for example instead of deletion the requests may pertain to altered marketing permissions.

The process of submitting a request, processing a request and returning a response (optionally automated) was described above. The following describes the way in which the data may be presented to the Subject to enable the Subject to securely identify the data held by the Controller relevant to them.

Upon receiving data in response to a request, the data may be saved in the database (for information pertaining to the request) and the file store (for storing the data received). This may be encrypted such that only the Subject to whom the data pertains may view it. The system itself may also be granted access, and any other authorised users who have been given authorisation by the Subject.

The system may have access to other data sets provided in response to previous requests of the same Subject. In such a case, the system may cross-check to ensure that all data collected in response to the request in question is consistent (i.e. relevant data items all match each other) or at least not inconsistent with previous request data. If they do not match, inconsistencies may be flagged to enable checking prior to data being sent. An example of an inconsistency could include two email addresses or dates of birth being associated with the candidate data set. It may be that such inconsistencies could stem from database errors in a Controller’s database. Such inconsistencies may however point to fraudulent activity on the account of that Subject (or by an impostor) and appropriate steps could be taken to ensure security of that data and/or a user’s account, which may include withholding the data or other steps described above, or other actions that may be obviously appropriate in light of the knowledge. The system provides a further safety net to prevent unauthorised distribution of data to impostor accounts or in response to fraudulent requests by reason of it providing a central repository for all data to be stored, which would not ordinarily occur in the normal course of things. The system may also be able to identify disparities between information returned by different Controllers in response to different requests about the same Subject, and highlight this to the Subject. It may further be configured to generate automatically a rectification requests to require Controllers to amend and update their information.

If the Subject agrees and/or requests, the system may be adapted to interpret the data and display it via the Subject Client using a dashboard or other data visualisation display (Client Dashboard). Such Client Dashboard would not be in the control of the Controller and could be customised or implemented elsewhere in the system for example at the side of the client. The Client Dashboard may use any method of visualising data that is appropriate to the data concerned in a way that makes it more readily interpretable by the Subject. This is enabled due to the architecture and technical approach of the system, because the system has obtained the data pursuant to a cooperative, structured request and because all or some of the processes described above have been carried out. In an ordinary request, such data visualisation would not be possible in this way.

As mentioned at the outset of this description, a Subject Access Request is not the only type of request the system may report but is used simply to illustrate the principles of the invention. Other requests may include data erasure requests (requiring data to be erased from a Controller’s system); requests for data to be rectified; and requests to identify what types or categories of data are held by a Controller. The architecture of the system can be adapted to facilitate such requests.

For example, in certain embodiments the deletion of data could be carried out in place of the sending of data to the Subject.

Additionally, if a Subject wanted to make a data rectification request for a discrete point (for example, because their address, name or marital status had changed) using the system described herein means that such a request could easily be generated and sent in a legally-compliant format to all relevant companies. The system could allow the Subject to choose which Controllers receive such a request; alternatively the system could determine which Controllers would be appropriate based on an analysis of the Subject’s history of making requests; or the Subject’s own computer system (for example, by inspection of browser bookmarks, email account data, or similar known methods).

Further the rectification of data could be effected automatically by the system upon a mere review of the relevant request.

If a subject access request as described above is carried out in respect of information, the data set transferred could be retained on the Controller Client and ‘tagged’ such that if a future data erasure request is made by the same subject, the erasure request can be effected instantly without the duplication of effort of Controller personnel and requiring only a very quick review, since the initial data set will already have been processed and reviewed exhaustively.

The GDPR also provides a right of portability, being the right for data to be transferred between different service providers in a machine-readable format. To support such a right the system may be adapted to facilitate the transfer of data received pursuant to a subject access request or portability request to a new service provider in a way that enables the new service provider to bring the user on board as a customer of their service. Because the system is set up in a way that facilitates the exchange of machine-readable data (such as by use of common formats and using other aspects of the invention described above) the right of portability is more efficiently effected.

To illustrate the ideas described herein more completely, Figure 6 illustrates a user journey as seen from the perspective of a consumer interacting with a Controller business.

The user will first register or login to the system (step 60). The user will then undergo a process of preparing the submission (step 61 ). This will include selecting a target (step 61 a), submitting the identification and information required by that target (step 61 b), selecting the data categories required (step 61 c) and identifying anything non-standard they wish to request (step 61 d). The request is then submitted to the system and passed to the Controller if it passes validation checks. A configurable delay (step 63a) then takes place before the Subject is offered Business Interaction (step 63b) for example, they may enquire whether the data is sufficient or complete. The data is subsequently extracted by the Controller (step 64a) and stored by the system into an accessible database (step 64b). The Subject is then notified (step 65). After receiving the notification, the Subject will login (step 66) and access their dashboard (step 67) where the data can be securely retrieved and is formatted to enable efficient retrieval and viewing.

Should the business refuse the request (step 68a) then the user is notified with a reason for the refusal (step 68b). If the reason is not remediable (step 68c) then the process ends (step 68d). If the reason is remediable (step 68c) and the user provides a remedy such as providing identity documents (step 68e) then the request is resubmitted and processed (step 68f).

It will be clear that the above scenarios are merely exemplary and used to demonstrate certain aspects of the overall system and examples of how the present invention may be implemented in practice.

While the present invention has been described in the context of certain servers or networks, it will be understood that the principles described may be implemented through any arrangement of suitable computing devices, distributed computing devices, or media not yet known. The principles are not limited to any specific operating system or architecture and indeed are designed to be system or platform agnostic. The device described as a user device above may be any sort of suitable device such as a personal computer, tablet computer or smartphone.

It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of a particular type of signal bearing media actually used to carry out distribution. Example of computer readable media include recordable-type media such as floppy discs, a hard disc drive, RAM, CD-ROMs and DVDs as well as transmission-type media such as digital and analogue communication links.

Claims

1. A method for electronically processing data protection requests between a subject and a data controller, the method comprising:

receiving an input electronic data protection request intended for a data controller from a subject over a network;

retrieving an electronic address of the data controller and a type of the data controller;

validating the request against a plurality of stored rules; and,

only if the request satisfies the stored rules, creating an output electronic request in a specific format depending on the type of data controller; and, forwarding the output request to the data controller by:

sending information relating to the output request to the electronic address of the data controller; and,

sending the output request to the data controller using protected data communication.

2. A method according to claim 1 , further comprising:

retrieving a unique identifier of the subject;

querying a selected identity verification service using the unique identifier, the service selected in dependence on the type of data controller; and,

forwarding the output request only if the identity verification service returns a successful indicator.

3. A method according to claim 2, in which the identity verification service is selected from a group comprising: 3D-Secure; OAuth; and, a two-factor authentication service.

4. A method according to any preceding claim, further comprising:

receiving an electronic copy of a personal identification document from the subject;

securely storing the electronic copy; and, sending an indication of the personal identification document with the output request based on the type of data controller and a type of the output request.

5. A method according to any preceding claim, in which the step of creating an output electronic data protection request further comprises performing a machine-translation on the input request to translate the input request into a different language.

6. A method according to any preceding claim, in which the information relating to the output request is a hyperlink to a secure data repository from where the output request can be retrieved by the data controller.

7. A method according to any preceding claim, further comprising:

receiving a response to the output request from the data controller; and, sending confirmation of receipt to the data controller including a time stamp.

8. A method according to any preceding claim, in which the protected data communication is a Secure Sockets Layer session.

9. A method according to any preceding claim, in which the output request is hashed using a cryptographic hash function prior to sending.

10. A method according to any preceding claim, in which the protected data communication is an encrypted communication channel.

1 1 . A method according to any preceding claim, in which forwarding the output request further comprises sending the output request to a plurality of electronic addresses of the data controller.

12. A method according to any preceding claim, in which creating or forwarding the output request further comprises aggregating multiple data protection requests.

13. A method according to any preceding claim, in which the step of creating further comprises modifying content of the input or output request based on instructions received from the data controller.

14. A method according to any preceding claim, in which the step of sending the output request comprises providing access to the output request using a secure web interface, the interface being configurable to display the request in a plurality of different formats based on instructions received from the Controller.

15. A method according to any preceding claim, in which the step of creating further comprises creating the output request in a specific format based on comparing the input request against a series of stored criteria representing rules for legal and technical compliance of the input request.

16. A method according to any preceding claim, further comprising:

receiving a reply from the data controller in response to the output request, storing the reply in a secure data repository; and,

sending secure access information for the repository to the subject.

17. A method according to claim 16, in which the reply is received using the protected data communication.

18. A method according to claim 16 or 17, further comprising:

comparing the received reply against a previously stored reply to identify any inconsistency.

19. A method according to any of claims 16 to 18, further comprising;

applying a tag to the received data to enable future identification of the same data by the data controller.

20. A method according to any preceding claim, in which the step of validating the request against a plurality of stored rules further comprises selecting a predetermined response from a set of responses based on the outcome of the validation.

21 . A method according to any preceding claim, further comprising:

retrieving an identifier of the Subject; and,

checking the identifier against a third-party database to identify if the request is potentially malicious or fraudulent.

22. A method according to any preceding claim, in which:

the output request includes at least one database query.

23. A method according to claim 22, further comprising

executing the database query on a database of the Controller;

receiving a dataset from the database;

formatting the dataset; and,

storing the formatted dataset in a secure data repository accessible to the Subject.

24. A method according to claim 22 or 23, further comprising:

checking a part of the query against the database to predict an expected result; and,

forwarding the expected result.

25. A method according to any preceding claim, further comprising:

comparing a part of the output request against an extract of a database to predict an expected result.

26. A method according to any preceding claim, further comprising:

comparing the output request against a plurality of rules and, based on the comparison, predicting a response.

27. A method for electronically processing data protection requests between a subject and a plurality of data controllers, the method comprising: receiving an input electronic data protection request intended for a plurality of data controllers from a subject over a network;

retrieving an electronic address of each of the data controllers and a type of each of the data controllers;

validating the request against a plurality of stored rules for each data controller; and,

only if the request satisfies the stored rules for each of the data controllers, creating an output electronic request for each data controller in a specific format depending on the type the relevant data controllers; and, forwarding each output request to the relevant data controllers respectively by:

sending information relating to the output request to the address of each data controller; and,

sending the output request to each data controller using protected data communication.

28. A computer readable medium comprising instructions which when executed by a computer cause the computer to perform the method of any of claims 1 to 27.

29. A system for electronically processing data protection requests between a subject and a data controller, the system comprising:

a Subject Client configured to receive an input electronic data protection request intended for a data controller from a subject over a network;

a processing module configured to:

retrieve an electronic address of the data controller and a type of the data controller;

validate the request against a plurality of stored rules; and, only if the request satisfies the stored rules, create an output electronic request in a specific format depending on the type of data controller; and, forward the output request to the data controller by:

30. A system according to claim 29, in which the Subject Client is further configured to retrieve a unique identifier of the subject and forward the unique identifier to the processing module, wherein the processing module is configured to:

query a selected identity verification service using the unique identifier, the service selected in dependence on the type of data controller; and,

forward the output request only if the identity verification service returns a successful indicator.

31 . A system according to claim 30, in which the identity verification service is selected from a group comprising: 3D-Secure; OAuth; and, a two-factor authentication service.

32. A system according to any of claims 29 to 31 in which the Subject Client is further configured to receive an electronic copy of a personal identification document from the subject and securely forward the copy to the processing module, wherein the processing module is configured to:

secure storing the electronic copy; and,

send an indication of the personal identification document with the output request based on the type of data controller and a type of the output request.

33. A system according to any of claims 29 to 32, in which the processing module is further configured to perform machine-translation on the input request to translate the input request into a different language.

34. A system according to any of claims 29 to 33, in which the information relating to the output request is a hyperlink to a secure data repository from where the output request can be retrieved by the data controller.

35. A system according to any of claims 29 to 34, in which the processing module is further configured to:

receive a response to the output request from the data controller; and, send confirmation of receipt to the data controller including a time stamp.

36. A system according to any of claims 29 to 35, in which the protected data communication is a Secure Sockets Layer session.

37. A system according to any of claims 29 to 36, in which the processing module is configured to hash the output request using a cryptographic hash function prior to sending.

38. A system according to any of claims 29 to 37, in which the protected data communication is an encrypted communication channel.

39. A system according to any of claims 29 to 38, in which the processing module is further configured to send the output request to a plurality of electronic addresses of the data controller.

40. A system according to any of claims 29 to 39, in which the processing module is further configured to aggregate multiple data protection requests prior to sending.

41 . A system according to any of claims 29 to 40, in which the processing module is further configured to modify content of the input request based on instructions received from the data controller.

42. A system according to any of claims 29 to 41 , in which the system further comprises a Controller Client, wherein the Controller Client is configured to provide access to the output request using a secure web interface, the interface configurable to display the request in a plurality of different formats based on instructions received from the Controller.

43. A system according to any of claims 29 to 42, wherein the processing module is configured to create the output request in a specific format based on comparing the input request against a series of stored criteria representing rules for legal and technical compliance of the input request.

44. A system according to any of claims 29 to 43, in which the processing module is configured to:

receive a reply from the data controller in response to the output request, store the reply in a secure data repository; and,

send secure access information for the repository to the subject.

45. A system according to claim 44, in which the reply is received using the protected data communication.

46. A system according to claim 44 or 45, in which the processing module is further configured to compare the received reply against a previously stored reply to identify any inconsistencies.

47. A system according to any of claims 44 to 46, in which the processing module is further configured to apply a tag to the received data.

48. A system according to any of claims 29 to 47, in which the processing module is further configured to validate the request against a plurality of stored rules and select a predetermined response from a set of responses based on the outcome of the validation.

49. A system according to any of claims 29 to 48, in which the Subject Client is further configured to retrieve an identifier of the Subject and forward the identifier to the processing module, wherein the processing module is configured to check the identifier against a third-party database to identify if the identifier is potentially malicious or fraudulent.

50. A system according to any of claims 29 to 49, in which:

the output request includes at least one database query.

51 . A system according to claim 50, further comprising a Controller Database Integration System, configured to:

execute the database query on a database of the Controller;

receive a dataset from the database; format the dataset; and,

forward to the formatted dataset to the processing module for storage in a secure data repository accessible to the Subject.

52. A system according to claim 50 or 51 , in which the Controller Database Integration System or processing module is configured to:

check a part of the query against the database to predict an expected result; and,

forward the expected result.

53. A system according to any of claims 29 to 52, in which the processing module is configured to compare a part of the output request against an extract of a database to predict an expected result.

54. A system according to any of claims 29 to 53, in which the processing module is configured to compare the output request against a plurality of rules and, based on the comparison, predicting a response.