Consultation outcome

Privacy and Consumer Advisory Group: Draft Identity Assurance Principles

Published 17 June 2013

This was published under the 2010 to 2015 Conservative and Liberal Democrat coalition government

1. Introduction

In our electronically enabled, 24/7 world it is very convenient to go online and receive information, pay bills, order consumables or send messages. So how do we know who we are communicating with? How do we identify ourselves so that it is our bill that is settled and not somebody else’s bill? What degree of identification is necessary to obtain a benefit or pension from the state? Is the same high degree of identity assurance needed to apply for a resident’s parking permit? How do we disclose the minimum detail that is necessary for the transaction we want to undertake? How do we fix things if there is a problem? And finally, how do we perform all these operations, in private, without raising any spectre that “someone, somewhere” could be keeping an unlawful record of our interactions?

The answer to such questions is provided by an Identity Assurance Service which is designed to allow individual users to control when to reveal their own identifying information and the minimum detail to reveal. Such focus on individual control and consent is far away from old-fashioned and discredited notions of an Identity Card Scheme where there are centralised databases, supported by mandatory disclosures and compulsion. The intention is to design a secure Identity Assurance Service that is attractive to consumers by allowing them to control a number of identity credentials, chosen by them, which can be voluntarily used with different Service Providers.

If individuals trust such an Identity Assurance Service then certain benefits follow: the Service Provider is less worried about ID theft and impersonation as fraudulent claims based on the use of diverse identities becomes well nigh impossible. At the same time, the individual citizen is reassured that their identity is secure and any transaction is safely delivered to the right organisation. This is a collaborative win-win outcome for the individual and all taxpayers; in summary everybody benefits.

To deliver these objectives there has to be a framework (the Nine Identity Assurance Principles) that gives real meaning to terms such as “individual privacy” and “individual control”. By necessity, therefore, there has to be a degree of precision concerning the wording of these Principles to ensure that those participating in an Identity Assurance Service are left in no doubt it is designed around the needs of the individual (and not on the needs of any state body or commercial corporation). So in order to demonstrate that these Principles do actually serve the interest of the individual, we have prepared a one sentence summary, expressed in the first person, which defines the intended effect of each principle.

Identity Assurance Principle	Summary of the control afforded to an individual
1. User Control	Identity assurance activities can only take place if I consent or approve them
2. Transparency	Identity assurance can only take place in ways I understand and when I am fully informed
3. Multiplicity	I can use and choose as many different identifiers or identity providers as I want to
4. Data Minimisation	My request or transaction only uses the minimum data that is necessary to meet my needs
5. Data Quality	I choose when to update my records
6. Service-User Access and Portability	I have to be provided with copies of all of my data on request; I can move/remove my data whenever I want
7. Governance/Certification	I can have confidence in any Identity Assurance System because all the participants have to be accredited
8. Problem Resolution	If there is a problem I know there is an independent arbiter who can find a solution
9. Exceptional Circumstances	Any exception has to be approved by Parliament and is subject to independent scrutiny

2. Commentary on the context of the Principles

Commentary to help the reader understand the context of how the Nine Identity Assurance Principles apply.

A. These Principles are not a set of principles devoted just to privacy or data protection. Although produced by the “Privacy Group”, these Principles cover ALL aspects of the operation of a user-centric, Identity Assurance Service which places the individual Service-User in control of when and how they assert their identity.

B. The Principles are equal to each other and do not-overlap. Each Principle has a specific role and, in combination, they are all necessary to engender trust in an Identity Assurance Service. Each Principle will apply in different circumstances (some of which, we stress again, are not limited to a mere privacy concern).

C. These Principles are limited in their application to the processing of data in an Identity Assurance Service (e.g. establishing and verifying identity of a Service-User; conducting a transaction that uses an identity, maintaining audit requirements in relation a transaction associated with the use of a service that needs identity verification etc). They do not apply to any other data (e.g. data that are used to deliver a service, or measure its quality).

D. The Nine Principles assume that an Identity Assurance Service is mature and well established. We understand that in the early stages that there might be a phasing in period in relation to each Principle or that in some cases, a Principle might need a degree of flexibility in the first instance. However, we believe that within a reasonable time-frame, all these Principles should have full effect.

