Does the UK have a (enforcable) law linked with the Data Protection Act to control document&#39;s metadata? Reading the information on the ICO's website, I came across a few items mentioning how to handle metadata on my organization's workflow like THIS or THIS. I noticed they use expressions like &quot;should consider&quot; or &quot;is recommendable&quot; when they refer to handling a document's metadata. As I understand, they do not enforce any &quot;special treatment&quot; to these pieces of information. Other European countries, like Spain, have special laws that describe how public bodies or private companies must handle metadata. Is there an equivalent law applicable in the UK? Who is responsible for the information contained in such metadata? EDIT I This is a follow up question after reading @Amon comment. Let's say for a given organization the person responsible for Data Protection Act compliance do all due dilligences up to his/her knowledge to make sure that the company is compliant. At one point, a third party discover a vulnerability that produces a data breach and notify the organization's DPO with the details of the data breach, but the DPO &quot;do not believe&quot; the info and just ignore the new information. Is that &quot;bad practice&quot;? Is this something regulated? Is there any responsible for &quot;ignore that&quot;? Who else should be notified?
Specific laws or regulations relating to metadata are unnecessary, and possibly counter-productive. UK data protection law is centered around the GDPR, which is largely principle-based – instead of providing a checklist of very concrete compliance measures, it is the data controller's responsibility to determine appropriate measures in order to achieve the data protection principles. For example, this obligation is expressed in Art 24 GDPR: Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. […] What risks exist for what activities is extremely contextual. Leaking information through metadata is a potential risk, but it's not a risk in every context. Thus, data controllers should consider whether metadata could pose a privacy problem in their workflows, but they are not necessarily required to redact such metadata. This provision of the UK GDPR is already enforceable, but it would need a case by case analysis to determine whether the risk analysis and selection of technical and organizational measures have been conducted incorrectly. The documents you linked are a HMRC internal manual. These are not normative – they do not bind other organizations. Instead, the existence of these manuals is an expression of HRMC's own obligation to consider various risks and implement appropriate technical and organizational measures (TOMs). Of course, other organizations could use such manuals as a starting point for their own analysis.
Per Art 3(2), GDPR only applies to non-European companies when their processing activities relate to the offering of goods or services to people in Europe, or when the processing activities relate to monitoring people in Europe. However, the word “offer” of this targeting criterion requires some level of intent. It is not enough for GDPR to apply that they're marketing to someone who happens to be in Europe, but GDPR would apply if they are intentionally marketing to people who are in Europe. I don't know what they are marketing, so I don't know if that would be the case here. Even if GDPR were to apply, it would not be the most appropriate law. Yes, there's the GDPR right to erasure, which applies under some conditions (though there's a pretty absolute right to opt-out from marketing). The EU's ePrivacy Directive provides more specific rules though, in particular that every such marketing email must offer a way to unsubscribe. Other countries have comparable anti-spam laws, potentially also the home country for this online service.
If you mean the Regulation of Investigatory Powers Act 2000 (aka RIPA), it doesn't provide for mandatory retention of communications data. Broadly speaking, RIPA is about interception as opposed to mass surveillance or retention just in case. The Data Retention (EC Directive) Regulations 2009 obliged &quot;public communications providers&quot; to retain what is commonly known as 'metadata', i.e. information about the communication - the originating phone number, the receiving phone number, the date, time and duration (if relevant), the type of call or message - not the content of the communication. See Schedule 1. In April 2014, in the case known as Digital Rights Ireland the Court of Justice of the European Union declared the EC Directive invalid. In response, the UK made the Data Retention and Investigatory Powers Act 2014 (DRIPA) - sunsetted on 31 December 2016. This provided for the Secretary of State to issue a data retention notice to a communications services provider (CSP), requiring it to retain the data types set out in the Schedule to the 2009 Regulations. DRIPA's Explanatory Notes support my claims above with a summary of the history. This was replaced by the Investigatory Powers Act 2016 (IPA), Part 4 of which deals with the retention of communications data. Here too the retention is of the metadata not the content (see s11(87) and the Explanatory Notes).
The same page at the ICO website also lists what an organisation should do if they refuse to comply with a request: What should we do if we refuse to comply with a request? You must inform the individual without undue delay and within one month of receipt of the request. You should inform the individual about: the reasons you are not taking action; their right to make a complaint to the ICO or another supervisory authority; and their ability to seek to enforce this right through a judicial remedy. You should also provide this information if you request a reasonable fee or need additional information to identify the individual. Even if they did not inform you about this, the last two bullet points basically list your options. You can make a complaint (Art. 77 GDPR), or go to court (Art. 79 GDPR) requesting the online retailer to comply with your request. (Or do both). You can request a compensation for damages, but it is often difficult to prove if you have suffered (non-material) damages.
GDPR definitely applies. Your scenario seems to raise two questions: What is the legal basis for processing? Are the security measures appropriate? Legal basis Every processing activity of personal data requires a legal basis. Most well-known is consent, but there are six categories in Art 6(1) GDPR including legitimate interests and necessity for performing a contract with the data subject. Conditions on consent are laid out in Art 7 GDPR. You say that data subjects “explicitly agree to the website's privacy policy and GDPR”. The GDPR does not generally expect “agreement” to a privacy policy, as information per Art 13 is an unilateral notice. Such general agreement also cannot constitute valid consent. In the context of certifications, the legal basis would likely be necessity for performing a contract with the data subject: You were contracted to provide this validation service to the data subjects. You should however make it clear which information will be displayed on the validation page (other than a valid/not valid) response. For example, I am concerned that showing the email address would not be strictly necessary for providing the validation service. You should also consider whether this validation service is a core component of your certification service, or whether there should be an opt-in or opt-out here. Security Measures The GDPR requires that you implement appropriate security measures, “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms” of the data subjects (see Art 32 GDPR). This gives you a lot of leeway to determine what measures are appropriate, but also criteria that you must consider in your determination. A number of security measures are explicitly suggested and must also be considered: pseudonymization and encryption ensuring confidentiality, integrity, availability, and resilience of your systems ability to restore the service (e.g. backups) processes for regularly testing and evaluating your measures Aside from generic IT security measures like backups and providing the service over a HTTPS connection, I would be concerned about “insecure direct object reference” style attacks on the database. If I know that certification no 1234 exists, I could try to get the information for other numbers like no 1233 and so on. This would leak personal data. Basic defenses could include requiring additional information such as the data subject's name to be provided, or using anti-bot measures such as captchas and rate limits. However, the real solution is to avoid sequential IDs, and to generate sufficiently large tokens with a cryptographically secure random number generator. Instead of a “certification number”, it would be better to view this as a “validation code”.
I think there are a couple of different ways to look at this. Deduplication is a technical detail that's irrelevant here While the data may be deduplicated on a technical level, the files remain logically distinct. If users 1 and 2 upload identical files, and then one user edits or deletes their file, this will not affect the other user's data. Users cannot tell whether their files are duplicates of someone else. From the user's perspective, it makes no difference whether or not the storage uses deduplication, except perhaps via the cost of the service. Because there is no user-perceptible difference, it would be difficult to interpret some GDPR significance into this scenario. Whose personal data is it anyway? Personal data is any information that relates to an identifiable data subject. The files here are likely to be their uploader's personal data. Thus, the uploaders would also have a right to have their uploaded files erased. In case of deduplicated storage, this would affect their logical copy. The contents of the uploaded files might also be personal data relating to a third party. Then that third party might have a right to get the file contents erased. But this right must be invoked with the data controller for that processing activity, which might be company A, company B, or the uploaders, depending on context. Which leads us to the next aspect: Company A is not responsible for handling erasures From your description, it sounds like company A is a data processor providing services on behalf of company B. In turn, B might be a processor acting on behalf of the uploaders. In any case, it seems that A would not be the data controller for these processing activities. Data subject rights like erasure must be invoked against the controller, as only the controller can understand whether such a request should be granted. The right to erasure is not absolute, and depends a lot on why that data is being processed. In particular: Personal data need not be erased if it is still necessary For example, a person might very well be the data subject of some of these files, and might then ask for erasure. But if the files are being stored because they are going to be needed as evidence in legal proceedings, the data subject can't use this GDPR right to destroy evidence. The data controller would be allowed to refuse a request in such cases. It could now happen that two different users of this deduplicated storage are storing the same file, but for entirely different purposes. Blanket deletion of all copies of a file could be quite problematic. Note that deletion is also a &quot;processing activity&quot; and needs a legal basis under the GDPR. Unexpected data loss could be a data breach. One user's erasure could be another user's reportable data breach incident. Thus, I would strongly expect such requests to be handled on a logical file level, not on the deduplicated storage level. Caveat: public access and cloned files If the (logical) file is made available to the public who can then clone or copy this file, and if the &quot;original&quot; is taken down due to an erasure request (or copyright takedown notice), it might be appropriate to remove logical clones as well. Again, this might not involve deleting the contents on the deduplicated storage level, but it might affect other users' copies. In a GDPR context, the grounds for this would be the Art 17(2) right to be forgotten: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. But this depends crucially on who those other controllers are. If A is the sole controller, the logical files could probably be deleted directly. If B or the end users are controllers, it could be more appropriate to forward the erasure request to them.
There are two related aspects to this question: can multiple legal bases cover the same processing purpose, and how must this information be presented in the privacy notice? In the following, this answer will address the following sub-questions, listed here alongside a short summary. Do you need a clear mapping between processing purposes and corresponding legal bases? Yes, such a mapping is effectively necessary to satisfy your GDPR obligation to be able to demonstrate that all your processing activities are covered by a legal basis. If one legal basis doesn't work out, can you fall back to a different one? No. This is nonsensical considering how the individual legal bases work. However, it is possible that similar processing activities serve different purposes under different legal bases, and it can be worth evaluating different legal bases when trying to determine which one you should rely on. How should legal bases be presented in a privacy notice? While a Termly-style generic list of potential legal bases is common, there are good reasons to believe that this fails to achieve the GDPR's transparency goals. It is better to clearly associate each processing purpose with its legal basis. Appendix: positive examples of structuring a privacy notice Do you need a clear mapping between processing purposes and corresponding legal bases? Yes, the data controller must always have a clear understanding regarding which processing activity is conducted under which legal basis. Under Art 5 GDPR, personal data shall only be “collected for specified, explicit and legitimate purposes” and processed “lawfully, fairly and in a transparent manner”. “The controller shall be responsible for, and be able to demonstrate compliance with [these obligations]”. To be able to demonstrate that each processing activity is covered by a legal basis, it is necessary in practice to have a document that spells out the specific legal basis relied upon for each processing purpose. Some data controllers are formally required to maintain such Art 30 Records of Processing Activities (ROPAs), but keeping track of core information makes sense for all data controllers. The ICO writes in their guide on lawful basis for processing: You need therefore to keep a record of which basis you are relying on for each processing purpose, and a justification for why you believe it applies. There is no standard form for this, as long as you ensure that what you record is sufficient to demonstrate that a lawful basis applies. This will help you comply with accountability obligations, and will also help you when writing your privacy notices. It is your responsibility to ensure that you can demonstrate which lawful basis applies to the particular processing purpose. If one legal basis doesn't work out, can you fall back to a different one? Probably not. Processing for different purposes. In some cases, it will happen that data is processed for one purpose initially, and for another purpose under a different legal basis subsequently. For example, a web shop might collect payment information in order to execute a contract to buy goods. But once that contract is fulfilled, it is likely that the webshop will have to archive some of that information for multiple years due to legal obligations around financial recordkeeping. While in both cases the processing activity is similar (storage of the information), the purpose is different and so the legal basis can differ. In this context, it is useful to consider Art 6(4), which discusses when data that collected for one purpose can be reused for another purpose. This is possible whenever those purposes are “compatible”. Multiple legal bases for the same purpose. Some data controllers try to apply multiple legal bases to the same processing purpose, in the hope that some will stick. For example: We're showing personalized ads based on your consent. But if you decline consent we will show you personalized ads because we have a legitimate interest in making money. And if you object to the legitimate interest then showing you personalized ads is necessary for performance of a contract we have with you, namely in section 7(23)(f)(ii)(ξ) of our terms of service where “Service shall make reasonable effort to ensure that Content shown is relevant to User”. This doesn't work. Specifically in the case of consent, consent can only ever serve as a legal basis if the data subject has an actual choice. If the data controller just falls back to a different legal basis in case consent is declined or withdrawn, that choice is hollow. Similarly, having a fallback for legitimate interests makes no sense. The core aspect of a legitimate interest is that there must be a balancing test between the legitimate interests and the data subject's rights and interests. A legitimate interest can only serve as a legal basis if it outweighs the data subject's interests. A core factor here is whether the data subject can reasonably expect their data to be processed for the given purpose. Data subjects can object to the legitimate interests, which may make it necessary to re-run the balancing test taking into account the objecting data subject's individual circumstances. But it is quite possible that the legitimate interest still overrides the data subject's interests, so that processing can continue. On the other hand if the objection prevails, it is difficult to conceive a scenario where there could exist some fallback legal basis to continue despite the successful objection. Specifically for the issue of using Art 6(1)(b) necessity for performance of a contract instead of other legal bases, the EDPB has published guidelines 2/2019. They explain that whether processing is indeed “necessary” must be considered from the perspective of the data subject, so that many purposes like “service improvement” or advertising cannot be covered by this legal basis. Something does not become truly necessary for a contract just because it was unilaterally inserted into a terms of service document. Determining an appropriate legal basis. However, thinking in terms of fallbacks can be quite useful for determining an appropriate legal basis. In general, legal obligations or necessity for performance of a contract should be considered first, falling back to a legitimate balancing test otherwise. Consent is a choice of last resort when no other legal basis would apply, since consent can authorize nearly any processing activity, no matter how risky or disadvantageous to the data subject, if the consent was obtained in a valid manner. How should legal bases be presented in a privacy notice? The GDPR is slightly ambiguous here. Per Art 13(1)(c), your privacy notice must provide the purposes of the processing for which the personal data are intended as well as the legal basis for the processing It is possible to interpret this in two ways: you list the purposes of processing, and separately any legal bases that you may rely on for any purposes; or you list the purposes of processing, and for each purpose you also list which legal bases you rely on for that specific purpose. Providing an abstract list of legal bases. You very commonly see the first approach, that essentially just summarizes Art 6(1) GDPR for the convenience of the reader. This boilerplate approach is of course attractive for privacy policy generators that do not understand the context your specific processing purposes. While the relevant EDPB guidelines on transparency don't take a clear stand on this matter, I have doubts that this first approach is fully GDPR compliant. This fails to provide required transparency. The Art 13 and Art 14 information obligations are an expression of the Art 5 GDPR principles like “lawfulness, fairness and transparency”. Merely listing any potentially applicable legal bases does not make it transparent to the data subject what data is being processed under which rules. But knowing the legal basis covering a particular processing activity has direct impact on the data subject's rights such as the right to revoke consent, to object to legitimate interests, or to erasure. This fails to specify the actual legal basis. Such a generic listing might also fail to fully satisfy the conditions for certain legal bases. Where the legal basis is a “legal obligation”, it is not sufficient to generically refer to legal obligations in abstract. Rather, Art 6(3) says that The basis for the processing referred to in point (c) and (e) of paragraph 1 shall be laid down by: (a) Union law; or (b) Member State law to which the controller is subject. Thus, I would expect a fully compliant privacy notice to actually reference those laws, at least in a general sense (e.g. compliance with court orders, or for financial recordkeeping). Specifically in the case where legitimate interests are used as the legal basis, Art 13(1)(d) says that those legitimate interests shall be provided. Guidance from the EDPB WhatsApp decision. While the Transparency Guidelines linked above are not excessively helpful here, there is a body of regulatory interpretation for example in the form of the EDPB binding decision 1/2021 regarding WhatsApp. In section 5.1, it is discussed whether the WhatsApp privacy notice at the time satisfied Art 13(1)(d). Here, the EDPB quite unambiguously argues that only the second approach – per-purpose information – can be compliant. From para 56 and 59 in the decision: The EDPB is of the view, […] that providing full information on each and every processing operation respectively is the only approach that will ensure that the data subjects can: (a) exercise choice as to whether or not they might wish to exercise any of their data subject rights and, if so, which one(s); (b) assess whether or not they satisfy any conditionality associated with the entitlement to exercise a particular right; (c) assess whether or not theyare entitled to have a particular right enforced by the data controller concerned; and (d) assess whether or not they have a ground of complaint such as to be able to meaningfully assess whether or not they wish to exercise their right to lodge a complaint with a supervisory authority. […] The EDPB considers that in the Legal Basis Notice WhatsApp IE has not specified the provided information with regard to the corresponding processing operation such as information about what categories of personal data are being processed for which processing pursued under basis of each legitimate interest respectively. Practical impact. Termly's templates fall short of this standard, but their fine print also makes it clear that their service does not provide legal advice and that they aren't responsible for anything. It may also be worth considering that your privacy notices will likely face less scrutiny than WhatsApp, as in the decision cited above. That a very strict standard was applied to WhatsApp also has to do with Facebook's/Meta's/WhatsApp's history of playing games around appropriate legal bases and its extremely large user base, also involving children, making it very important to provide clear and comprehensive notices. Appendix: positive examples of structuring a privacy notice My suggestion would be to think about these transparency obligations in a tabular manner where you have an Excel sheet with columns for purpose, data involved, retention periods, and legal basis: purpose data retention legal basis personalized ads cookie identifiers, interest profile 6 months Art 6(1)(a) consent server security logs IP address 3 months Art(6)(1)(f) necessary for legitimate interest showing comments to other users username, comment until you delete the comment Art 6(1)(b) necessary for performing service ... ... ... Many data controllers will have exactly such information anyway when they keep Art 30 Records of Processing. Based on these records, it is then possible to write an accurate and understandable privacy notice that clearly relates processing purposes with other required information. I have seen privacy notices that use exactly such a tabular approach, though it's more common to provide a sub-section per purpose. For example: Purposes for which we process your personal data: Personalized ads. If you give consent (Art 6(1)(a) GDPR), we will show you personalized ads. For this we will set a cookie identifier (→ about cookies), and collect a profile of your interests based on the content that you interact with. The profile will be deleted 6 months after you last interact with our site. ... Showing comments to other users. When you post public comments, we will show them to other users. Providing this service is necessary to perform our contract with you (Art 6(1)(b) GPDR). The comment will publicly display your username, the date when you posted the comment, and the contents of the comment. The comment will be shown indefinitely, but you can delete it at any time (→ help center). Such an approach also fits well with a “layered approach” to transparency, where you split the information of the privacy notice across multiple pages, so that data subjects only have to read about those processing activities that are relevant to them. For example, an online marketplace company might have different notices covering browsing the listings on their site, buying a product, seller-side activities, and their employee recruiting processes. Another reasonably good approach I've seen is to have a section per aspect required by the GPDR, and to then provide a list that goes through each processing purpose. This is essentially a flattened version of the above table: Processing purposes: personalized ads server security logs showing comments to other users Legal basis for processing purposes: for personalized ads: your consent pursuant to Art 6(1)(a) GDPR for server security logs: our Art 6(1)(f) GDPR legitimate interest in ensuring the security of our services against hacks, DDoS attacks, or other criminal acts for showing comments to other users: Art 6(1)(b) necessity for performing our contract with you: showing comments is a core feature of our website, as covered by our terms of service (→ link). Which data is processed: for personalized ads: cookie identifiers, interest profile based on the content you interact with for server security logs: your IP address, a timestamp, and which pages you visit on our site for showing comments to other users: your username, date when you posted the comment, and the contents of the comment How long your data is kept: ...
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.