Print

Print


All,

Many thanks to all for the comments that have come back on this.  The debate
has been a good one.  At the very least, I've confirmed that the matter is
not straightforward.

We have the issue what constitutes personal data; of work-related emails;
the ever present issue of unentangling the personal data of a data subject
and third parties.  (I think we are all well attuned to these.)  But
underlying this is fact that a data subject has no right to obtain the
personal data of third parties.  Clearly where they have already authored or
received the third party personal information - in the ICO's words - "it
will be more likely to be reasonable to disclose the information".  The
implication here, though, is that there will be occasional circumstances
where it is not reasonable.

And, as the ICO says:  if there is no consent "and you are not satisfied
that it would be reasonable in all the circumstances to disclose the third
party information, then you should withhold it".

Difficult judgements: and the arguments cut both ways.  The deadline is upon
me, however, and I have to get down off the fence....  Where does the
balance lie?  Once I've disclosed, it's out there.  And even if it is out
there already, if it gets out there again, then it will be my processing
that puts it there. You can't take it away, but I'm not convinced you have
to put it there again. As long as as the data subject gets their own
personal data that has been requested, that's the main thing for me.



Ray Cooke



On 3 June 2011 08:56, KPG Professional Services <[log in to unmask]> wrote:

>  I am inclined to agree with you here Trish, you cannot take away something
> that someone already knows and has especially as it relates to their own
> work.
>
> Some great debate about this but still to be convinced one way or the other
>
> Kevin Giles
> KPG Professional Services
> 51 Unity Terrace
> Perth
> PH1 2BG
>
> Tel: 07413 934228
>
> Web: http://www.kpgprofessionalservices.co.uk
>
> The information contained in this communication and its attachment(s) is intended only for the use of the individual to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify [log in to unmask] and delete the communication without retaining any copies. Thank you.
>
>
>
> On 03/06/2011 08:25, Bailey, Trish wrote:
>
> Paul
>
> Im sorry but I would have to disagree with you on this with regard to redacting info.  If you were to redact you are required to apply an exemption to cover the "withheld info".  My question is how can you possible apply an exemption to protect information that is already known to an applicant - does it not make the exemption null and void?
>
>
> Many thanks
> Trish
> Trish-louise Bailey
> Audit & Assurance (Information Governance)
> (IG covers:  Data Protection & Privacy, FOI, Information Security, Information Sharing & Confidentiality, Information & Records Management, Information Quality & Assurance)
> Telford & Wrekin Council
> Civic Offices
> Coach Central
> Telford
> TF3 4HDwww.telford.gov.uk
>
> em:   [log in to unmask] or [log in to unmask]
> tel:    01952 382537
> mb:   07528 969455
>
>
> -----Original Message-----
> From: This list is for those interested in Data Protection issues [mailto:[log in to unmask] <[log in to unmask]>] On Behalf Of Paul Ticher
> Sent: 02 June 2011 15:40
> To: [log in to unmask]
> Subject: Re: 3rd party data known to SAR applicant
>
> I've noted the comments from others about (a) that the data is not actually
> about the Data Subject (plausible argument), and (b) that it's nonsensical
> to withhold data the Subject already knows (also plausible).  However, it
> occurs to me that (b) may not be nonsensical in every case.
>
> Firstly, I can't see anything which says you *must* disclose data if the
> Data Subject already knows it.  That situation obviously makes it more
> likely to be disclosable, but doesn't require disclosure, unless I'm missing
> something.
>
> Second, I would distinguish between information which is available to the
> Data Subject on the internal e-mail system, and data that they can take away
> with them on paper and, presumably, show to other people (who may be legally
> privileged, but may just be their mates).
>
> Given that your Data Subject knows who the third party is, I would be
> inclined to redact the name, at least, because there is no detriment to the
> Data Subject in doing so but there is, at least, a warning that you consider
> the name of the third party deserving of protection.  They could, of course,
> immediately say to their mates "that name they've blanked out is X, Y" but
> that would be their choice, not your doing.
>
> So I think there is a good case for redaction.
>
> Paul Ticher
> 0116 273 8191
> 22 Stoughton Drive North, Leicester LE5 5UB
>
>
> ----- Original Message -----
> From: "Ray Cooke" <[log in to unmask]> <[log in to unmask]>
> To: <[log in to unmask]> <[log in to unmask]>
> Sent: Thursday, June 02, 2011 12:03 PM
> Subject: 3rd party data known to SAR applicant
>
>
>
>  All,
>
> I'd appreciate any thoughts from all you experienced folk out there on
> this
> one.
>
> Scenario is this.  Data subject (staff) makes subject access request.
> Emails to and from the data subject deal with 3rd party disciplinary and
> grievance issues sent to data subject in the course of work.  Some of the
> stuff is sensitive data.  Question is - should the 3rd party data be
> redacted out in responding to the SAR even though the data subject has
> seen
> it and may even still have access to email copies?
>
> I've taken the view that it is not appropriate or reasonable to leave this
> type of 3rd party data unredacted in supplying copies under SAR even
> though
> the data subject will have seen the material and indeed may have retained
> it
> within a work context.
>
> Is this the right approach to take in this particular circumstance?
>
> Grateful for any views on this.
>
> Ray Cooke
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     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)
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>
>
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      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)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> --------------------------------------------------------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error
> please notify the originator of the message.
>
> Any views expressed in this message are those of the individual
> sender, except where the sender specifies and with authority,
> states them to be the views of Telford & Wrekin Council.
>
> The content of this email has been automatically checked in
> conjunction with the relevant policies of Telford & Wrekin Council.
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      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)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  ------------------------------
>
> 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]<[log in to unmask]&BODY=LEAVE+data-protection>
>    - Suspending emails from all JISCMail lists: send *SET * NOMAIL* to
>    [log in to unmask] <[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]<[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]<[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]<[log in to unmask]>
>
> (Please send all commands to [log in to unmask]<[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)
>  ------------------------------
>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     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)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^