E. We recognise that special interests (e.g. law enforcement) may need exemptions from the Principles. Such special interests are subject to a simple rule: exemptions have to be explicitly defined in any legislation required to establish the Identity Assurance Service infrastructure. We do not think it advisable to allow existing legislation to define access to any data from any Identity Assurance Service as such legislation, when enacted, could not have been scrutinised in the context of an Identity Assurance Service; any exemption from these Principles needs that public scrutiny in order to gain credibility and maintain trust. As these Principles only apply to Identify Assurance data used by the Identify Assurance Service, they have no impact on any operational matter of any law enforcement agency, except where the operational matter relates to obtaining such data from an Identify Assurance Service. In such cases, the “Exceptional Circumstances Principle” will apply.

F. The wording of each Principle has been carefully chosen to balance any competing claim; they have been widely debated within the Privacy Group so we request that any changes to the text of any Principle to be supported by the detail of the problem which has been encountered. The Privacy Group is convinced it has drafted Principles which allow all identifiable interests to be balanced. Of course, we accept that this view might not be wholly shared by others and that is why we ask for the detail we have requested to be provided. We intend to review the Principles at least annually in the light of experience and any comments received.

G. Where appropriate, we expect that the application of these Identity Assurance Principles will be described: * in public documents that explain the operation of any Identity Assurance Service * in presentations about any Identity Assurance Service * in procurement processes, technical design and associated procedures of any Identity Assurance Service

H. The Principles are limited to their application to any Identity Assurance Service in the UK, with a particular emphasis on the UK Government objective to deliver many services electronically by 2018. We note, however, these Principles could have international reach, especially in the USA, or in European Union, OECD and APEC countries. However, our starting assumption has been that such interchangeability with any other nationally based Principles will only become relevant when the UK Principles have shown to have a proven track record in gaining the confidence of individuals who use a Service. However, we can assert that our Principles are fully consistent with all national and international data protection requirements and the obligations arising from the UK’s common law of confidence.

I. The Principles are drafted in a way that allows for a degree of precision. They are not drafted in a way that defines statutory Principles but the text could form the basis of a Statutory Code of Practice, for example on the model provided by the Statutory Code of Practice on Data Sharing. We have not insisted on any statutory enforcement mechanism other than any exemption be identified in the law that establishes the Service.

2.1 Definitions

These Principles are limited to the processing of IDA data in an Identity Assurance Service (e.g. establishing and verifying identity of a Service-User; conducting a transaction that uses a user identity, maintaining audit requirements in relation a transaction associated with the use of a service that needs identity verification etc). It does not include, for example, any data used to deliver a service.

In the context of the application of the Identity Assurance Principles to an Identity Assurance Service:

“Identity Assurance data (IDA data)” means any recorded information that is connected with a “Service-User” that are:

• “Personal data” (which means any recorded information that relates to a “Service-User” who is also an identifiable living individual). (Note: this is a data protection type definition that avoids Durant complications)
• “Audit data” (which includes any recorded information that is connected with any log or audit associated with an Identity Assurance Service)
• “Relationship data” (which means any recorded information that describes (or infers) a relationship between a “Service-User”, “Identity Assurance Provider” or “Service Provider” with another “Service-User”, “Identity Assurance Provider” or “Service Provider”, and includes any cookie or program whose purpose is to supply a means through which relationship data are collected)
• “Attribute data”, which means any recorded information that is connected with (“insert definition if needed”)
• “Identity data”, which means any recorded information that is connected with (“insert definition if needed”)
• “Transactional data”, which means any recorded information that is connected with (“insert definition if needed”)
• “General data” which means any other recorded information which is not personal data, attribute data, audit data, relationship data, identity data or transactional data but still is connected with a “Service-User” (note: this is a much needed “catch-what’s-left”)

However, IDA data does not include any anonymous recorded information that is only remotely connected with a Service-User.

“Processing” in the context of IDA data means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, correlating, aggregating, accessing” the data and includes any other operation performed on IDA data.

“Identity Assurance Provider” means the certified individual or certified organisation that provides an identity service (e.g. establishing an identity, verification of identity); it includes any agent of a certified Identity Assurance Provider that processes IDA data in connection with that identity service.

“Service Provider” means the certified individual or certified organisation that provides a service that uses an Identity Assurance Provider in order to verify identity of the Service-User; it includes any agent of the Service Provider that processes IDA data from an Identity Assurance Service.

