Follow up on user consent in telecom and 3GPP standardization
Back to basics
A controller is the entity that decides what, where, how, by whom, and for how long personal data is processed. A data subject is the person whose data a controller is interested in processing. Processing is every and all activities that can be performed on personal data, by man or machine, including holding it. Personal data is such information that can directly or indirectly identify a data subject. A processor is an entity tasked to process personal data per instruction and on behalf of a controller.
An agreement between two parties
GDPR describes many criteria for consent to be valid, most notably, consent must be specific, it must be freely given, and it must be retractable. Consent always involves two parties: the entity seeking approval for a proposal, and the individual who decides to agree or disagree to the proposal. So, we can state that consent requires the participation of a data subject and a controller; these are the two parties that form the agreement.
There are many ways to agree to a proposal, but agreement should precede processing. GDPR states that consent is valid until it is invalidated. Ways to invalidate consent include, for example, determining that the processing practices were unlawful to begin with, altering the conditions, practices or purposes that were initially agreed to, or revoking it.
Insights: Consent is an agreement between the data subject and the controller, even in cases where a processor is the entity that first captures or manages the data subject’s expression of consent. The agreement remains valid until it is invalidated.
A nuanced promise by the controller
When you are asked to consent, you are asked to agree to a subset of the controller’s intentions and practices surrounding your personal data. It is a proposal laid out for inspection, and a data subject has no obligation to agree to the proposal. Here is where it gets tricky. Some intentions and practices by a controller will be justifiable under different legal bases, for example, under the pursuit of a controller’s legitimate interests, or as a necessity in the fulfilment of a contract towards a data subject. Agreement itself is different here; for example, it may be binding until terminated (like the case in a monthly subscription contract) or it may not be formally required, as long as other principles like transparency, lawfulness and proportionality are observed (legitimate interest of the controller).
Additionally, data subject rights and the extent to which they apply are directly related to what legal basis is at play. Regulators outline what instruments (legal bases) are available for personal data processing, but the selection, justification and implementation are specified by the controller.
Insight: Promises made to consumers are as varied as the controllers behind them; controllers will declare which intentions and practices are governed by consent and which are governed by a different legal basis, for example, legitimate interest, fulfilment of contract, legal obligation, vital interest, and so on. Requirements for agreement and, for example, the rights to disagree or object differ with respect to the underlying basis for processing.
The volatile nature of consent
Some propositions are bad; you are under no obligation to agree to them. GDPR states that no detriment or ill-effect is to be suffered by the data subject as a result of withholding or revoking consent. In practice, what this means is that consent as a legal basis for personal data processing is in most cases, and by necessity, relegated to secondary purposes. Data that fulfills secondary purposes only is not and cannot be critical for the provisioning of a service.
Insight: Service provisioning in telecom requires a stable legal basis. Consent being volatile fits processing activities that are not crucial for either the data subject or the controller and its processors.
Upon what grounds does a processor handle personal data?
The promises made to the data subject, including the intentions and practices governed by consent, propagate throughout the processing chain; processors' and sub-processors' instructions reflect the conditions, allowances and restrictions that were presented to the data subject and that must be followed. These conditions exist in a Data Processing Agreement or corresponding binding document between a controller and a processor. Deviating from instructions can land a processor in a controller role (Article 28); therefore each party is concerned with maintaining role clarity. With these measures, GDPR cements the idea of personal data protection being a shared responsibility with mutual oversight.
Insight: Personal data is processed on instructions from the controller. Instructions must reflect what is communicated to data subjects. Processors cannot, and must not, act autonomously on the personal data they handle.
Consent revocation and continued processing
GDPR states that processing that occurred under valid consent shall not be made unlawful through the revocation of said consent. Consent revocation has therefore a clear forward intent and trajectory, corresponding to “stop utilizing”. But the regulation simultaneously states that when a legal basis that justifies the processing is no longer valid, processing must stop, unless another legal basis is found. The latter idea corresponds to “stop holding”.
It is worth highlighting here that the search and potential application of an alternative legal basis is not something that happens at the point of invalidation, but something that is known beforehand. Under no circumstance is it the right and obligation of the processor to find such justifications for continued processing of personal data. In practice, controllers will often declare a stop in utilization after consent revocation (listing and motivating possible exceptions) and advertise further data subject rights and how to exercise them.
Insights: Only a controller can determine what happens to personal data governed by consent at the time of consent revocation. This is a known strategy, published in controller practices and equally documented and propagated in instructions to processors.
Consent revocation and Right to Erasure
Let's discuss another aspect that is closely related but orthogonal to consent revocation. GDPR guarantees several rights to data subjects to empower them in exercising control over their own data. The Right to Erasure (Article 17), is often discussed together with consent revocation. Unlike consent revocation, the Right to Erasure has a retroactive intent and trajectory and is not limited to data governed by consent.
Article 17 says that a data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her, where one of six grounds apply; for example, the data is no longer necessary for the purpose for which it was initially collected, or consent was revoked. The Right to Erasure is a distinct request initiated by the data subject and directed at the controller. The controller has the responsibility to assess the merit of the request and has the obligation to respond to the data subject with a decision on how the request will be observed. This is why requests for erasure are handled case by case within the boundaries of the controller’s practices and what is permissible by law. A data subject who is not satisfied with the response may seek redress with a relevant supervisory authority.
Insight: Right to Erasure is a distinct and active request made by the data subject; it targets personal data beyond that which is governed by consent and is meant to take retroactive effect.
Hurdles to implement the letter of the law
The questions around understanding the intent of the data subject and guaranteeing other data subject rights have surfaced as problematic to answer in practice. For example, it’s recognized that certain technologies do not allow for the alteration or destruction of records. Hadoop file immutability, for example, means records remain (albeit as inactive originals) and are replaced by modified active copies. Blockchain technology is another example; what is committed to the public ledger can no longer be modified.
In addition to the hurdles caused by the choice of technology, hurdles may come in the shape of process irregularities. This was illustrated in a decision by the Berlin Data Protection Authority from October 2020. The case involved a data subject revoking consent and simultaneously requesting Right of Access (Article 15) to know what data was held about her. The controller deleted the personal data and could no longer present a record of data held to the data subject. The ruling declared that the controller violated Article 15 (1) and (2). The requests were received simultaneously, and the processor should have known to fulfill the access request before deleting the data subject’s data. Even if the requests were received simultaneously here, there is no guarantee for this always being the case. Doing the right thing in the wrong order comes with irreversible consequences.
To avoid this type of process mishaps and in order to ensure data subject rights are maintained, controllers tend to formulate consent revocation to mean a stop in utilization, and where deletion is necessary, a removal of records according to retention rules, unless other steps are taken by the data subject. Controllers make known to their data subjects the possibilities to manage their data. These possibilities include, for example, their right to correct, their right to object of processing and their right to erasure; for each of the rights, controllers will tell under what circumstances the right applies and how it will be observed by the controller if invoked. It is made clear that the rights are requested by the data subject and assessed by the controller, as opposed to observed automatically and indiscriminately.
Insight: Implementing and enforcing consent revocation has proven very difficult, for example, due to the choice of technologies, or the fact that the intention and expectations of a data subject are not very clear. Consent revocation can be combined or complemented with additional requests following revocation. These additional requests may come at any time and may reference auxiliary rights. In particular, the Right to Erasure (Article 17) or the Right to Access (Article 15) are possible to observe only when revocation is interpreted as a stop in utilization.
Handling consent revocation in the telecom network
Much like a subscription remains active until terminated, for a processor and network function (NF), consent remains valid until revoked. What should happen when consent is revoked? Given that processors cannot determine what to do on behalf of controllers, the best a processor can do is to acknowledge the signal and quarantine personal data associated with that consent and purpose. And await further instructions. Neither the processor nor the NF know what the allowed behavior is following consent revocation; remember that both operate under instructions by the controller. The follow up instructions may be any of the following:
- Release (all or parts of the data) from quarantine.
- Maintain in quarantine and schedule for deletion.
- Expire and delete immediately, leaving an audit trail of the event, or
- Something else entirely.
Therefore, at the time the network detects a consent revocation signal, it should be interpreted and implemented as “stop collecting and utilizing the associated personal data” and make the data inactive, for example, by isolating it. The advantages of this approach are that further instructions from the controller are possible to observe on the isolated data. This gives controllers the possibility to design and apply fine control over personal data in their custody, without curtailing the rights and freedoms of individuals whose data they process.
Insight: Standardization efforts must choose a path that enables fine granular control of processing behaviours without compromising the rights of individuals.
What's happening in 3GPP?
Over a course of online meetings, some advancements have been made in the user consent study (TR 33.867).
In the study, the "user" has been loosely defined to refer to the end users. They could be either the subscribers themselves who can give their own consent (adults like you and me who buy SIM cards) or they could be those who give consent on behalf of someone else (like a minor whose SIM card is bought by the parent) or they could be those who are authorized by the subscriber to provide the consent (like an employee using a company's SIM card).
It has been concluded that the user consent parameters are stored as subscription data in the 5G core NF called Unified Data Management (UDM) function. The consent remains effective until revoked and when the consent is revoked, data collection and processing is halted. For the use case of enablers of network automation (eNA), it was concluded that the NF called network data analytics function (NWDAF) is the enforcement point.
The remaining open points are about data deletion, definition of purpose and other use cases like edge computing (EC).
The latest meeting SA3#104-e was in August with two more meetings left in 2021. We, from Ericsson, will continue to keenly participate in the study and collaborate with other active companies.
Read our previous blog post on user consent in telecom and 3GPP standardization.
Learn more about Ericsson and network security standardization.
Like what you’re reading? Please sign up for email updates on your favorite topics.Subscribe now
At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.