As you will understand my views may only be generic on this as I have no
experience within the teleco field.
I will attempt to approach the subject solely from a data subject’s and
ex-directory telephone number perspective.
Narrowing the observations down to telephone numbers, in my experience where
a data subject feels their ex-directory telephone number has been
compromised two routes of attempting to identify the source of (or reason
for) any compromise exist:-
1. Through any identified data controller perceived as immediately creating
the compromise.
2. Through the original source of the data being used.
Accepting that the number of data controllers holding the telephone
number(s) of a given data subject are not restricted to teleco's, many data
subjects seem to utilise additional methods to uniquely identify data
controllers. e.g. different initials or forename(S) associated with the
number. The same issues may be seen more vividly with many e-mail addresses.
That practice seems to indicate attempts at the simplification of 1 above.
Where a difficulty exists in identifying 1 above, then 2 becomes the next
easiest option available, even if it is more complex. As a result the
teleco's may more frequently be seen as the offenders by data subjects.
Given that 2. above requires details of disclosures made (as can be required
by s.7.1(b(iii)) "recipients" rather than "classes of recipients" to whom
they [the data] are disclosed), if it is to work, 2 is completely negated or
significantly complicated by any lack of disclosure, or inherent
complexities in obtaining that type of data.
Hence the vast majority of compromised data subjects are disenfranchised
when any misuse of data occurs for which there is no simple trace to the
offending data controller, or trace from the offending controller to the
source of the data.
I would hazard a guess that where a data controller is knowingly carrying
out actions which may create some upset that they will take such actions as
are possible to protect themselves, including masking their identity and/or
the sources of their data. The detailed elements of s.7.1(b(iii)) then
become effectively neutered and generally ignored unless other reasons exist
to implement them.
Some useful question may be:-
Of those data controllers who hold recipient transaction type data, how many
actually disclose it as a routine part of their subject access process?
With the reliability of disks having improved so much and the cost of disk
storage being so cheap today, why are more costly methods of storing that
type of data more often used, even when the ROI period may be very short?
Does a lack of ability by a major portion of data subjects to effectively
manage these issues promote or chill their confidence in personal data
processing?
Ian W
> -----Original Message-----
> From: This list is for those interested in Data Protection
> issues [mailto:[log in to unmask]] On Behalf Of
> Roland Perry
> Sent: 10 January 2006 21:57
> To: [log in to unmask]
> Subject: Re: Section 29(3)
>
>
> In message <[log in to unmask]>, at
> 13:14:35 on Mon, 9 Jan 2006, Ian Welton
> <[log in to unmask]> writes
> >I was not intending to suggest that every part of each
> exemption used
> >should be notified to each data subject at a set period after the
> >exemption had been granted,
>
> OK, but some people do suggest that; although probably based
> on a false
> impression of what happens in some other EU states (which don't
> proactively notify, but simply give permission at some stage for the
> data to appear on SARs).
>
> >which is what I interpret as driving the question raised.
>
> Nevertheless, it still raises the issue of how much
> drill-down is to be
> expected. Should I really have to do a SAR on every phone
> company in the
> UK to determine if my number has ever been included in the phone bill
> released to law enforcement because one of that company's subscribers
> was under investigation? Or is it limited to *my* bills at
> those phone
> companies I use? (Which despite strenuous efforts to curb
> fragmentation
> is currently running at four).
> --
> Roland Perry
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: 1/9/06
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 message please send to the list owner
[log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|