“Service-User” means the person (i.e. an organisation (incorporated or not) or an individual (dead or alive)) who has established (or is establishing) an identity with an Identity Assurance Provider; it includes an agent (e.g. a solicitor, family member) who acts on behalf of a Service-User with proper authority (e.g. an agent who is a public guardian, or a Director of a company, or who possesses power of attorney).

“Identity Assurance Service” includes all aspects of the technology (e.g. hub, hardware, software, database, documentation) in the possession or control of any “Service-User”, “Identity Assurance Provider” or “Service Provider” that is used to facilitate a Service; it also includes any IDA data processed by that technology or by an Identity Assurance Provider or by a Service Provider in the context of the Service. (Note: extends to a Provider’s agents by definition).

“Third Party” means any person (i.e. any organisation or individual) who is not a “Participant” (e.g. the police or a Regulator). Note: we think it helpful to create a link to the language from the National Strategy for Trusted Identities in Cyberspace (NSTIC) which defines participants as “the collective subjects, identity providers, attribute providers, relying parties, and identity media taking part in a given transaction”. This way, Third Parties are not Participants.

“Participant” means any “Identity Assurance Provider”, “Service Provider” or “Service-User” in an Identity Assurance Service. (Note: a “Participant” includes any agent by definition).

2.2 Note on the Principles

The subsets of IDA data (e.g. “personal data”, “identity data”) identify all the main components of IDA data. Some of them (e.g. “identity data”) have been left undefined in case they are needed to specify an exemption to be approved by Parliament (e.g. see “Note E in the “Commentary about the Nine Principles” above or The Exceptional Circumstances Principle – Principle 9 below). The division of IDA data in this way allows any exemption to be narrowly defined.

3. The Nine Identity Assurance Principles

1. The User Control Principle

Identity assurance activities can only take place if I consent or approve them.

An Identity Assurance Provider or Service Provider must ensure any collection, use or disclosure of IDA data in, or from, an Identity Assurance Service is approved by each particular Service-User who is connected with the IDA data.

Rationale/commentary

Identity Assurance Providers or Service Providers cannot use or disclose IDA data without the Service-User’s knowledge and agreement (i.e. consent).

Service-Users must be able to control/choose whether or not to use or disclose their IDA data and whether or how they assert their identities.

Any exemption from the User Control Principle should be specified via the Exceptional Circumstances Principle.

The Data Minimisation Principle also applies to any collection, use and disclosure.

Legal commentary

The DPA requirement is that processing is either legitimised by consent of the data subject or is “necessary” for a contract with the data subject or is “necessary for a legal obligation or statutory functions of a public body. etc etc (i.e. one of the sched 2, paras 1 to 6 of the DPA).

Consent takes the meaning in the Data Protection Directive (or any successor Regulation)

Also covers some “fair processing” requirements.

2. The Transparency Principle

Identity assurance can only take place in ways I understand and when I am fully informed.

Each Identity Assurance Provider or Service Provider must be able to justify to Service-Users why their IDA data are processed.

Each Service-User, prior to using an Identity Assurance Provider or a Service Provider for the first time, must be provided with a clear description about the processing of IDA data in advance of any processing.

The information provided includes a clear explanation of why any specific information has to be provided by the Service-User (e.g. in order that a particular level of identity assurance can be obtained) and identifies any obligation on the part of the Service-User (e.g. in relation to the User’s role in securing his/her own identity information).

Any subsequent and significant change to the processing arrangements that have been previously described to a Service-User needs the prior consent or approval of that Service-User before it comes into effect.

Rationale/commentary

Organisations should engender trust by being open about all aspects of the processing of IDA data (Processing means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, aggregating, accessing” and anything else).

Such information does not need to be provided at every transaction, if the Service-User has been previously informed.

We expect that a public document explaining how these Principles have been applied to an Identity Assurance Service will be a valuable aid in meeting the objectives of this Principle (see also the Governance/Certification Principle below).

Where changes occur, any Provider would have to anticipate the fact that consent or approval might not be forthcoming.

Any exemption from the Transparency Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary

First data protection principle requirement that the processing of personal data is fair.

3. The Multiplicity Principle

