Data Governance in Marketing: How to integrate compliance-embedding mechanisms into existing business processes?

(1)

Data Governance in Marketing

How to integrate compliance-embedding mechanisms into

existing business processes?

Zijian WANG Student number: 10993460

University of Amsterdam Faculty of Science Thesis Master of Science in Information Studies

Track: Business Information Systems Final version: 10-7-2018 Supervisor: Tom van Engers

Examiner: Alexander Boer

Company Supervisor: Jannes Jakob (Jonas) Lodewegen

Abstract. Given the social and legal development over topics such as data

protection, it is pressing to address the data governance in the field of marketing. In light of the European legislation General Data Protection Regulation, the research is sought to compose a standardized mechanism to compliance embedding. Further, a case study of a data processor is exploited to illustrate the logic behind the proposed mechanism.

(2)

The General Data Protection Regulation (GDPR) is in effect as of the 25th_{, May 2018 in} the European Union (EU) member states (European Parliament, 2016). It imposes forces on personal data protection in various angles. For instance, the information collected should have a specific purpose and, in most cases, explicit consent from the data subject. Failing to comply with the legislation may result in a fine up to 20 million Euros or 4 percent of the global revenue of a company, whichever is larger (European Commission, 2016).

In the context of marketing, the emerging companies in providing marketing services, such as cloud-based Customer Relationship Management (CRM), Email marketing software, social media marketing tools, etc., are facing challenges to comply with the GDPR. The author looks into an Email marketing software service provided by the company Copernica, to illustrate the real-life challenges, as well as to propose a mechanism to ensure privacy by design. The research is sought to provide marketing practitioners and companies, worldwide, a case study in governing data in a privacy-driven fashion. Presumably, the mechanism is applicable to compliance-embedding under other legislations.

1.1. Research scope

Given that the GDPR is a European law, it is enforceable in all the member states of the EU. Despite that the scope of GDPR covers a wide range of institutions in both public and private sectors, the thesis focuses on the commercialization of personal data. Specifically, in the discipline of marketing. The field of marketing involves procedures that process personal data, in various approaches. The scope of this research falls into online marketing. Not only the academia is active in the field, but also real-life scandals have gathered attention from media and law enforcement authorities. For instance, Cambridge Analytica and Facebook are reported, investigated, and searched for the case of data breach and information manipulation. The stock price of Facebook has been affected negatively. For the period between 16th_{, March and 27}th_{, March, the price per} share has dropped by roughly 18%, which is the equivalent of 90 billion U.S. dollars.

That stated, the research aims to address both academic theories and commercial practice, to provide readers a holistic view on data governance in marketing.

1.2. Research questions

The ambition of the author lies in designing a compliance-proof mechanism that marketing companies can implement into the existing business processes. To realize that, legislations should be translated into a machine-readable format, as explained in section 5. Hence, the following three-step research question is proposed:

How can legislations be translated to machine-readable language? How can translated legislations be implemented into business processes?

How can the approach be generalized to other compliance-embedding requirements? The goal of suggesting a data governance mechanism should be achieved upon the successful investigation of the above three questions.

(4)

1.3. Case study

The company Copernica is an Amsterdam-based marketing software service provider. Its specialization lies in Email marketing. Philips, KPN, Toyota, among others, are customers of its Email marketing products. Copernica is the largest Email marketing company in the Benelux region and has users all over the world (Lodewegen, 2018).

It is crucial to differentiate the concepts of customer and consumer. In the case of a marketing service provider, companies which exploit its services are regarded as customers of the service provider. However, the consumers are the end-user benefit from the service provided, which are the receivers of the Email sent by the customers, i.e. the companies. Therefore, there is a triangulated relationship among the marketing service provider, customers and consumers.

Moreover, there are supervisory authorities in action, to check compliance of the GDPR and enforce punishment when necessary, according to Article 58: powers of the authorities.

2. Theoretical foundation

In this chapter, legal theories of different levels are explained. From general to specific, the chapter covers three definitions of reality and their appliance to the case selected, the legal relations and their presence in the case, and principles of the ‘privacy by design’. The research is built on the fundamental theories listed.

2.1. Three layers of reality

