Skip to toolbar

Community & Business Groups

Data Privacy Vocabularies and Controls Community Group

The mission of the W3C Data Privacy Vocabularies and Controls CG (DPVCG) is to develop a taxonomy of privacy and data protection related terms, which include in particular terms from the new European General Data Protection Regulation (GDPR), such as a taxonomy of personal data as well as a classification of purposes (i.e., purposes for data collection), and events of disclosures, consent, and processing such personal data.

The DPVCG was created as an outcome of the W3C Workshop on Data Privacy Controls and Vocabularies in Vienna in 2017, and started on 25th May 2018 – the date of the enforcement of GDPR. Since then, the DPVCG has worked to fulfil its aims and objectives, and produced the Data Privacy Vocabulary (DPV) as a deliverable.

Membership to the group is open to all interested individuals and organisations. To join the group, you need a valid W3C account – which is free to get and can be requested here. The group meets usually through online meeting calls, details of which, including past minutes, can be found here. The group also interacts through a mailing list regarding topics, discussions, sharing of agendas, actions, and other relevant items. The resources and work relevant to the group is hosted on the GitHub platform under the DPVCG name.

The group is currently chaired by:

Participation in Group Activities

The working of the group is fairly open and transparent in its process, with most of the information present on the wiki. For past work, actions, issues, and records – please refer to the wiki and threads on the mailing list. Anyone can use the mailing list to ask questions, suggest topics, raise issues, and offer solutions. Non-members might receive an automated reply asking them to authenticate their email or email address for posting.

Similarly, calls are usually open to attend, with the agenda shared on the public mailing list. Call details may be shared on the internal mailing lists accessible to only members for security purposes – so it may be best to ask the chair(s) or a member for attending a call.

General questions regarding what the group considers in scope can be determined from the aims and objectives. Specific queries or propositions should be conveyed to the mailing list. For issues regarding the DPV, including addition of concepts or a query or other relevant topics – you can use the mailing list or the issues feature in a GitHub repo.

Data Privacy Vocabulary (DPV)

The DPV is a vocabulary (terms) and an ontology (relationships) serialised using semantic-web standards to represent concepts associated with privacy and data protection, primarily derived from GDPR. It enables representation of which personal data categories are undergoing a what kind of processing by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal basis (e.g., consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g., storage locations and storage durations) in place.

The DPV is useful as a machine-readable representation of personal data processing and can be adopted in relevant use-cases such as legal compliance documentation and evaluation, policy specification, consent representation and requests, taxonomy of legal terms, and annotation of text and data.

The DPV is an evolving vocabulary – as the DPVCG continues to work on updating it with broader concepts as well as enriching its hierarchy of concepts. For this, we invite contributions of concepts, use-cases, requirements, and applications.


Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

drafts / licensing info

DPVCG Vocabulary
DPVCG GDPR Legal Basis Vocabulary

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

Data Protection Aspects of Online Shopping – A Use Case

By Bud P. Bruegger (ULD) , Eva Schlehahn (ULD), Harald Zwingelberg (ULD)


When illustrating concepts pertaining to data protection, it is often useful to have a concrete use case at hand. The following post therefore provides such a use case. Namely, it describes the various aspects of the processing activities of an online shop. In particular, the aspects include the involved entities, the purposes pursued by the processing, the legal bases for the processing, the data necessary to fulfill the purposes, as well as the storage period necessary for this data.

It is hoped that this use case can facilitate discussions on how to best describe data protection aspects of processing activities. In that sense, it is regarded a contribution to the Data Privacy Vocabulary Community Group.

1. Involved Entities

The example of online shopping has a number of participating entities. In particular these are:

  • The online shop who acts as controller.
  • One or several shipping services which for the purpose of this use case illustration are assumed to act as processors of the online shop.
  • Customers who act as data subjects.

2. Purposes

The processing activities of the example online shop pursue the following purposes:

  • Order Processing
  • Payment
  • Order Delivery
  • Status Notification
  • Customer Convenience
  • Accounting
  • Customer Support
  • Warranty
  • Continuing Customer Relationship

While these purposes are treated separately for analytical purposes, in actual processing there may be a strong interdependency of purposes and a processing step may involve multiple purposes.

The above purposes described in further detail in the sequel:

2.1 Order Processing

Order Processing is concerned with which items are contained in an order, how these items can be obtained internally in the shop, what their cost is, and what is necessary to package them.

2.2 Payment

This purpose is concerned with obtaining the payment for the merchandize and the shipping of the merchandize.

2.3 Order Delivery

This purpose is concerned with how the ordered merchandize can be delivered or shipped to the customer.

2.4 Status Notification

This purpose is concerned with keeping the customer informed about the current status of the order. Such notifications typically include tracking information for the shipment.

2.5 Customer Convenience