I can use and choose as many different identifiers or identity providers as I want to.

A Service-User is free to use any number of identifiers that each uniquely identifies the individual or business concerned.

A Service-User can use any of his identities established with an Identity Assurance Provider with any Service Provider.

A Service-User can choose any number of Identity Assurance Providers and where possible can choose between Service Providers in order to meet his or her diverse needs.

A Service-User shall not be obliged to use any Identity Assurance Provider or Service Provider not chosen by that Service-User; however, a Service Provider can require the Service-User to provide a specific level of Identity Assurance, appropriate to the Service-User’s request to a Service Provider.

A Service-User can terminate, suspend or change Identity Assurance and where possible can choose between Service Providers at any time

A Service Provider does not know the identity of the Identity Assurance Provider used by a Service-User to verify an identity in relation to a specific service.

Rationale/commentary

These first three need no explanation.

Obviously where there is a monopoly Service Provider (as is often the case with public sector services), then the Service-User does not have a choice of Service Provider. However, in general, there will be a number of Service Providers to choose from; this explains why the Principle uses “where possible”.

Where Service Providers are a monopoly or near monopoly, they should not be able to require a particular Identity Assurance Provider to be used.

However, a Service Provider must be able to insist on a particular (and not unreasonable) level of identity assurance before delivering a service.

Any exemption from the Multiplicity Principle should be specified via the use of the Exceptional Circumstances Principle.

It should not be possible to link a Service-User’s activities in different contexts.

4. The Data Minimsation Principle

My request or transaction only uses the minimum data that is necessary to meet my needs.

IDA data processed by an Identity Assurance Provider or a Service Provider to facilitate a request of a Service-User must be the minimum necessary in order to fulfil that request in secure and auditable manner.

Note: it is useful to remind the reader that this principle has a wide reach because of the definitions of IDA data and Processing:

• “IDA data includes “Personal data”, “Audit data, “Attribute data, “Identity data”, “Relationship data”; “Transactional data” and other “General data”
• “Processing” in the context of IDA data means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, aggregating, accessing” etc.

Rationale/commentary

So for the absence of doubt, any aggregation, correlation or corroboration of IDA data from diverse Identity Assurance Providers or Service Providers are subject to all the Identity Assurance Principles.

All IDA data processed has to be the minimum necessary in the context of service delivery or identity verification. Note that a Service User can, for his own convenience, request a Provider to hold information beyond the minimum necessary. Subject to any audit or legal requirement, the Minimisation Principle requires any aggregation, correlation or corroboration to be of a transient nature.

Data minimisation is a very important design criterion; we expect compliance with this Principle will be an essential component of any Identity Assurance Service.

Any decision that requires a risk assessment of the Service-User will need the correlation of data from possibly a number of sources will also be subject to the Data Minimisation Principle Note that the User Control or Transparency Principle should ensure the Service-User can provide informed consent/approval.

There should be no centralisation of IDA data.

Any exemption from the Data Minimisation Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary

Third and Fifth Data Protection Principles (“Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed” and “kept no longer than is necessary”).

The Data Protection Regulation currently being discussed by the European Commission and Member States aims to further strengthen the personal data minimisation requirements beyond those set in the Third Data Protection Principle of the 1998 Act. This is supported by Data Protection by Design objectives that also appear in the Regulation.

5. The Data Quality Principle

I choose when to update my records.

Service-Users should be able to update their own personal data, at a time at their choosing, free of charge and in a simple and easy manner.

Identity Assurance Providers and Service Providers must take account of the appropriate level of identity assurance required before allowing any updating of personal data.

Rationale/commentary

Unnecessary retention and excessive data collection would breach the Data Minimisation Principle.

If a Service User fails to keep his information up to date, then his transactions could fail; this we believe is the incentive for Users to keep information up to date.

Any legal obligation that requires, for example, an individual to notify a public authority of a change of circumstances is unaffected; a Service-User can choose to use an Identity Assurance System, at any chosen time, to update their own records subject to any identity assurance requirement prior to accepting an update.

As failed transactions (e.g. by virtue of a data mismatch) are likely to be alerted to Service-Users, this affords a possibility of designing procedures that offer Service-Users the opportunity to update their own details immediately – again subject to any identity assurance requirement prior to accepting any update.

