information.tex

\chapter{Analysing GDPR Compliance Requirements}
\label{chapter:information}

The analysis of state of the art in \autoref{chapter:sota} provided identification of opportunities for addressing the gaps within it.
These opportunities relate to research objective $RO3$ regarding construction of ontologies, $RO4$ for querying, and $RO5$ for information validation.
In order to achieve these, it is imperative to have an understanding of GDPR and its compliance requirements as required by research objective $RO1$.
The requirement gathering process is shaped by the scope of research question - which for this thesis is representation of activities associated with processing of personal data and consent.
The identified requirements then need to be expressed in a form which will facilitate representation of information as ontologies, its querying, and validation in compliance process. This is required to fulfil research objective $RO2$.

The approaches presented in SotA in \autoref{chapter:sota} directly delve into obligations and requirements of data controllers to demonstrate compliance or towards data subject's consent and rights.
Since requirements of GDPR compliance are also influenced by other stakeholders such as processors and authorities which play an unspecified role in the context of information associated with compliance, such roles consist of interactions between stakeholders and involve communication of information such as instructions provided by a data controller to a processor.
Therefore, along with requirements of compliance, it is also important to understand interactions between stakeholders, information involved in such interactions, and requirements of information in terms of its interoperability between them.

As an example, consider a data controller that can have any number of internal representations of information necessary to demonstrate compliance, but an investigation by a supervisory body requires such information to be provided as per their stated requirements in an mutually understandable form. Furthermore, a processor contracted by a controller may also be required to present information relevant in investigation of compliance - which would also need to be mutually understandable by the processor, controller, and investigating authority.
When utilising technological solutions for management of compliance information, analysis of information interoperability requirements enable identifying applications of such solutions within a larger context comprised of multiple stakeholders involved in the compliance process.

This chapter therefore first presents an analysis of GDPR in terms of stakeholders and interoperability of information between them to construct a model of information interoperability in \autoref{sec:info:model}.
The model provides an analysis of requirements in terms of information and interoperability from the perspective of interactions between entities.
This provides an overview of information requirements which is used to find additional applications for existing information representation approaches and to identify gaps which can be addressed through future opportunities.
Such analyses and requirements gathering related to GDPR also benefit the larger community and domain by providing information for standardisation activities in understanding role of information and its interoperability between stakeholders, such as those for DPVCG (see \autoref{sec:intro:dpvcg}).