This purpose is concerned with rendering it easier to customers to interact with the online store. It focuses particularly on avoiding that customers repeated have to type in the same data. For this purpose, it is for example common to store addresses and payment instrument data across individual orders.

2.6 Accounting

Accounting is concerned with the operations of the online shop as a commercial enterprise, as well as the legal requirements of accounting and taxation.

2.7 Customer Support

Customer support, while potentially more general in character, is here only concerned with a single order. In particular, it has to handle cases where shipments are delayed or lost, or where the merchandize is faulty or unsuited. The according processing supports, among others, the return of merchandize and possible reimbursements.

2.8 Warranty

The example assumes that the online shop manages the warranty of certain products. For this purpose, it needs to be possible to determine that a possibly warranty claim indeed refers to merchandize sold by the store and that the warranty period has not yet expired.

2.9 Continuing Customer Relationship

In this example, continuing customer relationship is concerned with informing customers of special offers and new items. It is assumed that there is no customization of offers for specific customers and that the activities are therefore restricted to the delivery of information to customers.

3. Legal Bases

The different parts of the processing that make up online shopping are typically sustained by different legal bases. The following discusses possible legal bases for each purpose:

3.1 Order Processing

The purchase of merchandize from an online shop can be considered a contract. Order processing can thus be based on Article 6(1)(b) GDPR “processing is necessary for the performance of a contract”.

3.2 Payment

Payment is also necessary for the fulfillment of the same contract and is thus also covered by Article 6(1)(b) GDPR.

3.3 Order Delivery

The same goes for order delivery that again is covered by Article 6(1)(b) GDPR.

3.4 Status Notification

Status notifications are today considered an integral part of the operations of an online shop. Notifications can thus be considered part of the core activities pursued to fulfill a the contract of the purchase and the legal basis is thus represented by Article 6(1)(b) GDPR.

3.5 Customer Convenience

Customer convenience is not required for the core activity to fulfill the contract that regulates a purchase. It must therefore be an option that is offered to customers who need to grant their consent according to Article 6(1)(a) GDPR.

3.6 Accounting

Accounting constitutes one of the core activities of any commercial enterprise. It is further governed by laws on commerce (in Germany, for example, the Handelsgesetzbuch) and taxation (in Germany, for example, the Abgabeordnung). Accordingly, the matching legal basis for the required processing in the GDPR is either Article 6(1)(f) “legitimate interests pursued by the controller” or, more fittingly, Article 6(1)(c) “compliance with a legal obligation”.

3.7 Customer Support

Customer support is necessary for the fulfillment of the contract of a purchase. It is thus also covered by Article 6(1)(b) GDPR.

3.8 Warranty

Warranty is also an integral part of a commercial operation. It may also be mandated by law. The suitable legal basis is thus either represented by Article 6(1)(b) or 6(1)(c) GDPR, respectively.

3.9 Continuing Customer Relationship

An online shop informing its customer base about offers and news can under certain circumstances be based on the legitimate interest of the online shop, or alternatively it may be possible based on request (i.e., consent) by the customer. Accordingly, the legal basis is either Article 6(1)(f) or 6(1)(a).

Some EU Member states (such as Germany) have introduced further requirements compared to the GDPR in their national data protection laws. E.g. in Germany, there are differentiations made between marketing via email or via postal address. Moreover, it may be regulated nationally which customer data can be used specifically for marketing. One selected example: In Germany, *email* marketing for own products or products of partner enterprises needs to be based on explicit consent, thus excluding the possibility of legitimate interest.

4. Necessary Data Elements

The following discusses which data elements are necessary for the different purposes.

4.1 Order Processing

The data elements necessary to support order processing include at least:

  • An identifier for the customer (customer number)
  • An identifier and number of for each ordered item

4.2 Payment

The data that are necessary here include the following:

  • Total amount due
  • Payment instrument, for example:
    • name of card holder
    • credit card number
    • expiration date
    • possibly the CVV Number (“Card Verification Value”)
  • Invoice data:
    • Name of person or company
    • Possibly VAT number of company
    • Billing address

4.3 Order Delivery

To deliver an order, the following data is required:

  • Shipping address
  • Optionally contact information such as a telephone number that the shipping service can use to optimize delivery
  • Selected shipping options (currier service, standard or express, etc.)

4.4 Status Notification

To deliver status notifications, a suitable contact, such as an e-mail address of the customer is necessary.

While there are evidently alternative ways of delivering notifications, as for example as messages accessible from customer accounts, for simplicity it is assumed that the store pushes messages to the customer.

4.5 Customer Convenience

4.5 Customer convenience, to avoid the need for repeated input of the same data by the customer, stores these data for later reuse. This is typically done in connection with an account that requires registration. It typically includes addresses for shipments and invoices, as well as payment instrument information.

