JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DATA-PROTECTION Archives


DATA-PROTECTION Archives

DATA-PROTECTION Archives


data-protection@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DATA-PROTECTION Home

DATA-PROTECTION Home

DATA-PROTECTION  March 2011

DATA-PROTECTION March 2011

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Personal Images on work computers (Does this contravene more than the DPA?) [Long post]

From:

Andrew Charlesworth <[log in to unmask]>

Reply-To:

Andrew Charlesworth <[log in to unmask]>

Date:

Wed, 30 Mar 2011 12:30:00 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (226 lines)

WRT to the information security point:

> I am not sure the information security approach works.  The quick counter
> argument is to show that the material has been scanned and is clear of
> viruses or malware.  If that is the case, then the information security
> or the integrity of the system is moot.

This rather misses the point of such a policy, which is not to treat 
material on case-by-case basis, as that is to (surely erroneously) assume 
that all staff are technically literate enough to ensure their material is 
clean.  Such a policy bars all private material because it only takes one 
member of staff fail to sanitize their material properly for the system to 
be potentially compromised.  Therefore, whether an individual staff member 
can demonstrate 'clean' material is irrelevant to the objective of the 
policy, and thus irrelevant to the question of whether it is OK for them to 
import the material.

WRT (one last time) to the DP angle:

> The problem, as I see it, is that personal information has been uploaded
> onto an organisation's systems and computers without consent.  Once it is
> on the system, the organisation becomes a data controller.  If someone
> gives you a package and you accept it into your home, you are potentially
> liable for what is inside the package because it is in your possession.
> The DPA does state that the data controller is one who stores the
> personal data.

The first sentence is correct " ... personal data has been uploaded onto an 
organisation's systems and computers without consent."

The second sentence is wrong.  "Once it is on the system, the organisation 
becomes a data controller."  It does not (even if it is a public 
authority), see (s.1(1) DPA 1998).

The third sentence is, and remains, a non sequiteur in this context, no 
matter how often repeated.

The fourth sentence is wrong. "The DPA does state that the data controller 
is one who stores the personal data." It does not, see (s.1(1) DPA 1998).

The determining factor in DP is not who is holding the data (hence the 
differentiation between data controllers and data processors), but, as I 
noted, "who (either alone or jointly or in common with other persons) 
determines the purposes for which and the manner in which any personal data 
are, or are to be, processed" (s.1(1) DPA 1998).  That is the precise 
statutory definition of a 'data controller'.

S.1(1)(e), as Peter notes, is irrelevant to this determination, as it does 
not change the definition of data controller.  Even if it was potentially 
relevant, the data referred to would already be caught by S.1(1)(a) DPA and 
thus S.1(1)(e) is not triggered.  Further speculation, however well 
researched, built on the basis of s.1(1)(e) is thus built on sand.

For the record, "held" is clearly NOT synonymous with "stored"; although as 
Lawrence notes, what it *does* mean is not wholly clarified.

The Council makes no determination about the purposes for which, and the 
manner in which the personal data (the photographs) are, or are to be, 
processed.  Therefore the Council is not a data controller for the purposes 
of the DPA.  The staff member does make a determination about the purposes 
for which, and the manner in which the personal data (the photographs) are, 
or are to be, processed (dissemination to friends) and thus is a data 
controller (but the images probably fall under s.36 DPA Domestic purposes). 
Where the data is stored is simply not relevant for DP purposes, it's the 
determination of purpose of processing which is the key.

 - If I process work data about my students on my work computer, it is 
personal data for which my university determines the purposes for which and 
the manner in which any personal data are, or are to be, processed.  My 
university is the data controller and not me.  If I lose it, the university 
is responsible in DP terms, as data controller.  I will probably be subject 
to internal disciplinary proceedings, as my university has specific 
regulations on the safe handling of student data by staff.

 - If I process my local caving club's records on my university computer, 
the University does not determine the purposes for which and the manner in 
which any personal data are, or are to be, processed (running the caving 
club). The university is not the data controller, and if I lose the data, 
the University will face no sanction under the DPA or I under the 
university's DP-related regulations.  Depending on the arrangements between 
the club and myself, either I or the caving club could face sanction as the 
data controller.

 - If my University regulations state that I may not use university 
computer systems for personal or non-work related matters, my processing of 
the caving club's records on my university computer will breach those 
regulations, and may lead to disciplinary action, regardless of whether 
they are stored safely or not for DP purposes.

 - If the University provides storage for personal or non-work related 
