POL00367005
POL00367005
Message
From: Anthony de Garr Robinson
Sent: 23/02/2019 16:13:07
To: Andrew Parsons
cc: it
Owain Draper jonathan Gribben
i; Katie Simmonds [E.
Subject: RE: Data deletion
Understood. If you don't ask you don't get, so I thought I’d ask and then see whether quick answers were possible.
We need to serve these statements before the experts address remote access in their joint statement and in good time
before closings are lodged. I would therefore proceed on the basis of a Tuesday night deadline.
Tony
From: Andrew Parsons
Sent: 23 February 2019 1
To: Anthony de Garr Robi
imon Henderson {
Jonathan Gribben <7"
Owain Draper <_
Subject: RE: Data deletion
Torstein had already spoken to Steve about this and they both agreed. I will get Steve to double check though.
On Parker 3 — when do you think is the hard-deadline for this getting served? Some of your questions are not
straightforward so may only get answered if time permits.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP
Stay informed. sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON v ©
From: Anthony de Garr Robinson [mailto? “I
Sent: 23 February 2019 15:56
To: Andrew Parsons
Cc: Simon Henderson (}
Gribben; Katie Simmonds
Subject: RE: Data deletion
; Owain Draper; Jonathan
POL00367005
POL00367005
agree about the need to cover this off in Godeseth 3. Can we check wither Parker agrees on the logic and the
terminology? He will be cross examined on this too.
Here are my thoughts on Parker 3. You will see that my draft includes some paras correcting Parker 2 (we cannot serve a
further statement from him which does not do that, particularly in circumstances where Freeths have asked us to do that).
My draft also includes some paras dealing with deleting data from counters — I am now confused about this, and not just
because of your email last night: it seems from Parker I para 55.4 that deleting counter data (as opposed to message store
data) was something that used to be done in Legacy Horizon. Query whether Parker and Godeseth should cover this off
in their statements: you are currently in a better position than me to make a decision about this, Andy.
Tony
From: Andrew Parsons
Sent: 23 February 2019 15:28
To: Anthony de Garr
GRO +; Jonathan Gribben
“Subject: RE: Data deletion
All
I've spoken to Torstein.
He is adamant that FJ do not delete transaction data. His words: "it would be so bloody difficult to do, I can't even
imagine how you would do it".
In relation to the specific points raised by Coyne on data deletion, Torstein says that FJ are "deleting" data from the
BRDB, but not transaction data. When conducting a transaction, the BRDB keeps lots of flags in lots of different database
tables (think of each table as a separate database) to record when stuff is happening and when things are completed. For
example, it keeps a flag on when a session starts and ends or when a recovery process needs to run. Sometimes these
flags can get out of sync with what happened at the branch (say because of a comms issue) which can cause Horizon to
become locked ie. there is flag starting a session but no flag ending the session, so the next session cannot
commence. FJ do use privileged user access to go in and change / delete the out of sync bit of a database table, but this
is not the transaction database table. This does not change any transaction data. It just unblocks the system.
He's not actually sure that they even delete the flags - they may actually insert a missing flag or update the flag to the
correct status. He says it depends on the nature of the problem and he'd have to look at the detailed design documents
to know for sure. But he says people will casually refer to this as "deleting a session". But everyone in FJ knows what
this means and knows that it does not mean deleting transaction data.
In Torstein's view this is not a semantic distinction. Deleting a single marker in a database table is (he says) nothing like
deleting transaction data, and Coyne should know this.
I've attached my updated notes which explain this in more detail — page 20 onwards.
The difficulty is that the above explanation is not obvious on the face value of the Peaks, which talk about "deleting
sessions". I think we need a short couple of paras dropped into Godeseth 3 to cover this off. I'll draft something and then
circulate.
A
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP.
POL00367005
POL00367005
‘Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON v ©
From: Andrew Parsons
Sent: 23 February 2019 09:54
To: ‘Anthony de Garr Robinson’
Cc: Simon Henderson (~ GRO
Gribben; Katie Simmonds
Subject: RE: Data deletion
wain Draper; Jonathan
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
From: Anthony de Garr Robinson [mailto’
Sent: 23 February 2019 09:41
To: Andrew Parsons
Cc: Simon Henderson {
Gribben; Katie Simmonds
Subject: RE: Data deletion
wain Draper; Jonathan
Dear Andy,
’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.
POL00367005
POL00367005
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.
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 [mailto GRO j
Sent: Friday, February 22, 2019 7:55 PM
To: Anthony de Garr Robinson
Cc: Simon Henderson (; GRO. } Owain Draper; Jonathan
Gribben; Katie Simmonds
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
POL00367005
POL00367005
Andrew Parsons
Partner
Womble Bond Dickinson (UK) LLP.
Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON v ©
From: Andrew Parsons
Sent: 22 February 2019 17:55
To: 'Matthew.Lenton@
Cc: Jonathan Gribben; ;
Subject: URGENT - support needed over the weekend
; pete.newsome@
iams
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 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
Cc: Paul I Smith
Subject: RE: ATF:17186625 I Session Correction Request
Hai
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
POL00367005
POL00367005
Gillian Hoyland
FSC Operational Support Manager
Date:20-Dec-2017 13:47:45 User:Joe Harrison
in resolve this I need to run the following SQL on a BRDB instance
I
delete from brdb branch_user_sessions
where branch_accounting_code = 111832
jand fad_hash = 124
and node_id = 2
land 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
Pate: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.
[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
Cc: MAC ¢. i
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.
POL00367005
POL00367005
2017-10-26 11:39:37 [ Watts, James Marcus]
HDIoutSTU : From: Post Office Service Desk
{mailto:f[”
Sent: 26
To: MAC { GRO
Subject: RE: A17004602 - I7
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 "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.Lenton¢”
Sent: 21 February 2019 11:05
To: Jonathan Gribben;
ndrew Parsons; Katie Simmonds; Michael Wharton
Subject: RE: Action requests [WBDUK-AC.FID123822914]
Jonny,
POL00367005
POL00367005
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 11" 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.
Regarding Torstein, I will check with him.
Matthew Lenton
Post Office Account Document Manager
P&PS, Digital Technology Services
Fujitsu
RG12 8SN
From: Jonathan Gribben [mailto
Sent: 21 February 2019 10:04
To: Lenton, Matthew ¢
Cc: Newsome, Pete ¢. Andrew Parsons
Simmonds Michael Wharton:
Subject: RE: Action requests [WBDUK-AC.FID123822914]
>; Ibbett, Dave
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
POL00367005
POL00367005
Stay informed: sign up to our e-alerts
WOMBLE womblebonddickinson.com
BOND
DICKINSON v in}
From: Jonathan Gribben
Sent: 20 February 21
To: Matthew.Lenton
Cc: 'pete.newsome¢ GRO
Emma Campbell-Danesh (7
Subject: Action requests [WBDUK-ACFID123822014]
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:-
¢ —apaper which explains what the APPSUP tool is, who New requests — top priority.
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)
Papers on Coyne's 22 bugs Ongoing — WBD and FJ working to
produce papers on each of the 22
bugs cited by Jason Coyne
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
POL00367005
POL00367005
2. Cross-examination of Richard Roll (document/information Requested by WBD on 18/2 at 14:45
request)
JG email of 24 January re issues relating to Steve's second With Steve — update requested
statement Email sent with first 4 sections
14/02/19
Please consider the environment! Do you need to print this emai
The information in this e-mail and any attachments is confidential and may be legally privileged and protected by I only is authorised to access
this e-mail and any attachments. If you are not matthew.lenton¢""" GRO ~~}. please notify jonathan.gribbeng~ Th as soon as possible and delete any copies.
Unauthorised use, 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 Privaey 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 0C317661. 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.
Womble Bond Dickinson (UK) LLP is a member of Womble Bond Dickinson (Intemational) 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 (Intemational) Limited does not practice law. Please see 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
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
POL00367005
POL00367005