4.6 Accounting

The data necessary for accounting largely depends on national legislation and the shop’s accounting practices. It is therefore not possible to describe what data is actually necessary here.

4.7 Customer Support

Customer support not only needs access to the data regarding the order, the payment, and the shipping, it also needs to manage the communications about the support case with the customer.

4.8 Warranty

To process warranty claims, a record of which covered merchandize was sold on which date is necessary. Information about the amount paid for the merchandise may also be necessary in case of the possibility of reimbursement (in addition to repair and replacement). If the merchandise is identified by an individual serial number, storing serial number and date may be sufficient to determine whether the merchandise is still covered by warranty; in case that the individual pieces of merchandize are undistinguishable and could have been purchased elsewhere, data about the identity of the buyer may also be necessary.

4.9 Continuing Customer Relationship

Continuing customer relationship requires contact information, such as an e-mail address, in order to be able to send the relevant information.

5. Necessary Storage Periods

Processing activities for different purposes usually have different life spans until they are completed. It is a principle of European data protection that personal data shall be deleted as soon as it is no longer needed for the purpose (data minimisation principle, see Article 5(1)(c) GDPR). The following therefore discusses how long data is needed for the different purposes.

5.1 Order Processing

The processing of an order usually ends when the merchandize is packaged and sent off. However, when this happened, the information obtained for the order processing usually cannot be deleted yet. The reason being that the data it is still needed for other purposes such as payment, customer support, or accounting. The necessary storage period is therefore determined by these other purposes.

5.2 Payment

Data on payment instruments is only necessary until the payment has been fully received. The data may however live on for other purposes such as customer convenience that stores this data for use in future orders.

5.3 Order Delivery

Data needed for delivery of an order are usually no longer needed once the shipment has arrived at the shipping address. For other purposes, such as customer support, they may have to be stored longer, however.

5.4 Status Notification

Contact information for the delivery of status notifications is no longer necessary once the merchandise has been delivered to the shipping address.

5.5 Customer Convenience

Customer convenience data are only necessary as long as a customer has recurring contact with the online shop. In the case where a customer has not had any contact for a certain period of time (for example, a year), the data is unlikely to be further used and can be deleted. In case that the data also contains contact information of the customer, a notification in advance of the deletion may leave the choice of deletion to the customer.

5.6 Accounting

In particular tax laws require a relatively long retention period of accounting data. For example, in Germany, certain data need to be stored for 10 years.

5.7 Customer Support

Customer support typically requires the storage of data initially collected for other purposes (such as order, payment, or shipping) beyond the life time of those purposes. In particular, after delivery of the merchandize and thus the fulfillment of the purchasing contract, the customer must be given a certain time period (for example, 3 months), in which to initiate a customer support ticket. There may be national laws governing such time periods and the rules with which the enterprise must comply. Once this period has expired without opening a ticket, the data is no longer required. If a support ticket was opened, the communication data that was collected in order to process the ticket can be closed a certain period after the closure of the ticket.

5.8 Warranty

Data kept to support warranty can be deleted after the expiry of the warranty period. Minimal warranty periods may be prescribed by law.

5.9 Continuing Customer Relationship

Contact data to send informational material to customers should not be kept indefinitely, particularly if consent was used as a legal basis. Consent should always be given for a limited period of time (for example, a year) at the end of which customers can be asked to renew their consent or simply let it expire.

Two vocabularies

The Data Privacy Vocabularies and Controls Community Group published two vocabularies to describe personal data and the ways it can be processed. The vocabularies are meant to be used in software that automates verifications against the European General Data Protection Regulation (GDPR).

The group describes the vocabularies as ‘version 0.1’, because it is likely that, on further review, there are both too many and too few terms in them. That’s why the group asks for feedback.

The documents asked for comments to be sent before the 15th of September 2019, but that doesn’t mean that comments won’t be accepted anymore. It just means comments may not get into the next version, but into a later one.

Data Privacy Vocabulary

The first of the two vocabularies is called ‘Data Privacy Vocabulary v0.1’. It provides terms (classes and properties) to annotate and categorize instances of legally compliant personal data handling according to the EU General Data Protection Regulation. The terms it defines fall into a number of groups:

  • Classes of personal data, such as address, family relations, credit rating, hair color, job, religion and much more.
  • Purposes of data processing, such as identity verification, personalizing user interfaces, academic research, delivery of goods, product recommendations, etc.
  • Categories of data processing, such as acquiring the data, erasing, copying, sharing, anonymising and combining.
  • Technical and organisational measures required by the GDPR and other regulations to protect data, including anonymisation, guidelines, contracts, staff training and encryption.
  • Properties of consent, such as the consent notice, the expiry time and the method by which consent was obtained.
  • Roles, such as Data Subject, Data Controller, Recipient, Third Party and Child (a special kind of Data Subject).