Following the above, \autoref{sec:info:compliance-questions} frames `compliance questions' that provide information requirements necessary to evaluate compliance, with its methodology presented in \autoref{sec:info:compliance-questions-methodology}, and \autoref{sec:info:constraints} presenting assumptions and constraints that can be used to validate information for correctness and completeness.
The use of compliance questions as competency questions in development and evaluation of ontologies is presented in \autoref{chapter:vocabularies}, and  use of constraints for validations is presented in \autoref{chapter:testing}.

\section{Interoperability Model of Information based on GDPR}\label{sec:info:model}
This section presents a model of interoperability for information associated with stakeholders based on an analysis of GDPR in terms of interactions between stakeholders and information involved in such interactions. The model enables understanding role of stakeholders in compliance process in terms of information requirements and provides a framework to establish relationship between interactions and information required for compliance. 
The model also provides motivation to incorporate interoperability as a core requirement within representations of information towards GDPR compliance.
This provides context for development of ontologies presented in this thesis in terms of their intended application and usefulness to stakeholders associated with GDPR compliance.

The model serves to place contributions presented in this thesis within the larger context of stakeholders involved in GDPR compliance process. It guides the design and impact of ontologies presented in \autoref{chapter:vocabularies} in terms of establishing interoperability as a requirement based on potential exchange of information between stakeholders. Additionally, it also provides context about the roles and activities of stakeholders regarding information management and documentation for GDPR compliance.

The work described in this section was published within the interoperability and standardisation community as a conference paper
\cite{pandit_gdpr_2018} which was later expanded upon in a journal article \cite{pandit_exploration_2018} and a book chapter \cite{pandit_standardisation_2020}.

\subsection*{Interoperability Model}
The creation of a model is based on identifying categories of entities as defined within GDPR and identifying interactions between them.
\autoref{fig:info:interoperability-model} visualises interactions between entities, and consists of Data Subject (DS), Data Controller (DC), Data Processor (DP) and Supervisory Authority\footnote{Supervisory Authority are also referred to as Data Protection Commission or Regulatory Body} (SA) as entities defined within GDPR.
The points of interactions consist of potential information exchange between entities and are guided by requirements of compliance. For example, interaction between data subject and data controller consists of data subject providing personal data to controller, while the controller is required to provide a copy of provided personal data for fulfilment of rights granted by GDPR.
\begin{figure}[htbp]
    \centering
    \includegraphics[width=0.75\linewidth]{img/interoperability-model.png}
    \caption{Interactions between entities based on requirements of GDPR \cite{pandit_exploration_2018}}
    \label{fig:info:interoperability-model}
\end{figure}

The model and information categories serve to provide a larger context of information requirements of GDPR and demonstrate areas for application of contributions presented in this thesis. They also provide future development and application of presented work to other areas of GDPR compliance. More specifically, they provide opportunities where developed work can be extended or re-applied to represent additional information regarding activities associated with GDPR compliance - such as for data breach records, carrying out rights, recording compliance procedures, or data processing agreements.

\subsection*{Information Categories}
The analyses of information flows between entities (additional description presented in publications \cite{pandit_exploration_2018,pandit_gdpr_2018}) provides categorises of information requirements as: provenance records, consent information, data processing agreements, compliance information, and seals/certifications - of which provenance records and consent have a direct bearing on the stated research objectives.
Carrying out further investigation and analyses of interactions and information involved is out of scope for research presented in this thesis given the focus of research question on information about activities associated with processing of personal data and consent.
To this end, analyses of information categories presented below concerns only categories of provenance and consent, and provides requirements for design of ontologies required by research objective $RO3$.

\subsubsection*{Provenance records}
Provenance in this case refers to information about entities and activities involved in the compliance process where a record is required to be kept and exchanged for compliance purposes. For example, GDPR requires controllers and processors to maintain provenance records of processing activities carried out under their responsibility in order to maintain and demonstrate compliance to supervisory authorities. Provenance records are also required to be maintained to enable provision of rights to data subjects, and for information sharing between controllers and third parties.

The information stored within provenance records is related to demonstrating compliant processing of personal data and fulfilment of obligations towards demonstration of compliance. They are modelled within state of the art (see \autoref{chapter:sota}) variously as logs, life-cycles, workflows, activities, and process flows. The term provenance in this case refers to both ex-ante and ex-post phases and is indicative of provenance of information to specify its existence. Therefore provenance in ex-ante phase means record of a model or plan used to indicate future processing of personal data, while that in ex-post phase refers to record or log of processing.

Since provenance information as described above encompasses information about artefacts and processes related to compliance, sharing this information in an interoperable format with other entities benefits both in their obligations regarding compliance. For example, controllers and supervisory authorities sharing interoperable compliance documentation can use the same set of tools and approaches for interacting with information. Also, by recording processes associated with compliance as provenance records, the same interoperable methods can be used to maintain, document, and demonstrate compliance. This is especially useful where information is to be shared between joint controllers and processors that need to exchange plans of processing for agreement as well as logs for successful implementations.

Since a data controller is required to ensure their intended activities are compliant as well as maintain records of processing activities regarding use of personal data, provenance records to be documented consist of intended plan of processing activities and their execution. Similarly, provenance records of consent requests and provision also need to be maintained to demonstrate compliance. Given the similarity in requirements for maintaining provenance records for different reasons, it is beneficial to provide a singular interoperable representation of provenance activities in a form that can capture and represent all aspects of provenance records required for compliance.

\subsubsection*{Consent information}
As per GDPR, consent is an assent or agreement by a data subject regarding processing of their personal data for specified purposes by one or more entities. 
For compliance, a controller must record information regarding how consent was requested and choices provided by a data subject as given consent.
GDPR has several obligations and requirements when it comes to valid consent, with additional requirements depending on sensitivity of personal data and processing. 
Artefacts associated with choices offered for consent therefore need to be preserved to demonstrate the validity of consent obtained using those choices.
Similarly, consent revocation or revisions also need to be recorded and linked to earlier instances of consent to demonstrate a change was valid as per requirements of GDPR.

The processes associated with offering consent choices, retrieving and recording given consent, enabling withdrawal of consent, and executing revocation in internal processes need to be documented for compliance by relevant controller(s).
These are associated across both ex-ante and ex-post phases where consent choices, provision of right to withdrawal, and demonstrating utilisation of consent in processing are demonstrated as ex-ante measures while given consent and revoked consent are ex-post artefacts. 

If consent is considered as an instance of personal data, the same information model used to document processing of personal data can be re-purposed or reused to represent activities associated with consent. In addition to this, activities need to capture different stages of consent and personal data by representing their life-cycles which involve processes and artefacts which use them or are dependant on them to indicate their evolution and use over time. 

\subsubsection*{Stating interoperability as a requirement}
The model and analyses of information flows between entities provides motivation for establishing interoperability in representation of information to be exchanged.
As the scope of thesis focuses on representation of activities associated with processing of personal data and consent, requirements gathered from this analysis relate primarily to information associated with provenance of activities and information about consent.
Within this scope, ensuring potential reuse towards other categories through future extensions is provided by developing an interoperable ontology by using standards that can be utilised to also represent data processing agreements and compliance agreements in the future.
This involves using standards of RDF and OWL2 to represent ontologies along with reuse of existing standardised vocabularies such as PROV-O and ELI.
In addition, the research also provides transparency by using terminology of GDPR in developed ontologies, indicating requirements used to shape design of ontology and indicating source of concepts within GDPR.

Representing provenance is not limited to representation of processing of personal data, but is also applicable to information about other categories - consent, data processing agreements, compliance, and certifications. Therefore, utilising the same or compatible representation in representing provenance across all use-cases has advantage towards cohesive management of all associated information for compliance - and provides an objective for future work in expanding contributions presented in this thesis.

With this motivation, the next parts of this chapter provide requirements gathered for representing information regarding processing of personal data and consent while also including other relevant information such as data breaches and provision of rights to indicate potential applicability and reuse of developed ontologies in representing information through provenance records for GDPR compliance.

\section{Compliance Questions}\label{sec:info:compliance-questions}
This section presents `compliance questions' whose answers provide information necessary for evaluating GDPR compliance. The questions are essential to development of information representations within compliance management systems by providing requirements for structuring of information and its validation. Within this thesis, they are used to guide development of ontologies as competency questions (see \autoref{chapter:vocabularies}) and validation of information (see \autoref{chapter:testing}). \textbf{The questions presented here are by no means exhaustive but represent gathered requirements from authoritative sources.} As supervisory authorities and courts continue to clarify and interpret compliance requirements of GDPR, these questions are expected to change and expand in future.

