Yep. You have convinced me. That's it folks: no more use of live data
please for testing purposes (except perhaps parallel running with the
real system and so - if it all works properly - you will only ever
change the data in an accurate fashion).
I really can't see a way round the 4th principle. (Of course, this
might also be an illustration of the all-pervasiveness and "business
unfriendly" black-and-white aspects of the DPA, of which there are many
examples, but that's another debate.)
Renzo
Renzo Marchini
Dechert LLP
+44 (0) 20 7184 7563 direct
+44 (0) 20 7184 7001 fax
[log in to unmask] <mailto:[log in to unmask]>
www.dechert.com <http://www.dechert.com/>
________________________________
From: This list is for those interested in Data Protection
issues [mailto:[log in to unmask]] On Behalf Of Tim Trent
Sent: 15 October 2009 10:35
To: [log in to unmask]
Subject: Re: [data-protection] sharing data with system
developers
To me it comes down, as always, since I am by no means a legally
trained person, to good sense and good ethics. We know that the "live
data" set has no intrinsic value as a testing tool, and I think that
horse is dead. I shall flog that one no more. What it has allowed me to
do is to develop my thinking into the 4th principle area.
Taking your quandary, let me look at it first on the real, live
system. On that system, if I change something about you to be patently
incorrect - let us change your sex to Female, for example, that is a
clear breach. yet we cannot say that is now data that is not about you,
for it is. It is simply incorrect. Were that not so we could argue
(with no legitimacy) that any data incorrectness rendered the data
record somehow impersonal.
Now, let us set the scenario where we have replicated that data
set and placed it on a new system. At the moment there are no
differences because no tests have started. This remains personal data.
It is identical in all respects save for the environment in which it is
held. Now I change your sex to Female. However hard I think, I cannot
conceive or argue that this is no longer your personal data. What it has
become is inaccurate personal data.
By the way I may have confused you with the "your daughter is
dead" element as referring to consent. I meant it to be an example of
gross mishandling of data and the testing process together. Even consent
for such processing would not have removed any duty of care to ensure
that letter be not mailed. But consent would certainly have removed any
doubt about whether the data record may be played with or not.
Marchini, Renzo wrote:
Tim, I was up to now against you - but I am beginning to
have doubts.
I agree (contra your view) that 1st principle can be
fulfilled without consent but with para 6. On the foolishness of the
"your daughter is dead" letter scenario - of course tragic, but not an
argument for saying you must have consent; only an argument for saying
that the other data protection principles should be adhered to. Some of
these principles will be easy to comply with: keep the secure and so
that letter won't be sent - if the letter is sent then that is a breach
of 7th principle.
The 4th principle is not so easy to address so, and you
are giving me doubts. You are right, testing will on the face of it
inevitably render the data inaccurate. I am not sure how to square that
one but have a quick thought to be shot down over: perhaps the
processing inevitably gone through as part of testing makes the data no
longer the personal data about the individual. Example: I am on a
database (say a bank's account system). For testing purposes, I am
given a very generous credit balance in the new system. Its no longer
really about me so perhaps it is no longer data which "relates to" me as
the data is only now test data and not real data. ie its no longer my
personal data. It would become my personal data again when it is then
used to make decisions about me (letter of death, wrong HIV status) that
it then engages the other data protection principles.
Just a thought ... probably can be criticised on a
number of grounds, but then how else do we address 4th principle?
R
Renzo Marchini
Dechert LLP
+44 (0) 20 7184 7563 direct
+44 (0) 20 7184 7001 fax
[log in to unmask]
<mailto:[log in to unmask]>
www.dechert.com <http://www.dechert.com/>
--
________________________________
Tim Trent - Consultant
Tel: +44 (0)7710 126618
web: ComplianceAndPrivacy.com - where busy executives go to find
the news first
personal blog: timtrent.blogspot.com/ - news, views, and
opinions
personal website: Tim's Personal Website
<http://www.trent.karoo.net> - more than anyone needs to know
Marketing by Permission
<http://feeds.feedburner.com/%7Er/MarketingByPermission/%7E6/1>
Important: This message is private and confidential. If you have
received this message in error, please notify us and remove it from your
system. This email and any attachment(s) are believed to be virus-free,
but it is the responsibility of the recipient to make all the necessary
virus checks. This email and any attachments to it are copyright of
Meadowood Associates, owners of Compliance And Privacy, unless otherwise
stated. Their copying, transmission, reproduction in whole or in part
may only be undertaken with the express permission, in writing, of
Meadowood Associates, at Meadowood House, 30 Redditch, Bracknell,
Berkshire, RG12 0TT.
________________________________
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
Selected commands (the command has been filled in below in the
body of the email if you are receiving emails in HTML format):
* Leaving this list: send leave data-protection to
[log in to unmask] <mailto:[log in to unmask]&BODY=LEAVE
data-protection>
* Suspending emails from all JISCMail lists: send SET *
NOMAIL to [log in to unmask]
<mailto:[log in to unmask]&BODY=SET * NOMAIL>
* To receive emails from this list in text format: send
SET data-protection NOHTML to [log in to unmask]
<mailto:[log in to unmask]&BODY=SET data-protection NOHTML>
* To receive emails from this list in HTML format: send
SET data-protection HTML to [log in to unmask]
<mailto:[log in to unmask]&BODY=SET data-protection HTML>
All user commands can be found at
http://www.jiscmail.ac.uk/help/commandref.htm and are sent in the body
of an otherwise blank email to [log in to unmask]
Any queries about sending or receiving messages please send to
the list owner [log in to unmask]
(Please send all commands to [log in to unmask] not the
list or the moderators, and all requests for technical help to
[log in to unmask], the general office helpline)
________________________________
This e-mail is from Dechert LLP, a law firm, and may contain information that is confidential or privileged. If you are not the intended recipient, please delete the e-mail and any attachments, and notify the sender. Dechert LLP is a limited liability partnership registered in England & Wales (Registered No. OC306029) and is regulated by the Solicitors Regulation Authority. A list of names of the members of Dechert LLP (who are solicitors or registered foreign lawyers) is available for inspection at its registered office, 160 Queen Victoria Street, London EC4V 4QQ.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask]
All user commands can be found at http://www.jiscmail.ac.uk/help/commandref.htm
Any queries about sending or receiving messages please send to the list owner
[log in to unmask]
Full help Desk - please email [log in to unmask] describing your needs
To receive these emails in HTML format send the command:
SET data-protection HTML to [log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