The reality is perceived through lenses of beliefs, desires and intention. According to van Engers and van Doesburg (2016), based on the work of Searl (2011), there are three layers of reality; sources of norms, institutional reality, and social reality. Each layer represents a generalized perspective on the issue at hand. To assist the understanding of data governance in marketing, the concept of three layers is further defined as the following table.

Table 1. The three layers of reality and its relevance

Layers Definition Interpretation

1 Sources of Norms The description of norms in natural language

Legislation, i.e. GDPR 2 Institutional Reality The interpretation of the

previous layer using justifications such as legal positions

The approaches companies adapted to respond to the regulation

3 Social Reality The reaction of individual agents, in various patterns of social interaction

The experience that

customers and consumers have while complying with the regulation

(5)

2.2. Legal relations

Given the nature of the GDPR, as a law, some basic legal concepts need to be made clear. Fundamentally, four legal relations are proposed by Hohfeld (1913): a. Power-Liability, b. Immunity-Disability, c. Duty-Claimright, d. Liberty-Noright. Van Engers and van Doesburg (2016)’s work includes the relations a., c., and the concept framework, and argues that the relations b. and d. are not as relevant. The author argues otherwise, further explanation on this can be found in section 7.3.

The perspective of Copernica is taken to detect the legal positions it corresponds in scenarios it might be hold liable. Generally, marketing service providers are in need of a legal clarification for their legal obligations and social responsibilities.

Figure 1 Simplified legal relations among stakeholders of Copernica

The above figure provides a simplified view on the legal relations among stakeholders of Copernica. For starters, Copernica, as a service provider, has duty (liability) to deliver the service to its customers; on the other hand, the customer has claim rights (power) over Copernica. However, Copernica has limited liability to the consumers, normally speaking, because it does not deal with the consumers directly. Instead, the customers do, and they will need to gather consents from the consumers and provide them with information needed. The legal relations can be very much complicated and case-specific.

There could be exceptional cases, in which data processor can be liable. However, for the sake of generalization, the outlier cases do not fall into the scope of this research. 2.3. Privacy

Privacy is an inter-discipline, attention-grabbing, and fast-growing academic field. European nations has been shedding lights upon privacy matters in recent decades and the discussion is heated along the years. Academics in Amsterdam devoted hard work in teaching, research and conference organizing to enrich the knowledge in the field. Copernica, which roots in Amsterdam, exposes itself to a social reality that privacy is

(6)

concerned, discussed and valued. Hence, it is of importance for Copernica to improve its software infrastructure as optimal as possible for privacy protection.

Among the trendy privacy theories, ‘privacy by design’ is the guideline for service providers in particular. It refers to systems that designed in aim of protecting privacy. The figure below listed the 7 fundamental principles of privacy by design.

Figure 2 The 7 Foundational Principles of Privacy by Design (Deloitte, 2015)

The above 7 principles guide the redesign of the Copernica Emailing service. The emphasis is on transferring the control towards the end of consumers’. Consumers should be able to control, monitor, revise and delete their personal information freely. According to the chapter 3 of the GDPR, Rights of the Data Subject, the newly designed system should allow consumers to operate the system by themselves along the data processing journey. The operation may range from giving consent to deleting profile. The approach adopted is known as privacy by design.

(7)

3. Methodology

To derive a theoretical generalization from the case study, in-depth literature review is conducted. Based on the literature at hand, the GDPR is analyzed thoroughly with a theoretical framework in check. A few clauses are selected to be tested in the context of Email marketing.

The research is conducted in an inductive fashion, for which upper ontology, such as the concepts of ‘data subject’, ‘controller’ and ‘processor’ in the GDPR, is broken down to domain-specific ontology, specifically for the field of marketing. The research method exploited for this research balances both the academic and social relevance.

Given the complexity of the software design, interviews with practitioners are conducted to find out the current infrastructure and desired functionality. Considering the interviews are informal, continuous, and unstructured. The author decided to not to include transcriptions; however, the useful information gathered is reflected in the business representation in the following section. Comparing to the existing business processes, suggestions are made to improve the compliance by implementing a standardized mechanism. A concept of mechanism is proposed based on the list of legal requirements for GDPR compliance. It contributes to the existed pool of knowledge by demonstrating a practical solution to a pressing legal issue at hand. That stated, this research exploits a design approach.