GDPR Legal Basis Vocabulary

The second vocabulary is called ‘DPVCG GDPR Legal Basis Vocabulary’. It defines terms for the legal bases for personal data processing defined in the GDPR, i.e., all the circumstances under which data processing is allowed.

The group identified 17 classes of legal bases in the GDPR, including explicit consent, a legal obligation, the public interest, preventive medicine and the fact that a data subject already made the data public.


Feedback on these vocabularies can be given by email to <> or by raising issues or submitting ‘pull requests’ (patches) on the group’s GitHub repository.

Call for Participation in Data Privacy Vocabularies and Controls Community Group

The Data Privacy Vocabularies and Controls Community Group has been launched:

The mission of the W3C Data Privacy Vocabularies and Controls CG (DPVCG) is to develop a taxonomy of privacy terms, which include in particular terms from the new European General Data Protection Regulation (GDPR), such as a taxonomy of personal data as well as a classification of purposes (i.e., purposes for data collection), and events of disclosures, consent, and processing such personal data.

The Community Group shall officially start on 25th of May 2018, the official data of the GDPR coming into force, as a result of the W3C Workshop on Data Privacy Controls and Vocabularies in Vienna earlier this year.

It is the goal of the CG to harmonize related efforts and bring together stakeholders that already have brought forward proposals to develop respective vocabularies to enable semantic interoperability and interchange of transparency logs about personal data processing, enable data portability for data subjects, etc. The exact scope of use cases related to making personal data processing interoperable by respective standards in order to ease proof of compliance with the GDPR and related privacy protection regulations will be the first deliverable of the CG.

More concretely, the following steps and deliverables are planned so far.


  1. Use cases and requirements: in a first step we will collect and align common requirements from industry and also from other stakeholders to identify areas where interoperability is most needed in the handling of personal data. The outcome shall be a prioritized list of requirements for what needs to be covered by shared vocabularies to enable interoperability in the identified use cases.
  2. Alignment of vocabularies and identification of overlaps: in a second document, we will collect existing vocabularies and standardization efforts to identify their overlaps and suitability as starting points to minimally and extensibly cover the requirements prioritized in step one.
  3. Glossary of GDPR terms: a third deliverable will be an understandable glossary of common terms from the GDPR and how they shall be covered by the agreed vocabularies.
  4. Vocabularies based on the heterogeneity or homogeneity of the agreed upon use cases and requirements, we will define a single or a modular set of vocabularies for exchanging and representing interoperably: personal data, purposes/processing, disclosure/consent, anonymisation, and transparency logs.


For the moment, we plan the following milestones:

  • 24 May 2018: Presentation of this initial charter draft to initial stakeholders
  • 25 May 2018: Launch of the CG by registration as a proposed W3C Community Group
  • 26-30 May 2018 until 30 June 2018: dissemination of invitations to participate in the CG & feedback collection on the present charter draft.
  • 29-31 August 2018: 1st Face-2-face meeting co-located at MyData2018 in Helsinki, Finland, agreement on first steps and regular telephone conference slots and commencement of biweekly telephone conferences.
  • 12-14 November 2018: 2nd Face-2-face meeting co-located with the European Big Data Value Forum 2018 in Vienna, Austria. The goal of this meeting is have set up a common environment to jointly work on deliverables, and have identified editors for first drafts.

Milestones beyond the second meeting shall be defined as outcome of these first two F2F meetings. The current goal is to agree on first public drafts of minimal sets of vocabularies to be finished by December 2018, with first stable working drafts being reached latest on 25 May 2019.

The CG shall work in an agile manner to iteratively propose and refine its scope, starting from (i) collecting and prioritizing requirements and existing input vocabularies, (ii) extracting minimal overlaps/coverage, (iii) agreement on minimal representations, (iv) iterate.

In this sense the deliverables structure above shall be understood as current snapshot of the planned focus which directly reflects the prioritized outcomes of the Vienna workshop. If more is needed in terms of standardization, e.g., a discussion of protocols/architectures then we shall be open to extend the scope later on, as soon as first results have been achieved on those primary, initial goals.

The CG invites all interested stakeholders to contribute, particularly those people who expressed interest at the Vienna workshop, but as all W3C CGs considers itself an Open Community with the intention to grow to a critical mass to finally bring its results into a W3C working group for standardization.



In order to reach our goal to launch this CG on 25 May 2018 please support the launch of this group. You will need a W3C account to do so; request an account if necessary.

In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2018-05-23 by Axel Polleres. The following people supported its creation: Axel Polleres, Simon Steyskal, Iliana Petrova, Jose Emilio Labra Gayo, Joss Langford, Uros Milosevic, Rigo Wenning, Andrea Perego, Sabrina Kirrane. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at

Thank you,
W3C Community Development Team