All the examples and views given do serve to illustrate the necessity for
carefully considered views informing the policy of the data controller,
which obviously then requires fully implementing.
There are many examples of police officers (including inspectors and above)
abusing the s.29(3) exemptions, for domestic, financial, or other personal
purposes, resulting in a reduction of trust in every individual police
officers discretion and an increased internal trend by the police service of
requiring an inspector rank to countersign the originating request.
Inevitably in such a culture, as further abuses come to light which that
authority level has proven insufficient to stop, pressures to further raise
the level of authority across the board are likely to initially be seen as a
previously effective and simple to implement rectification exercise.
Many organisations will suffer similar issues, (I do recall where a member
of the political establishment was shown to have abused s.29(3) - the
flexibility provided by police discretion was thought suitable to deal with
that case as part of an internal exercise.) to varying extents with any
level of staff, and each will no doubt seek to implement resolutions
suitable for their organisational culture and the data in question. Hence
the need to ensure requesting organisations views are reflected in any
authority level for s.29(3) disclosures, but they should not be the only
determining factor.
Many issues could well identify variations in the associated risks and
required authority dependent upon the organisation being disclosed to, the
data itself, the purpose held, and the ease of administration within each
data controller organisation.
My experience has shown that some organisations accepted a constable’s
authority for some data but that an inspector’s authority was often
insufficient for access to other data. Should a s.29(3) request be refused
the policing organisation may always consider other options. e.g. I
perceive many circumstances where a s.29(3) request signed by a police
inspector and served on a journalistic organisation could well be rejected
and have seen other circumstances where direct computer access is granted to
service s.29(3) requests with the level of authority delegated to temporary
staff operating computer terminals working within given parameters provided
in a policy document and the work being audited subject to operational
requirements as opposed to identified risk or need. I would hazard a guess
operational requirements in the recent security environment have largely
taken precedence over many more mundane administrative matters.
Whilst a general acceptance by all organisations of an inspectors counter
signature may be simple for the police to train their officers in, and does
greatly simplify the internal training and administration there, it clearly
does not reflect the varying levels of security risk associated with the
personal data held by all organisations in the wider community, and in
itself often creates a weakness. i.e. Overworked police inspectors (or
acting inspectors) signing a pile of what may be viewed at the time as
routine s.29(3) requests during the end of a shift may provide nothing more
than merely a consistent level of authority.
In a similar way to any data fishing exercise, seemingly measured s.29(3)
requests may result in data which is excessive, or more costly to maintain
for the purpose than intended, whilst also distracting the data controllers
involved.
As has been previously muted by others a number of times a very real level
of audit of s.29(3) separate from both data controllers could be provided by
a requirement for disclosure of the s.29(3) data disclosure to a data
subject at a sufficient time after an exemption had been granted not to
cause a compromise.
Unfortunately views that having to provide details of audit trail access to
records as part of any subject access request are more frequently seen as
additional costs or possible compromises for data controllers, than real
benefits which may be achieved by such audit details forming part of any
database record, and deny the difficulties caused by audit trails themselves
being subject to subject access, making considerations regarding time
limiting compromises for data controllers more difficult to identify and
alienating compromised data subjects.
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: 07 January 2006 19:14
> To: [log in to unmask]
> Subject: Re: Section 29(3)
>
>
> In message
> <[log in to unmask]>, at
> 20:14:49 on Fri, 6 Jan 2006, Christopher Spray
> <[log in to unmask]> writes
>
> >I can't seem to find an up to date version of the form
>
> This site (which I maintain) has the history of the first two
> generations of 29(3) form:
>
> http://www.internetcrimeforum.org.uk/dpa29-3form.html
>
> If anyone has any later versions available I'd be happy to
> include them.
>
> >I think the more up to date versions include a confirmation
> that >failure to provide the information would be likely to
> prejudice the
> >investigation (to give you assurance under the S29(3)
> requirements for >disclosure).
>
> The form I have says that "failure to provide the information
> will, in
> [the authorising officer's] view, be likely to prejudice" ..
> either ..
> "The prevention and detection of crime, or the apprehension or
> prosecution of offenders" or "National Security".
>
> Whether or not that's a sufficient claim to provide 100% assurance is
> still something that requires evaluating in the light of individual
> circumstances when the form is received.
> --
> Roland Perry
> Secretariat, Internet Crime Forum.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.11/219 - Release Date: 1/2/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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