4. Case analysis

This chapter is sought to investigate the case of Copernica thoroughly, to provide an in-depth overview of its business processes, room for improvement and possible risks the GDPR may cause for its operation. The focus of the case is on the rights of data subjects, since the data subjects are the ones have claim right against the customers of Copernica. 4.1. Business Process Modelling

To assist the understanding of the business processes of the Copernica, a BPMN-based model is composed. The activities of Copernica and its customer are both demonstrated to identify the roles each party plays in controlling and/or processing the personal data of consumers.

(8)

(9)

The model is composed by the business modelling software Signavio, using the BPMN 2.0 as the notation rule. As the above figure shows, personal data are collected and processed by the customer to initiate the Email marketing campaign, instead of Copernica, which makes the customer a data controller in the context of GDPR. The sub-processes of ‘Design Email marketing campaign’ and ‘Follow up with the request’ can be found in Appendix III.

4.2. GDPR implications

The GDPR contains 99 articles, covering legal obligations of data subject, data processor, data controller and supervisory authority. This research limits the scope predominately to the rights of data subject, the full text of selected articles can be found in Appendix I. As crucial as the articles are, Copernica, as a data processor, is not liable directly; however, it is obligated to support its customers to be able to comply (Meesters, 2018). That stated, Copernica needs to introduce features in its software to assist its customers to comply.

Table 2 Selected articles, GDPR

Section Article

Chapter 3 Section 3

Rectification and erasure

Art. 17

Right to erasure (‘right to be forgotten’) Art. 20

Right to data portability Chapter 4 Section 1 General obligations Art. 28 Processor Art. 29

Processing under the authority of the controller or processor

The Table 2 shows the list of articles selected from the GDPR. The articles are selected for its representativeness in legal relations. They are translated into a machine-readable language in the following chapter. The articles of the chapter 3 define the rights of a data subject, which Copernica needs to ensure the ability of its customers to provide. In recent history, such privacy-related business requirements are suggested by the 1995 Data Protection Directive (European Data Protection Supervisor, 2018). Given its legal status as a directive, not all European countries have implemented it into the local legislation, even though its content, to a large extent, overlaps the GDPR. However, there are a few articles of the GDPR derived from the development of technology along the years, such as ‘the right to be forgotten’.

Governatori, Milosevic and Sadiq (2006) argue that many organizations have limited awareness of the compatibility of their business processes to external constraints such as legislations and business contracts. In light of the GDPR, several new features need to be introduced. According to Meesters (2018), among the requirements of the GDPR, the features that enable the right to be forgotten (Article 17) and the right to data portability (Article 20) are of great importance. Therefore, the articles 17 and 20 are selected to investigate for improved mechanism designs.

(10)

5. Knowledge representation

5.1. Knowledge representation in law: FLINT

Knowledge representation assists in translating legislation into computer-executable language. Researchers, such as Sartor (2006) and Governatori, et al. (2006), developed methods to translate legal sources to working mechanisms. Sartor (2006) aims at providing researchers with ‘a general introduction to normative positions’; hence, his representation of concepts is rather straightforward. For example, this is an action semantic representation of a simple behavior that Robert drinks: DoesRobert[drink]. In this

fashion, the action type, whether behavioral or productive, the actor, and the action are represented separately, which made it feasible to store and recompose elements when needed. Governatori, et al. (2006), on the other hand, exploit the deontic logic Formal Contract Language (FCL) to compose formal representation of contracts, which is complex but powerful.

Van Engers & van Doesburg (2016) proposed a method named Calculemus, and used a representation language called FLINT to represent legal sources. The representation is not as fragmented as Sartor’s approach, and not as abstract as the FCL. It formalized the institutional reality after interpreting the sources of names. In FLINT, it differentiates concepts horizontally, i.e. institutional fact (iFact) and institutional action (iAct), as well as vertically with precondition and postcondition. The iFact and iAct are in horizontal relations since that they are instances which change state spontenuously. By vertical relations, the author refers to the order of occurance. The language has been tested with a case of Immigration Law, among others. In this case, the privacy law GDPR is investigated. The following subchapters demonstrate knowledge representations based on selected articles of the GDPR respectively.

