|
Re comment
> The bit about purposes I agree with, but my concern stemmed from a
> review of the security of the transmission of personal data. 'A'
> contracts with 'B' to manage personal data. 'B' is a big company, and
> is not going to be told by 'A' how to run it's business and therefore
> makes decisions about its network security and how data is shipped
> around. Because it makes those decisions it is a data controller,
I disagree 'B' is the data controller in the context of the data subjects of
'A', whose data it is processing.
e.g. A organisation IEM offers lots of computer processing services but they
carry none of the liability or obligations to the data subjects of their
customers whose personal data they are processing for them. If IEM have a
security breach the data subject has no right of action against them
directly unless the data controllers contract ensures that this can occur.
Now if I also use IEM as Security consultants how do they avoid the conflict
of interest as part of that service to advise the data controller how to
transfer all costs and liabilities to them when they act my data processor.
This is a bit like the arguments going around conflicts of interests for
auditors also offering accountancy services.
In reality are data subjects rights rights weakened given the way a
processing services really operate. If you are the best security expert in
the world then who is qualified to conduct the appraisal of the processes
you may be offering. (Who audits the auditor argument).
As a data subject according to the Act I am mean't to be informed of the
identity of the 'data processors' used by my controller. Articles 10 and 11
of the EC 95/46 refer to notifying 'recipients' identities to data subjects.
DPA 98 Sect 70 defines recipients as data processors. DPA 98 Sch1 Part II
2(3d) which links to Articles 10 and 11 has left it all deliberately woolly.
Check it out. Giving the UK Acts drafting few data subject are likely to
understand their rights under DPA in this respect. I wonder what the OIC
would advise a data subject enquiring if they should be told of which
processors any given controller has choosen to use. Anyone seen any direct
reference to this in existing OIC guidance? If a data subject doubts the
accuracy of a data controllers response can they get any further via a
request for assessment through the OIC in arguing a potential breach of
principle 1?
How many controllers on this list are advising their data subjects who their
data processors identities are or even what type of processors they are
using.
As an individual I can't remember a single case where I have been advised
this (although I am tending to not look too closely at the small print these
days). If this is a principle 1 breach does that not allow me to seek
damages for unlawful processing against controllers who may have passed on
to a processor without informing me? What damage can I know I have suffered
without understanding who is processing my data? e.g. Bank lose credit card
data to hacker - was my data amongst it? It appears a drawn out process to
try to construct an argument if I do not know if a processor is used or not.
Now if I write to my local council, my university, my bank, my insurer, my
GP, my MP etc as data controllers for my data, what will they advise? I
suspect a full spectrum of responses would occur from an implied '--- off'
to 'Can you explain what you mean by 'data processor'?'
As you say 'dogs breakfast' I wonder who's holding the bone and risking an
arm
Anon
Name and address withheld ;-)
> -----Original Message-----
> From: This list is for those interested in Data Protection issues
> [mailto:[log in to unmask]]On Behalf Of Duncan Smith
> Sent: 18 February 2002 21:56
> To: [log in to unmask]
> Subject: Re: Don't use data processors!
>
>
> The deeper you get, the darker it gets!
>
> The bit about purposes I agree with, but my concern stemmed from a
> review of the security of the transmission of personal data. 'A'
> contracts with 'B' to manage personal data. 'B' is a big company, and
> is not going to be told by 'A' how to run it's business and therefore
> makes decisions about its network security and how data is shipped
> around. Because it makes those decisions it is a data controller,
> because it's a data controller it is not obliged to act in accordance
> with the wishes of the Data Protection Act 1998 as dictated by 'A' (data
> processor and all that). So what is the point of having that bit in the
> Act about data processors and written contracts? It has to be for every
> body, or nobody. 'A's relationship with 'B' should be as tightly bound
> as if it were a data controller - data processor relationship - surely?
>
> Dog's breakfast again!
>
> -----Original Message-----
> From: This list is for those interested in Data Protection issues
> [mailto:[log in to unmask]] On Behalf Of Ian Welton
> Sent: Friday, February 15, 2002 7:51 PM
> To: [log in to unmask]
> Subject: Re: Don't use data processors!
>
>
> I spent some time pondering this one too.
>
> The conclusion I came to was that if data controller 'A' was aware that
> information they were legitimately supplying to data controller 'B' was
> either being used by 'B' outside of the purpose it was provided, or for
> a purpose which did not match the purpose(s) the data subject had been
> advised of, then 'A' could not continue to disclose the data, without a
> breach of principle occuring, unless some schedule 2 or 3 criteria could
> be legitimately applied.
>
> Ian W
>
> > -----Original Message-----
> > From: This list is for those interested in Data Protection issues
> > [mailto:[log in to unmask]]On Behalf Of Duncan Smith
> > Sent: 15 February 2002 15:55
> > To: [log in to unmask]
> > Subject: Don't use data processors!
> >
> >
> > Is this just plain madness, or what?
> >
> > If, as a data controller, I ask someone to process personal data on my
>
> > behalf, there appears to be three options for the relationship. The
> > other party is either a data processor, a joint data controller, or a
> > data controller in common.
> >
> > My reading of Data Protection Act 1998 indicates that only in the
> > first situation, where the other party acts as a data processor, is
> > there any
> > 'protection' for the data subject. In this situation, the
> > [first] data
> > controller has an obligation under principle 7 to ensure that further
> > down the line any data will be handled in accordance with the Act. If
> > however the data is passed to another data controller, then the first
> > data controller has NO obligation to ensure the safe processing of the
> > data once outside their hands.
> >
> > Would there be joint & several liability in this instance, or could
> > the first data controller simply pass all the blame onto data
> > controllers 'down the line'?
> >
> >
> > Duncan S Smith
> > Principal Consultant
> >
> > e-mail: [log in to unmask]
> > gsm: +44 (0)777 556 8180
> >
> > Company Profiles
> > "The process of Improvement"
> > ----------------------------------------------------------------
> > The information transmitted is intended only for the person or entity
> > to which it is addressed and may contain confidential and/or
> > privileged material. Any review, retransmission, dissemination or
> > other use of, or
> > taking of any action in reliance upon, this information by persons or
> > entities other than the intended recipient is prohibited. If you
> > received this in error, please contact the sender and delete the
> > material from any computer.
> >
> > This footnote confirms that this email message has been swept by
> > Norton Antivirus software for the presence of computer viruses.
> >
> > Company Profiles Huntingdon UK +44(0)1480 461671
> > -----------------------------------------------------------------
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 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 : -
> > www.jiscmail.ac.uk/user-manual/summary-user-commands.htm
> > (all commands go to [log in to unmask] not the list please)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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 : -
> www.jiscmail.ac.uk/user-manual/summary-user-commands.htm
> (all commands go to [log in to unmask] not the list please)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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 : -
> www.jiscmail.ac.uk/user-manual/summary-user-commands.htm
> (all commands go to [log in to unmask] not the list please)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 : -
www.jiscmail.ac.uk/user-manual/summary-user-commands.htm
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
