GDPRhub style guide

From GDPRhub
Revision as of 08:25, 21 November 2022 by Kv (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

We try to keep articles and pages on GDPRhub as consistent and understandable as possible.

Given the very different national traditions on citation and formatting in legal writing, we have tried to develop a middle ground that ensures that all readers can fully understand the articles on GDPRhub. Please follow this guide when editing GDRPhub.

A helpful tip: if you are not sure about GDPR-related terminology in a specific language, go to the GDPR on EUR-Lex and look for the terms used in the provisions of the GDPR in that specific language.

Example: In the Netherlands, the GDPR is called AVG (= Algemene Verordening Gegevensbescherming).

General hints when editing GDPRhub[edit | edit source]

The GDPRhub aims at making legal texts from across the EU accessible to everyone.

The legal culture of each EU/EEA country is characterised by very local traditions, customs and styles. We therefore ask all editors to follow these basic principles for the sake of consistency:

  • Use Simple English, as English is not the first language for most readers.
  • Try to use English formatting (e.g. 1,000 or 1000 instead of "1.000"), but not American formatting (28.5.2018, not 5/28/2018).
  • Use British English, instead of American English (e.g. "organisation" instead of "organization, and "honour" instead of honor).
  • Provide the necessary context, so that a foreign reader (that may not know the local procedure or facts) can follow you.
  • Use our templates when you create a new page.
  • Use the text editor (not the visual editor) when possible, to ensure you can include all necessary code.
  • Check that a new page is categorized properly, so that readers can find it.

Constructing your sentences[edit | edit source]

Start with the subject, the verb, and the object[edit | edit source]

Legal sentences have a tendency to become rather complicated, especially when they contain a lot of detail and separate the key words. Help your readers by putting the subject and the verb towards the beginning of the sentence, and avoiding abundant qualifiers or conditions before the subject and verb.

Example: The DPA found a violation of Article 32 GDPR because the controller failed to take technical and organisational measures to protect the website visitors.

Example: Not Because of the lack of technical and organisational measures of the controller to protect the website visitors, the DPA found a violation of Article 32 GDPR.

Use the active voice rather than the passive[edit | edit source]

The active voice can make the reading easier, as it respects the expectation that the subject of the sentence will perform the action of the verb. It can also make the writing more lively and generally requires fewer words.

Example: The court found a violation of Article 6(1)(a) GDPR.

Example: Not A violation of Article 6(1)(a) GDPR was found by the court.

Use the past simple tense[edit | edit source]

When writing the summary, use the past simple tense in order to be consistent between decisions and in order to be consistent in the GDPRtoday newsletter.

Example: The Spanish DPA held that fingerprint clock-in systems are not acceptable under Article 5(1)(c).

Example: Not The Spanish DPA has held that fingerprint clocking systems are not acceptable under Article 5(1)(c).

Example: Not The Spanish DPA holds that fingerprint clocking systems are not acceptable under Article 5(1)(c).

Use the € symbol, but the official codes for other currencies[edit | edit source]

When talking about money, use the € symbol, but the official codes for other currencies. Put them always before the number. The € symbol is not followed by a space, but the codes are.

Use a comma if the number is 1,000 or bigger, don't use a comma if it's smaller.

Example: The Romanian DPA fined Facebook Romania €5,000 (RON 25,000).

Consistent indication of dates[edit | edit source]

When indicating dates, use the following format.

Example: On 28 February 2022, the data subject filed an access request.

Example: Not On 28.02.2022, the data subject filed an access request.

Example: Not On February 28, 2022, the data subject filed an access request.

The summary section[edit | edit source]

Short summary[edit | edit source]

The brief (200-250 characters) summary of the GDPRhub decisions is particularly important for the GDPRtoday newsletter. The aim is to automatically extract this text and use it for the weekly newsletter. Therefore, consistency and conciseness are even more important for this section than for the other parts of the summary. Please try to always follow the subsequent structure when drafting the summary, and reserve more detailed sentences for the following sections of the summary.

Keep in mind:

  • The short summary should contain the following elements: WHO against WHO for WHAT action according to WHICH provision of the GDPR. You can be flexible with the inclusion and order of the elements depending on each particular case.
  • Convey the key takeaway from the case without, for example, overwhelming a morning commuter reading this on their phone with information.
  • Also please convert the fine amount to euros if in another currency (any online currency converter is fine). Remember to use the € symbol with no space before the amount

Try to avoid:

  • General statements like (like "X violated the GDPR") as this gives readers very little information.
  • Company names (like "Creditinfo Lánstrausti hf.") unless the company is generally known in Europe (like "Amazon").
  • Say "a controller" (when the type of company is irrelevant) or "a credit ranking agency" (specific type of company).

Example template: The 'X' DPA fined 'Y' €50,000 for violating Article 'Z' GDPR by illegally processing the image of a data subject.

Example 1: The Spanish DPA imposed a €35,000 fine on an energy company for the violation of Articles 5(1)(f) and 32 GDPR because an employee accidentally sent an email to the data subject with personal data belonging to other clients.

Example 2: The Danish DPA reprimanded an online marketing service. The controller, among others, lacked legitimate interest under Article 6(1)(f) GDPR to process data on questionnaires. Also, it did not sufficiently inform data subjects of the inclusion on a "no-thanks" list against Articles 12(1) and 13(1)(d) GDPR.

Example 3: The Hungarian DPA ordered the operator of a weather forecasting website to stop transferring data to the US via Google ad services. The DPA held that the website operator used Google Analytics without implementing adequate safeguards for U.S. data transfers as required by Article 46 GDPR.

Facts[edit | edit source]

The Facts section is for describing what happened prior to the DPA/court taking action (unless this decision is already an appeal). Do not include the violation or the fine here. Rather, say something along the lines of "The controller did/did not do X... The data subject filed a complaint because X." You may include the data subject's and/or the controller's arguments here but do not mention what the DPA/court held.

Keep in mind:

  • Try to be as chronological as possible. Rather than starting with the complaint being filed e.g. in October 2021 and then going back to the alleged violations in October 2020, start with what happened in October 2020 and finish with October 2021.
  • Focus on the facts that are relevant to the data protection issue at hand. The decision may concern other areas of law - leave out the facts that are only relevant to these other areas of law but not to data protection law.
  • Establish who was the data subject and who was the controller/processor at the beginning. E.g. "X, an electronics retailer (the controller), took back its customer's (the data subject) used TV." After that, refer to them consistently as the controller and the data subject throughout the whole summary.
  • If it is an appeal, then previous decisions should be summarised here (after you explain what the crux of the matter was).

Holding[edit | edit source]

The Holding is the "legal principle to be drawn from the decision". It is the rationale for the decision on the core dispute of the case. Indicate what the violation was and why. Explain the reasoning of the DPA with reference to the relevant provisions of the GDPR and national law. You may also include aggravating or mitigating circumstances here, if applicable.

Keep in mind:

  • If the decision concerned other areas of law, only mention them to the extent that it is relevant to data protection law. For instance, whether the controller lawfully collected a debt may be a prerequisite for finding whether the processing was lawful or not, but it is always important to circle back to the fact that the issue is whether the processing was lawful, not whether the debt collection was.
  • If multiple GDPR violations were found, it is usually a good idea to separate it into different paragraphs and start each paragraph with "First, the DPA held.." and "Second, the DPA also.." etc.
  • Do not say e.g. "The DPA held that under Article 21(2) GDPR, data subjects have the right to object to the processing of their personal data for direct marketing purposes." That's what the law itself says, that was not what the DPA held. Instead, you can say that the DPA "noted" or "pointed out" that data subjects have such a right and then follow up with e.g. "Hence, the DPA held in this case that because X, the controller violated Article 21(2) GDPR."
  • Similarly, for factual findings (e.g. that the controller did not erase the data), it is better to say "the DPA found". "The DPA held" should be used in regard to the actual ratio, e.g. "The DPA held that the meaning of 'sex life' under Article 9(1) GDPR encompasses...", "The DPA held that X constitutes a legitimate interest under Article 6(1)(f) GDPR", "The DPA held that Article 15(3) GDPR must be interpreted as.." or "The DPA held that the controller violated Article 6(1) GDPR."

Try to avoid:

  • Restating what the law says without drawing any conclusions for the particular case. Do not only write, e.g. "The DPA recalled that Article 4(1) GDPR defines 'personal data' as any information relating to an identified or identifiable natural person", but also try to explain why the DPA considered that the information in question was considered personal data under Article 4(1) GDPR.
  • Unnecessarily long explanations following the structure of the full decision. The DPA's structure may not always be suitable for the purposes of a GDPRhub summary, e.g. because the decision also concerned other areas of law or because the decision contained a number of procedural issues irrelevant to the GDPR violations.

Comment section[edit | edit source]

The summary is supposed to be an objective overview of the decision without including personal opinions of the author. You are welcome to add any remarks you have on the decision to the comment section. This is also where you can include references to similar decisions by the DPA, especially if previous decisions have been issued against the same controller.

Note, it is not mandatory but highly encouraged to fill in this section.

General comments[edit | edit source]

Helpful tips:

  • Remember to set hyperlinks to GDPR provisions and national law.
  • Write dates and fines in the correct manner.
  • Remember to use British English.
  • Consistently use the legal terms established in the facts.
  • Use simple language, repetition of terms, such as "the DPA" or "the controller" are very much in order as they make it easy to follow the decision.

When gender is unknown, use the gender-neutral "they" as a singular pronoun[edit | edit source]

Singular "they" is the use in English of the pronoun "they" or its inflected or derivative forms, them, their, theirs, and themselves (or themself), as a gender-neutral singular pronoun. Try to only use this when referring to a data subject of unknown gender so that you can avoid using the binary "his or her."

Example: The data subject asked the controller to delete their data.

Example: Not The data subject asked the controller to delete his or her data.

References within GDPRhub[edit | edit source]

Citing Laws[edit | edit source]

GDPR[edit | edit source]

All Articles are called "Article X GDPR". We do not use abbreviations like "Art." or "Art" as they are widely different in each jurisdiction.

Paragraphs and subparagraph are added in brackets, as there are different forms of naming them in the member states.

Example: Article 6(1)(a) GDPR
Example: Not Art. 6 Abs 1 Lit a GDPR or Article 6 GDPR or GDPR Article 6, Sec 1(a)

Recitals are also not shortened.

Example: Recital 47
Example: Not R 47 or Recital 47 GDPR

Other EU Laws[edit | edit source]

Other EU laws follow the same system for naming the articles, but have the name of the legal act (e.g. regulation, directive) after the Article.

Example: Article 5 of the ePrivacy Directive should be cited as "Article 5 Directive 2002/58/EC."

When there is a common name for an act that allows the reader to understand the content of the act quicker, you should put the common name between the Article and the official number of the legal act. Keep the official number to ensure that the reader can still identify the act.

Example: Article 5 of the ePrivacy Directive should be cited as "Article 5 ePrivacy Directive 2002/58/EC."

National Laws[edit | edit source]

National laws are cited as usual in each country, but paragraphs and subparagraph follow the system of brackets as explained above for GDPR Articles, as they are widely different in each national jurisdiction. In other words: the national name for the Paragraph (§), Article or Section is used, but the numbering then follows the GDPRhub logic.

Example: § 6 Abs 4 Lit c) of an Austrian law becomes § 6(4)(c) on GDPRhub.
Example: Section 1 para 1(c) of an Irish law becomes Section 1(1)(c) on GDPRhub.

Linking to laws[edit | edit source]

When you cite a law for the first time on a page, you should always also link to the original text of the law, so that the reader can easily follow and verify your work.

Linking to GDPR Articles[edit | edit source]

GDPRhub has a page for each GDPR Article. It includes the text, the relevant recitals and a commentary on the Article. Ideally you should link to the actual subparagraph of each Article, as GDPRhub is using these subparagraphs to find the right cases.

Example: A case about consent as a legal basis should always use Article 6(1)(a) GDPR, not only Article 6 GDPR.

You can link to each page in the text editor by putting two square brackets before and after the Article.

Example: [[Article 6 GDPR]] will become Article 6 GDPR on a page.

You can show another name for the link (e.g. to only name it "Article 6" and not repeat "GDPR" within a text more than necessary.

Example: [[Article 6 GDPR|Article 6]] will be visible as Article 6.

You should always link to the exact part of the Article, which can be done by adding the subparagraph at the end of the link. For technical reasons, brackets are not possible here. Subparagraph (1)(b) therefore has to be written as #1b!

Example: [[Article 6 GDPR#1b|Article 6(1)(b)]] becomes Article 6(1)(b) and links to Article 6, section (1), subsection (b) of the relevant page.

Linking to other national and EU laws[edit | edit source]

For other national or EU laws you should link to the official publication of the law with a hyperlink.

Example: § 9 of the Austrian Data Protection Act (DSG) is linked as § 9 DSG to redirect to the external source.

Footnotes[edit | edit source]

References (e.g. to books, laws, cases or other documents) within a text can be added by using the wiki-function "Reference".

In the text editor you can just put the reference/footnote between an"<ref>" and "</ref>" element. It will generate a footnote and move the link to the text (your reference) between the two tags to the bottom of the page.

In the visual editor, you can click on "cite" to include a reference/footnote. It will generate a footnote and move the link to the reference to the bottom of the page.

Consistent names on GDPRhub[edit | edit source]

Naming DPA and court cases[edit | edit source]

On GDPRhub all cases are named by Court/DPA, a hyphen and the case number or the case name. If a case number is available, always use the case number. If no case name or number is available, you may use a description of the case as a title.

If there is an abbreviation of the court or DPA, this will be used for titles. Abbreviations of the DPAs can be found in the DPA overview. Abbreviations of courts can be found in the court overview.

Example: Decision FS50819531 of the Information Commissioner's Office is called "ICO - FS50819531".

Naming DPAs and courts in page titles[edit | edit source]

The names of DPAs are mostly the abbreviation in the national language and the country name in brackets. Abbreviations of all DPAs can be found in the DPA overview.

Example: The UK Information Commissioner's Office can be found as ICO (UK).

Courts are named by the abbreviation and the country name in brackets.

Example: A case of the Den Haag Court of First Instance (Rechtbank) can be found as Rb. Den Haag - C/09/581973/KG ZA 19/1024.

Local names of laws and institutions[edit | edit source]

Names of many non-English elements (e.g. names of a court or a law in the local language) can be very confusing and hard to follow. To ensure that the reader can follow the articles, an English translation and the original name are used on GDPRhub.

Always use an English translation (or description) and add the local name in brackets so that the reader can follow you. Local abbreviations are used and may be added in the brackets, separated with a hyphen. When further citing the element or using it in a title of a page, you may use the national abbreviation.

Example: The German "Oberlandesgericht Köln" becomes the "High Regional Court Cologne (Oberlandesgericht Köln - OLG Köln)".
Example: The German "Oberlandesgericht Köln" becomes the "OLG Cologne" when used in a page title.
Example: The German Bundesdatenschutzgesetz (BDSG) becomes the "German Federal Data Protection Act (Bundesdatenschutzgesetz - BDSG)". Once this abbreviation is established on a page, you may later simply refer to the BDSG in your article.

Consistently referring to "controller" and "data subject"[edit | edit source]

A good summary immediately gives the reader a clear overview of the facts and reasoning. In this regard, it is important to consistently refer to the roles of the the parties, to prevent that the reader has to look up the original.

Therefore, it is important to prevent wording like "complainant", "claimant", "plaintiff", "defendant", etc., and stick to the roles that are assigned under the GDPR: "data subject", "controller", "processor", and "DPA". After all, it depends on the circumstances whether the "defendant" is the controller, or perhaps the DPA.

Specific elements on GDPRhub[edit | edit source]

Examples[edit | edit source]

Examples can be added by including ::<u>Example:</u> before a paragraph in the text editor.

Example: This is an example.

GDPRhub commentary style guide[edit | edit source]

The GDPRhub Commentary features relatively short analysis regarding a GDPR Article. Commentaries should not exceed 4000 words total (including abstract, main text, references and figure legends). They should have an abstract of 50 words or less ("Overview") and no more than 35 references.

Overview[edit | edit source]

Commentary begins with an introductory paragraph that immediately presents the issues under discussion in a way that captures the reader's interest. The Overview should be general enough to orient the reader not familiar with the specifics of the field being discussed. Here, and throughout the article, the author should avoid the jargon and special terms of his or her field or system.

Body of the text[edit | edit source]

The body of the text should, in the limited space available, develop the discussion in a lively manner. By "lively" we don't mean hype and oversimplification. Rather, the editors seek clear, declarative writing that avoids the passive tense, tangled constructions, and needless detail. Avoid asides that interrupt the flow of the text.

Commentary structure[edit | edit source]

In general, the commentary should follow the structure of the Article. We prefer an analytical approach. This means that, if possible, we analyse the meaning of the most important sentences included in each paragraph of the Article, and then we move on to the next one, with the same approach. That said in general terms, it is also true that we don't need to be that analytical all the time. In other words, if a paragraph is terribly boring or does not deserve more than five minutes of your time, you don't need to split hairs. A general headline will work just fine.

Article 12 makes a good example. The provision is made of 8 paragraphs and each one of them is commented (check the index of contents, here). However, certain paragraphs (for example 1 and 5) require deeper analysis while others can be grouped in a more general "issue", without further analysis.

Paragraph numbering[edit | edit source]

The Wiki automatically numbers paragraphs once they are given a hierarchy value ("Heading", "Sub-heading 1", "Sub-heading 2", etc). Therefore, there is no need to give a number to each paragraph. If doing so helps you in visualising the structure of the Commentary, do it. Please, remember that no numbers should be given to the paragraphs once the commentary is uploaded on the GDPRhub.

Citation Style[edit | edit source]

  • Books (monographies)
    • surname(s) of author(s),
    • full title,
    • page,
    • publisher and year in brackets.

Example: Endicott, Administrative Law, p. 10 (OUP 2009).

  • Commentaries
    • surname of author(s) in italics. (if applicable), in
    • editor(s) (if applicable),
    • full title,
    • Article,
    • margin number (or page if applicable)
    • publisher and year in brackets (you may need to also cite 'Edition')
    • (if online, provide date of access)

Example (paper): Leupold, Schrems, in Knyrim, Der Datkomm, Article 80 GDPR, margin number 49 (Manz 2018)

Example (paper): Docksey, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 68 GDPR, p. 1046 (Oxford University Press 2020).

Example (online): Klabunde, in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 67 GDPR, margin number 16 (C.H. Beck 2018, 2nd Edition).

  • Journal papers
    • surname(s) author(s),
    • full title, in
    • full name of the journal,
    • volume number (if available),
    • (year),
    • page or page numbers.
    • (if online, provide link and date of access)

Example: Young, In Defence of Due Deference, in Modern Language Review, 72 (2009), p. 554.

  • EDPB/DPAs guidelines, opinions --> name of the authority (EDPB, CNIL, etc.), title, date, page number, link to the document
    • Example: EDPB, 'Guidelines 05/2020 on consent under Regulation 2016/679', 4 May 2020 (Version 1.1), p. 12 (available here).
  • Exception for WP29 guidelines, opinions --> WP29, 'title', version number, date, page number, link to the document
    • Example: WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 29 (available here).
  • EDPB, DPA, Court decisions --> name of the authority, case + case number, name, date, parties, relevant paragraphs (if possible) + link to the GDPRhub summary (if available) [if not available, link to the official decision or reference to the book or journal that features the decision]
    • Example: CJEU, Case C-403/03, Schempp, 12 July 2005, margin number 19 (available here).

Practical tips[edit | edit source]

  • Please, always cite the full work in each footnote. In other words, do not use "op. cit", "ibid", "Idem" and similar;
  • Where there are two authors, both should be named; with three or more only the first author's name plus "et al." need be given.
  • Do not use footnotes in your word draft. It will be easier for you to upload the file in the Hub and use the "Cite" feature on the Wiki.

    Example: "Articles 39(1)(d) and (e) lay down the DPO’s obligations in relation to the supervisory authorities. For example, the DPO could facilitate cooperation of the organisation in prior consultation procedures or DPA investigations. [6. Klabunde, in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 67, margin number 16 (C.H. Beck 2018, 2nd Edition).]