matters, and I use it to process my local caving club's records, it is up 
to me (or the club) as data controller to determine whether the 
university's facilities are adequate to meet my obligations as a data 
controller.  The University is at most simply a data processor, it holds no 
direct DP obligations, except those which it enters into with me as the 
data controller. If the records are lost because the system is insecure, 
that's my problem as a data controller.  If the university has 
contractually agreed to ensure safe storage, then I may be able to mitigate 
any losses incurred as a result of data subject action against me by 
pursuing the University for breach. Otherwise, I'm on my own.

> The key for me is that the organisation has not consented to receive the
> information on its system and once on its system it is held for the
> purposes of the FOIA (albeit against its will) and for the purposes of
> the DPA. (With the caveat mentioned above.)

I would refer to the ICO' guidance, again, in terms of FOI (only)

b) Personal written communications (emails, etc)
In most circumstances private emails sent or received by staff in the 
workplace
would not be held by the authority as it has no interest in them. It will 
be a
question of fact and degree whether a public authority does hold them,
dependent on the level of access and control it has over the e mail system 
and
on the computer use policies. It is likely to be the exception rather than 
the rule
that the public authority does hold them.
Problems can arise with hybrid emails, those which contain a mixture of 
personal
content and that relating to the duties of the employee. The information 
which
falls within the latter classification is potentially disclosable, and so 
as part of
good email management the formulation of such emails should be avoided.

<http://www.ico.gov.uk/upload/documents/library/freedom_of_information/detailed_specialist_guides/awareness_guidance_12_info_caught_by_foi_act.pdf>

In terms of the DPA, the question cannot arise as the Council cannot, by 
clear statutory definition, be the data controller for the private material.


> In sum, I would argue that uploading personal images or information onto
> an organisation's computer system without permission will put the
> organisation in breach of the DPA unless there are specific policies,
> procedures and guidance in place stating that this is not acceptable. Or
> to put it positively, anyone wanting to upload personal information onto
> the organisation's system needs to have the consent (permission) of the
> organisation. If the information has been uploaded without consent of the
> organisation, the organisation (as a data controller) can take steps, as
> authorised by the DPA (and any other legislation) to remove the
> information so that it complies with the DPA.  In one sense, the
> organisation is in danger of holding personal information that is
> incompatible with the purposes for which it notified the ICO.
>
> I am happy to be corrected on any of these points as this is something I
> want to get right if only for my own understanding of the DPA.

In rebuttal:

1) The organization cannot be in breach of the DPA as a 'data controller', 
because it is not, by statutory definition, a 'data controller'.

2) The staff member may breach the DPA - they are the 'data controller' for 
that material, as they are the ones determining the purposes for which, and 
the manner in which the personal data are, or are to be, processed.

3)  I am unclear as to what section of the DPA the organisation could have 
breached regarding the material, as it is not the 'data controller'.  I 
would be interested in Lawrence's thoughts on this point.

4) As an employer, you are perfectly within your rights to

a) refuse to let your systems be used for their private purposes by your 
staff;
b) subject to the conditions in the RIPA and the LBPR, to monitor to ensure 
that this is the case.


I think I've now said all that I can say on this thread, and if Lawrence 
remains unconvinced, then I doubt I'm going to change his mind through 
further discussion.  In the long run, I suppose on a pragmatic view if a 
Council wishes to  bar staff from uploading private material (including 
material containing personal data) onto its computers, then for 99% of 
people, that's all that's relevant.  The precise rationale for a Council 
doing so is not going to worry them unduly - so "the DPA 1998 says 'No'" is 
as good a reason as any, even if the precise reasoning behind the policy 
is, in my opinion, erroneous.  I also doubt many people are going to 
subject that reasoning to the degree of scrutiny that this group can being 
to bear, or be able to identify the flaws in it.


This whole discussion is, I think, another argument for the need to review 
the DP regime, which, it will be clear from the debate,  is an extremely 
blunt tool to address the complexities of the modern technology environment 
- I'm willing to bet that when the EU Directive was being debated in the 
late 1980s, the fact that national implementing legislation would have to 
deal with situations as complex as individuals (as data controllers in 
their own right) importing privately generated digital materials containing 
personal data into their employer's computer systems, was not considered in 
any detail...



Andrew



Andrew Charlesworth
Reader in IT and Law
Director, Centre for IT and Law
School of Law/Department of Computer Science
University of Bristol
Wills Memorial Building
Queens Road, Bristol BS8 1RJ

Tel: 0117 954 5633 (CompSci)
Fax: 0117 954 5208 (CompSci)
E-mail: [log in to unmask]

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

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager