OECD Privacy Guidelines – changes between 1980 and 2013 versions – comparison / markup / redline

Here's a markup showing changes between the 1980 and 2013 versions of the OECD Privacy Guidelines (ie Annexes to the Recommendations), aka the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, as I've not found anything similar online.

I used Word's automated comparison feature, tidied up a bit, so the last few paragraphs are not as clear as they could be, but they're usable enough. Obviously I've not compared the explanatory memoranda as they're very different.

GUIDELINES GOVERNING THE PROTECTION OF PRIVACY AND TRANSBORDER FLOWS OF PERSONAL DATA

PART ONE. GENERAL

DEFINITIONSDefinitions

1. For the purposes of these Guidelines:

a) "data“Data controller"” means a party who, according to domesticnational law, is competent to decide about the contents and use of personal data regardless of whether or not such data are collected, stored, processed or disseminated by that party or by an agent on its behalf;.

b) "personal“Personal data"” means any information relating to an identified or identifiable individual (data subject);).

c) “Laws protecting privacy” means national laws or regulations, the enforcement of which has the effect of protecting personal data consistent with these Guidelines.

d) “Privacy enforcement authority” means any public body, as determined by each Member country, that is responsible for enforcing laws protecting privacy, and that has powers to conduct investigations or pursue enforcement proceedings.

e) "transborder“Transborder flows of personal data"” means movements of personal data across national borders.

Scope of the Guidelines

2. These Guidelines apply to personal data, whether in the public or private sectors, which, because of the manner in which they are processed, or because of their nature or the context in which they are used, pose a dangerrisk to privacy and individual liberties.

3. TheseThe principles in these Guidelines are complementary and should be read as a whole. They should not be interpreted:

a) as preventing:a) the application, of different protective measures to different categories of personal data, of different protective measures depending upon their nature and the context in which they are collected, stored, processed or disseminated; or

b) the exclusion from the application of the Guidelines of personal data which obviously do not contain any risk to privacy and individual liberties; or

c) the application of the Guidelines only to automatic processing of personal data.

b) in a manner which unduly limits the freedom of expression.

4. Exceptions to the Principles contained in Parts Two and Three of these Guidelines, including those relating to national sovereignty, national security and public policy ("ordre public"), should be:

a) as few as possible, and

b) made known to the public.

5. In the particular case of Federalfederal countries the observance of these Guidelines may be affected by the division of powers in the Federation.federation.

6. These Guidelines should be regarded as minimum standards which are capable of beingcan be supplemented by additional measures for the protection of privacy and individual liberties., which may impact transborder flows of personal data.

PART TWO. BASIC PRINCIPLES OF NATIONAL APPLICATION

Collection Limitation Principle

7. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

Data Quality Principle

8. Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

Purpose Specification Principle

9. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

Use Limitation Principle

10. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except:

a) with the consent of the data subject; or

b) by the authority of law.

Security Safeguards Principle

11. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.

Openness Principle

12. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

Individual Participation Principle

13. An individualIndividuals should have the right:

a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him;them;

b) to have communicated to himthem, data relating to himthem

i. within a reasonable time;

ii. at a charge, if any, that is not excessive;

iii. in a reasonable manner; and

iv. in a form that is readily intelligible to him;them;

c) to be given reasons if a request made under subparagraphs (a) and (b) is denied, and to be able to challenge such denial; and

d) to challenge data relating to himthem and, if the challenge is successful to have the data erased, rectified, completed or amended.

Accountability Principle

14. A data controller should be accountable for complying with measures which give effect to the principles stated above.

PART THREE. IMPLEMENTING ACCOUNTABILITY

15. A data controller should:

a) Have in place a privacy management programme that:

i. gives effect to these Guidelines for all personal data under its control;

ii. is tailored to the structure, scale, volume and sensitivity of its operations;

iii. provides for appropriate safeguards based on privacy risk assessment;

iv. is integrated into its governance structure and establishes internal oversight mechanisms;

v. includes plans for responding to inquiries and incidents;

vi. is updated in light of ongoing monitoring and periodic assessment;

b) Be prepared to demonstrate its privacy management programme as appropriate, in particular at the request of a competent privacy enforcement authority or another entity responsible for promoting adherence to a code of conduct or similar arrangement giving binding effect to these Guidelines; and

c) Provide notice, as appropriate, to privacy enforcement authorities or other relevant authorities where there has been a significant security breach affecting personal data. Where the breach is likely to adversely affect data subjects, a data controller should notify affected data subjects.

PART FOUR. BASIC PRINCIPLES OF INTERNATIONAL APPLICATION: FREE FLOW AND LEGITIMATE RESTRICTIONS

16. A data controller remains accountable15. Member countries should take into consideration the implications for other Member countries of domestic processing and re-export of personal data. under its control without regard16. Member countries should take all reasonable and appropriate steps to ensure that transborder flows of personal data, including transit through a Member country, are uninterrupted and secure.the location of the data.

17. A Member country should refrain from restricting transborder flows of personal data between itself and another Member country except where (a) the latter does not yetother country substantially observeobserves these Guidelines or where(b) sufficient safeguards exist, including effective enforcement mechanisms and appropriate measures put in place by the re-export of such data would circumvent its domestic privacy legislation. A Member country may also impose restrictions in respect of certain categories of personal data for which its domestic privacy legislation includes specific regulations in view of the nature of those data and for which the other Member country provides no equivalent controller, to ensure a continuing level of protection. consistent with these Guidelines.

18. Member countries should avoid developing laws, policies and practices in the name of the protection of privacy and individual liberties, which would create obstaclesAny restrictions to transborder flows of personal data that would exceed requirements for such protection.should be proportionate to the risks presented, taking into account the sensitivity of the data, and the purpose and context of the processing.

PART FOUR.

PART FIVE. NATIONAL IMPLEMENTATION

19. In implementing domestically the principles set forth in Parts Two and Threethese Guidelines, Member countries should:

a) develop national privacy strategies that reflect a co-ordinated approach across governmental bodies;

b) adopt laws protecting privacy;

c) establish legal, administrative or other procedures or institutions for the protection of privacy and individual liberties in respect of personal data. Member countries should in particular endeavour to:and maintain privacy enforcement authorities with the governance, resources and technical expertise necessary to exercise their powers effectively and to make decisions on an objective, impartial and consistent basis;

a) adopt appropriate domestic legislation;

bd) encourage and support self-regulation, whether in the form of codes of conduct or otherwise;

ce) provide for reasonable means for individuals to exercise their rights;

df) provide for adequate sanctions and remedies in case of failures to comply with laws protecting privacy;

g) consider the adoption of complementary measures which implement the principles set forth in Parts Two and Three; and, including education and awareness raising, skills development, and the promotion of technical measures which help to protect privacy;

eh) consider the role of actors other than data controllers, in a manner appropriate to their individual role; and

i) ensure that there is no unfair discrimination against data subjects.

PART FIVE.

PART SIX. INTERNATIONAL CO-OPERATION AND INTEROPERABILITY

20. Member countries should, where requested, make known to other Member countries details of the observance of the principles set forth in these Guidelines. Member countries should also ensure that procedures for transborder flows of personal data and for the protection of privacy and individual liberties are simple and compatible with those of other Member countries which comply with these Guidelines.

21. Member countries should establish procedures to facilitate:

information exchange related to these Guidelines,

20. Member countries should take appropriate measures to facilitate cross-border privacy law enforcement co-operation, in particular by enhancing information sharing among privacy enforcement authorities.

21. Member countries should encourage and mutual assistance in the procedural and investigative matters involved. support 22. Member countries should work towards the development of principles, domestic and international arrangements that promote interoperability among privacy frameworks that give practical effect to these Guidelines.

22. , to governMember countries should encourage the applicable law indevelopment of internationally comparable metrics to inform the case of policy making process related to privacy and transborder flows of personal data.

23. Member countries should make public the details of their observance of these Guidelines.

Cloud security principles - UK guidance

