POL00364056
POL00364056
From: Jonathan Gribbenf
Sent: Thur 28/02/2019 1:33:12 PM (UTC)
To: Anthony de Garr Robinso! ; Andrew Parsons[
Ce: ‘Simon Henderson (é
5 Lucy
1]
Subject: Godeseth 3 and Parker 3 [WBDUK-AC.FID123822914]
Attachment: _DOC_154490922(3)_Third Witness Statement of Torstein Olav Godeseth v9.DOCX
Attachment: _DOC_154500419(1)_Third Witness Statement of Steven Paul Parker v10.DOCX
Dear Tony,
Please find attached revised versions of these statements. There is just one point for each witness to clarify.
You'll see that we have moved the points that were in TG3 para 26 (injecting transactions in Legacy Horizon) to SP3.
Steve hasn't confirmed he is happy with this yet, but Torstein advised that he'd spoken to Steve about one of the two
Peaks so I don't think it will be an issue.
You'll also see that we have added some wording to para. 14.1 of TG3 to make it clear that while privileged users
could theoretically inject, edit or delete transaction data in Legacy Horizon, they couldn't do it in the message store
because Riposte wouldn't allow it).
In his first statement Torstein talked about privileged users editing or deleting transaction data. Having considered it
further he thinks that with enough access rights a privileged user could also inject transaction data. Do you think we
need to make that clear in the statement?
Torstein and Steve have confirmed that the ability to conduct a BT in Horizon Online did not require privileged user
access and you'll see that I've asked Torstein to confirm whether injecting transaction data in Legacy Horizon required
such access. I'm not proposing to explain this in his statement expressly, but it's something we should be aware of.
Finally, I've responded to your point 4.k. in red below.
Please let me know if you have any comments or questions.
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
womblebonddickinson.com
WOMBLE
BOND
DICKINSON vy 0
Gribben
Sent: 28 February 2019 09:51
To: ‘Anthony de Garr Robinson’; Andrew Parsons
Ce: 'Simon Henderson ¢-
Simmonds
Subject: RE: Godeseth 3 [WBDUK-AC.FID123822914]
)
; Owain Draper; Katie
POL00364056
POL00364056
Dear Tony,
I will find out.
Kind regards
Jonny
From: Anthony de Garr Robinson
Sent: 28 February 2019 08:43
To: Jonathan Gribben; Andrew Parsons
Cc: ‘Simon Henderson
Simmonds
Subject: RE: Godeseth 3 [WBDUK-AC.FID123822914]
; Owain Draper; Katie
Dear Jonny,
I’ve been ruminating overnight. Is there any possibility that Parker could speak to the points made in TG3 para 26?
Best wishes,
Tony
From: Anthony de Garr Robinson
Sent: 27 February 2019 19:09
To: Jonathan Gribben
Ce: Simon Henderson
Andrew Parsons
‘atie Simmonds ¢
Subject: RE: Godeseth 3 [WBDUK-AC.FID123822914]
Dear Jonny,
My comments on your comments below.
Best wishes,
Tony
From: Jonathan Gribben <:
Sent: 27 February 2019 17:33
To: Anthony de Garr Robinson ¢
Cc: Simon Henderson (i
Katie Simmonds <.
Subject: RE: Godeseth 3 [WBDUK-AC.FID123822914]
Dear Tony,
I've added some responses in red below.
I'm about to send Torstein an updated version of his statement and will share the next (and hopefully final) version
with you asap, but suspect that will be tomorrow.
Kind regards
POL00364056
POL00364056
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
\ womblebonddickinson.com
DICKINSON y ©
From: Anthony de Garr Robinson
Sent: 27 February 2019 15:33
To: Jonathan Gribben; Andrew Parsons
Cc: Simon Henderson ¢
Simmonds
Subject: RE: Godeseth 3 [WBDUK-AC.FID123822914]
; Owain Draper; Katie
Dear Jonny,
Here are my comments on the current draft of Godeseth 3:
1. Para 2 — insert “... but Lhave been asked to expand...”.
2. Para 3 — for clarity, refer to a change in the branch’s overall cash or stock position, rather than a movement.
By the way, I love the elegant way TG includes opening stock and cash positions as transaction data.
3. Para 8.2 — remind the reader what BAL is.
4. Para 14 is confusing and incomplete. For example, para 14.1 is going to say something about Legacy Horizon
but stops in mid air. Could the whole para be clarified/rewritten in the following ways?
a. Deal with Legacy Horizon separately from Horizon. Because there were Legacy Horizon message stores
in branch as well as at Post Office, and the remote access position was very different with respect to
message stores as compared to the BRDB, it is best to deal with Legacy Horizon first before saying anything
about Horizon Online.
b. Para 14.1 — assuming TG is just talking about Legacy Horizon, is he going to say that PUs can inject,
edit and delete data anywhere - in counters, in message stores, and anywhere else in Horizon? If so, how
does this square with TG] para 37 and SP1 para 19? We've asked TG to clarify
c. Para 14.3 — who at Fujitsu could inject transaction data in Legacy Horizon? Any Fujitsu employee? Any
SSC member? Just PUs? Was it a form of PU access? Was there a tool for it, like the Horizon Online BT
tool? Changed to SSC.
d. Para 14.4-
i. see my earlier email’s questions about SP3 para 18.
ii. Isn't this inconsistent 37 of TG1? Given what he is now saying, can TG
say a few words which would explain why he said what is said in that para?
iii. Has TG overlooked the form of non-automatic data deletion and copying
discussed in SP2 para 38.2? Does that not need to be accommodated?
e. Para 21 —
POL00364056
POL00364056
i. puta full stop after “deleted” and take out the words “and so”.
ii. See the query in my earlier email about SP3 para 15. They can’t be
saying inconsistent things! Resolved by your change to Parker 3
f. Para 22 — following on from my comment on para 21, this seems to be drafted on the hypothesis that PUs
do change transaction data. But TG’s evidence is they do not. Could some words be included in para 22 to
make this clear — e.g. that PUs do not edit or delete transaction data properly so called but, even if they
did,... etc. Changed
g. Para 24 —can TG safely assert that to everyone at Fujitsu, the words “balancing transaction” means
BTs? My understanding from conversations (I think with Andy (?)) is that there are some Peaks referring to
“balancing transactions” which are not BTs. Have I got that wrong? Given that only one BT has happened
in 9 years, it seems surprising that everyone at Fujitsu had a clear view as to what the words mean. So I
wonder whether the wording should be softened a bit, without changing the sense? Changed
h. Para 25 — the last sentence is not good news. The witness appears to be saying that he did not know what
he was talking about. Can TG say anything to pre-empt the inevitable accusation that he should not have
given evidence on oath on something he did not know about? He is saying he was aware of one method of
injecting transactions in Legacy Horizon but not the other. The statement he made in his first statement was
his understanding at the time. There isn't any way around this.
i. Paras 26.1 and 26.2 — references to assurances from colleagues will not do. Under the CPR, sources of
information have to be identified, and on significant issues like this unattributed hearsay will deprive the
evidence of any weight. We have used colleagues previously to avoid mentioning Gareth Jenkins. Also, TG
will be accused of again giving evidence on oath about something he does not know about, what can he do
say to avoid this? Nothing — he doesn't have the requisite knowledge of Legacy Horizon. We know about
this. WE HAVE USED COLLEAGUES ON LESS IMPORTANT POINTS. THIS REALLY WILL NOT
DO. IS JENKINS REALLY HIS ONLY SOURCE OF INFO? IF SO, TO REFER TO “COLLEAGUES”
IN THE PLURAL IS POSITIVELY MISLEADING. CAN WE REFLECT ON WHETHER WE CAN
DO WITHOIUT THIESE PARAS ALTOGETHER?
j. Para 26.2 — the para should start with a capital T.
k. Para 27 —re- the first sentence, what is our evidence here? Do we say that there were few Legacy
Horizon transaction injections (whether via counter 32 plus or via a branch counter) or that there might have
been lots but there were many more other kinds of injections? The letter is not very helpful tous. He
doesn't have the requisite knowledge of Legacy Horizon to say how many transactions were injected into
Legacy Horizon. We could ask FJ to run a search to see how many were entered in total (the search referred
to in Parker 2 relates to injections at the counter only, but this will take time and won't be ready for this
statement). ARE YOU SAYIUNG THAT WE COULD HAVE ASKED THIS EARLIER BUT HAVE
LEFT IT TOO LATE? CAN WE ASK NOW, ANYWAY? YES AND YES
Best wishes,
Tony
From: Jonathan Gribben <j"
Sent: 27 February 2019 13:31
To: Anthony de Garr Robinso:
i>; Andrew Parsons’
Katie Simmonds <7
Subject: Godeseth 3 [WBDUK-AC.FID123822914]
Dear Tony,
We'll work through these comments. In the meantime, here's an advanced version of Godeseth 3 and a PDF showing
the changes made to the previous version, so you can see what Torstein has changed.
Kind regards
Jonny
POL00364056
POL00364056
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
= womblebonddickinson.com
}) WOMBLE
BOND
DICKINSON Ain)
From: Anthony de Garr Robinson [1
Sent: 27 February 2019 12:42
To: Jonathan Gribben; Andrew Parsons
Cc: Simon Henderson
Simmonds
Subject: RE: Data deletion [WBDUK-AC.FID123822914]
; Owain Draper; Katie
Dear Jonny,
Here are my immediate comments on Parker 2, without the benefit of having sight of Godeseth 3. Some of them are
quite fundamental, sadly (in particular, my queries about para 15 and para 18). Hopefully they can all be quickly
answered: this statement (and Godeseth 3) are urgent.
Para 6 —I think Riposte was a piece of software, not a store. If I’m right, please use the proper name for the store. Is
Steve Parker referring to the branch message stores in branches and/or the Post Office message stores?
Para 13 — typo at the beginning of the third sentence. Could it be spelt out that APPSUP is only relevant to Horizon
Online — or does Godeseth make this clear?
Para 14 — this may not matter, but what does Steve mean by the word “site”?
Para 15 — the second sentence indicates that APPSUP can be and has been used to change (alter and delate) transaction
data, is that right? If so, this is inconsistent with Godeseth I para 59.1, who says it never happens in practice. Does
Godeseth 3 correct this? If not, we have a problem: Which of Godeseth and Steve Parker is right?
Para 18 —
1. The usual scenario is deleting the data on a defective counter and replicating it from elsewhere (e.g. another
counter or the branch message store). As I understand it, the message stores held at the branch were not counters
and nor were the Post Office message store. To be clear, though, is Steve saying that message stores were also
sometimes deleted and replicated from another source (presumably, counters)?
2. Regardless of the answer to (1) above:
a. Is Steve saying that one could delete all the transaction data (and other accounting data — e.g. stock and
cash positions) completely from the relevant machine (counter or message store), and then separately cause
the relevant data to be replicated from another source?
b. Or is he saying that one could delete all the data completely from the relevant machine (counter or
message store), and this would automatically cause the relevant data to be replicated from another source?
POL00364056
POL00364056
c. Or is he saying that one could cause a process of replication to one source from another and this would
inevitably result in the deletion of the data on the first source?
I think the answer to this is a or b, because of what Steve says in para 38.1 of Parker 2. Para 19 implies b, but
maybe the answer is usually b but a was possible. I don't know and I would like to understand before approving
this para.
Para 20 is con fusing and frankly looks evasive. We’ve discussed this before, but I’ll repeat:
1. Parker 2 was commenting on a claim in Parker I that the SSC could not use its remote access powers to cause
payments to be made in bank accounts.
2. Parker 2 appeared to qualify that claim by saying that one could not cause payments to be made in normal bank
accounts but one could cause payments to be made in Giro accounts, because they are different. He did not say so
expressly, but to my mind that is the clear impression achieved by the first two sentences of para 35 and the
footnote to Parker 2.
3. As I understand it, Parker thinks that one could cause payments to be made in normal bank accounts.
4. If that is the position, to avoid looking evasive and willing to mislead, I think he should say so squarely. If you
disagree, feel free to call me.
5. I do not understand the point being made in the last sentence. How is it relevant to any of this?
Best wishes,
Tony
February 2019 11:35
To: Anthony de Garr Robinson ¢
Ce: Simon Henderson
Subject: RE: Data deletion [WBDUK-AC.FID123822914]
Dear Tony,
Please find attached what should hopefully be the final version of Parker 3 for your final review. By way of
explanation, we have restated the words "seek to" in para. 3 and the word "usually" in para. 5 to avoid making
unequivocal statements.
Steve is lined up to sign this afternoon
Kind regards
Jonny
Jonathan Gribben
Managing Associate
Womble Bond Dickinson (UK) LLP
POL00364056
POL00364056
Stay informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
BOND
DICKINSON vy ©
From: Anthony de Garr Robinson [/
Sent: 23 February 2019 15:56
To: Andrew Parsons
Cc: Simon Henderson £
Gribben; Katie Simmonds
Subject: RE: Data deletion
€
“3 Owain Draper; Jonathan
J 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
Sent: 23 February 2019 15:28
To: Anthony de Garr Robinsot
Cc: Simon Henderson
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.
POL00364056
POL00364056
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.
Stay informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
N
' BOND
DICKINSON Yin)
From: Andrew Parsons
Sent: 23 February 2019 09:54
To: ‘Anthony de Garr Robinson’ o . oer,
Cc: Simon Henderson (; GRO ! Owain Draper; Jonathan
Gribben; Katie Simmonds
Subject: RE: Data deletion
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
Sent: 23 February 2019 09:41
To: Andrew Parsons
Cc: Simon Henderson ¢
Gribben; Katie Simmonds
Subject: RE: Data deletion
Owain Draper; Jonathan
Dear Andy,
POL00364056
POL00364056
\’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.
1G
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.
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! 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:
POL00364056
POL00364056
34. SSC is hugely reluctant to change financial data — not ther job and they recognised the seriousness of doing so.
Tony
From: Andrew Parsons {~
Sent: Friday, February 22, 2019
To: Anthony de Garr Robinson
Cc: Simon Henderson,
Gribben; Katie Simmonds
Subject: Data deletion
}); Owain Draper; Jonathan
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
Partner
Womble Bond Dickinson (UK) LLP
Stay informed: sign up to our e-alerts
womblebonddickinson.com
DICKINSON min)
From: Andrew Parsons
Sent: 22 February 2019 17:55 ;
To: 'Matthew.Lenton@- ; Dave. Ibbettt
Cc: Jonathan Gribben; Christopher. Jay¢
Subject: URGENT - support needed over the weekend
pete.newsomef
+ Rodric Williams
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.
POL00364056
POL00364056
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
Hi
Due to the circumstances at the branch this session can be removed but the branch must
e 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
lattached which shows what the transaction was for, date etc will not be actioned by FSC
luntil this form is received as this allows us to investigate the incident.
(Thanks
Gill
Gillian Hoyland
IFSC 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
here branch accounting code = 111832
land fad_hash = 124
land node _id = 2
jand 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
Ithe 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.
bate: 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
Ibe able to rollover. We will supply formal closure later.
POL00364056
POL00364056
{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
‘ eServiceDesI
Cc: MAC <MACt
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]
HDIoutSTU : From: Post Office Service Desk
[mailto:PostOfficeServiceDesk{
Sent: 26 October 2017 12:36
To:
Subject: RE: Al1/0046002 — I/186625
Hi Jackie,
Apologies for this late response.
We already sent to POL the session correction form and just
awaiting for their approval.
We’1l 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,
POL00364056
POL00364056
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¢ _. I [mailto:Matthew.Lenton@ (
Sent: ebruary 2019 11:05
To: Jonathan Gribben; Dave.Ibbett@
Cc: pete.newsome¢ “4; Andrew Parsons; Katie Simmonds; Michael Wharton
Jonny,
1. We havea 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
PPS, Digital Technology Services
Fujitsu
RG12 8SN
Email: matthew.lentor
POL00364056
POL00364056
Web: https://www. fujitsu.com/global/
From: Jonathan Gribben}_
Sent: 21 February 2019 11
To: Lenton, Matthew <f
Cc: Newsome, Pete Andrew Parsons
Simmonds >; Michael Whartoni
Subject: RE: Action requests [WBDUK-AC.FID123822914]
"73 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
Stay informed: sign up to our e-alerts
womblebonddickinson.com
WOMBLE
BOND
DICKINSON y ©
From: Jonathan Gribben
Sent: 20 February 2019 11:36
To: Matthew.Lento!
Cc: 'pete.newsome( Andrew Parsons (andrew.parsons@
Simmonds; Emma Campbell-Danesh (emma.campbell-danesh¢
Subject: Action requests [WBDUK-AC.FID123822914]
(GRO. }; Lucy Bremner; Katie
my Prime (amy.prime¢
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.
POL00364056
POL00364056
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
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
POL00364056
POL00364056
Please consider the environment! Do you need to print this email?
and any attachments is confidentia
access this e-mail and rents, If you are not matthew
Unauthorised use, dissemination, distribution, publication or co
personal data is in our Privacy Policy on our website.
ail will have been checked by us with virus detection software before transmission, Womble Bond Dickinson (UK) LLP accepts no liability for any
be caused by software viruses and you should carry out your own virus checks before opening any attachment.
Any files attached to thi
loss or damage which ma
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 Mor
or consultant who is of equivalent standing. Our VAT registration m
ondon 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
nber 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 enti
Womble Bond Dickinson entity. Womble Bond Dickinson (International) Limited does not practice law. Please see
wlegal notices for further details.
and is not responsible for the acts or omissions of, nor
can bind or obligate, anoth:
www. womblebonddiekinsoy
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: symi
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
POL00364056
POL00364056