China’s recommended national standard Information Security Technology - Personal Information Security Specification (Specification) came into force on 1 May 2018. Although not legally binding, the standard provides guidance on what best practice a personal information (PI) controller may formulate in order to comply with the provisions on PI protection such as those prescribed under the PRC Cybersecurity Law. As a result, the Specification has become an important compliance document in the area of PI protection.

On 1 February 2019, the Chinese government released a draft amendment to optimise and update the Specification. After public consultation, on 25 June 2019, the relevant authority released a second draft amendment; and on 24 October 2019, a third draft amendment (Draft III). Through comparison, we summarise some of the major differences between Draft III and the current Specification as follows:

A.

Distinguished betweenauthorised consentandexpress consent

The Specification has mentioned several times that for the processing of PI, in some cases, the express consent of the PI subject should be obtained first, whereas in other cases, only authorised consent need to be obtained. However, the Specification doesn’t state the differences between these two types of consent. Draft III clarifies that authorised consent is used as a general term, whilst express consent refers to a consent meeting specific requirements, that is to say, an express consent refers to, when facing requests raised by a PI controller processing a PI subject’s specific PI, the PI subject’s authorisation of such processing by positive actions (e.g., by written statement). Authorised consent, on the other hand, is defined as including not only the foregoing positive action of authorisation, but also authorisation through passive inactions (e.g., PI subject does not leave that area after being informed of the information collection act).

Under Draft III, we understand that except for the specified exceptions, for PI controllers’ PI processing activities (including but not limited to collecting, consignment processing (i.e., processing by a third party), sharing, and transferring PI), authorised consent from PI subjects shall be required. However, when such processing may have significant impact on that PI subject (e.g., when collecting, sharing, transferring sensitive PI, or when using PI outside the original purpose of collecting PI, etc.), then it shall be necessary to obtain express consent from the subject.

B.

Added the requirement of no compelled acceptance of multiple business functions

A product or service may have multiple business functions (e.g., a payment application may have several functions such as payment, life services, social networking, etc.), and from a technical perspective, the PI that needed to be collected for each business function can be quite different. However, in order to collect as much information as possible, some PI controllers would sometimes compel PI subjects to accept multiple business functions and to provide more PI through unreasonable authorisation interface design. In order to prohibit such coercive conduct, Draft III puts forward some special requirements. For example, requiring a PI controller not to compel a PI subject to provide his PI through bundling a product or the service’s multiple business functions which he would not have otherwise applied.

C.

Added requirements for “use of personalized display”

In the course of providing business functions, e-commerce services, and news information services etc., PI controllers may sometimes provide a PI subject with personalised display based on the individual’s interests, habits, and other characteristics (e.g., some shopping applications may recommend or push specific products to a user based on his browsing history). Currently, relevant display often does not notify PI subjects which pushed information is personalised and which is not. At the same time, PI controllers rarely provide users with the way to withdraw from or manage the extent of personalised display. From the users’ perspective, personalised display does help many people to obtain contents that they are interested in without spending much effort. However, excessive display may also limit users’ convenient access to other type of information. Moreover, since pushed information often reflects the user’s past internet usage behaviour (e.g., browsed content), which may in turn lead to privacy leakage. To address such issues, Draft III added relevant requirements. For example, for e-commerce services, PI controllers are required to provide options to PI subjects to enable them to choose not to display search results on products or services which are based on their personal characteristics.

D.

Supplemented operational requirements for “PI subject account cancellation”

The amount of users is an important indicator in evaluating the operational status of a network platform. In addition to direct operating revenue, a substantial amount of registered users and registration information can also bring benefits to the platform in respect of in-depth data development and so forth. As such, some platforms deliberately set obstacles to the cancellation of PI subjects’ account, or do not provide cancellation path at all. In order to facilitate protection of account cancellation rights, Draft III supplements the provision on account cancellation in the Specification with several operational requirements. For example, for cancellation requests that needs to be processed manually, a PI controller is required to complete relevant verification and processing within the promised time frame (in principle, no more than 15 days).

E.

Supplemented several requirements for “consignment processing, sharing, transfer and disclosure of PI”

The current Specification sets out some detailed requirements for the consignment of processing, sharing, transfer, and disclosure of PI. Draft III has, on that basis, made some further supplements. For instance, in terms of “consignment processing” of PI, Draft III supplements that PI controllers shall take remedial measures when finding that a third party who is consigned to process the PI has mishandled such PI. For the “sharing and transfer of PI”, Draft III supplements that PI controllers shall stipulate the responsibilities and obligations of the data receiver by means of contracts, etc. For the “disclosure of PI”, Draft III supplements a requirement that no analysis results of sensitive personal data such as race, nationality, political opinions and religious beliefs of Chinese citizens shall be disclosed; and so on.

In addition to the above contents, Draft III has also proposed amendments to the current Specification in several other aspects, such as restrictions on the use of user profiling, privacy policy templates, third-party access management, and so forth. In comparison with the previous two rounds of draft amendments, Draft III continues the original revision framework, and makes further optimisation.

As it is still at the revision stage, organisations engaged in PI processing activities do not necessarily need to make any adjustment to their internal management systems, privacy policies and so forth according to those draft amendments. That said, however, they may consider using the draft amendments as a reference so as to be in line with the revised framework when designing new PI provisions (e.g., terms regarding PI sharing) with business partners, so that when an updated Specification is implemented, the chances of not being able to comply with the new compliance guidance due to difficulty in obtaining cooperation from business partner can be reduced.