5.1.1. Compliance mechanism: Article 17

LEGAL SOURCE: Article 17 General Data Protection Regulation

TEXT: “The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay”

NORMATIVE RELATION: GDPR 17

iACT: [request erasure of personal data concerning data subject] ACTOR/POWER: [data subject]

ACTION: [request erasure]

OBJECT: [personal data concerning data subject] RECIPIENT/LIABILITY: [controller]

PRECONDITION: (

[personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed]

OR

[data subject has withdrawn consent] OR

[data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing]

(11)

OR

[data subject objects to the processing pursuant to Article 21(2)] OR

[personal data have been unlawfully processed] OR

[personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject]

) AND

NOT [processing of personal data is necessary for exercising the right of freedom of expression and information]

CREATING POST CONDITION: <duty to erase personal data of data subject> TERMINATING POST CONDITION: (void)

LEGAL SOURCE: Article 20.1 General Data Protection Regulation

TEXT: “The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided”

iACT: [to decide on the request portfolio of personal data concerning data subject] ACTOR/POWER: [data subject]

ACTION: [request portfolio]

OBJECT: [personal data concerning data subject] RECIPIENT/LIABILITY: [controller]

PRECONDITION: (

[the data subject has given consent to the processing of his or her personal data for one or more specific purposes]

OR

[the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject]

OR

[processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract]

) AND (

[the processing was carried out by automated means] AND

[the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible]

(12)

AND

[the right shall not adversely affect the rights and freedoms of others] AND

NOT [GDPR 17]

CREATING POST CONDITION: <duty to create the portfolio of data subject> TERMINATING POST CONDITION: <send the portfolio of data subject> 5.1.3. Compliance mechanism: Article 28.3

LEGAL SOURCE: Article 28.3 General Data Protection Regulation

TEXT: “Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.”

iACT: [to sign a contract that sets out subject-matter and duration of the processing] ACTOR/POWER: [supervisory authority]

ACTION: [sign contract]

OBJECT: [the contract that sets out subject-matter and duration of the processing] RECIPIENT/LIABILITY: [processor]

PRECONDITION: (

[Processing by a processor shall be governed by a contract] OR

[other legal act under Union or Member State law] )

AND

[the contract is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.]

CREATING POST CONDITION: <duty to comply with the contract that sets out subject-matter and duration of the processing >

TERMINATING POST CONDITION: < the contract is signed by the controller and the processor>

LEGAL SOURCE: Article 29 General Data Protection Regulation

TEXT: “The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law.”

NORMATIVE RELATION: GDPR 29 iACT: [process data]

(13)

ACTION: [allow to process data] OBJECT: [personal data]

RECIPIENT/LIABILITY: [processor] PRECONDITION:

[Instructions to process data is given by the controller] OR

[Data processing is required by Union or Member State law] CREATING POST CONDITION: <duty to process data>

TERMINATING POST CONDITION: <the data processing is executed>

5.2. Remarks

Visual representation of the legal relations for Article 17 and Article 20 are made to assist the understanding of the logic, which can be found in Appendix II.

Despite that Articles 17, 20 and 28 demonstrates unrelated scenarios, a linear relationship of power can be found in the order of: supervisory authority, data subject (consumer), data controller (customer) and data processor (service provider). The direction of power indicates how claim right is transferred in the relationship. Moreover, comparing Articles 28 and 29, it is evident that one party’s power may overrule another, which creates a disability-immunity relation. An analysis on above relations is presented in subchapter 6.2.

6. Concept development

6.1. Business process reengineering

The process overview of Copernica depicted in Figure 3 provides a general perspective of the whole business cycle of a contract. However, it is too simplified to illustrate legal relations. Therefore, two zoom-in versions of processes, representing special requests and data processing agreement respectively, are composed. The figure 4 demonstrates the flow of special requests such as the right to be forgotten as well as the right of portability (Articles 17 and 20). The figure 5 depicts the process of signing a contract with Data Processing Agreement (DPA) (Article 28.3).

The reengineering is aimed to provide a detailed view of the implementation of the business requirements. It is possible that the actual processes have been conducted as redesigned; nonetheless, it is necessary for practitioners to have a well-elaborated view on specific decision points that matter.

(14)

(15)

Figure 5 Business process representation: DPA*

* Attention should be drawn on the message exchange between the pools. Each out going message indicates the execution of a power or the fulfillment of a duty. The legal relations among pools are explained in the following section.

(16)

6.2. Legal relations

The Hohfeld legal relations, especially the power-liability relationships, can be found in the context of a legislation. In the case of GDPR, the following relations are identified based on the selected articles. The Article 17, right to erasure, and the article 20, right to data portability, both described a power (claimright) comes from the consumer’s side, then becomes a liability of the customer’s, which requires the customer to execute its power towards the service provider and activates a liability of its. The power is at the side of the data-subject i.e. the liability at the side of the controller. If the power is executed by the data-subject, then a duty is created at the side of the controller and the connected claimright at the side of the data-subject. This duty-claimright will be terminated if the controller executes his power to provide the data (in case of data portability), or to erase the data of the data-subject (in case of the request to be forgotten). Similarly, the Article 28, processor, defined the contract should be signed by both controller and processor, then the power of the authority converts to liabilities of both the customer and the service provider. Under Article 29, either the authority, or the customer, may execute the power to allow any person to process. Hence, the liability is the service provider’s.

Figure 6 Legal mechanism representation (example Power-Liability)

While above examples hold for the majority of the cases, there are exceptional cases should be allowed by the mechanism. For instance, the powers with conflicting goals. The Article 29, processing under the authority of the controller or processor, compared to Article 28, has a potential scenario of conflicting instructions from multiple power holders. Then, as the figure 7 shows, if the supervisory authority executes its power on the data processor for certain actions to be taken, while the data controller instructs otherwise, then the authority’s power overrules, and creates disability on the controller’s part and immunity on the processor’s part in response to the controller’s request.

(17)

Figure 7 Legal mechanism representation (example Disability-Immunity)

To conclude, there are two types of generalized legal relations identified. Firstly, if a linear power chain can be identified, then the power-liability relations are hierarchical, as illustrated by figure 6. Secondly, as depicted in figure 7, if two or more powers are in conflict, an overruling power should be identified and set in effect, which makes the other powers disabled and creates the other legal relation: disability-immunity.

6.3. Mechanism

For each of the selected articles, there is a unidirectional flow of power. The power can be originated by either supervisory authority, the data subject, or the data controller, and leads to the generation of a liability of the receiving party. It requires a separate process to fulfill the requirements of the duty. For example, the obligation of a DPA comes from the execution of power of the supervisory authority, which creates liabilities for both the customer and the service provider to comply, and leads to the processes of creating, agreeing and signing the DPA. In general, legislations can be translated in such manner as long as the flow of liabilities is defined. The power-holding party triggers a set of processes by executing the power. Once the power is executed, a duty is activated from the receiving side. Upon the time a duty is triggered, actions need to be conducted to fulfill the duty. The integrated representation including both functional and procedural perspectives is shown in figure 8.

(18)

7. Discussion

7.1. Generalization

As the legislation catching up with the development of information technology, it is foreseeable that a standard mechanism for compliance embedding is of demand. Derived from the case investigated in this work, a generalized step-by-step guideline is proposed as the following:

i. Selecting the relevant legal sources

ii. Translating the legal sources into machine-readable format iii. Modelling the current business processes

iv. Identifying types of legal relations

v. Integrating legal requirements into business processes vi. Reengineering the business processes accordingly

For steps ii. and iii., the research has utilized the FLINT and the BPMN 2.0 respectively. They are state-of-the-art approaches for legal translation and business process modelling; that stated, they are replaceable if further developed or better accepted practices become available. As for the step iv., the author identified to common scenarios, namely a) the chain of power and b) the contradicting powers. The legal source can be inserted in the business process representation with an URL with a remark of the type of the legal relation. The type of legal relation should guide the reengineering of the business processes.

