Privacy by design
Part two: Barriers to privacy by design
Introduction
Privacy by design is an approach that will go a long way towards addressing the privacy-related tensions between individuals and organisations. However, there are management, process and technology ‘barriers’ that will prevent the evolution of a more productive privacy environment. These must be removed if privacy by design is to succeed.
Lack of management engagement
At the heart of individuals’ concerns about processing of personal information is a perception that there is a lack of rigorous processes, failure to recognise organisations’ responsibilities for privacy management, and a lack of accountability at senior management levels for the proper handling of personal information, despite the high-profile data loss incidents of recent times. There are a number of significant barriers that contribute to this situation.
Attitudes towards privacy and data protection
A cultural barrier to privacy by design arises in attitudes toward the Data Protection Act (DPA). Many organisations see the DPA as the maximum requirement for privacy rather than the minimum, and look to the law to tell them what they can’t do rather than what they can, leading to disputes about what constitutes morally acceptable use of personal information. Often these organisations view the Act as ‘just another compliance issue’10, and leave compliance to the relevant department rather than encouraging an organisational culture in which respect for privacy is valued.
Some organisations treat privacy as a function of information security, which can lead to failures to respect privacy needs. For example, the Poynter review of data losses in HMRC11 explores the causes of the biggest loss of personal data in UK history, yet at no point in the document does it mention the word ‘privacy’, but instead treats the problem as a systemic security failure.
The consequence of these issues is that executive managers do not always recognise their duties for privacy management, and hence often fail to create an organisation-wide culture that respects the rights of individuals.
The language of privacy
The difficulty of defining privacy needs has already been explored; but an equally significant problem is that of expressing the highest level requirements in a way that does not undermine privacy principles.
The language of privacy and identity is complex and whilst taxonomy is developing12, there are still disagreements, even between privacy professionals about how to describe privacy-related concepts. This lack of a shared vocabulary to discuss privacy and identity issues, compounded with a lack of awareness of what is required, means that system owners and executive managers all too often issue and sign-off system specifications that fail to address privacy satisfactorily. For example, they confuse ‘identification’ with ‘authorisation’ or ‘verification’, resulting in systems that capture personal information that simply isn’t needed.
Uncertain benefits of privacy management
For the majority of organisations, the benefits case for offering privacy, and in some cases for meeting the basic compliance needs of the DPA (particularly outside of regulated or publicly owned organisations), is unclear. This makes it very hard to justify investment in privacy functionality for new systems.
Indeed for some businesses there would an argument – albeit not a legitimate one – that it could be cheaper to ‘just not do it’. By gathering and retaining as much data as possible the business has a perception that it may receive likely benefits such as future data mining and marketing opportunities, despite the ‘toxic liability’ that may arise from holding this information. This is because the risks of legal or regulatory action arising from data loss incidents remain minimal. Traditionally, sanction imposed by courts or the ICO tend not to be punitive, and the cost of a fine is unlikely to be as great as that of implementing a compliance regime. Clearly this is not a morally or legally acceptable approach, but the reality is that it is one that some businesses do take.
Whilst personal information is perceived by businesses as a valuable commodity, with few risks associated with holding it, this state of affairs is likely to continue.
Key points:
- Executive managers don’t always recognise or correctly prioritise their organisation’s responsibility or their own accountability for protecting individuals’ privacy.
- Executives and their staff often lack a shared language to discuss or to specify privacy requirements in a clear unambiguous way. As a result, poor privacy specifications deliver poor privacy controls.
- Commercial risks and benefits of managing personal information are often unclear, making it hard to justify privacy investment. In consequence privacy needs are often omitted from the business cases for new systems.
Failure to plan for privacy in the systems lifecycle
Even when an organisation’s executive management issue a clear mandate to adopt privacy-friendly practices, an important barrier to privacy by design is the ability to incorporate privacy issues into organisational risk assessment and management processes. Security risk assessments – of which there are many – rarely take into account the needs of the individual and often fail to assign meaningful threat values to the loss of personal information, so the risks associated with such incidents are not properly managed. Similar problems exist in security standards such as ISO27001 that do not take into account risks from the individual’s perspective, nor do they prescribe privacy controls.
“Risk assessment processes haven’t kept pace with technology. You try losing 25 million paper files.”
- Attendee, Privacy by Design workshop
This often means that assessments fail to identify these non-functional or ‘hidden’ requirements and thus the need for appropriate privacy controls. In other words, system owners fail to specify them because they are either unaware of the need, or assume that they will be dealt with automatically at some point in the development lifecycle (this situation being similar to security in the past, where designers would often take the attitude that “the operating system has security controls so I don’t need any”).
In such an environment, organisations do not often demand privacy functionality from system vendors, or weight it highly when assessing ‘off-the-shelf’ software. As a result, vendors have little incentive to build privacy functions into their systems.
Furthermore, for many organisations assessments aren’t continued beyond the system specification stage. Systems are commonly assigned new tasks (often referred to as ‘function creep’), original objectives often fail to be clear or auditable, and data such as account details, challenge/response questions and scanned signatures spread beyond systems and organisations, where individuals’ control over that data is lost.
When privacy functionality is omitted from the system design
An important example of what can happen when privacy functionality is not properly considered is that of transparency. The DPA mandates the right of individuals to access their personal information held by data controllers, a process that is achieved through a subject access request (SAR). A request is typically submitted by sending a letter to the data controller, together with a payment of no more than £10. The request allows individuals to see what data is held on them and what is being done with it, and is a keystone of transparency in personal information processing.
However, problems can arise when systems have not been designed with functions to identify the presence of personal information about a given individual, or where an organisation operates numerous diverse systems containing distributed or even duplicated data. A lack of automated SAR functionality can greatly increase the cost to the organisation of servicing the request, and there are success stories from organisations that have not only addressed, but have in fact automated, their SAR process: for example, some credit reference agencies have fully automated their SARs with online applications for individuals13.
The privacy impact assessment (PIA)
The ICO Privacy Impact Assessment Handbook is an important step forward to address privacy needs in the systems lifecycle, but unless an organisation has incorporated the process throughout its project lifecycle, privacy risks are unlikely to be adequately managed. Within government circles, concerns have been raised that the PIA appears to duplicate work already present in the risk management accreditation document set (RMADS) that is mandatory for all new systems, and the exact nature of how the two processes should be integrated appears unclear to many practitioners. Further guidance in this area would be of benefit to all parties.
Key points:
- Traditional risk management methodologies often fail to consider the value of personal information, and hence do not take privacy needs into account.
- Risk assessment approaches often fail to manage privacy needs throughout the systems lifecycle, so many bespoke and off-the-shelf systems are still built without proper or innovative privacy controls.
- Privacy needs are often not rigorously considered at any stage of the systems lifecycle, so systems can be modified or re-used without consideration for privacy implications.
- Systems do not always support automated subject access requests, and hence information retrieval procedures can be onerous for organisations.
Balancing data sharing with privacy needs
The pressure to share personal information both within and outside of organisations is compelling: internal efficiencies, enhanced marketing and the commercial value of personal information all drive the data sharing agenda in private organisations and public authorities. However, more often than not it is data sharing that causes major privacy breaches. Data can be lost when copies are transferred between systems using unencrypted physical media such as CDs or memory sticks, yet many organisations still see this as a workable solution to the data sharing agenda.
Government must accept a degree of responsibility for this attitude, since the most serious breaches have been within public authorities. When data losses happen in the public sector, they are often on such a large scale that the loss is too big to quantify in any meaningful way. Data of this scale has a great potential value to criminals, and losses are likely to have a long ‘afterlife’ when so much data is involved since much of it will remain usable for a long time. Public sector bodies traditionally often didn’t apologise for losses; private sector organisations are perceived as being quicker to change their ways and offer compensation or apologies to affected individuals.
Silos and systemic problems
The data sharing agenda has the potential to undermine privacy controls in those systems that have otherwise handled privacy issues in a meaningful manner. Perhaps the most important technology issue is that of operating multiple systems as ‘data silos’ without taking into account the broader systemic implications of many silos across one or more organisations, and the combined impact of those silos on private information.
If a single system is built in accordance with good privacy principles derived from a PIA, and incorporates necessary privacy controls and technologies, it may be capable of protecting personal information. However, if the organisation operates multiple systems, each of which has been designed in isolation, then it will have multiple silos of personal information. In all likelihood, not all of the systems concerned will have been built in accordance with good privacy practices, and will need to share data for the organisation to deliver its necessary processing outcomes. This means that the ‘privacy-friendly’ system shares information with other systems that do not incorporate such controls, and the data becomes vulnerable as soon as it passes to those systems. Few organisations – even those that have incorporated PIAs into their system operations – take this overall systemic impact into account when considering privacy risks.
The loss of privacy metadata
Systemic issues also impact the value of privacy ‘metadata’ – data about personal information, such as when it was collected, from what source, with what expiry date, and with which usage permissions from the individual. This is essential information for nearly any privacy-friendly system to manage personal information in accordance with the wishes of the individual.
However, as data is shared between systems, privacy metadata may be lost since the non-compliant systems may have to strip the metadata in order to process the information. Those new systems are unable to fulfill the privacy wishes of the individual; nor is any subsequent system with which it shares the data; and that data will exist thereafter without any privacy metadata that could be used to rebuild the privacy needs of the individual.
Data sharing or data aggregation?
One of the key privacy problems – particularly in government – that arises from the data sharing agenda is a confusion between ‘data sharing’ and ‘data aggregation’. Very often, instead of creating an index that facilitates cross-referencing between existing databases, it is deemed simpler to create a new, larger database containing aggregated data. Potential consequences of this centralisation of databases include duplication of personal information; increased risk of inaccurate or inconsistent data; loss of control over where data resides; increased data processing and storage costs; and a lack of transparency of processing that can have regulatory consequences.
Confusing identifiers with indices
The Transformational Government agenda14 calls for personalised service delivery facilitated by technology, but for many legacy systems this target will require the collection and maintenance of large volumes of (often duplicated) personal information. Data such as name, date of birth, national insurance number are used as indices – and in many cases as the primary identifying credentials – in many systems. This may facilitate data sharing but also renders the systems vulnerable to identity-related fraud. Ironically the personal information often isn’t necessary for service provision, but in the absence of sharing between legacy systems has to be recorded time and again. The ‘Tell Us Once’ project15 aims to reduce this problem, but it will take many years before the thousands of affected systems can be updated. Until services such as the Government Gateway16 are both operational and interfacing with systems across government this state of affairs is likely to continue.
Key points:
- The pressure to share personal information within and outside of organisations can lead
to privacy-related problems:
- data from ‘privacy-friendly’ systems are shared with other systems that are less able to respect privacy needs;
- copies of personal information in transit are not always appropriately secured;
- organisations often aggregate data rather than sharing it;
- identifiers are used as indices, making it hard to anonymise data thereafter; and
- privacy metadata can be lost as information is shared between systems.
- If system PIAs are conducted in isolation the results may fail to take into account the broader systemic implications of data sharing.
The need for privacy standards
For any organisation that is implementing privacy practices, whether for baseline compliance with the DPA, or a more rigorous privacy regime, a fundamental challenge is the absence of internationally recognised privacy standards and associated best practice guidelines and development standards.
The DPA, and similar legislation around the world, define the privacy outcomes that are required without providing guidance on how to achieve it. Whilst it is clearly not the role of legislation to define such guidelines, standards are important for businesses. Inconsistent interpretations of the EU Data Protection Directive in each member state, a fundamentally different approach to the protection of personal information in the US, and the extra-territorial nature of some laws (eg California) mean that organisations have a wealth of international laws with which to comply. Many of these conflict with each other, and it is extremely difficult to track the changes worldwide.
Some excellent standards exist, such as those published by the Canadian Institute of Chartered Accountants17, but none that are yet internationally recognised (the British Standards Institute18 and ISO/IEC19 have ongoing projects in this field). Most importantly, whilst some data protection laws (Spain) dictate certain security requirements to comply with security principles of the DPA, there is no widespread recognition of what constitutes an acceptable level of security for the protection of personal information.
This situation leaves organisations in a difficult position, as they are unable to confirm what constitutes compliance with data protection laws, and need to implement their compliance efforts on a case-bycase basis. It becomes hard for executive management to be certain that the organisation has achieved compliance (particularly since auditors have no baseline against which to confirm as such), and even when it has there remains the risk that if an incident occurs then an investigation may judge security controls over personal information to be inadequate.
Designing for privacy
As a result of the lack of recognised standards, the privacy controls within any new system or process largely depend on a number of factors:
- the organisation’s overall privacy or data protection policy (if any);
- whether or not the organisation has adopted a PIA into its systems lifecycle;
- the privacy awareness and capability of the system owner and individual designers;
- the complexity, schedule and budget for the system (which may deter the wish to introduce privacy controls – often seen as an additional complexity – into the programme); and
- the regulatory environment in which the organisation operates (eg financial service organisations will have to implement controls in order to comply with their regulators).
In the absence of specifications, developers are left to use common sense, their interpretation of the DPA and their own perception of social responsibility, and in such circumstances it is highly unlikely that developers will interpret individuals’ wishes in a rigorous or accurate way. This can be contrasted with information security, where there are numerous detailed standards available, secure development methodologies and recognised security testing and audit mechanisms. Whilst it seems unlikely that a universal privacy standard will be achievable in the short or even medium-term, the complete absence of such standards is clearly a hindrance to a privacy by design approach.
Key points:
- Organisations are often uncertain how to implement systems that comply with data protection law, and are left to manage privacy in accordance with ‘best efforts’, with each system approaching the issue on a case-by-case basis.
- There are no internationally-recognised standards to guide organisations in implementing privacy controls.
The problems with PETs
Rapid technology developments make it very difficult to develop and agree standards for PETs. In consequence organisations are nervous about adopting the technologies, for fear of introducing unnecessary project complexity, risk, or investing in a technology that later proves to be obsolete. Legacy systems cannot be updated easily, and where new systems incorporate privacy protection, the associated technologies and metadata are often incompatible with older systems.
The move towards Web 2.0 and service oriented architectures (SOA), coupled with the emergence of cloud computing20, has further complicated the environment for PETs: traditional data models are no longer relevant, the location and ownership of personal information becomes unclear, and the new relationship between organisations and vendors is not clearly understood by all parties concerned. Where software and storage are being procured as a service, rather than an in-house function, it can be unclear who is responsible for managing privacy controls, and where the resultant accountability rests. PETs are not going to be developed and deployed in this environment without a fresh catalyst for their usage.
Key points:
- PETs have yet to find widespread adoption in ‘real world’ environments because organisations and vendors are fearful of committing to specific PETs in case these quickly prove to be obsolete as technologies develop. Web 2.0, cloud computing and SOA developments will most likely add further complexity to this problem.
Regulating privacy
Finally, a key barrier to privacy by design is the regulatory/compliance environment. Certain industry sectors (eg financial services) that regularly handle large volumes of sensitive personal information are subject to stringent regulatory controls and associated punitive sanctions from their respective regulators if they fail to comply. However, the majority of organisations are not subject to any privacy enforcement mechanism other than the requirements of the DPA and the powers of the ICO. Unfortunately, the ICO has in the past had insufficient resources to detect, investigate and prosecute organisations that openly disregard and breach the DPA, let alone to pursue those that are operating in a manner that may be legal but is not acceptable to individuals.
Good compliance does not ensure good privacy
In organisations that are not subject to sector-specific privacy regulation, it is quite possible to attempt to comply with the DPA without in fact protecting privacy – for example, to submit a ‘blanket’ data controller registration and provide a fair processing notice which allows for unrestricted sharing and use of collected information. Such an approach can be a particular problem in large organisations which provide a single fair processing notice but use this to share personal information throughout the organisation for a multitude of purposes. In such cases, internal data sharing is not viewed in the same way as sharing outside of the organisation.
There is also a problem – particularly associated with public authorities – of information being collected under statutory authority or where there is ‘enforced consent’, since individuals have little option but to offer their consent if they are to obtain essential services such as social security payments, the right to drive or watch television, collection of their refuse, or access to healthcare. Such organisations have a far greater moral duty of care over the information they collect, even where consent has been ‘freely given’. Mere compliance with the DPA is not enough in these circumstances.
Defining personal information
Despite guidance and clarification from the ICO, a further legal barrier to implementing privacy by design is uncertainty about what constitutes personal information.
For example, the IP addresses used by individuals’ PCs may be considered not to be personally identifiable, except where the data controller has access to other information that might enable crossreferencing of the address21 against other information to identify the likely holder of the address. Privacy advocates argue that these addresses are identifiable. This lack of certainty has been a contributing factor to the debate over the acceptability of online behavioural profiling systems such as Phorm22.
Ownership of personal information
Another area of significant legal confusion is that of ownership of personal information. It is generally accepted that where personal information is gathered by an organisation, that information is the property of the organisation concerned, although it remains subject to the stipulations of the DPA. However, the issue of who should have control over the personal information is not always clear.
Privacy professionalism
It is also widely acknowledged that conventional risk assessment approaches are only as good as the practitioners who use them, yet there are few recognised qualifications for privacy professionals, and few individuals who hold the relevant qualifications, leaving organisations uncertain about whether their privacy practitioners are actually competent to do the job. This also makes it difficult to compare assessment results between projects or organisations, since there can be little confidence that the practitioners concerned share the same skill sets. The information security profession has been through this same problem, and is now engaged in the establishment of a range of professional qualification, accreditation and regulation activities.
Key points:
- The ICO lacks the necessary resources and powers to detect, investigate and where necessary enforce compliance through punitive sanctions. In consequence, individuals perceive organisations as unaccountable when privacy problems arise.
- Many organisations treat the DPA as ‘just another compliance issue’, which is not necessarily enough to ensure effective privacy management controls.
- Despite the ICO’s guidance, organisations are sometimes uncertain about what constitutes personal information or what powers individuals have over that data.
- Privacy professionals operate in an unregulated environment where there are few recognised qualifications or accreditation bodies. This makes it hard for organisations to gauge the level of competence of the individual practitioner, or to trust that person’s work.
11 http://www.hm-treasury.gov.uk/poynter_review%20.htm
13 http://www.wiseconsumer.uk.experian.com/
17 http://www.cica.ca//index.cfm/ci_id/36529/la_id/1.htm
19 http://www.iso.org/iso/iso_technical_committee?commid=45306