\subsection{Methodology}\label{sec:info:compliance-questions-methodology}
The questions were created by studying authoritative sources regarding GDPR compliance consisting of data protection commissions, legal experts and agencies - that have published guidelines and resources to assist organisations with the process of establishing and maintaining GDPR compliance.
In this process, each identified clause or article of GDPR pertaining to the research question was formulated as a question, with the above mentioned sources providing indication on how the question should be interpreted and  requirements for its compliance.
The questions were derived from reading and understanding of compliance requirements and are intentionally expressed as a `simple question' whose answering requires minimal information in order to determine requirements of such information towards constructing an ontological representation of it.
% As questions were formulated from an understanding of GDPR, they are associated with specific clauses where a question was derived explicitly from particular clauses.

For questions presented in this thesis, following sources were used or referenced in addition to text of GDPR:
\begin{itemize}
    \item Guidelines, clarifications, and discussions on interpretation of GDPR published by European Data Protection Board\footnote{\url{https://edpb.europa.eu/}} (EDPB)
    \item Guidelines, clarifications, and discussions on interpretation of GDPR published by Article 29 Working Party\footnote{\url{https://ec.europa.eu/newsroom/article29/news.cfm?item_type=1360}} and endorsed by EDPB
    \item Resources published Data Protection Commission\footnote{\url{https://dataprotection.ie/}} (Ireland) - with particular focus on document `GDPR guidance for SMEs'\footnote{\url{https://dataprotection.ie/en/guidance-landing/guidance-smes}}
    \item Resources published by Information Commissioners Office\footnote{\url{https://dataprotection.ie/}} (United Kingdom), with particular use of `Data protection self assessment for organisations'\footnote{\url{https://ico.org.uk/for-organisations/data-protection-self-assessment/}}
    \item Resources published by federated data protection offices in Germany, in particular the audit checklist published by Lower Saxony Data Protection Authority\footnote{\url{https://lfd.niedersachsen.de/download/146715/}} self-translated from German to English\footnote{\url{https://doi.org/10.5281/zenodo.3380469}}
    \item Resources regarding GDPR compliance published by professional institutions within legal compliance domain, specifically - Nymity\footnote{\url{https://info.nymity.com/gdpr-compliance-toolkit}} and IAPP\footnote{\url{https://iapp.org/resources/article/gdpr-genius/}}
    \item Executive and Court decisions regarding GDPR compliance, tracked through an online community service \url{https://www.enforcementtracker.com/} which also denotes relevant articles of GDPR
\end{itemize}

The questions pertaining to consent and its associated processing activities were validated through consultation with a law professor at Trinity College Dublin who served as a legal domain expert and validated the questions and information required to answer them. This consisted of providing a spreadsheet containing categories of questions along with their assumptions and constraints as information requirements, with the feedback consisting of whether stated information was correct, utilised correct terminology, and changes in statements to suit legal interpretations.
Other questions pertaining to processor obligations, data breach requirements, and rights were not validated through this process due to unavailability of expert and their lower priority in relevance to the research question.

The author of this thesis was part of an informal consultation on a real-world (details confidential) research project at MasterCard regarding creation of a semantic web ontology for expressing consent information based on requirements of the GDPR.
The consultation consisted of identifying information for representing consent based on requirements of GDPR and designing an ontology to represent it. 
This process provided real-world requirements about management of consent information which had an influence on compliance questions associated with consent and design of GConsent ontology presented in \autoref{sec:voc:GConsent}.

The collected questions were rephrased and divided into smaller more granular questions towards establishment of information requirements and constraints. 
Each question was assigned an ID to enable tracking its use.
Where possible, each question was associated with specific clauses of GDPR by denoting an article or recital relevant to it. Each question was analysed in terms of information requirements to identify assumptions that clarify interpretation of the question, and constraints that express a condition that can be tested and used to validate information. For each identified constraint, a failing test case was identified that did not satisfy the condition and could be used to test its validation.
% \todo{upload all documents to Zenodo and put link here}
% A spreadsheet was used to collect and organise the questions, assumptions, and constraints - and is available as an open resource\footnote{\url{TODO: upload spreadsheet to Zenodo and post link here}}.

The list of questions is presented in \autoref{sec:info:compliance-questions-list} with assumptions and constraints presented in \autoref{sec:info:constraints}. Along with compliance questions regarding activities associated with processing of personal data and consent, the list also contains questions about additional activities associated with right to be informed and reporting of data breach by controllers. These questions are used in development of ontologies that demonstrate application of a common approach to represent activities related to processing of personal data, consent, data breach, and provision of rights for GDPR compliance. 

\subsection{List of Questions}\label{sec:info:compliance-questions-list}
The questions are categorised based on the topic they focus on within the context of compliance. Where a question was directly derived from specific clause(s) a reference to the clause(s) is provided at end of sentence\footnote{Shortened references are used to indicate the clause of GDPR. For example: R32 indicates Recital 32, A7-2 indicates Article 7 Para 2, and A9-2c indicates Article 9 Para 2 Sub-Para c.}.
In order to provide a context for application of questions within real world, a group of use-cases are provided in \autoref{sec:info:use-cases}.
An overview of compliance questions and their categorisation as follows:
\begin{itemize}
	\item \autoref{sec:info:CQ:1} Compliance questions pertaining to records of processing activities to be kept by controllers: \texttt{CMQ.1 - CMQ.15}.
	\item \autoref{sec:info:CQ:2} Compliance questions pertaining to records of processing activities to be kept by processors: \texttt{CMQ.16 - CMQ.25}.
	\item \autoref{sec:info:CQ:3} Compliance questions pertaining to legal basis of processing activities: \texttt{CMQ.26 - CMQ.27}.
	\item \autoref{sec:info:CQ:4} Compliance questions pertaining to personal data: \texttt{CMQ.28 - CMQ.34}.
	\item \autoref{sec:info:CQ:5} Compliance questions pertaining to given consent: \texttt{CMQ.35 - CMQ.69}.
	\item \autoref{sec:info:CQ:6} Compliance questions pertaining to change in consent state: \texttt{CMQ.70 - CMQ.87}.
	\item \autoref{sec:info:CQ:7} Compliance questions pertaining to provision of right to be informed: \texttt{CMQ.88 - CMQ.105}.
	\item \autoref{sec:info:CQ:8} Compliance questions pertaining to reporting of data breach by controllers: \texttt{CMQ.106 - CMQ.120}.
\end{itemize} 

\subsubsection{Use-cases}\label{sec:info:use-cases}
To identify application of compliance questions in various scenarios within real world, 15 categories of use-cases were identified to determine necessary information required to identify their ontological representations.
The use-cases are based on identifying information affecting compliance requirements and identifying variances which affect representations of that information.
These were useful to guide development of ontologies by serving as test scenarios where an ontology could be applied and evaluated for representing information.
These use-cases are not intended to be comprehensive or normative from a legal compliance point of view, but are helpful in understanding presented work by providing a context for their application.

A summary of these use-cases is as follow:
\begin{enumerate}
% \tightlist
\item
  Obtaining / Declaring Consent (its state)

  \begin{enumerate}
%   \tightlist
  \item
    The consent is given
  \item
    Consent was given, but is now invalidated (by the controller)
  \item
    Consent was given, but was withdrawn (by the Data Subject)
  \item
    Consent was requested (by the controller)
  \item
    Consent was requested, but was refused (by the Data Subject)
  \item
    Consent state is unknown (e.g. when importing data about consent)
  \end{enumerate}
\item
  Entity the consent is about

  \begin{enumerate}
%   \tightlist
  \item
    The consent is about a Data Subject who is not a minor
  \item
    The consent is about a Data Subject who is a minor
  \end{enumerate}
\item
  Activity for Data Subject

  \begin{enumerate}
%   \tightlist
  \item
    There was an age verification process associated with the consent
    (such as for minors)
  \item
    There was an identity verification process associated with the
    consent
  \end{enumerate}
\item
  Entity that provided consent

  \begin{enumerate}
%   \tightlist
  \item
    Consent was provided by the Data Subject it is about
  \item
    Consent was not provided by the Data Subject it is about, but was
    provided by a Delegation

    \begin{enumerate}
    % \tightlist
    \item
      Consent in the Delegation was provided by another Data Subject
    \item
      Consent in the Delegation was provided by a Person
    \item
      Consent in the Delegation was provided by another Delegation
    \end{enumerate}
  \end{enumerate}
\item
  Role within Delegation

  \begin{enumerate}
%   \tightlist
  \item
    Entity is the Parent/Guardian of the Data Subject
  \item
    Entity is a third-party to the Data Subject
  \end{enumerate}
\item
  Activity of Delegation

  \begin{enumerate}
%   \tightlist
  \item There was some verification process to assert the authentication of
    the delegation
  \end{enumerate}
\item
  Personal Data associated with consent

  \begin{enumerate}
%   \tightlist
  \item
    Consent was given for specific instances of personal data e.g. John/Jane Doe
  \item
    Consent was given for categories of personal data e.g. Name
  \end{enumerate}
\item
  Medium of Consent

  \begin{enumerate}
%   \tightlist
  \item
    consent is given via a web-form
  \item
    consent is given as a signed paper document
  \item
    consent is given as a verbal confirmation
  \item
    consent is given implicitly in some form (medium)
  \item
    consent is given via delegation in some form (medium)
  \end{enumerate}
\item
  Activity responsible for consent

  \begin{enumerate}
%   \tightlist
  \item
    Activity created consent as a new entity
  \item
    Activity modified existing consent
  \end{enumerate}
\item
  Previous consent and relationship

  \begin{enumerate}
%   \tightlist
  \item
    Consent has no previous instance
  \item
    Consent has a previous instance and replaces it
  \end{enumerate}
\item
  Differences between consent instances

  \begin{enumerate}
%   \tightlist
  \item
    Something changes between two consent instances (e.g. personal data
    category is added)
  \end{enumerate}
\item
  Time constraints

  \begin{enumerate}
%   \tightlist
  \item
    consent expires (has a tangible expiry such as a specific date or
    duration)
  \item
    consent does not expire (is valid for ``as long as required'')
  \end{enumerate}
\item
  Third party Association

  \begin{enumerate}
%   \tightlist
  \item
    Personal Data is collected from a third party
  \item
    Personal Data is stored with a third party (processor)
  \item
    Personal Data is shared with a third party
  \item
    Processing involves third party
  \item
    Purpose involves third party
  \end{enumerate}
\item
  Role of Third Party

  \begin{enumerate}
%   \tightlist
  \item
    Third Party is a Processor contracted by the Controller
  \item
    Third Party is another Controller
  \item
    Third Party is another entity (regulatory/supervisory/governmental)
  \end{enumerate}
\item
  Storage Duration and Locations for Personal Data

  \begin{enumerate}
%   \tightlist
  \item
    Data is stored for a fixed time (specific instance or duration)
  \item
    Data is stored for an indefinite duration (``for as long as
    required'')
  \end{enumerate}
\end{enumerate}

% COMPLIANCCE QUESTIONS - CONTROLLERS
\subsubsection{Compliance questions pertaining to records of processing activities to be kept by controllers}\label{sec:info:CQ:1}
\begin{enumerate}[label={\textit{CMQ.\theenumi}}]
    \item How are the records of processing activities maintained? (R82,A30,A30-3)
    \item What is the name and identity of the controller(s) and their representatives/DPOs? (A30-1a)
    \item What are the purposes of processing? (A30-1b)
    \item What are the categories of data subjects? (A30-1c)
    \item What are the categories of personal data? (A30-1c)
    \item Is data shared?
    \item If data is shared, what are the categories of recipients to whom the personal data is or will be disclosed? (A30-1d)
    \item If data is shared, what are the identities of the recipients to whom the data is or will be disclosed? (A30-1d,A30-1e)
    \item If data is shared, are the recipients to whom the data is or will be disclosed based in a Third Country or International Organisation? (A30-1e)
    \item If data is shared, and the recipients are in a Third Country or International Organisation, what are the safeguards associated with data transfer? (A30-1e)
    \item Is data stored?
    \item Where data is stored, its erasure is based on what criteria: time limit or condition or event?
    \item Where data is stored, what are the time limits or conditions or events for erasure for different categories of data? (A30-1f)
    \item What are the technical and organisational security measures w.r.t to the processing of personal data? (A30-1g)
    \item Where data is shared, what are the purposes for sharing of personal data with the recipients?
\end{enumerate}

% COMPLIANCE QUESTIONS - PROCESSORS
\subsubsection{Compliance questions pertaining to records of processing activities to be kept by processors}\label{sec:info:CQ:2}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item How are the records of processing activities maintained? (R82,A30,A30-3)
    \item What is the name and identity of the processor(s) and their representatives/DPOs? (A30-1a)
    \item What is the name and identity of the controller(s) the processor is acting on behalf of? (A30-2a)
    \item What are the categories of processing carried out on behalf of the controller? (A30-2b)
    \item If data is shared, what are the categories of recipients to whom the personal data is or will be disclosed? (A30-1d)
    \item If data is shared, what are the identities of the recipients to whom the data is or will be disclosed? (A30-1d,A30-1e)
    \item If data is shared, are the recipients to whom the data is or will be disclosed based in a Third Country or International Organisation? (A30-1e)
    \item If data is shared, and the recipients are in a Third Country or International Organisation, what are the safeguards associated with data transfer? (A30-1e)
    \item What are the technical and organisational security measures w.r.t to the processing of personal data? (A30-1g)
    \item Where data is shared, what are the purposes for sharing of personal data with the recipients?
\end{enumerate}
% COMPLIANCE QUESTIONS - LEGAL BASIS
\subsubsection{Compliance questions pertaining to legal basis of processing activities}\label{sec:info:CQ:3}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item What is the legal basis for processing of data?
    \item What is the legal basis for the purpose for processing of data?
\end{enumerate}

% COMPLIANCE QUESTIONS - PERSONAL DATA
\subsubsection{Compliance questions pertaining to personal data}\label{sec:info:CQ:4}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item What are the sources of personal data?
    \item What personal data are collected from the data subject?
    \item Where personal data are not collected from the data subject, what are their sources?
    \item Where data has been anonymised, what techniques were used for anonymisation?
    \item Can pseudo-anonymised data be de-anonymised by the organisation using information it already possesses or is available to it?
    \item Where personal data is collected, is it pseudo-anonymous?
    \item What are the special categories of personal data being processed?
\end{enumerate}

% COMPLIANCE QUESTIONS - GIVEN CONSENT
\subsubsection{Compliance questions pertaining to given consent}\label{sec:info:CQ:5}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item Who is the Data Subject associated with consent? (A4-11)
    \item What are the Personal Data associated with consent? (R32,A4-11)
    \item What are the Purposes associated with consent? (R32,R42)
    \item What are the Data Processing associated with consent? (R32,A4-11)
    \item What is the current Status of consent? (A7-3)
    \item Who are the Data Controllers associated with consent?
    \item Who provided consent? (A7-2)
    \item Was consent provided by Delegation? (A8-c)
    \item If consent was provided by Delegation, what was the role played by Delegate with respect to the Data Subject?
    \item If consent was provided by Delegation, how was the delegation executed?
    \item If consent was provided by Delegation, how was the delegate authenticated? (A8-2)
    \item Who was the consent given to?
    \item If consent was not given to the Data Controller, what is the relationship between the entity it was provided to and the Data Controller?
    \item How was the consent given/obtained?
    \item What artefacts were involved in the giving/obtaining of consent?
    \item What were the choices provided for consent?
    \item What was the statement or affirmative action indicating given consent?
    \item How was the right to withdraw consent communicated to the data subject?
    \item At what location was the consent given?
    \item What is the medium associated with consent? (R32,A7-2)
    \item What is the timestamp associated with the consent?
    \item What is the expiry of the consent?
    \item Is the purpose or processing associated with a third party?
    \item What is the role played by the third party in the purpose or processing?
    \item Does the processing of data involve storage of data?
    \item If personal data is being stored, what is the duration of storage for Personal Data?
    \item If personal data is being stored, what is the location of storage?
    \item Are processing associated with consent of automated nature? (R71,A9-2c,A22-2c)
    \item Does the processing of data involve transfer to a Third Country or International Organisation? (R111,A49-1a)
    \item If processing of data involves transfer to a Third Country or International Organisation, what is the identity of the Third Country or International Organisation?
    \item Do the personal data associated with consent belong to a special category? (R51,A8-2a)
    \item How is personal data associated or linked to the data subject?
    \item Is the Data Subject of legal age to provide their own consent? (A8)
    \item What are the specific laws that determine the legal age to provide consent? (A8-1)
    \item Does the Data Subject have a specific relationship with the Data Controller? (R43)
\end{enumerate}

% COMPLIANCE QUESTIONS - CHANGE IN CONSENT STATE
\subsubsection{Compliance questions pertaining to change in consent state}\label{sec:info:CQ:6}
In this, the definition of change in consent is where the state/status of consent is changed. Example: unknown to not asked or not given, from given to withdrawn, from given to invalidated. Changes where the result is given consent or obtained consent where none existed is considered as given consent with compliance questions listed in the previous section.
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item Who is the Data Subject associated with consent? (A4-11)
    \item What are the Personal Data associated with consent? (R32,A4-11)
    \item What are the Purposes associated with consent? (R32,R42)
    \item What are the Data Processing associated with consent? (R32,A4-11)
    \item What is the current state/status of consent? (A7-3)
    \item Who are the Data Controllers associated with consent?
    \item Who changed the state/status of consent?
    \item Was consent changed by Delegation?
    \item If consent was changed by Delegation, what was the role played by Delegate with respect to the Data Subject?
    \item If consent was changed by Delegation, how was the delegation executed?
    \item If consent was changed by Delegation, how was the delegate authenticated? (A8-2)
    \item How was the consent state/status changed?
    \item What artefacts were involved in the change in state/status of consent?
    \item If change in consent was done by the Data Subject, what was the statement or affirmative action indicating change to their consent?
    \item At what location was the consent changed?
    \item What is the medium associated with change in consent? (R32,A7-2)
    \item What is the timestamp associated with the consent?
    \item If the current state/status of consent is valid for processing, what is the expiry of the consent?
\end{enumerate}

% COMPLIANCE QUESTIONS - RIGHT TO BE INFORMED
\subsubsection{Compliance questions pertaining to provision of right to be informed}\label{sec:info:CQ:7}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item How was information relevant for the right to be informed provided to the data subjects?
    \item When was the information relevant to right to be informed was provided to the data subject?
    \item Was the name and contact details of the controller’s representative provided to the data subject under the right to be informed?
    \item Was the name and contact details of the DPO provided to the data subject under the right to be informed?
    \item Was the purposes for processing provided to the data subject under the right to be informed?
    \item Was the legal basis for processing provided to the data subject under the right to be informed?
    \item Where the legal basis for processing was legitimate interest, was this communicated to the data subject under the right to be informed?
    \item If personal data is not obtained from the data subject, were the categories of personal data obtained communicated to the data subject under the right to be informed?
    \item If personal data is not obtained from the data subject, were the sources of data communicated to the data subject under the right to be informed?
    \item Where personal data is shared, were the recipients or categories of recipients communicated to the data subject under the right to be informed?
    \item If personal data is transferred to a third country or international organisation, were the identity of the third country or international organisation communicated to the data subject under the right to be informed?
    \item Where personal data is stored, were the retention period communicated to the data subject under the right to be informed?
    \item Were the rights available communicated to the data subject under the right to be informed?
    \item If the data subject provided consent, was the right to withdraw consent provided under the right to be informed?
    \item Was the right to lodge a complaint with a supervisory authority provided to the data subject under the right to be informed?
    \item Where personal data needs to be provided under statutory or contractual obligation, was this communicated to the data subject under the right to be informed?
    \item Where personal data needs to be provided under statutory or contractual obligation, and if this data needs to be obtained from the data subject, was this communicated to the data subject under the right to be informed?
    \item Where automated-decision making, including profiling is used, was this communicated to the data subject under the right to be informed?
\end{enumerate}

% COMPLIANCE QUESTIONS - DATA BREACH
\subsubsection{Compliance questions pertaining to reporting of data breach by controllers}\label{sec:info:CQ:8}
\begin{enumerate}[label={\textit{CMQ.\theenumi}},resume]
    \item When did the data breach occur?
    \item When did the controller become aware of the data breach? (R85,R33-1)
    \item Was the data breach notified to the supervisory authority?
    \item When was the notification of data breach provided to the supervisory authority? (R85)
    \item How was the notification of data breach provided to the supervisory authority? (R85,R33-1)
    \item Is the data breach likely to result in a high risk to the rights and freedoms of the natural person whose data is associated with it? (R86,A33-1,A34-1)
    \item Who are the data subjects whose personal data are associated with the data breach?
    \item Was the data breach notified to the data subjects?
    \item When was the notification of data breach provided to the data subjects?
    \item How was the notification of data breach provided to the data subjects? (R85,R33-1)
    \item How did the notification of data breach to the data subject provide information about the data breach? (R86,A34-2)
    \item How did the notification of data breach to the data subject provide information about mitigating potential effects? (R86,A34-2)
    \item What data was involved in the data breach?
    \item What technical measures were in place for the protection of data involved in the data breach? (R88)
    \item What steps were taken to prevent or mitigate the effects of the data breach?
\end{enumerate}

\subsection{Assumptions \& Constraints}\label{sec:info:constraints}
An assumption is defined as information or condition that always holds true and is useful in the interpretation of the compliance question. A constraint is defined as a condition that the information pertaining to compliance question must satisfy in order for it to be valid. The assumptions and constraints are listed with reference to the relevant compliance question at the end in brackets.
An overview of the assumptions and constraints based on the categories of compliance questions is as follows:
\begin{itemize}
	\item \autoref{sec:info:CQ:1} Compliance questions pertaining to records of processing activities to be kept by controllers: \texttt{CMQ.1 - CMQ.15}  has Assumptions \texttt{A.1 - A.5} and Constraints \texttt{C.1 - C.18}
	\item \autoref{sec:info:CQ:2} Compliance questions pertaining to records of processing activities to be kept by processors: \texttt{CMQ.16 - CMQ.25} has Constraints \texttt{C.16 - C.32}
	\item \autoref{sec:info:CQ:3} Compliance questions pertaining to legal basis of processing activities: \texttt{CMQ.26 - CMQ.27}  has Assumptions \texttt{A.6} and Constraints \texttt{C.33 - C.34}
	\item \autoref{sec:info:CQ:4} Compliance questions pertaining to personal data: \texttt{CMQ.28 - CMQ.34}  has Assumptions \texttt{A.7} and Constraints \texttt{C.35 - C.38}
	\item \autoref{sec:info:CQ:5} Compliance questions pertaining to given consent: \texttt{CMQ.35 - CMQ.69}  has Assumptions \texttt{A.8 - A.28} and Constraints \texttt{C.39 - C.69}
	\item \autoref{sec:info:CQ:6} Compliance questions pertaining to change in consent state: \texttt{CMQ.70 - CMQ.87}  has Assumptions \texttt{A.30 - A.39} and Constraints \texttt{C.70 - C.87}
	\item \autoref{sec:info:CQ:7} Compliance questions pertaining to provision of right to be informed: \texttt{CMQ.88 - CMQ.105} has Constraints \texttt{C.88 - C.113}
	\item \autoref{sec:info:CQ:8} Compliance questions pertaining to reporting of data breach by controllers: \texttt{CMQ.106 - CMQ.120} has Constraints \texttt{C.114 - C.130}
\end{itemize} 

\subsubsection{Assumptions}
\begin{enumerate}[label={\textit{A.\theenumi}}]
    \item Processing activities as a whole can involve multiple controllers - (CMQ2)
    \item Data recipient categories refer to a collection or abstraction of recipients based on some context such as purpose e.g. “our ad partners” or requirement e.g. “law agencies” - (CMQ8)
    \item Data recipients cannot be a collective or a group whose identity cannot be represented as a list of its members e.g. “our partners” vs “our partners – A, B, C” - (CMQ9)
    \item Identity of the recipients does not need to be associated with the processing record if category of recipients is already documented. However, the identity of recipients within the category at that point of time must be recorded (somewhere). - (CMQ10)
    \item Where data is stored, its erasure can depend on a condition or an event e.g. “XX days after your last sign-in”, or “as long as your account is active” - (CMQ12)
    \item Processing carried out for a specific purpose adopts the legal basis of the purpose - (CMQ26)
    \item Personal data may not have the source information associated with it directly. It must have some link (chain, path) to the information and its source from which it was obtained. - (CMQ28)
    \item If there are multiple categories of personal data, consent is granted for all (union) of them - (CMQ36)
    \item If a consent is given for multiple purposes, consent is considered given for all (union) of them - (CMQ37)
    \item If a consent is given for multiple processing, consent is considered given for all (union) of them - (CMQ38)
    \item Valid status of consent are when it is given (explicitly or implicitly) by the data subject, or by delegation - (CMQ39)
    \item Invalid status of consent are when it its status is unknown, refused, not offered, withdrawn, invalidated, terminated, or expired. - (CMQ39)
    \item The status of consent indicates whether it can be used as a legal basis for processing - (CMQ39)
    \item Consent provided by a Person that is not the Data Subject is consent by Delegation - (CMQ41)
    \item A delegation can involve another delegation for the provision of consent - (CMQ42)
    \item If consent is provided to an actor not the data controller associated with consent, the actor is considered as acting on behalf of the controller - (CMQ46)
    \item Specifying location for obtained consent is optional - (CMQ53)
    \item Specifying medium for obtained consent is optional - (CMQ54)
    \item Consent may not have a tangible expiry - (CMQ56)
    \item Consent may have multiple forms of expiry depending on conditions or events - (CMQ56)
    \item A purpose or processing may be associated with zero or more third parties - (CMQ57)
    \item Processing of data may involve storage of data - (CMQ59)
    \item Different personal data, processing, or purpose may have different storage of data - (CMQ60)
    \item Storage duration may not be a tangible instance in time, it can depend on conditions or event - (CMQ60)
    \item Processing may involve transfer of data to a third country or international organisation - (CMQ63)
    \item Personal data associated with consent may belong to a special category - (CMQ65)
    \item A data subject may be a minor or a child - (CMQ67)
    \item The data subject may have a relationship of relevance with the Data Controller - (CMQ69)
    \item If there are multiple categories of personal data, consent is granted for all (union) of them - (CMQ71)
    \item If a consent is given for multiple purposes, consent is considered given for all (union) of them - (CMQ72)
    \item If a consent is given for multiple processing, consent is considered given for all (union) of them - (CMQ73)
    \item Valid status of consent are when it is given (explicitly or implicitly) by the data subject, or by delegation - (CMQ74)
    \item Invalid status of consent are when it its status is unknown, refused, not offered, withdrawn, invalidated, terminated, or expired. - (CMQ74)
    \item The status of consent indicates whether it can be used as a legal basis for processing - (CMQ74)
    \item Consent state/status can be changed by Delegation - (CMQ76)
    \item A delegation can involve another delegation for the provision of consent - (CMQ77)
    \item Specifying location for changed consent is optional - (CMQ84)
    \item Specifying medium for changed consent is optional - (CMQ85)
    \item Consent may not have a tangible expiry - (CMQ87)
    \item Consent may have multiple forms of expiry depending on conditions or events - (CMQ87)
\end{enumerate}

\subsubsection{Constraints}
\begin{enumerate}[label={\textit{C.\theenumi}}]
    \item Processing carried out by a controller must have information on how its records are being maintained - (CMQ1)
    \item Records of processing activity under the responsibility of a controller must have the names/identity of all associated controllers - (CMQ2)
    \item Each controller associated record of processing activities under the responsibility of (this) controller must have one or more contact details - (CMQ3)
    \item Each controller associated with records of processing activities under the responsibility of (this) controller must have the identity and one or more contact details of the DPO - (CMQ4)
    \item Processing under the responsibility of a controller must have one or more purposes of processing associated with it - (CMQ3)
    \item Processing under the responsibility of a controller must have one or more categories of data subjects associated with it - (CMQ4)
    \item Processing under the responsibility of a controller must have one or more categories of personal data associated with it - (CMQ5)
    \item Processing under the responsibility of a controller must explicitly state when data is shared - (CMQ6)
    \item Processing under the responsibility of a controller where data is shared must have the category of recipients to whom the data is or will be disclosed - (CMQ7)
    \item Processing under the responsibility of a controller where data is shared must have the identities of recipients to whom the data is or will be disclosed - (CMQ8)
    \item Processing under the responsibility of a controller where the recipients to whom the data is or will be disclosed are based in a Third Country or International Organisation must explicitly specified it as such - (CMQ9)
    \item Processing under the responsibility of a controller must specify the identity of the Third Country or International Organisation to whom the data is or will be disclosed - (CMQ10)
    \item Processing under the responsibility of a controller where personal data is transferred to a third country or an international organisation must specify the safeguards present for the transfer - (CMQ10)
    \item Processing under the responsibility of a controller must explicitly state when data is stored - (CMQ11)
    \item Processing under the responsibility of a controller where data is stored must specify the criteria for its erasure - (CMQ12)
    \item Each category of data associated with a record of processing must have a time limit or a condition or an event specified for its erasure - (CMQ13)
    \item The record of processing must have technical and organisational security measures associated with it - (CMQ14)
    \item Every sharing of personal data must specify the purposes of sharing with the recipients - (CMQ15)
    \item Every processing must have information on how its records are being maintained - (CMQ16)
    \item Each record of processing activity under the responsibility of a processor must have the names/identity of all associated processors under its responsibility - (CMQ17)
    \item Each processor associated with a record of processing activity under the responsibility of a processor must have one or more contact details - (CMQ17)
    \item Each processor associated with a record of processing activity under the responsibility of a processor must have the identity and one or more contact details of the DPO - (CMQ17)
    \item Each record of processing activity under the responsibility of a processor must have the names/identity of the controller(s) it is acting on behalf of - (CMQ18)
    \item Each record of processing activity under the responsibility of a processor must have name and contact details of the controller's representative and DPO - (CMQ18)
    \item Each record of processing carried out by a processor on behalf of a controller must specify categories of processing associated with it - (CMQ19)
    \item Each record of processing under the responsibility of a processor where data is shared must have the identity of recipients to whom the data is or will be disclosed - (CMQ20)
    \item The identities of the recipients to whom data is or will be disclosed must be specified - (CMQ21)
    \item If the recipients to whom the data is or will be disclosed are based in a Third Country, or International Organisation, this must be specified as such - (CMQ22)
    \item The identity of the Third Country or International Organisation to whom the data is or will be disclosed must be specified - (CMQ22)
    \item The transfer of personal data to a third country or an international organisation must specify its safeguards - (CMQ23)
    \item The record of processing must have technical and organisational security measures associated with it - (CMQ24)
    \item Every sharing of personal data must specify the purposes of sharing with the recipients - (CMQ25)
    \item Each processing of data must have an associated legal basis - (CMQ26)
    \item Each purpose for processing of data must have an associated legal basis - (CMQ27)
    \item Each personal data must have information about its source - (CMQ28)
    \item Personal data collected from the data subject must be clearly specified as such - (CMQ29)
    \item Every anonymisation of data must specify the techniques used for anonymisation - (CMQ31)
    \item Where pseudo-anonymised data can be de-anonymised by the organisation, it must be clearly specified as such - (CMQ32)
    \item Every consent must be associated with only one Data Subject - (CMQ35)
    \item Every consent must have one or more categories or types of personal data associated with it - (CMQ36)
    \item Every consent must have one or more purposes associated with it - (CMQ37)
    \item Every consent must have one or more processing associated with it - (CMQ38)
    \item Every consent must have one and only one state/status - (CMQ39)
    \item Every consent must be associated with one or more Controllers - (CMQ40)
    \item Consent is given by exactly one Person - (CMQ41)
    \item Consent provided by delegation must be clearly specified as such - (CMQ42)
    \item Consent provided by delegation must have a single chain of delegation - (CMQ42)
    \item Delegate in a consent has to play one or more roles that are associated with the Data Subject - (CMQ43)
    \item Every delegation must have information on how it was executed - (CMQ44)
    \item A delegate must be authenticated to act on behalf of the data subject in a delegation - (CMQ45)
    \item Every consent must have information on who it was provided to - (CMQ46)
    \item An entity collecting consent on behalf of the Data Controller must have information on the relationship - (CMQ47)
    \item Every given consent must have information on how it was obtained - (CMQ48)
    \item Every consent must have some artefacts associated with how it was given/obtained - (CMQ49)
    \item Every consent must have information on what choices were provided to the data subject - (CMQ50)
    \item Every consent must have a statement or affirmative action indicating given consent - (CMQ51)
    \item Every consent must have information on how the right to withdraw was communicated - (CMQ52)
    \item Consent must not have more than one location it was provided at - (CMQ53)
    \item Consent must not have more than one medium it was provided in - (CMQ54)
    \item Every consent must have a timestamp indicating when it was given/obtained - (CMQ55)
    \item Every purpose or processing associated with Third Party must have information on the role played by the Third Party - (CMQ58)
    \item If data is being stored, it must have information on how long it will be stored for - (CMQ60)
    \item Every storage of data must have information on its storage location - (CMQ61)
    \item Processing of personal data which is of automated nature must be clearly indicated as such - (CMQ62)
    \item Every processing of data involving transfer to a third country or international organisation must have the identity of the third country or international organisation specified - (CMQ64)
    \item Every personal data belonging to a special category must be clearly indicated as such - (CMQ65)
    \item Every personal data must have information on one or more identifiers that link it to a particular data subject - (CMQ66)
    \item A data subject who is not of legal age to provide their own consent must be clearly indicated as such - (CMQ67)
    \item There must be information on the relevant laws that determine the legal age of consent - (CMQ68)
    \item Every consent must be associated with only one Data Subject - (CMQ70)
    \item Every consent must have one or more categories or types of personal data associated with it - (CMQ71)
    \item Every consent must have one or more purposes associated with it - (CMQ72)
    \item Every consent must have one or more processing associated with it - (CMQ73)
    \item Every consent must have one and only one state/status - (CMQ74)
    \item Every consent must be associated with one or more Controllers - (CMQ75)
    \item Every change in the state/status of consent must be attributed to one or more agents - (CMQ76)
    \item Consent changed by delegation must be clearly specified as such - (CMQ77)
    \item Consent provided by delegation must have a single chain of delegation - (CMQ77)
    \item Delegate in a consent has to play one or more roles that are associated with the Data Subject - (CMQ78)
    \item Every delegation must have information on how it was executed - (CMQ79)
    \item A delegate must be authenticated to act on behalf of the data subject in a delegation - (CMQ80)
    \item Every change in the state/status of consent must have information on how it was changed - (CMQ81)
    \item Every change in state/status of consent must have some artefacts associated with how it was changed - (CMQ82)
    \item Every change to consent by the Data Subject must have a statement or affirmative action indicating the change - (CMQ83)
    \item Consent must not have more than one location it was changed at - (CMQ84)
    \item Consent must not have more than one medium it was changed in - (CMQ85)
    \item Every consent must have a timestamp indicating when it was changed - (CMQ86)
    \item Information about how the right to be informed was implemented must be specified - (CMQ88)
    \item Information part of right to be informed must be concise - (CMQ88)
    \item Information part of right to be informed must be transparent - (CMQ88)
    \item Information part of right to be informed must be intelligible - (CMQ88)
    \item Information part of right to be informed must be easily accessible - (CMQ88)
    \item Information part of right to be informed must use clear and plain language - (CMQ88)
    \item When the information relevant to the right to be informed was provided to the data subject must be specified - (CMQ89)
    \item Information relevant to the right to be informed was provided to the data subject must be provided at most within one month of obtaining the data - (CMQ89)
    \item If information relevant to the right to be informed is to be communicated to the data subject, it must be provided at most during the first communication with the data subject - (CMQ89)
    \item If data is to be disclosed to someone else, information relevant to the right to be informed must be communicated to the data subject at latest when the data is disclosed - (CMQ89)
    \item Information part of right to be informed must contain name and contact details of the controller’s representative - (CMQ90)
    \item Information part of right to be informed must contain name and contact details of the DPO - (CMQ91)
    \item Information part of right to be informed must contain purposes for processing - (CMQ92)
    \item Information part of right to be informed must contain legal basis for processing - (CMQ93)
    \item Information part of right to be informed must specify processing whose legal basis is legitimate interest - (CMQ94)
    \item Where personal data is not obtained from the data subject, information part of right to be informed must specify categories of personal data obtained - (CMQ95)
    \item Where personal data is not obtained from the data subject, information part of right to be informed must specify the sources of such data - (CMQ96)
    \item Where personal data is shared, information part of right to be informed must specify the identity of the recipients or categories of recipients - (CMQ97)
    \item Where personal data is transferred to a third country or international organisation, information part of right to be informed must specify the identity of the third country or international organisation - (CMQ98)
    \item Where personal data is stored, information part of right to be informed must specify the retention period - (CMQ99)
    \item Information part of right to be informed must specify the available rights - (CMQ100)
    \item Where consent is obtained from the data subject, information part of right to be informed must specify the right to withdraw consent - (CMQ101)
    \item Information part of right to be informed must specify right to lodge a complaint with the supervisory authority - (CMQ102)
    \item Information part of right to be informed must specify where personal data is obtained under statutory or contractual obligation, - (CMQ103)
    \item Information part of right to be informed must specify where personal data is obtained from the data subject under statutory or contractual obligation - (CMQ104)
    \item Information part of right to be informed must specify if automated-decision making, including profiling is being used - (CMQ105)
    \item Every record of a data breach must have a timestamp indicating when it occurred - (CMQ106)
    \item Every record of a data breach must have a timestamp indicating when the controller became aware of the breach - (CMQ107)
    \item Every data breach must be notified to the supervisory authority - (CMQ108)
    \item Every record of a data breach must have a timestamp indicating when it was notified to the supervisory authority - (CMQ109)
    \item Every record of a data breach must specify how the notification was provided to the supervisory authority - (CMQ110)
    \item Every record of a data breach must specify the identities of the supervisory authorities it was communicated to - (CMQ110)
    \item Every record of a data breach must specify if it is likely to result in a high risk to the rights and freedoms of the natural persons whose data is associated with it - (CMQ111)
    \item Every record of a data breach must specify the process used to determine if it is likely to result in a high risk to the rights and freedoms of the natural persons whose data is associated with it - (CMQ111)
    \item Every data breach must specify the data subjects affected by the data breach - (CMQ112)
    \item Every data breach must be notified to the data subjects whose personal data was associated with the breach - (CMQ113)
    \item Every record of a data breach must have a timestamp indicating when it was notified to the data subjects - (CMQ114)
    \item Every record of a data breach must specify how the notification was provided to the data subjects - (CMQ115)
    \item Every notification of a data breach to the data subject must provide information about the data breach - (CMQ116)
    \item Every notification of a data breach to the data subject must provide information about mitigating potential effects of the data breach - (CMQ117)
    \item Every record of a data breach must specify the data involved in the breach - (CMQ118)
    \item Every record of a data breach must specify the technical measures for the protection of data involved in the data breach - (CMQ119)
    \item Every record of a data breach must specify the steps taken to prevent or mitigate the effects of the data breach - (CMQ120)
\end{enumerate}

\section*{Summary}
Through this chapter, an analyses of information associated with GDPR and its compliance was presented. 
% information interoperability model
\autoref{sec:info:model} presented a model of information interoperability between entities as defined by requirements for GDPR compliance. The model provides an analyses of information requirements and information flows between different entities, and categorisation of information requirements as provenance records, consent information, compliance documentation, data processing agreements, and use of seals/certifications.
Its analyses also provides a strong motivation towards adopting a common information model for representation of all activities associated with GDPR compliance.

Following this, \autoref{sec:info:compliance-questions} presented `compliance questions' which aim to retrieve information relevant in evaluation of GDPR compliance. The section also provides the methodology used to formulate questions from authoritative sources. The compliance questions are accompanied with identification of assumptions and constraints which are useful towards establishment of information requirements and its validation.

The next chapter presents ontologies developed for addressing research objective $RO3$, and which utilise compliance questions presented in this chapter as competency questions in their ontology engineering process.