7.2. Limitations

The mechanism is smart, concise, and easy to implement. Yet, it has a number of flaws that need to be solved. For example, the timing of tasks are not feasible to be generalized with the BPMN, nor the FLINT, even though both can include time constrains. Often, a legal obligation is required to be fulfilled within a time limit. This requirement is not included in this work.

Moreover, unfortunately, it is not tested if the mechanism can be generalized to the reality of each organization, considering the change management is not covered in the research. The management of personnel plays a vital role in information system transformation; unfortunately, it does not fall into the scope of this research.

7.3. Implications for future work

The research conducted recommended a data governance method to (re-)design the mechanism to comply with legislation. Knowing that the legislation is never perfect, specific cases of violation would be revealed over time. Such cases may aspire researchers to look into the compliance-embedding further.

Meeting the legal obligations is a must to survive, but exceeding expectations of customers makes companies thrive. Marketing software companies could benefit from further developing features that provide their customers with options to tackle specific cases in line with the legislation. For instance, the Article 8 of the GDPR states special conditions to children’s consent, which might be applicable to the business purposes of customers in businesses including cinema, casino, and night clubs, etc. Nonetheless,

(19)

apart from the under-aged group, there are other groups classified as ‘special categories’ in Article 9. That stated, it is recommended for researchers to test out the design with various articles and laws. Moreover, as a technology service provider, an interface is needed to automate the transition from a power to a liability. The legal responsibilities should be communicated concisely and straightforward using the interface. A mock-up of a simple interface is attached as Appendix IV. Even though conceptual, it is a starting point for implementing the mechanism for the front-end, which is a potential area for future work, as well.

