Some thoughts / observations
Id recommend rejecting request unless a 29(1) authorised by the Insurer
themselves supports it.
Its useful to examine the legal relationships here of the parties to unravel
potential informtion flows and points of responsibility.
The PI should confirm he is acting as an investigation agent of the Insurer
under contract. The Insurer is working for their insured client under
contract. The client here appears to be the engineering company presumably
the employer of the data subject at time of claim.
The data subject has presumably made an employers liability claim against
his employer. The employer has to have statutory employer liability
insurance (applies to virtually all UK employers).
There is no obligation for an employer to raise a claim against their
insurance policy, but should they chose to do so they are tied to the terms
of thier agreed insurance contract.
The employer should be notifying their employees that they will be
disclosing any information they hold to their insurers which is relevant to
managing employer liability claims, eg, pay records, sickness records etc.
Presumably this is done by all employers in entering into contracts with
their employees. (Does your employer notify of the potential purpose and
disclosures to their insurers). Technically its arguable that all
employers should define exactly what type of investigations will need to be
conducted by their insurer should an employee raise an employee liability
claim. (not all insurance policies cover the same risks or require the same
data to operate).
Ideally some transparency over potential information flows in employer
liability cliams should be made as condition of the employment contract.
As an aside here, where insurance and sensitive data is concerned the
insurer and their clients can also utilise condition 6 of the SI 2000/417 in
the Sensitive data processing order which in some cases can negate the need
for consent. e.g. medical data held by employer about an employee who
subsequently decides to claim from their employer under a personal injury
claim.
If an employee is breaching their employment contract by claiming for
'injury' when knowingly working for another employer that appears to be an
attempt at obtaining pecuniary advantage by deception. A criminal offence.
The employer is entitled to pursue this and this can be an integral part of
their insurance contract.
In Insurance claims investigations I advise that the insurer should make
such requests utilising 29(1) request procedures, as this information if
existing and not made available would appear predjudicial to investigating a
crime in this circumstance.
The prime purpose of the 29(1) request itself is as evidence to protect the
staff of the disclosee data controller and the importance of the declaration
by the requestor that they are indeed investigating a 'criminal offence'
cannot be overstressed.
I had asked the OIC if insurers can use 29(1) in insurance investigations in
this manner and they advised there is no reason why not. However the caveat
to this is that if a data subject subsequently challenged the insurer on
'fair and lawful processing' the insurer would have to satisfy the
authorities (regulator or court) that a criminal offence was indeed being
investigated. If they are unable to do this there can be an offence of
obtaining information by deception and / or unlawful processing. The
requestor could suffer substantial loss if making any false 29(1) requests
given potential impacts on individuals.
If an individual employee is 'moonlighting' with another employer then a
failure by that employer to disclose employment dates and type to a criminal
investigation would indeed appear to be predjudical to that investigation.
Moonlighting itself could possibly be a non-criminal offence but if the
individual seeks to gain advantage by raising a false injury claim against
his employer (seeking a payout) then a criminal action element is
introduced.
However exactly what data the investigation officer needs to supply to the
disclosee to effect a factual match on 'employee Mr Smith' is not clear. It
is the data matching elements where a disclosure can become difficult, and I
would suggest a refusal to supply could be argued on these grounds.
If you consider what you ask a data subject to provide to identfy themselves
then can a third party requestor supply same?.
A section 29(1) relates to information provision on a data subject under
investigation. The form by its nature must contain sensitive data (alledged
offender) so how such requests are to be managed by any controller has to be
considered. e.g. Can the data subject obtain a copy of this form from the
disclosee using SAR.
I suggest the only way this can be prevented is if it is kept in paper form
and filed in date order away from any records linked to the individual.(A
Data controllers processes must prevent any potential match with other
records in their possession). 29(1) request forms should be handled by a
properly empowered Data Protection Officer who should only make these forms
available to the OIC or the courts should the need arise not to any member
of staff of the controller (this including all senior management).
The DPA does not prevent disclosures it simply sets the control framework in
how they should be made.
In summary
I suggest the role of the disclosee is to examine if 'predjudice' to an
investigation by refusal to supply data can be seen to exist and if
accepting the requestors explantion that it does, in supplying information
they must properly control the request form and data flows.
The role of the requestor is to take responsibility for their actions in
making the request. (section 55 obtaining data in an unauthorised manner can
arguably come into play if falsifying a section 29(1) request. Data
controllers using such requests should have controls on their issue.
The data subject can pursue any breaches of DPA with the requestor (e.g.
obtaining information by deception / unlawful processing).
If the data controller disclosee accepts the 29(1) in good faith with
reasonable controls (e.g training to those who will handle) then they should
be protected.
OK Ive stuck my neck out. Whose wielding the Friday axe
David Wyatt
----- Original Message -----
From: "Colette Healiss" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, October 24, 2002 10:08 AM
Subject: [data-protection] Disclosure query
> Dear All
>
> We have received an enquiry from a private investigator acting on behalf
of
> a well known insurance company in pursuit of a case against an individual
> who is bringing a substantial personal injury claim against his employer
> (an engineering company).
> With me so far ?
> The private investigator has found out that the individual concerned is
> believed to have been working as a doorman here during the period he was
> supposed to be signed off work because of his injury and are requesting us
> to confirm whether or not he is registered with us.
>
> I can see that there would be justification for releasing relevant
> information we may hold in this case. What has been exercising my brain
> cells though is that I would be uncomfortable with releasing information
> either to this investigator or to the insurance company (were they to
write
> in with a request). I feel we should only respond to such requests when
> made by a solicitor (acting on behalf of the employer or insurance co in
> this scenario) in connection with the compiling of evidence for a legal
> case.
>
> What do others feel on this one?
>
> Colette Healiss
> IT Strategy and Regulation
> St Helens Council
> Town Hall
> Victoria Square
> Telephone 01744 456052
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