The Identity Assurance/Service Provider has to be able to decide the level of identity assurance before accepting a change to a Service User’s data.

Any exemption from the Data Quality Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary

Accuracy requirements of DPA (4th Principle).

6. The Service-User Access and Portability Principle

I have to be provided with copies of all of my data on request; I can move/remove my data whenever I want.

Each Identity Assurance Provider or Service Provider must allow, promptly, on request and free of charge, each Service-User access to any IDA data that relates to that Service-User.

It shall be unlawful to make it a condition of doing anything in relation to a Service-User to request or require that Service-User to request IDA data.

The Service-User shall have the right to require an Identity Assurance Provider to transmit his personal data, to a second Identity Assurance Provider in a standard electronic format, free of charge and without impediment or delay.

The Service-User’s right to data portability shall also apply between Service Providers.

Rationale/commentary

For the absence of doubt, such access includes access to logs of Service-User activity, disclosure logs of any Service-User data, and any audit data relating to that Service-User’s activity but excludes any anonymised data that can no longer be linked or associated with a particular Service-User.

The prohibition is needed as there is a practice in the UK of requiring data subjects to use their subject access rights to criminal records and medical records and show the product of their access request to an employer or insurer. The prohibition stops unscrupulous use of the access right. The text is based on the prohibition in the ID Card Act 2005.

This is the right to data portability.

Any exemption from the Service-User Access and Portability Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary

Subject access under the DPA.

Privacy by Design (under the heading Data Protection by Design) should include a user access functionality; free Subject Access is part of the European Union’s Data Protection Regulation under discussion.

Stopping Enforced Subject Access is very important.

(Data Portability forms part of the European Union’s Data Protection Regulation under discussion).

7. The Governance/Certification Principle

I can have confidence in any Identity Assurance System because all the participants have to be accredited.

As a baseline control, all Identity Assurance Providers and Service Providers shall be certified.

There shall be a certification procedure subject to an effective independent audit regime which ensures that all relevant, recognised identity assurance and technical standards, data protection or other legal requirements are maintained by Identity Assurance Providers and Service Providers.

In the context of personal data, certification procedures include the use of Privacy Impact Assessments and Privacy by Design concepts.

All Identity Assurance Providers and Service Providers shall take all reasonable steps to ensure that a Third Party cannot capture IDA data that confirms (or infers) the existence of relationship between any Participant.

Certification can be revoked if there is significant non-compliance with any Identity Assurance Principle. The architecture of an Identity Assurance Service must be based on open standards.

Rationale/commentary

This Principle mandates the use of all relevant standards as the baseline for all information assurance/security/integrity controls used.

We expect that this Principle will require the production of document that describes how the design of the Identity Assurance Service has been informed by the application of the Identity Assurance Principles to the design (See also the Transparency Principle above).

The “reasonable steps” tries to ensure that web-based services cannot capture details of a relationship between a Service User and any Identity Assurance Provider or Service Provider (for example through the use of webcrawlers or webspiders)

(Note: this is why relationship data includes in its definition relevant cookies and programs that collect such data.)

Any exemption can be specified via use of the Exceptional Circumstances Principle, but we don’t expect many (or indeed any!).

Legal commentary

The Accountability Principle in the Data Protection Regulation (currently under discussion in Europe); the current obligations in the Seventh Data Protection Principle (or HMG Security Framework or ISO27000) are expected to form part of the Certification process.

Privacy Impact Assessments and Privacy by Design concepts will be legal obligation if the European Commission’s Data Protection Regulation becomes law (see under the heading Data Protection by Design and Data Protection Impact Assessments).

Consideration needs to be given as to whether it should be made unlawful for such details to be captured (even overriding any User’s explicit consent). We are very concerned that many Users do not know what permissions they have given nor do they read privacy policies of organisations based outside the EEA. There is a need to take away the defence of a Third Party that it has the permission of the User to capture details from an Identity Assurance Service.

8. The Problem Resolution Principle

If there is a problem I know there is an independent arbiter who can find a solution.

A Service-User, who after a reasonable time, cannot or is unable to resolve a complaint or problem directly with a Identity Assurance Provider or Service Provider can call upon an independent Identity Ombudsman to seek independent resolution of the issue.

