POL00364020
POL00364020
From: Anthony de Garr Robinson{i
Sent: Sat 23/02/2019 12:16:18 PM (UTC)
To: Andrew Parsonsf
Ce: Simon Henderson i.
; Katie
Subject: Re: Data deletion
Attachment: image001.png
Attachment: image002.png
Attachment: image003.png
Attachment: image705a57.PNG
Attachment: image0fb0e8.PNG.
Attachment: image8e4ec7.PNG
In that case, I’ll leave the matter in your hands. Unless you disagree, I won’t delve into long notes that you sent
me last night until you have bottomed this out, one way or the other. The explanation (it is not an an answer)
may be that when Fujitsu talk about not having any process for deleting branch transaction or financial data, they
mean deleting data relating to whole transactions that have been entered into and are recorded on the system. Is
the kind of deletion were talking about is nothing like that?
One of the problems with this kind of last minute firefighting is that takes us away from our priority jobs. I need
to spend the rest of the weekend reviewing the draft opening submissions.
Tony
On 23 Feb 2019, at 09:54, Andrew Parsons {~
uk.com>> wrote:
Torstein sent me a short email last night saying that there is an explanation and he still believes his first statement
is correct.
I'm trying to speak to him to understand how he can say this.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP
d:
m
t
e.
POL00364020
POL00364020
Stay informed: sign up to our e-alerts<https://www.womblebonddickinson.com/uk/preferences>
<image705a57.PNG>
womblebonddickinson.com<http://www.womblebonddickinson.com>
<image0fb0e8.PNG><http://www.twitter.com/wbd_uk>
<image8e4ec7.PNG><https://www.linkedin.com/company/womble-bond-dickinson-uk-llp/>
From: Anthony de Garr Robinson I,
Sent: 23 February 2019 09:41
To: Andrew Parsons
>); Owain Draper; Jonathan Gribben;
Subject: RE: Data deletion
Dear Andy,
TP’ve been reviewing TG’s and SP’s witness statements and summarise below the things that they have each said
about remotely deleting transaction/financial data. In short, I don’t think the problem just lies with para 59 of TG
and it looks to me as if SP may have to correct at least his first statement and possibly his second also.
Until we know how this happened — which requires explanations from TG and Spink as to what they were
thinking — we cannot decide how or even whether we can present this to the court in a way that does not destroy
FJ’s credibility.
TG
TG (thankfully?) only deals with this in his first statement. In summary, he says the following things in the
following paras:
17. There are only four sources of transaction data. The fourth is via remote access — he specifies BTs on
Horizon online and transaction injections in Legacy horizon. No reference to remote editing or deleting.
57. He is not aware of any way that FJ could theoretically edit or delete transaction data. He also makes it clear
that this is all largely hypothetical — other than one BT, he is not aware of FJ ever having edited or deleted
transaction data.
58.10 Under the heading “Balancing Transactions”, having dealt with the one BT on Horizon online, he breezily
refers to Legacy Horizon transaction injections, implying that they happened but not saying so clearly and not
giving any sense of how often it happened.
59.1 Under the heading “Privileged Users”, he says (1) that PUs’ editing or deleting transaction data is only a
theoretical possibility which would require circumvention of controls, (2) that there is no policy, process or
practice calling for t Pus to edit or delete transaction data and (3) that as far as he is aware, FJ has never used PU
rights to edit or delete transaction data.
59.2 He says PU editing or deleting data is not part of the functionality of Horizon because other tools such as
TCs and BTs are enough.
59.3 He refers to PU changes to the BRDB as hypothetical only.
POL00364020
POL00364020
61. He indicates that as far as he is aware there is no other way FJ can remotely affect transaction data or other
branch account data.
Parker
In summary, Parker 1 says:
11. Roll’s account of editing and deleting branch data is incorrect and misleading.
19. The suggestion that FJ edited or deleted transaction data is not correct. He confirms TG1 para 37 that in
Legacy Horizon it was not possible to edit/delete messages committed to the message store.
55.4 Interestingly, Parker describes a form of remote data deletion here — deleting all the data in a faulty counter
in Legacy Horizon. So there may be a partially face-saving distinction to be drawn between deleting counter data
and deleting message store data. But I doubt that this distinction will help us with deletion in Horizon online.
55.6 He cannot think of any other incidents of remotely accessing counters.
In summary, Parker 2 says:
34. SSC is hugely reluctant to change financial data — not ther job and they recognised the seriousness of doing
so.
Tony
From: Andrew Parsons I,
Sent: Friday, February 22, 2019 7:55 PM
To: Anthony de Garr Robinson
Cc: Simon Henderson (¢-
~>); Owain Draper; Jonathan Gribben;
Subject: Data deletion
Tony
Below is a summary of the point we discussed earlier.
I've attached:
1. Our long briefing note on remote access — data deletion is covered at page 20. This note is still to vetted by FJ
but is built on all their mini reports.
2. The FJ original report on data deletion (that has been largely carried across into 1).
3. The key Peak with all the horrible stuff about FJ deleting data — which is very messy.
This matter has been escalated to Rob Houghton.
A
Andrew Parsons
POL00364020
POL00364020
Partner
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts<https://www.womblebonddickinson.com/uk/preferences>
<image001.png>
womblebonddickinson.com<http://www.womblebonddickinson.com>
<image002.png><http://www.twitter.com/wbd_uk>
<image003.png><https://www. linkedin.com/company/womble-bond-dickinson-uk-Ilp/>
From: Andrew Parsons
Sent: 22 February 2019 17:55
Rodric
Williams
Subject: URGENT - support needed over the weekend
Matthew and all at FJ
I'm sorry to drop this late on Friday but we have come across a point that could be a major problem. We will
need this urgently addressed over the weekend as it may require an amendment to Torstein's evidence on
Monday. I'm around all weekend on my mobile if easier to discuss with someone.
At para 59.1 of Torstein's first statement he says that as far as he is aware a privileged user has never deleted
transaction data from the BRDB.
In the attached note (under Section 2 and Section 4) it appears that SSC are deleting transaction data when there
is a stuck session that is stopping a counter from working. If true this appears to contradict Torstein's evidence
because I understand that "a session" holds transaction data.
The associated Peaks make clear that this is happening using APPSUP, which as we determined yesterday is a
POL00364020
POL00364020
form of Privileged User access.
For example, PC0263716 (attached) says:
From: Gillian Hoyland
Sent: Wednesday, November 22, 2017 11:18 PM
To: Post Office Service Desk
Ce: Paul I Smith
Subject: RE: ATF:17186625 I Session Correction Request
Hi
Due to the circumstances at the branch this session can be removed but the branch must be made aware that if
there are any losses/gains from removing it then they will be liable.
Please note, in future any requests of this nature that do not have the applicable form attached which shows what
the transaction was for, date etc will not be actioned by FSC until this form is received as this allows us to
investigate the incident.
Thanks
Gill
Gillian Hoyland
FSC Operational Support Manager
Date:20-Dec-2017 13:47:45 User:Joe Harrison
To resolve this I need to run the following SQL on a BRDB instance
delete from brdb_branch_user_sessions
where branch_accounting_code = 111832
and fad_hash = 124
and node_id = 2
and session_status = 'FAILED' or session_status = 'RECOVERING'
PLease can you authorise the unix team to grant me the "set role appsup" permission.
Date:20-Dec-2017 13:48:32 User:Joe Harrison
The Call record has been transferred to the team: Security Ops
Progress was delivered to Consumer
Date:22-Dec-2017 10:28:30 User:Joe Harrison
Operation complete - please transfer call back to me for closure.
Date:27-Dec-2017 14:35:15 User:Joe Harrison
[Start of Response]
The failed transaction has been deleted so please inform the branch that they should now be able to rollover. We
will supply formal closure later.
POL00364020
POL00364020
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
Earlier in the same Peak, there is a comment that makes clear this is not a one-off event.
From: MAC
Sent: 26 October 2017 17:48
To: Post Office Service Desk
Ce: MAC <j
Subject: RE: A17004602 - 17186625
Hi
What is the next course of action then?
POL have previously authorised removal of a session that is not related to travel money card plenty of times in
the past.
Regards
Emma Millman
There even appears to be an established process for this.
2017-10-26 11:39:37 [ Watts, James Marcus]
HDloutSTU : From: Post Office Service Desk [/~
Sent: 26 October 2017 12:36
To: MAC
Subject: RE: A17004602 - 17186625
Hi Jackie,
Apologies for this late response.
We already sent to POL the session correction form and just awaiting for their approval.
We’ll let you know as soon as we have receive a response.
In the attached note from FJ (in response to Coyne 3.271), there is the following comment:
"For these types of incident Fujitsu have not affected any transactional information that has been committed by
the branch and therefore will not affect the branch accounts. Session and Recovery tables use transitory
information to provide standard recovery business rules, however they cannot be exercised in the case when a
counter has been removed. The only option is to remove such information."
Is there a distinction between what Torstein has said and what is happening above? When Torstein refers to
POL00364020
POL00364020
"transaction data" does he mean something different? Or is the above not transaction data?
Earlier in the same note (section 2), the following comment is made in relation to a different incident:
3.267 [Coyne] said: "It has previously been said by Post Office that whilst Fujitsu could modify transaction data
to perform corrective fixes, they would not have delete capabilities (see paragraph 9.24 of my original report)."
In this case the session recovery had to be marked as completed (which removed it from site at the branch but
not from audit)
Again, how is this different, if at all, from Torstein's statement that deletion of transaction data from the BRDB
cannot happen?
I would be grateful if a full explanation could be provided as a matter of urgency. I'd also be grateful for
Torstein's input on whether his statement needs correcting?
Kind regards
Andy
From: Matthew. Lento:
[mailto:Matthew.Lenton@
Sent: 21 February 2019 11:05
To: Jonathan Gribben;
Cc: pete.newsome:
Michael Wharton
Subject: RE: Action requests [WBDUK-AC.FID 123822914]
Andrew Parsons; Katie Simmonds;
Jonny,
1. We have a basis for the paper on the APPSUP question and will be seeking to get that reviewed and returned
to you today if we can.
2. comments on paragraphs 3.249 and 3.266 of Coyne's supplemental report;
a. Attached is a paper relating to 3.249 to 3.265
b. Attached is a paper relating to 3.266 to 3.276
3. comments on WBD's paper on "Peaks with evidence of remote access"; - This is 3.277, I don’t believe I have
received that, can you re-send? We sent the original analysis of this one on 11th Feb, presumably you have a
follow up document to that?
4. comments on the table circulated by WBD — yes, doing that in conjunction with point 1 above.
POL00364020
POL00364020
Regarding Torstein, I will check with him.
Matthew Lenton
Post Office Account Document Manager
P&PS, Digital Technology Services
Fujitsu
Lovelace Road, Bracknell, Berkshire, RG12 8SN
From: Jonathan Gribben
Sent: 21 February 2019
To: Lenton, Matthew
Dave <Dave.Ibbett@
Cc: Newsome, Pete
<andrew.parsons@
<Katie.Simmonds'
<michael.wharton@
Subject: RE: Action requests [WBDUK-AC.FID 123822914]
; Ibbett,
“p; Andrew Parsons
Katie Simmonds
; Michael Wharton
Matthew, Dave,
Please would you provide an update in relation to the remote access requests below? When can we expect to
receive the information requested?
We intend to use some of the information that we have already requested in relation to remote access to produce
an additional witness statement from Steve and/or Torstein. I'm producing drafts now with a view to circulating
them internally today and sharing them with you shortly after that. Can Torstein be available to review and
comment before Tuesday?
We also need Torstein to consider whether it is necessary for him to correct certain aspects of his first witness
statement in light of Coyne's supplemental report and the Claimants’ supplemental witness evidence. I will send
you a note on that shortly. I'm aware that he has Bond Solon training today — can we arrange for him to look at
this after that?
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
ergs
POL00364020
POL00364020
Stay informed: sign up to our e-alerts<https://www.womblebonddickinson.com/uk/preferences>
<image001.png>
womblebonddickinson.com<http://www.womblebonddickinson.com>
<image002.png><http://www.twitter.com/wbd_uk>
<image003.png><https://www.linkedin.com/company/womble-bond-dickinson-uk-Ilp/>
From: Jonathan Gribben
Sent: 20 February 20
To: Matthew.Lenton
Dave. Ibbett}
Ce: 'pete.newsome@
(andrew.parsons@
Emma Campbell-Danesh
uk.com>); Amy Prime (
Subject: Action requests [
>'; Andrew Parsons
; Lucy Bremner; Katie Simmonds;
Matthew, Dave,
Further to our call this morning here's an updated action list, in order of priority. I'll pick up the commercially
sensitive documents point in a separate email.
Let me know if you want to discuss.
Kind regards
Jonny
Action
Current Status
Remote access:-
POL00364020
POL00364020
* a paper which explains what the APPSUP tool is, who could use it, what they could do and how it was audited;
* comments on paragraphs 3.249 and 3.266 of Coyne's supplemental report;
* comments on WBD's paper on "Peaks with evidence of remote access"; and
* comments on the table circulated by WBD at 18:35 on 19/2 (call or email)
New requests — top priority.
Papers on Coyne's 22 bugs
Ongoing — WBD and FJ working to produce papers on each of the 22 bugs cited by Jason Coyne
Confirmation of the documents referred to in the KEL analysis in Steve Parker's first statement
Requested by WBD on 19/02
ML email of 20/2 at 11:11
Release Notes
Requested by WBD on 15/02
We are due to write to Freeths re this — can this be provided today please?
1.
Further comments on Coyne 2
Requested by WBD on 18/02 at 17:57
DI email on 19/02 at 15:24
WBD response 20/02 at 11:21
2.
Cross-examination of Richard Roll (document/information request)
POL00364020
POL00364020
Requested by WBD on 18/2 at 14:45
JG email of 24 January re issues relating to Steve's second statement
With Steve — update requested
Email sent with first 4 sections 14/02/19
MSCs
Email from ML 19 /02/19
Closed
Andy Dunks statement
ML email of 20/2 at 11:00
Closed
Please consider the environment! Do you need to print this email?
The information in this e-mail and any attachments is confidential and may be legally privileged and protected by
law. matthew.lenton® “> only is authorised to access this e-
mail and any attachmer
matthew. lenton'
. If you are not
dissemination, distribution, publication or copying of this communication or attachments is prohibited and may
be unlawful. Information about how we use personal data is in our Privacy
Policy<https://www.womblebonddickinson.com/uk/privacy-policy> on our website.
Any files attached to this e-mail will have been checked by us with virus detection software before transmission.
Womble Bond Dickinson (UK) LLP accepts no liability for any loss or damage which may be caused by software
viruses and you should carry out your own virus checks before opening any attachment.
Content of this email which does not relate to the official business of Womble Bond Dickinson (UK) LLP, is
neither given nor endorsed by it.
This email is sent by Womble Bond Dickinson (UK) LLP which is a limited liability partnership registered in
England and Wales under number OC317661. Our registered office is 4 More London Riverside, London, SE1
2AU, where a list of members' names is open to inspection. We use the term partner to refer to a member of the
LLP, or an employee or consultant who is of equivalent standing. Our VAT registration number is
GB123393627.
POL00364020
POL00364020
Womble Bond Dickinson (UK) LLP is a member of Womble Bond Dickinson (International) Limited, which
consists of independent and autonomous law firms providing services in the US, the UK, and elsewhere around
the world. Each Womble Bond Dickinson entity is a separate legal entity and is not responsible for the acts or
omissions of, nor can bind or obligate, another Womble Bond Dickinson entity. Womble Bond Dickinson
(International) Limited does not practice law. Please see
www.womblebonddickinson.com/legal<http://www.womblebonddickinson.com/legal> notices for further details.
Womble Bond Dickinson (UK) LLP is authorised and regulated by the Solicitors Regulation Authority.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No
96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker
Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories
of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central,
Hayes End Road, Hayes, Middlesex, UB4 8FE.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be
privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-
free.
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com