The UK government issued some concise but fairly comprehensive cloud service security principles (edit: available in the preceding link, in HTML format only), in mid-December 2013, as guidance for UK public sector organisations when considering the use of cloud services to process official information. They were described by Government Digital Service COO Tony Singleton and on a related webpage (edit: see the preceding link for associated info) as being in public beta, although this is not stated on the page containing the principles itself. (Feedback should be sent to [email protected])

Below I set out the text of these security principles (licensed under the Open Government Licence), but adding some suggestions, highlighting and comments of my own with deletions and insertions marked (eg I've highlighted the sentence regarding a named senior executive being responsible for security).

These principles apply to proposed UK public sector use of cloud services and are not limited to personal data, of course. It is interesting that there is much use of 'should', rather than 'must', and no recommendations are explicitly made on whether obligations on the part of the service provider regarding these issues should be made legally-binding by embodying them in the contract terms.

Guidance
Cloud Service Security Principles

The UK government issued some concise but fairly comprehensive cloud service security principles, in mid-December 2013. They were described by Government Digital Service COO Tony Singleton and on a related webpage as being in public beta, although this is not stated on the page containing the principles itself. (Feedback should be sent to [email protected])

Below I set out the text of these security principles (licensed under the Open Government Licence), with some suggestions, highlighting and comments of my own added (eg I've highlighted the sentence regarding a named senior executive being responsible for security).

These principles apply to proposed UK public sector use of cloud services and are not limited to personal data, of course. It is interesting that there is much use of 'should', rather than 'must', and no recommendations are explicitly made on whether obligations on the part of the service provider regarding these issues should be made legally-binding by embodying them in the contract terms.

Guidance
Cloud Service Security Principles

This document describes principles which should be considered when evaluating the security features of cloud services. Some cloud services will provide all of the security principles, while others only a subset. It is for the consumer of the service to decide which of the security principles are important to them in the context of how they expect to use the service.

Some service providers will be able to offer higher levels of confidence in how they implement the different security principles. Consumers[1] will need to decide how much, if any, assurance they require in the different security principles which matter to them.

These principles apply equally to Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) as defined by NIST.

1. Data in transit protection

The confidentiality and integrity of data should be adequately protected whilst in transit.

The following aspects should be specifically considered:

• Consumer to service

• End user to service [ie individual citizens using the service]

• Within the service (for example, between data centres)

2. Asset protection and resilience

Data should be physically secure as it is processed by and stored within the service. This security should be based on suitable physical security controls within data processing, storage and management locations.

The business requirements for availability of the service should be an important consideration when choosing a cloud service. The consumer should ensure that a contractual agreement is in place with the service provider which adequately supports their business needs for availability of the service.

The legal jurisdiction of the service will be an important consideration[2] for many consumers, especially if they wish to use the service to store or process personal data. This principle dependsmay depend on the physical locations of processing, storage, transit and/or management of the service. as well as jurisdictions where the service provider or any relevant sub-provider(s) is incorporated or established or where it has operations and/or assets

The following aspects should be specifically considered:

• Location of data centres hosting the service

• Security surrounding those data centres

• Location of service management facilities

• Countries of relevant service providers’ establishment or incorporation, and where they may have operations or assets

• How the confidentiality and integrity of data-at-rest will be maintained as appropriate to the nature of the data and service concerned (eg encrypting or tokenising data before upload to the service, bearing in mind the importance of adequate key access and key management; and paying for backups by the service provider if not included in the service, or for backups to another service provider, or even backing up to internal systems)

• Availability of the service

3. Separation between consumers

SeparationLogical separation between different consumers of a service (guaranteed to a level appropriate to the requirements of the [consumer]) should be achieved at all points within the service, including across compute, storage and networking resources.

An important consideration will be whether the service is a public, private, or community, shared cloud service; if all tenants[3] of the service are known to be trustworthy then less confidence in the separation properties of the service may be acceptable.

4. Governance

The service provider should have a security governance framework that coordinates and directs their overall approach to the management of IT systems, services and information. A clearly identified, and named, senior executive should be responsible for security of the cloud service.

5. Operational security

The service provider should have processes and procedures in place to ensure the operational security of the service.

The following aspects should be specifically considered:

• Configuration and change management

• Vulnerability management

• Protective monitoring

• Incident management

6. Personnel security

Service provider staff and any relevant sub-contractor staff should be subjected to adequate personnel security screening for their role. At a minimum this should include identity, unspent criminal convictions, and right to work checks. For roles with a higher level of service access, the service provider should undertake and maintain appropriate additional personnel security checks. Each individual’s access to [consumer] data, including metadata, should be limited to only data they are required to access to perform their role.

7. Secure development

The service should be developed in a secure fashion and should evolve to mitigate new threats as they emerge.

8. Supply chain security

Cloud services often rely upon third party services. Those third parties can have an impact on the overall security of the services. The service provider should ensure that its supply chain satisfactorily supports all of the security principles that the service claims to deliver[4] .

9. Secure consumer management

Consumers should be provided the tools they need to securely manage their usage of the service.

The following aspects should be specifically considered:

• Authentication of consumers to management interfaces

• Separation of consumers within management interfaces

• Authentication of consumers within support channels

• Separation of consumers within support channels

10. Secure on-boarding and off-boarding

The service should be provisioned to consumers in a known good state, and their data must be satisfactorily deleted when they leave the service. What is ‘satisfactory’ may vary with the requirements of the [consumer] as regards the nature (eg sensitivity) of the data and usage concerned, eg number of passes, confirmation of deletion from all duplicates and backups etc. When physical storage components reach their end of life, the service provider should make appropriate arrangements to securely destroy or purge any consumer data they held.

11. Service interface protection

All external or less trusted interfaces of the service should be identified and have appropriate protections to defend against attacks through them.

The following aspects should be specifically considered:

• Connections to external services on which the service depends

• Dedicated connections to tenants[5]

• Remote access by service provider

• Publicly exposed services

12. Secure service administration

The methods used by the service provider’s administrators to manage the operational service (monitor system health, apply patches, update configuration etc.) should be designed to mitigate any risk of exploitation which could undermine the security of the service. The security of the networks and devices used to perform this function should be specifically considered.

13. Audit information provision to tenants[6]

Consumers should be provided with the audit records they need in order to monitor access to their service and the data held within it. [What’s meant by ‘audit’ here? Just access to logs? Or formal annual audit reports by independent third party security experts? It would be helpful to have more detail on what kind of logs should be required, eg logs of accesses to metadata as well as data, and what kind of formal audits should be required.]

14. Secure use of the service by the consumer

Consumers will have certain responsibilities when using the service in order for their use of it to remain secure, and for their data to be adequately protected.

Depending on the type of service, the consumer will have responsibilities relating to the following topics:

• Audit and monitoring

• Storage

• Networking

• Authentication

• Development security

• End user devices used to access the service

• Secure configuration of the service

• Patching

15. Glossary

Management interface	a service exposed to consumers or service provider administrators to allow administrative tasks to be performed.
Support channel	an online, or out of band (e.g. telephone), communication channel which consumers can use to obtain support from the service provider.
On-boarding	the process of a consumer moving on to the service.
Off-boarding	the process of migrating a consumer away from a service.
Public, private and community cloud	refer to the NIST definitions of these terms.
Consumer	a tenant[7] of the cloud service.

---

[1]May be confusing to use the term ‘consumer’, which many think of as individual end users, eg citizens who use a government department’s service that the department provides using a cloud service. ‘Customer’ of cloud service?

[2]Absolutely. This is the critical point. I argue that, legally, physical location should be relevant not per se but only because it may determine legal jurisdiction and/or IT security.

[3]See comment on Glossary below on use of ‘tenant’

[4]What if the provider makes no or limited claims regarding its service’s security?

[5]As before.

[6]Or ‘consumer’?

[7]‘Tenant’ applies to IaaS but less so to PaaS and SaaS. And see previous comment on ‘consumer’.