As part of the certification process, Identity Assurance Providers and Services Providers are obliged to co-operate with the Identity Ombudsman and accept his impartial determination and to ensure that contractual arrangements:

• reinforce the application of the Identity Assurance Principles
• contain a reference to the Identity Ombudsman as a mechanism for problem resolution

The Identity Ombudsman can resolve the same or similar complaints affecting a group of Service-Users.

The Identity Ombudsman can co-operate with other Regulators in order to resolve problems and can raise relevant issues of importance concerning an Identity Assurance Service.

An adjudication/recommendation of the Identity Ombudsman shall be published.

There can be more than one Identity Ombudsman.

The Identity Ombudsman can recommend changes to standards or certification procedures or that an Identity Assurance Provider or Service Provider should lose their certification.

Rationale/commentary

The central problem is that many different Regulators (e.g. Information Commissioner; FSA, OFCOM) could be involved and that an individual has to be able to complain to a central point of contact in order to resolve an issue.

Without an Ombudsman/Advocate, there is a risk that the Service User will be passed from pillar to post.

One assumes, however, that a Service-User will resolve a complaint in the usual way. However, it is possible that complaints will not be resolved satisfactorily.

We expect that any determination made by an Identity Ombudsman can be appealed to the Courts by any party to the dispute.

Any exemption from the Problem Resolution Principle can be specified via use of the Exceptional Circumstances Principle (but we can’t see the need of any exemption as explained as follows).

Take an extreme example, and suppose there was an exemption needed for say “national security”, then the Regulator who has the responsibility for the national security function could be designated as the “ombudsman” for that purpose. This would maintain the integrity of this Principle and the secrecy required of the national security function.

9. The Exceptional Circumstances Principle

Any exception has to be approved by Parliament and is subject to independent scrutiny.

Any exemption from the application of any of the above Principles to IDA data shall only be lawful if it is specified in a statutory framework that legitimises all Identity Assurance Services, or an Identity Assurance Service in the context of a specific service.

Any exemption from the application of any of the above Principles that relates to the processing of personal data must also be necessary and justifiable in terms of one of the criteria in Article 8(2) of the European Convention of Human Rights: namely in the interests of national security; public safety or the economic well-being of the country; for the prevention of disorder or crime; for the protection of health or morals, or for the protection of the rights and freedoms of others.

Any subsequent processing of personal data by any Third Party who has obtained such data in exceptional circumstances (as identified by Article 8(2) above) must be the minimum necessary to achieve that (or another) exceptional circumstance.

Any exceptional circumstance involving the processing of personal data must be subject to a Privacy Impact Assessment by all relevant “data controllers” (where “data controller” takes its meaning from the Data Protection Act).

Any exemption from the application of any of the above Principles in relation to IDA data shall remain subject to The Problem Resolution Principle.

Rationale/commentary

There are a myriad of data sharing laws each with different standards and rules. To engender trust in identity assurance and to improve Parliamentary scrutiny, it is proposed that ONLY statutory gateways created by any legislation needed to establish the programme are valid. There might be a phasing in period (as discussed in the workshop).

The special interests indentified in Article 8(2) are expressly put into this Principle. However, the linkage to individual human rights means that the link can only relate to personal data (i.e. an identifiable living individual). This is why a definition of “personal data” is needed

This allows for limited onward data sharing, so long as it is consistent with Article 8 of the HRA. There is a real issue as to whether the current level of privacy protection is adequate for some public bodies (e.g. is the protection in RIPA adequate? is the Regulatory regime for the Security Service, GCHQ or the Police OK?).

Our construction avoids the opening up what would be an everlasting debate; however, the last paragraph of this Principle is the necessary “quid pro quo” for this position. (See comments at the bottom of Principle 8 re Governance on national security.)

Legal commentary

The Privacy and Consumer Advisory Group to the Government’s IDA Programme recommends that legislation is enacted to implement the Government’s Identity Assurance Plans. Any such legislation would be the natural vehicle to describe all aspects falling under the “Exceptional Circumstances Principle”.

It is expected that any exemption will be limited, and expressed in terms of particular subsets of IDA data (e.g. “personal data”, “audit data”, “relationship data”) necessary for the application of any exemption.

The European Commission’s Data Protection Regulation calls for mandatory Data Protection Impact Assessments (i.e. Privacy Impact Assessments).