Apart from the case-specific implications, it is advisable to improve the knowledge representation language FLINT. According to the representation of the article 29, it is not feasible to demonstrate the conflicting powers and the impact of one power overrules another. Therefore, it is worth investigating whether the FLINT should include the legal relations of immunity-disability and liberty-norights.

In conclusion, the research has contributed to the pool of knowledge with a concept of a mechanism embedding compliance into business processes. Best practices in the field, such as FLINT and BPMN 2.0, are exploited to demonstrate the proposed mechanism. With changing the dynamics in law practices in 21st_{century in mind, the author deems} this concept ‘vague but exciting’.

(20)

Acknowledgement

This work is realized thanks to a joint support by dedicated supervisors from both the University of Amsterdam and Copernica. With much gratefulness and thankfulness in mind, the author would like to thank his academic supervisor Professor Tom van Engers, company supervisor Mr. Jannes Jakob (Jonas) Lodewegen for the valuable, constructive and timely feedback along the research. Further, special thanks to Mr Wenyun Wang and Ms Nailian Bai, who made the experience of participating and thriving in a master program at UvA financially possible, and Miss Wanting Wei, who supported the author emotionally throughout the journey of the education in Amsterdam.

References

Deloitte. (2015). Privacy by Design: Setting a new standard for privacy certification. European Commission. (2016, May). Data protection in the EU. Retrieved from

European Commission: https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en

European Data Protection Supervisor. (2018, May 1). The history of the General Data Protection Regulation. Retrieved from EDPS: https://edps.europa.eu/data-

protection/data-protection/legislation/history-general-data-protection-regulation_en

European Parliament. (2016). REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016. Official Journal of the European Union, L 119/ 1-88.

Governatori, G., Milosevic, Z., & Sadiq, S. (2006). Compliance checking between business processes and business contracts. Proceedings of The 10th International Enterprise Distributed Object Computing Conference (pp. 221-232). Hongkong: IEEE.

Hohfeld, W. N. (1913). Some Fundamental Legal Conceptions as Applied in Judicial Reasoning. Yale Law Journal, 16-59.

Lodewegen, J. J. (2018, April 13). Company information of Copernica. (Z. Wang, Interviewer)

Meesters, A. (2018, May 1). Copernica's status in GDPR compliance. (Z. Wang, Interviewer)

Sartor, G. (2006). Fundamental legal concepts: a formal and teleological characterisation. San Domenico: European University Institute.

van Engers, T. M., & van Doesburg, R. (2016). Modeling the Interpretation of Sources of Norms. The Eighth International Conference on Information, Process and Knowledge Mangement (pp. 41-50). Venice: IARIA.

van Engers, T., & Boer, A. (2011). Public Agility and Change in a Network Environment. Journal of Democracy, 99-117.

Data Governance in Marketing: How to integrate compliance-embedding mechanisms into existing business processes?