Privacy
That is, what don't you need to know?
Lockstep's angle on privacy
We've come to realise that privacy and digital identity management are two sides of the same coin.
As a digital identity expert, Lockstep's Stephen Wilson has spent over 16 years helping organisations work out what they need to know about someone to do e-business with them. Along the way he realised that the key to protecting privacy is knowing what you don't need to know!
Lockstep's privacy practice is based around this very practical yet rigorous perspective.
Clients
We have undertaken Privacy Impact Assessments for clients including:
- Victoria's Smart Meter program (managed by the Department of Primary Industries)
see http://www.dpi.vic.gov.au/__data/assets/pdf_file/0003/138963/Lockstep-DPI-AMI-PIA-Report-1.2.1.pdf
- Queensland Health
- HealthSMART, Department of Health (Victoria)
- Department of Foreign Affairs' Australian Passport Office
- Businesslink (the NSW Government's IT and business process outsource provider)
- Vicroads' proposed registration & licensing system overhaul
- Australia Post
And we have delivered privacy design services, research and/or training for:
- Office of the [Federal] Privacy Commissioner
- Department of Justice (Victoria)
- Department of Health and Ageing
- Australian General Practice Network
- NSW Human Services Agencies' "HSNet"
- CSIRO.
Privacy is so much more than security, or secrecy, or confidentiality
While most business people appreciate that good privacy compliance requires good information security, many organisations still struggle to identify tangible privacy controls; i.e. practical IT and e-security design features that pro-actively protect privacy and improve the organisation's privacy posture. As with security, privacy is now subject to special technical governance requirements, but there is a grave risk that an overly compliance-oriented approach can be expensive and ineffective. Businesses must be careful they can still 'see the wood for the trees'.
Bridging a gap
Most privacy advisers come from a legal and/or policy background, and look at privacy through the lens of compliance, or public policy. That's perfectly fine of course, yet the compliance perspective can fall short of engaging IT projects in their formative stages. To build privacy in, you need to understand in detail what privacy means for informatics requirements, architecture, software design, and security.
IT professionals sometimes underestimate privacy because they have long been told that "privacy is not a technology issue". They can presume that if they have security covered, then privacy will follow, and in any case, it seems to be someone else's responsibility! But many times we've seen this viewpoint morph into complacency, which in turn leads to privacy vulnerabilities in information systems that aren't then detected until it's too late.
Some examples help to illustrate the gap:
1. Security is not the same thing as privacy. Consider two highly secure organisations A and B, and suppose that A wishes to share data about its customers with B. Let's assume A and B are both secure to the highest standards. Then what's the problem? Simply, it doesn't matter how secure is B; under the law, personal information about A's customers cannot generally be transferrred to B without those customers being informed, and without limits being placed on what B can do with it. Disclosure, or Secondary Usage, are not automatically OK just because the receiver is "secure".
2. Equally, secrecy is not the same thing as privacy. Too often the mistake is made that personal information found in the public domain can be exploited without the individuals' knowledge (this was the fundamental error made by Google in their StreetView wifi misadventure). But information privacy law doesn't much care where personal information comes from; the law doesn't even use the terms 'public' and 'private'. Instead the test is simply whether the information in question is personally identifiable. If it is identifiable, then there are limits on what an organisation can do with it, no matter how it was obtained.
Lockstep Consulting is able to bridge the gap between 'technology' and the 'business'.
"Privacy Engineering"
In addition to trust & privacy strategy development and Privacy Impact Assessments (PIAs), a truly unique offering of Lockstep's is what we call Privacy Engineering, a privacy-by-design approach that generates tailored, practical guidance for ICT architects, designers and project managers so they can build privacy controls into their systems. We work closely with our clients to fine-tune local design practices, building privacy controls in (as opposed to hoping 'audit' them in). Privacy Engineering protects customer relations, pro-actively uncovers privacy problems, saves money by solving problems sooner, and enhances compliance. Special focus areas include audit logs and transaction histories, web forms, change management processes, and databases.
A little more detail on the approach is given in Babystep 14.
More sophisticated PIAs
For an example of our Privacy Impact Assessments, see http://www.dpi.vic.gov.au/__data/assets/pdf_file/0003/138963/Lockstep-DPI-AMI-PIA-Report-1.2.1.pdf.
Lockstep's PIAs are more technologically sophisticated than most. We focus on discovering issues and identifying privacy controls in a timely manner, as part of systems design. We have the experience and orientation to work with architects and deverlopers, and to even be embedded in dev teams at the crucial stages of a project. Many PIAs, even if they manage to uncover significant technical issues, are conducted too late in the development life-cycle to make a real difference.
Lockstep keeps a watching brief over ongoing developments in PIA practices. Over time we have developed a flexible generalised PIA template in line with international best practices, and which we customise for each engagement. In particular, our approach adapts readily to different privacy regimes. An indicative table of contents is shown below.
- Introduction and overview
- Description of the project/system
- Information flows
- Privacy analysis
Each system has its own characteristic privacy issues. To underpin realistic recommendations, in this section we document the major issues. Subsections are varied by agreement with the client. We find that typically, the most prominent issues are Collection, Disclosure and Openness.
- Privacy risk assessment
- Privacy enhancing responses (if applicable)
Depending on where a client’s project is at on the development lifecycle, it can be appropriate to provide substantive responses to the privacy analysis, in the form of design suggestions or process improvements.
- Compliance with Privacy Principles
Here we capture in detail the degree to which compliance with applicable privacy principles (as agreed with the client depending on their regulatory environment) is impacted by features and functions of the system.
- Collection
- Use and Disclosure
- Data Quality
- Data Security
- Openness
- Access and Correction
- Unique Identifiers
- Anonymity
- Trans-border Data Flows
- Sensitive Information
- Recommendations
Advocates for Privacy and Privacy Enhancing Technologies
Stephen blogs regularly on privacy; search his posts at http://lockstep.com.au/blog/privacy.
As digital identity experts, Lockstep has also led they way in articulating a positive and robust vision for Privacy Enhancing Technologies. On this point, Stephen made a detailed submission to the 2005 Senate Inquiry into the Privacy Act, looking closely at intelligent authentication, smartcards and biometrics.
Sister company Lockstep Technologies undertakes award-winning R&D into innovative PETs.
Track record
Stephen's experience in privacy is summarised in profile below, and his publications in the field are gathered at the privacy section of the Lockstep library. He has also made numerous submissions on privacy to government nquiries into the Privacy Act, the ill-conceived Human Services Access Card, and spyware.
