This is the unperfected transcript of proceedings on Day 20 of the Horizon High Court trial, part of the Bates and others v Post Office group litigation.
Today was the third day of Dr Robert Worden's cross-examination. Dr Worden is the independent IT expert contracted by the Post Office to look into the Horizon issues.
Transcript follows:
Friday, 14 June 2019
(10.30 am)
DR ROBERT PEEL WORDEN (continued)
Cross-examination by MR GREEN (continued)
MR JUSTICE FRASER: Just before we start, in relation to
timings, have you discussed when you are going to stop
so Mr de Garr Robinson can --
MR GREEN: My Lord, what I have said to my learned friend is
I will do pro rata exactly what I gave my learned
friend, so stop by 4 o'clock, being 10 minutes per day.
MR DE GARR ROBINSON: My Lord, I've indicated that that may
not be enough time, and my learned friend has very
kindly said he will try and cut it back as much as he
can.
MR JUSTICE FRASER: All right, that's excellent.
And then just a reference point, this is just for
the two of you to look at lunchtime, not now. On Day 18
at page 98 in one of the answers about ground rules, the
transcript says May 2015. I'm not sure that date can be
right, 2015.
MR DE GARR ROBINSON: No, it doesn't sound right.
MR JUSTICE FRASER: So if you just check it. It might have
been corrected in the finalised version.
MR GREEN: I understand it is 2018 but we will check.
MR JUSTICE FRASER: So just check it, that's all.
All right, Mr Green.
MR GREEN: I'm most grateful.
Dr Worden, yesterday we had arrived at a point where
you had seen the presentation, it has the £25,000 and
£2,500 outstanding?
A. The presentation about?
Q. The Fujitsu presentation about the Dalmellington bug.
A. Yes.
Q. Now I would like to invite you to look, please, at your
second expert's report.
A. Sorry, where is it? Here, yes.
Q. I would like you to look at page 41, please.
A. Page 41?
Q. Sorry, {D3/6/41}.
A. Okay, I'm getting there. Yes.
Q. Now, this is where you deal with the Dalmellington bug
in your second expert's report?
A. Yes, right. Okay.
Q. And it is in section 6.2.2, yes?
A. Yes.
Q. And it goes -- it runs through to page {D3/6/42} and
then over the page to {D3/6/43}, if you want to look.
A. Yes.
Q. So it is in these paragraphs 154 to 163. Can I just
take you through them because the first two paragraphs
that we see on page 41, which are paragraphs 154 and
155, those two paragraphs are directly referring to what
you have described as "the Dalmellington incident".
{D3/6/41}
A. Yes.
Q. And you would fairly accept that the phrase "the
Dalmellington incident" suggests one event?
A. Well, one event, but I think there is a type of event
that it refers to.
Q. Let's have a look, if we may.
Paragraphs 154 and 155, just to map out how this
section works, are actually talking about Dalmellington
itself.
A. The actual Dalmellington, yes.
Q. Yes, the actual Dalmellington. Then at 156 you move
from the specific reaction to that to the more general
position that you infer about Post Office and Fujitsu --
A. Yes, I mean -- sorry, in a sense a KEL implies a general
position in some way.
Q. I understand. But you are moving certainly at the
highest level from the specific to a more general
exposition of your views in the light of this because we
see at 156 you say:
"Even so, Post Office and Fujitsu were concerned
that Horizon should not induce the user to make such an
error, even in rare circumstances."
A. Yes.
Q. Then you say at 157:
"To make this point more clearly: in my opinion, for
many KELs ..."
So that is not limited to Dalmellington at all?
A. No, that's a rather general statement.
Q. So it is a general statement:
" ... it would have been obvious to Fujitsu that any
error in branch accounts would have been corrected in
due course, by the normal processes ..."
You see?
A. Yes.
Q. And the general statements continue into 158 over the
page on {D3/6/42}.
A. I think that is right. Can I read it?
Q. But you do then pick up Dalmellington at the bottom of
158 again.
A. "Dalmellington was such a case."
Q. Exactly. So you return from the general to the specific
at the bottom of 158, and you bring us back to
Mr Godeseth's second witness statement at paragraphs 55
onwards --
A. Yes.
Q. -- referring to Dalmellington, yes?
A. Yes.
Q. If we can just bring up Mr Godeseth's second witness
statement at 55 onwards. We are going to find that, if
we may at {E2/7/14}.
A. So the paragraph I quote is which?
Q. You say Mr Godeseth, his second witness statement at
paragraphs 55 onwards, in his Dalmellington section.
A. His Dalmellington section, yes.
Q. Yes?
A. Yes.
Q. And we can see at {E2/7/14}, his Dalmellington section
begins on page 14 of his witness statement at
paragraph 55.
A. Yes.
Q. Which is the one you have referenced.
A. Yes.
Q. And if we go over the page, please {E2/7/15}, we see on
page 15 the reference in paragraph 61 to "total 112
instances"?
A. Yes.
Q. Yes? And we also have Fujitsu's analysis --
A. Yes.
Q. -- expressly exhibited there.
A. Yes.
Q. So in your second report you are expressly referring to
the passage that you didn't refer to previously?
A. Well, I'm referring to that one, yes.
Q. Let's go back to your report, if we may. {D3/6/42}
A. Yes.
Q. We have established that at the bottom of 158 you come
back to Dalmellington and refer to that bit of
Mr Godeseth's statement. Then you say there at
paragraph 159:
"Further, but weaker, support from this view ..."
This is your theory?
A. Yes.
Q. But you refer specifically to a note by Anne Chambers?
A. Yes.
Q. And you only recite there -- well, you recite there what
she says?
A. Yes.
Q. And refer to the fact that she had looked for other
affected branches?
A. Yes.
Q. And you say:
"She said: 'I can only check back two months; I've
found 4 other instances ... and all but the last removed
the discrepancy by completing a rem out for the excess,
which corrected the system cash holding.'"
A. Yes.
Q. And then you would accept, I think, that notwithstanding
having gone to -- made express reference to that PEAK in
which four other instances are mentioned, at no point
between there and 163 do you mention the fact that 118
branches were affected -- sorry, 88 branches were
affected by 112 events?
A. Between which paragraphs?
Q. The ones we are on, 159/160, all the way down to 163.
A. Let me just check:
"... 'we are going to have to find ... and correct
their accounts'."
Yes. Okay, yes.
Q. Now, there are two possible explanations for you not
making reference to the fact that in this case the bug
concerned affected 88 branches rather than 1 or 4 or 5.
There are two possible explanations for not mentioning
the 112 instances or the 88 branches. One is that you
didn't know, and the other is that you did know and you
chose not to mention it. Which of those two is the
explanation?
A. That is a good question. I think I knew, but my
prevailing view is that remming errors are detected very
directly by an imbalance between a rem in and a rem out
and that therefore remming TCs do not involve a large
element of human judgment as to whose fault it was that
did this, or whether it was the bank etc. So remming
TCs in my opinion are rather fast and direct things and
I was not concerned -- for instance, by the time we have
the 118 it was many years and I don't know exactly --
for instance, I cannot recall the exact timing between
Anne Chambers PEAK and the whole sequence of several
years, but my understanding is that over the whole
sequence of several years these rems, these TCs
consequent on remming errors, were made rather rapidly.
And that is my whole background understanding of
Dalmellington and other incidents.
Now, if I fail to mention Dalmellington and other
incidents on this case, perhaps I should have done, but
I think it is clear from my reports that all remming
errors I believe get corrected by TCs --
Q. Pausing there, Dr Worden. It would have been helpful to
the court in identifying the errors which had
a potential to have an impact on branch accounts.
A. In my mind they didn't have the potential -- didn't
have -- had a small potential of having a lasting effect
on branch accounts. Certainly they had a transient
effect, there is no question of that.
Q. In terms of simply identifying whether they had the
potential to have an effect without your gloss of
lasting on it, it would be important, wouldn't it, for
the court to have an understanding of how many
branches -- what's the magnitude, order of magnitude of
the number of branches affected by that bug?
A. Yes, indeed, I could have for instance mentioned that
112 branches were affected by this bug versus 20,000
branches a year which are affected by manual remming
errors, but my opinion is that they are all corrected
quite rapidly. I'm sorry if I did not mention it there,
but the prevailing background of my opinion on the
remming issues is that there are large numbers of
remming errors during the year and they get corrected by
a TC which does not involve a huge element of human
judgment to see a discrepancy between two figures and
say this has to be corrected.
Q. But it is a striking figure, 88 branches, isn't it?
A. Well, compared with 20,000 it is not.
Q. And you are prepared to mention anything but you are not
prepared to mention that?
A. No, I'm saying if I failed to mention it here it is
an oversight and I apologise to the court.
MR JUSTICE FRASER: When you just said not compared to
20,000, where do you get your 20,000?
A. I get the figure of 20,000 from the table of TCs which
says -- quoted in my first report, which says there are
100,000 per year approximately and, of those,
approximately 20,000 are remming errors.
MR GREEN: Now, Dr Worden, can we now do an exercise of
going through the bugs table in joint 2?
A. Yes.
Q. And that begins at --
A. Shall I get joint 2 up?
Q. -- {D1/2/3}.
A. I have got joint 2. Okay.
Q. And if we look at -- if we go forward, please, we have
on page -- there are the first two, receipts and
payments and Callendar Square?
A. Yes.
Q. Then we go over the page to the suspense account bug.
A. Yes.
Q. Now, you accept that that's one of your branches that
had the potential to have a lasting impact?
A. Yes.
Q. We dealt with Dalmellington just now, that's number 4.
A. Yes.
Q. If we go to number 5, please {D1/2/5}. That is remming
in?
A. Yes.
Q. And your view in the "Worden Opinion" column is:
"As for the Dalmellington bug, above – PO had a
robust process for detecting and correcting remming
errors, whatever their origin.
"So, there were no lasting effects on branch
accounts."
A. Yes, we have just been over that.
Q. And that is the reason for not including them in lasting
errors --
A. Yes, that's why they are not in my 12, if you like.
Q. Now, I'm going to have to take all these not at a huge
level of detail, as you will understand.
A. Yes, sure.
Q. But can I ask you this question: there was a KEL in
relation to this bug, wasn't there? Can you remember?
A. Well, we have got acha4221Q, yes.
Q. Yes. Did you look at the PEAK that was mentioned in
that KEL?
A. I cannot recollect, honestly. I probably did because
when a KEL -- I mean, when I look at KELs, if it seems
to me that the KEL is clear as to what happened, the KEL
is a kind of distillation whereas the PEAK is
a long-running diary, if you like. So if the KEL is
clear I don't go on to the PEAK, but if the KEL leaves
me some room for doubt then I will go on and look at the
PEAK.
Q. Could we look at this on your own response at
{D3/2/170}, please, in your expert's report?
A. D3. That is a supplemental report, is it?
Q. This is actually in the appendix to your first report.
A. Right, okay.
Q. It is at {D3/2/170}.
A. Both my reports are D3. Sorry. Anyway, let's go to it.
Yes.
Q. So we can see your view in relation to this KEL?
A. And this is part of the table where I analyse the 62
KELs that Mr Coyne had cited, is that right?
Q. Yes, there are two tables, aren't there? There is what
you call the pound table --
A. Yes.
Q. -- and the Coyne table?
A. That is right.
Q. Yes? And we are here looking at -- the bottom box is
acha4221Q.
A. That is the one.
Q. Which is the KEL at {F/794/1}. And you have referred to
it there, you have summarised your view of it --
A. Yes --
Q. "The clerk went into --"
A. Can I just clarify, I believe the next to left-hand
column is kind of quotations out of the KEL and the
PEAK, or a PEAK, and the right-hand column is my
analysis.
Q. I'm grateful. So you quoted from the KEL. We can
actually see that made good, just to be fair to you,
Dr Worden, at page {D3/2/164} if you want briefly to --
so if we go up to page 164.
A. Go to my first report at 164? Or in the appendix or ...
Q. No, page 164 of this {D3/2/164}.
A. Sorry. D3/2 ... get used to this convention.
Q. This is in the same table, Dr Worden.
MR JUSTICE FRASER: Why are we going to 164?
MR GREEN: Just in fairness to Dr Worden, to remind him of
the --
A. Page number again, sorry?
Q. Let's stay on this page. Dr Worden, your heading for
that middle column, the large column, is "Quotes from
KEL and PEAKs"?
A. Yes.
Q. So what you have done is selected what you regarded as
relevant quotes from the KELs and PEAKs to include
there?
A. That is right.
Q. And we see what you have included. You say:
"The clerk went into the Delivery menu and scanned
two pouches (one of currency and one of coins)."
A. Sorry, are we back on the --
Q. Yes, we are back here on this page, which is {D3/2/170}.
A. On screen I don't have it.
MR JUSTICE FRASER: Okay, I'm just going to intervene to try
and streamline this. We should have 170 on the common
screen now.
A. 170. We do, yes.
MR JUSTICE FRASER: And you are being asked about the
quotation in the main substantive column.
A. Okay.
MR JUSTICE FRASER: The heading to that column being "Quotes
from PEAKs and KELs".
A. Yes. So we saw the heading and now we are looking at
the ...
MR JUSTICE FRASER: Yes, Mr Green.
MR GREEN: I'm most grateful. On the left-hand side we see
acha4221Q in the second lower box.
A. Yes.
Q. And in the main substantive column there is your quote
from the KELs and PEAKs.
A. Yes.
Q. It says:
"The clerk went into the Delivery menu and scanned
two pouches (one of currency and one of coins). The
second pouch was recorded twice on the system, resulting
in a loss of £80."
A. Yes.
Q. Did you look at the PEAK that was referred to in that
KEL?
A. I'm not sure if I did but I would suspect I didn't,
because my views on remming in and remming out errors
have been clear for some time and therefore I would have
probably found what I wanted in the KEL.
Q. I understand. Let's look, if we may, at that PEAK which
is {F/588/1}. A hard copy will be handed up by
Ms Donnelly.
A. Thank you.
Q. The PEAK number is PC0195380.
A. Can I just start at the top:
"Rem in transaction appears twice right."
Yes, right.
Q. Can you turn to page {F/588/2}, please.
A. Yes.
Q. And you have got the reference to the loss of £80 in the
penultimate box at the bottom.
A. The Anne Chambers grey box?
Q. Yes.
MR JUSTICE FRASER: 2nd March 2010 at 51.21.
A. Got that.
MR GREEN: Exactly, 15.21.46. Second paragraph:
"This has caused them a loss of £80. They cannot
reverse this transaction."
Do you see that?
A. Yes.
Q. Did you know why they couldn't reverse the transaction?
A. I don't know the detail of that, but ...
Q. I understand.
A. Obviously this is one of two ways it can be corrected,
by reversal or a TC.
Q. Let's go over the page, if we may, to {F/588/3}. When
we look there you can see halfway down the page at
3 March 2010, 10.56.59, Anne Chambers.
A. Yes.
Q. Do you see halfway across the first line:
"This problem can cause losses which are hard for
the branch to identify, so it does need to be fixed."
Do you see that?
A. Yes.
Q. And you hadn't seen this text because you don't think
you looked at the PEAK, that is right?
A. I do not think this text yet would change my opinion.
Q. But on my question --
A. In other words, I saw enough from the KEL, and this PEAK
has not yet changed my --
Q. I think the court has got your answer on the reason.
But it's factually correct, you hadn't seen this text?
A. I don't recall these words.
Q. Look at the box almost at the bottom, 3 March 2010,
18.15.47, Anne Chambers.
A. Sorry, 3 March 18.15. Yes:
"Just seen another example ..."
Q. "... of this in live ... this time they scanned the bar
codes, then pressed Previous instead of Enter after the
last barcode, and then went forward again. They now
have a loss of £25,000."
A. Yes.
Q. You would accept that that reference to £25,000 conveys
a very different order of magnitude of the potential
loss here, doesn't it?
A. I would. Obviously a remming error can be remming
an error. If you double up a rem then you double up the
amount of cash and that can be big or small depending on
lots of factors.
Q. And as you didn't look at this I'm not going to take you
to further parts of that.
Can we move forward now, please, to the other PEAK
referenced in the same KEL.
A. Yes.
Q. It is {F/695.1/1}. Did you look at this PEAK?
A. I don't think I did because, as I say, I feel
I understand remming TCs and I feel I understand --
generally the KELs give me --
Q. You can just say "for the same reason" each time. You
don't need to do it each time.
A. Yes, "for the same reason" is fine. Yes. I do not
think I have looked at the PEAK but --
Q. {F/695.1/3}, if we go there.
A. Page 3. Yes.
Q. If you look --
A. Sorry, could I just check the header of this PEAK and
get the problem statement. So it is remmed into
counters again. Okay. PM scanned it.
Right, thank you. Sorry.
Q. If you look, you see there is a large box in the bottom
half of the page --
A. Yes.
Q. -- which is 17th August 2010 at 15.48.59.
A. Yes.
Q. If you go halfway down that box --
A. This explains why rem reverse -- you can't reverse the
transaction. It says "rem reversal isn't allowed".
Q. Indeed. But look immediately under that.
A. "This is NOT another example ..."
Q. "This is NOT another example of the duplicate rem
problem that we have seen in the past, where use of the
Prev key accepted the same pouch twice. In this case
the pouch was processed on both counters ..."
Do you see that?
A. Yes. So one case was twice on one counter and the other
case was -- sorry, is that right?
Q. Yes.
A. The other case was two counters. Yes.
Q. If we go over the page {F/695.1/4}.
A. Yes.
Q. And we look at 18th August 2010, two-thirds of the way
down the page, 18.35.20, Anne Chambers.
A. Sorry, 18.35 and ...
Q. 20 seconds. It is a yellow box for you. Do you see
that?
A. This is about the BAL OSR logs?
Q. Yes. Immediately under that you will see the sentence
that says:
"Gareth Jenkins thinks that it should not be
possible to complete the rem in on both counters.
Please investigate."
A. Yes.
Q. Now, if he was right that it shouldn't be possible to
complete a rem in for the same pouch on two different
counters -- because they have unique barcode IDs, don't
they?
A. Yes.
Q. If he was right that it shouldn't be possible to do
that, that aspect was a bug in the system, wasn't it?
A. Yes.
Q. And if he was wrong in his understanding, it was
a defect in the system in allowing it to do it?
A. I see. Something shouldn't have happened.
Q. Yes.
A. Absolutely.
Q. But my question is a fair one, isn't it?
A. It is a fair one, yes --
Q. Even if you wouldn't say it in the same words.
A. Yes.
Q. And the consequence of that is that you get an error in
branch accounts as we have seen?
A. You get a transient error.
Q. Let's move on to the next one in the table which is 6.1.
A. Sorry, I have too much paper here.
Q. I will trace it through for you, Dr Worden, in the same
way as I did for number 5.
A. This is remming out, yes?
Q. We are going to go to {D1/2/5}.
A. Right. Can we just get it on the screen?
Q. Yes. This is just where it is in the --
A. Right, okay, I'm there --
Q. -- in the table of bugs. So we have done 5?
A. Yes, and we're doing 6(i) --
Q. We have done the first four above, and we have done 5,
now we are moving on to 6(i) which is at the bottom of
the page.
Your answer on 6(i) is:
"As for the Dalmellington bug, above – PO had a
robust process for detecting and correcting remming
errors, whatever their origin."
A. Yes.
Q. That is a direct paste from above, isn't it? It is the
same reasoning as number 5?
A. I don't -- I probably typed those words again, but ...
Q. Okay. But it is the same words and the same reason?
A. Very similar words because a very similar case, really.
Q. The words are identical. Anyway, it doesn't really
matter, they are the same.
A. No.
Q. And then underneath:
"So, there were no lasting affects on branch
accounts."
If we go over the page {D1/2/6}, that bit is not
there for that but we can see it pops back in on 6(ii)
underneath?
A. Oh yes, I missed that out on 6(i).
Q. That's just a mistake on 6(i)?
A. I think so, yes.
Q. You would have meant presumably to include the same --
A. I think I would, yes.
Q. -- test for all three. That's why I was asking you
about the pasting.
A. It wasn't -- yes, I do not think I kind of do that,
really.
Q. When we look at 6(i), did you look at the KEL for this
one, which is acha508S?
A. I believe I did, yes.
Q. Do you remember?
A. I believe I did. I would have done.
Q. Do you remember that it suggested that calls about
inconsistencies in stock rem outs should be redirected
to NBSC?
A. I don't recall that at this moment, no, but again I do
start with a strong prior expectation that remming
errors get fixed.
Q. I understand. And that's the basis on which you
approached your report?
A. That is right.
Q. And we all understand that.
Paragraph 96 -- sorry, there is a PEAK referred to
in that KEL, yes? Did you look at the PEAK, can you
remember --
A. No, I wouldn't have. I suspect not.
Q. Let's have a quick look at it, if we may. It is at
{F/384/1}. You have got a hard copy of that.
A. Right.
Q. Just in the interests of time, Dr Worden, let me take
you to page {F/384/3} of that, if I may?
A. Can I just read -- get the problem statement.
(Reads to self)
So I don't see -- cash problem reversing, sorry,
yes, let's get to that.
Q. If I can take you to page 3.
A. Yes.
Q. And we come down, it will be the third yellow box for
you.
A. Right.
Q. It is 15 February 2007 at 14.04.08.
A. Yes.
Q. It says there:
"Have talked to PM about the problem and
consequences, which she understands. POL will be
informed of the transaction correction required to
remove the excess cash in pouches (along with the 50 or
so similar branches)."
Do you see that?
A. Yes.
Q. And you hadn't read this, you think?
A. No. But, again, it doesn't -- reading it now doesn't
change my opinion.
Q. Your opinion we find in relation to that one is in the
table at {D3/2/165}.
A. Can we go there?
Q. It is the top box which is referring to acha508S.
A. Yes.
Q. The PEAK is referred to there, the PEAK we have just
seen at {F/384/1}.
A. Yes.
Q. And the quotes you have chosen to take from the KELs and
PEAKs doesn't give any hint that there were 50 other
affected branches, does it?
A. That is correct.
Q. Let's move on now, if we may, to the next one in the
bugs table in the joint report, which is 6(ii), which is
going back to {D1/2/6}.
Dr Worden, I'm only going to do the first ten
because time won't allow me to do 27 of these.
A. Right, okay.
Q. So we are looking at 6(ii).
A. Yes. So again my standard wording comes in.
Q. That's it. You will see there:
"'Remming out' (ii) Bug (not acknowledged)."
This isn't one that you had in either of your tables
in your appendix originally.
A. No.
Q. Did you have a look at the KEL in that case?
A. I believe I did, yes.
Q. Can we look at it now, please. This is at {F/276/1}.
A. Rem out ... Yes.
Q. This is the GMaxwell3853P KEL. If we look at the bottom
where it says "Solution - Atos".
A. Bug in the code, yes, right.
Q. "Development have identified a possible bug in the
counter code. However, due to the frequency of the
problem & the risks involved in making the necessary
changes it has been decided that a code change will not
be made."
A. Yes.
Q. You hadn't noticed that, had you?
A. I believe I had, but again the point about permanent
effects, lasting effects, on branch accounts is not
altered by that.
Q. And the point about this is there was a lasting bug?
A. There may have been a lasting bug, but they took
a decision based on its frequency and the difficulty of
making the change, perhaps the risk of making the
change, that it was not worth addressing. That actually
the remming process would pick it up and its
frequency -- they took a decision, I don't know what the
details were of their trade off. They took a decision
that fixing the code was not worthwhile.
Q. I'm just asking you: it is a lasting bug?
A. It is a lasting bug, yes.
Q. Let's go to number 7 now, if we may, please.
A. Sorry, it might have been fixed in the next release, for
instance, one doesn't have the history, but there we go.
Q. That is speculation in favour of the Post Office.
A. Absolutely. I'm sorry, I shouldn't have done that.
MR DE GARR ROBINSON: My Lord, I just wonder whether there
is a potential confusion in the question my learned
friend has asked. It may be my confusion.
Where my learned friend said "lasting bug", bearing
in mind the emphasis I placed during my submissions and
indeed in cross-examination on bugs with lasting effect,
it might be helpful if my learned friend could
distinguish between a bug that lasts and a bug which has
lasting effect. I believe he is putting the first
point, not the second.
MR GREEN: I think you knew what I meant, Dr Worden, didn't
you?
A. I did. And I'll clarify what I mean: it's a bug that
was not fixed, we cannot see was fixed, but it was a bug
without lasting effects in my opinion.
Q. For all the reasons we have heard?
A. Yes.
Q. Let's go to number 7. I'm grateful to my learned
friend. {D3/2/173} is your ...
MR JUSTICE FRASER: Number 7, "Local Suspense Issues".
Q. Local suspense issues, which are not the same as the
local suspense bug. This was a bug that occurred in
April 2010.
A. Mm.
Q. And if we look at the joint table for a moment at
{D1/2/6}, and we look under your opinion, it says:
"The KEL ... implies that PO and Fujitsu were able
to identify all occurrences of the problem, without
being notified by any Subpostmaster I would therefore
expect them to have corrected any impact on branch
accounts as part of normal error correction processes."
A. Yes.
Q. Then you say:
"I would not expect evidence of all corrections to
accounts to have survived to the present day. Peaks and
KELs are not used to record corrections of financial
impact."
A. Yes.
Q. Fujitsu, in fairness, analysed the KEL, you say here,
and said:
"... 'Temporary financial impact which would have
been cancelled out in the following period by
a corresponding discrepancy.'"
Do you see that?
A. Yes.
Q. Now, did you look at the KEL?
A. Well, I infer from that Fujitsu did it, but I had done
it previously.
Q. Let's go, please, to {F/637/1} which is the KEL
acha5259Q.
A. Right. Sorry, can I remind myself of the ...
"... local suspense cleared ... balance report ...
cash ..."
Q. Do you see if we look at the problem --
A. Yes.
Q. -- the summary was that the PM was forced to clear local
suspense several times resulting in the cash figure on
the balance report changing and possibly a discrepancy
in the new trading period.
A. Yes.
Q. So that certainly had the potential to cause an impact
on branch accounts at the time, subject to later
correction?
A. Yes.
Q. And probably did, yes?
A. I think it did, yes.
Q. If we look at the problem, please, at the bottom of the
page?
A. Counter logs.
Q. "Looking at the counter logs, after they pressed the
Stock Balancing/Report button the first time, there was
a ClassCastException ..."
A. Yes. I could explain, that is a Java thing that
shouldn't happen.
Q. So a Java error that shouldn't happen.
"... system error 0437 (trying to process a corrupt
ReportingService response), forcing them to start again.
"The reason for this exception is understood ..."
And it refers to --
MR JUSTICE FRASER: You have gone over to the next page.
MR GREEN: Sorry, I do apologise, yes.
MR JUSTICE FRASER: You don't have to apologise, we just
have to turn the page so we can see what you are
reading. {F/637/2}
"The reason for the exception is understood ..."
And there is a reference to a PEAK and a KEL.
"This problem particularly affected branches in the
first 2-3 weeks of April, and could start occurring
again."
Did you notice that?
A. I believe I did, and obviously that doesn't state the
number of branches affected.
Q. Do you remember whether there was an indication of the
number of branches?
A. No, I have no idea of the number of branches.
Q. Okay.
A. But --
Q. Let's look just below that, under "Solution - Atos",
second paragraph under that heading --
A. Oh, it says lower that 33 branches had this problem.
Q. Yes.
A. So I probably was aware of that at the time.
Q. Yes:
"33 branches which had this problem between 7th and
15th April have been identified."
A. Yes.
Q. So pausing there. We know that the problem particularly
affected branches in the first two to three weeks of
April --
A. And --
Q. -- not exclusively?
A. Yes.
Q. And could start occurring again, and for an eight day
period which they tested for, they had actually already
identified 33 branches?
A. Yes, so we are looking at a number bigger than that,
basically.
Q. We are. But you had not spotted that magnitude of
branches --
A. Well, my analysis was not about the number of branches
affected, it was about the lasting effect. I mean --
Q. And --
A. -- I think -- sorry, to state the obvious, there are
bugs in Horizon that have no affect on branch accounts
and they are very wide in scope.
Q. I think we have got your answer on the corrections so
let's just focus, if we may, just on this.
A. Sorry.
Q. Can you remember if you looked at the PEAK that's
referred to for that?
A. I doubt I would have again because ...
Q. So on the first page of that KEL you will see PEAK
PC0198077, do you see that?
A. Coming back again?
Q. Go back a page very kindly {F/637/1}. That's it.
You can see the PEAK --
A. Yes, there we go.
Q. -- 0198077. If we look at that PEAK, please, it is at
{F/630/1}. Ms Donnelly will give you a copy.
A. Thank you.
Q. Now, once you have got your eye in on page 1 ...
A. (Reads to self)
Yes. Just to say, "discrepancy" is not highly
specific. Carry on.
Q. Will you forgive me, Dr Worden, if we just try and
focus, because I'm quite tight on time to get through so
many --
A. I'm sorry, I just like to get the problem statement.
Q. And I want to be fair to you to do that.
On {F/630/2}, which is the second page of this PEAK,
there is a large box --
A. Right.
Q. -- occupying most of the top half of the page. If you
come just short of halfway down that, you can see --
maybe a third of the way down, do you see 2010-04-15 at
14.11.53, do you see that?
A. Yes.
Q. Martin White. It says:
"LOG: On logging on 15/04/2010 ..."
Do you see that?
A. Yes.
Q. "... produced a balance snapshot that showed nil
discrepancy and again the inflated cash figure."
Yes?
A. Yes.
Q. Now, it then says:
"The spmr had logged a couple of incidents with
NBSC, and was referred to the HSD ..."
With a reference number.
A. Yes.
Q. "The spmr was bounced back to NBSC as a balancing error
rather than a system problem."
A. Yes.
Q. So we know this was in fact a bug, and what happened
when this SPM was put through to the Horizon support
desk is they were bounced back and it was suggested that
it was a balancing error, yes?
A. Yes.
Q. And you would accept that from what we now know, that
judgment was incorrect?
A. It appears to be the case, certainly.
Q. And that shows us, doesn't it, at least the -- that's at
least consistent, in your meaning of the word
consistent, with Angela Van Den Bogard accepting that
there was sometimes user error bias, at least on
Post Office's behalf?
A. It is not to my mind a question of bias. What this
tells me is that HSD on this occasion made a mistake.
Q. And they made a mistake against the subpostmaster?
A. Yes, absolutely.
Q. And on your definition of consistent, that is consistent
with UEB?
A. Sorry, that is right.
Q. Now, if we go down to the bottom of this PEAK, this page
of the PEAK, it is 21 April 2010 at 10.18.57.
A. Yes.
Q. Bottom box, it is a yellow one on the page:
"NBSC has just advised that another office had
a similar problem, although the discrepancy has now been
sorted out. Details of the site and problem are below
for information."
A. Yes.
Q. So that is an example of your idea of the
countermeasures working effectively --
A. Well --
Q. -- on the face of it?
A. -- if they say it was sorted out --
Q. Exactly.
A. -- it looks as if it was sorted out.
Q. That is consistent with your view that there are lots of
occasions when it is sorted out?
A. Yes.
Q. Let's read on:
"Office: Hucclecote ..."
And look at the bottom paragraph:
"Office was dealing with the discrepancy in the
office following the TP rollover, and selected settle
centrally. The office reports that nothing happened and
they ended up doing this a further 2 times before they
could proceed. This has resulted in the office settling
the loss centrally 3 times. This showed as such as the
total on the final balance. The Trading Statement and
suspense account seemed to be correct though. On Monday
19th April the office reported they showed a cash gain
of double the original loss and after further
investigation a suspense account was produced that
showed 2 clear loss from local suspense entries."
{F/630/3}:
"We have cleared this by clearing gain from logical
suspense, which should clear the gain in the office."
A. Yes.
Q. So that is the resolution?
A. That appears to be, and it is a bit complicated, isn't
it?
Q. But at least it appears to be the resolution?
A. Yes.
Q. Let's look at the immediate entry below that on page 3.
A. "... solution we thought ... not resolved the problem
..."
So they thought they had fixed it, they hadn't.
Q. Let's take it in stages. Top of page 3, first new box
on page 3. 22 April 2010, 11.26.12.
A. Yes.
Q. "The solution we thought we had for Hucclecote SPSO, FAD
186523, has not resolved the problem, but has actually
doubled the discrepancy."
A. Yes. So it appears they again made a mistake, and this
perhaps illustrates that PEAKs are this kind of train of
investigation and there are false starts, whereas the
KEL usually distills what comes out of the end of it.
Q. You didn't find a reference to the fix going wrong and
doubling the SPM's discrepancy in the KEL, did you?
A. No, but frequently these things happen in PEAKs. They
do (inaudible) investigations, it is a false -- it's
a -- the trail leads nowhere, they start somewhere else
and so on. You have to read through the whole PEAK to
get the whole picture, whereas a KEL distills out what
was learnt eventually. And so that is why I have --
when the KEL tells me what happened, I generally don't
pick the way through all the PEAKs.
Q. Let's look at page {F/630/8}, if we may. Just two last
references on this PEAK and then we will move on to the
next bug. We come down to the second yellow box which
is 16th June 2010 at 9.37.08.
A. Sorry, I haven't fixed the time. Could you repeat it?
Q. It is the second yellow box.
A. Yes:
"... general issue ... error handling ..."
Yes.
Q. Second part of that box:
"There is a wider, general issue in relation to
error handling that is still not addressed, hence which
can and will still cause roll-over and subsequent
discrepancies."
A. Yes.
Q. You didn't see this either because you didn't look at
the PEAK?
A. No, I didn't look at the PEAK.
Q. "This wider issue is outstanding, and can also
contribute to screen freezes and double settlements and
hence further discrepancies."
A. Yes.
Q. "The wider issue can occur when any unhandled exception
occurs in the early stages of the roll-over process ...
this was just one example."
A. Yes. Sorry, are we still on the PEAK --
Q. Yes, still on the same PEAK.
A. -- where the KEL said it was a Java exception?
Q. Yes.
"The wider issue is addressed by the fix for this
PEAK."
That is in June.
A. Yes.
Q. Okay. Let's just go now to, finally, page {F/630/10} of
the same PEAK, it is the last reference on this one. If
you look, it is 17th September 2010, 16.31.53.
A. Yes. This quote does sound familiar to me, actually.
Q. "This problem has happened intermittently since April
but never at the levels seen then. Being investigated on
PC0204396. The good news is that no instances have been
seen since this fix was applied. Closing call."
A. Yes.
Q. So we have a period there that we can identify over
which it was happening intermittently as well?
A. Yes.
Q. And you had no feeling for any of that because you
hadn't read the PEAK?
A. My feeling was I'd read the KEL and I think I'd formed
the opinion it was a transient effect, and Fujitsu had
done that, so I didn't drill down.
Q. For the reasons you have given before?
A. Yes.
Q. Let's move if we may now to number 8 and we find that --
just to do it the same way again, if we go back to the
joint statement 2 table and we look at {D1/2/7}.
A. Row 8.
Q. It is row 8. The recovery issues are identified there.
A. Mm.
Q. Mr Coyne has made references to the text in certain
PEAKs.
A. Yes.
Q. And you have given your opinion there, you say they are
not indicative of errors in Horizon, they provide
guidance on how to correct discrepancies caused by human
errors or other errors.
A. Yes.
Q. You say:
"Because there were many such errors, there were
many calls to the help desk and many PEAKs and KELs."
Then it is basically your same theory, that:
Normally, correction of errors involved back office
reconciliation and issuing TCs."
And that's accurate.
A. It is a different theory really. Recoverable
transactions are a big subject and they are complicated
because the point at which a recoverable transaction can
go wrong is very variable through the sequence, and
therefore the number of recovery actions, the type of
recovery actions is complicated. Horizon was designed
so that with the assistance of the postmaster most of
these could be recovered, but there are things called
failed recoveries, which again were part of the design
of Horizon, and those were the failed recoveries but
particularly the ones where Fujitsu had to get involved.
But failed recoveries means the recovery process had
failed, that's the way Horizon was designed because
these things are so complicated you can't handle them
all automatically. So it is a big subject but there is
plenty of useful evidence about it.
Q. You say in your table at {D3/2/124}.
A. This is the 959T KEL, is it?
Q. Yes. You say:
"This is another complex KEL with strong overlap
with previous KEL."
A. Yes. This KEL is cited in a large number of PEAKs.
Q. And in fact when we go back to the table at {D1/2/7},
Mr Coyne has actually quoted from one of the PEAKs we
see there, the first one he quotes from. Do you see
"PC0198352"?
A. Yes.
Q. And he has quoted:
"This problem caused a loss at the branch for which
they should not be liable."
Pausing there. This did have the potential to cause
the type of discrepancy which you have given evidence
about being later corrected, didn't it?
A. The word "problem" doesn't imply a bug in Horizon.
Q. You didn't read these PEAKs yourself, did you?
A. I have read a fair sample of recovery PEAKs. Maybe not
these ones, but I have read a fair sample.
Q. If we go over the page {D1/2/8}, do you see Mr Coyne
points out there that this KEL is referred to by 2,473
PEAKs --
A. Yes, that's --
Q. -- from 2010 to 2018.
MR JUSTICE FRASER: Where are we looking?
MR GREEN: At the top of that page under the "Coyne Opinion
as to branch account impact", my Lord.
MR JUSTICE FRASER: Yes.
A. That is correct.
Q. Just pausing there, Dr Worden. If something is handled
by NBSC and corrected straightaway, it doesn't make it
necessarily up the line to SSC, does it?
A. No. I mean there are various levels of recoverable
transactions. There is a recoverable transaction that
the subpostmaster can follow the instructions and can
fix it himself, there is the ones where he needs help
from NBSC, there's ones where he needs help from further
down, and there are failed recoveries where PEAKs are
involved. All of those things happen.
Q. In the case of a failed recovery, it can be sorted by
NBSC in some way or by a transaction correction without
referring to SSC?
A. That's a good question. I think the failed recovery
port usually involves not just NBSC, it involves MSU,
and there is quite a complicated process of guiding the
transaction through various states until it gets to the
F99 state.
Q. Can I just invite you to look at what Mr Coyne said --
A. Yes.
Q. -- having actually tried to identify through the
available disclosure how many PEAKs were referenced and
set them out. He says it is referred to by 2,473 other
PEAKs from over that range:
" ... each of these may (but may not) indicate a
similar issue with the horizon recovery process and
potentially creating a discrepancy within branch
accounts."
If we accept his definition of discrepancy and not
yours, yes?
A. This is all about temporary discrepancies in branch
accounts.
Q. Park the temporary discrepancy point about which we have
heard a lot.
A. Yes.
Q. What he has said there is correct in the number of PEAKs
as far as you know?
A. It is correct, yes.
Q. And it is scrupulously fair in how he has described it?
A. Well, "issue with the Horizon recovery process",
I believe these issues are how Horizon was designed.
Q. But what he's said there, he has carefully put "issue",
leaving open the availability of an argument between
experts about what the nature of the issue is, but what
he has scrupulously done there is perfectly fair, isn't
it?
A. I think so. I mean the difference between the experts
is that, to summarise something Mr Coyne said in his
oral evidence, he believes that these recovery processes
can be automatic. Now, I don't believe that. I believe
recovery of recoverable transactions is very complicated
and needs human intervention and things like failed
recoveries are inevitable.
Q. We can come back to that.
Can we look at now over the page -- I apologise,
stay on page 8, if we may.
MR JUSTICE FRASER: Are we going on to number 9?
MR GREEN: We are going on to number 9 at {D1/2/8}.
A. Reversals.
Q. Now, the description Mr Coyne gives is fair one, isn't
it, where he says:
"In April 2003 due to a failure in regression
testing, Horizon version S30 was released by Fujitsu and
this introduced a bug where the value of transactions
reversed by subpostmasters was shown twice in the amount
of the reversal in branch accounts."
That's a fair summary?
A. I think that's correct, yes.
Q. And --
A. Sorry, can I --
Q. You have said, beside it:
"Transaction reversals are a complex area which,
like recoverable transactions are less familiar to
subpostmasters and are more prone to human error."
A. Yes.
Q. "They lead to many calls to the helpline and to many
KELs and PEAKs - not necessarily related to any fault in
Horizon."
A. Yes.
Q. Now, you then refer to Mr Coyne's supplemental report at
3.99 to 3.101. He refers there to cash remming reversal
issue, and you say:
"Whether or not this was caused by a fault in
Horizon, all remming errors are detected by Horizon and
corrected by TCs ... therefore ... no lasting effect on
branch accounts."
So a slightly different context but the same point
about correcting remming errors is your response to what
he said?
A. That is my response to those paragraphs of his report.
Q. And the correction by transaction corrections is a point
that we can trace all the way back to Dalmellington?
A. Dalmellington is an example of it, yes.
Q. Then if we go over the page {D1/2/9}, we get to number
10, which I think is one that you accept in your list?
A. I do, yes.
Q. Can I just ask you about the entry in your appendix
table at {D3/2/129}, 5.93.
A. Obeng.
Q. This is a Catherine Obeng KEL.
A. Yes.
Q. And what you say about it, you have given your opinion
there. You say:
"This is further evidence of the failed recovery
report doing its job ..."
A. Yes.
Q. ... alerting Fujitsu -- "
MR JUSTICE FRASER: "Allowing".
MR GREEN: I'm so sorry.
MR JUSTICE FRASER: Or is it --
MR GREEN: My Lord, I think in 5.93 I think it says
"alerting".
MR JUSTICE FRASER: I'm so sorry. Yes.
MR GREEN: "... alerting Fujitsu to failed recoveries, so
they can investigate them and make any necessary
corrections to accounts."
A. Yes. Perhaps I should have said have "guided the
transactions to the correct state".
Q. Then you say:
"This was caused by a complex 'grey' communications
failure which could not be reproduced ..."
A. I presume I got the word "grey" from somewhere, but the
meaning I would mean is intermittent, come and go.
Q. Is this your wording, Dr Worden?
A. "Grey" is not my natural choice of terminology so I must
have got it from the KEL or the PEAK or something.
Q. Let's have a look at where you may have got it from.
Let's look at the appendix to Mr Parker's statement,
{E2/11/43}.
A. This is Fujitsu's analysis?
Q. The words here are:
"This is further evidence of the failed recovery
report doing its job ..."
A. Yes.
Q. Just to give you the wording you had in yours:
"This is further evidence of the failed recovery
report doing its job."
A. Yes.
Q. Mr Parker has the word "and", you have a dash.
And then:
"... alerting Fujitsu to failed recoveries to enable
them to investigate them and make any necessary
corrections ..."
A. Yes.
Q. And then a couple of lines down, you see:
"The incident was caused by a complex 'grey'
communications failure ..."
You took that from Mr Parker's appendix, did you?
A. No, I wrote my bit before that.
Q. So he may have taken it from you, we don't know?
A. He may have taken it. He definitely would know if they
took it from me.
Q. I see. But you are not sure where you got it from,
"grey"?
A. I think I must have got it from a KEL or PEAK somewhere.
Q. You are pretty sure that Mr Parker got it from you
rather than --
A. Absolutely, because I know the chronology. I only saw
the witness statement when it was issued, I had written
my report, and it is obvious from the terminology that
they use that they sometimes picked up my wording.
Q. I understand.
MR JUSTICE FRASER: And "grey" means intermittent?
A. To me, yes.
MR JUSTICE FRASER: And is that correctly -- or does that
match your understanding of what the words in brackets
of Mr Parker mean, where he I think describes grey?
A. "... network kept switching between good and bad; not
solid good or solid bad ..."
So that is very much the sense, yes.
MR JUSTICE FRASER: That's the same as your intermittent?
A. Yes, intermittent, yes.
MR GREEN: Can we look at a discrete issue in relation to
Drop & Go, if we may, for a moment, please, and look
please at {F/1848.8.2/1}. This is one of the more
recent PEAKs disclosed, this was disclosed on
30 May 2019. We are going to provide you with a copy.
I think we may have a copy of that.
A. Drop & Go I think is a business parcel service where you
can somehow jump the queue if you have got a card.
(Handed) Thank you.
Q. If we get that up on the common screen.
Sorry, do you want a tab, Dr Worden?
A. All right, thank you.
Q. To be fair to you, Dr Worden, this was only disclosed on
30 May. Do you know if you have had a chance to look at
this?
A. I do not think I have seen this PEAK. I have gone and
looked at what Drop & Go is, but not this PEAK.
Q. I understand. We can see it is created on
21st August 2018. You see it is opened just under the
"Progress Narrative", the start of the main box, date
21st August 2018, 15.43.56.
A. Yes, it is "Failed Drop & Go & Go Top Up". I understand
that is you have a card for Drop & Go and you top it up,
and some process decrements it when you send parcels and
it enables you to do them quickly.
Q. Now could we go over the page, please, to
{F/1848.8.2/2}, and you will see there:
"The mystery is how a top up of £30 came to be in
the Horizon basket without having been credited to any
Drop & Go account."
A. Yes.
Q. "We have heard anecdotals of other such occasions, but
never with adequate information to be able to
investigate."
A. Yes.
Q. You are aware, aren't you, I think, one of the closure
codes for SSC was that they didn't have adequate
information to investigate?
A. Yes, and that was a kind of a black mark for the low
level support, I think.
Q. If we go over the page to {F/1848.8.2/3}, please, this
is an instance of KEL cardc235Q. Do you see that?
A. Yes.
Q. Then it says:
"As stated in the KEL 'This may be an issue with
script ADCScript-CDBalanceTopUp or a user error ...'"
A. Yes. So they don't know if it is reference data error
or user error.
Q. They don't know whether it is a problem with the script
or a user error.
A. That is right, yes.
Q. And then immediately under that, Dr Worden, do you see
it says:
"Here are the keystrokes and messages from the
counter ..."
A. Yes.
Q. "... which might help Atos."
A. Yes.
Q. And we can actually see individual keystrokes being
entered?
A. Yes.
Q. And set out there?
A. Yes.
Q. And whatever we might have made of those lines of text
before, we can see they are actually described as
"keystrokes and messages from the counter"?
A. Yes.
Q. So:
"Button: WS-F-Home ..."
Etc. Do you see:
"Button: enter ..."
A. Yes.
Q. "Button: 0/OK to continue."
A. Yes.
Q. So, if you had understood from Post Office's evidence at
some point that keystrokes would have been available to
Post Office, this is the sort of thing that that would
look like, isn't it?
A. Yes, it is. But I do not think that is what it is.
Q. What do you think this is?
A. I think in frontline support Fujitsu had an operation
called TED, which I can't remember what the initials
stand for, but they look at event logs, and I think
keystrokes are in event logs and used by Fujitsu when
they are investigating a bug or a mystery of some kind.
Q. So you think that somewhere in the system through event
logs you can find these keystrokes?
A. I think so. I'm pretty sure of it.
Q. Pretty sure, thank you.
A. Yes.
Q. Now, what we see in relation to this, if I can refocus
your attention on the script that was identified in the
KEL.
A. Yes, the ADC script.
Q. Yes, it is the ADC script. It is the CD balance top up
script, isn't it?
A. Yes.
Q. If we go please to the fix, we find that at {F/1787.1/1}
A. Sorry, are we -- have we got there?
Q. That will come up in a minute. It is a document on
{F/1787.1/1}.
A. Right, okay.
Q. You will see here "Drop & Go Top Up Live Issue Fix".
A. Yes, that seems to be the same thing ... date and ...
yes.
Q. If we go over the page, please, you will see there is
a contents page?
A. So this is --
Q. Okay?
A. -- an Atos ...
Q. Then we go over the page to page {F/1787.1/3}. And this
was also disclosed on 30 May, so you may not have seen
this before?
A. No, I haven't seen this before. It is interesting.
Q. But if we look at page {F/1787.1/3}.
A. We're on page 3, yes.
MR JUSTICE FRASER: Can you just tell me the date of this
document?
MR GREEN: This document, my Lord, is dated 6th April 2018.
If we look under the table "Branch: Hasland":
"The Balance & Top Up APADC script ..."
And then in brackets we can see a number, and then:
"... CDBalanceTopUp ..."
So it is the same script, isn't it?
A. Yes. It is interesting that the fix report is concerned
with the specific branch where the problem came up.
There we are.
Q. Let's just take it in stages, if we may. It says that
the script had a bug in it --
A. Yes.
Q. -- and that it incorrectly allowed the transaction to
progress after an unrecoverable time out had been
identified?
A. Yes.
Q. This is resolved in version 6.12.
A. Yes.
Q. Do you see that?
A. Yes.
Q. They had also noticed a problem, immediately under that,
issue 2, that the same logic had been used for another
transaction, the open account transaction?
A. Right. I don't know what the open account transaction
is.
Q. Let's leave that on one side for a moment.
What we notice about this, Dr Worden, is that this
document, with quite a detailed explanation of having
identified the bug in the fix, is dated 6th April 2018,
isn't it?
A. I believe so.
Q. Then if we go back to {F/1848.8.2}, which is the PEAK
that we were looking at.
A. It is later, yes.
Q. It is later.
A. Yes.
Q. It is 21st August 2018.
A. Yes.
Q. And at that point we can see, if we go back to page 1 of
the PEAK, very kindly, we can see that Henk Bakker at
the Post Office, this is all a mystery to him
{F/1848.8.2/1}.
Because if we go over the page --
A. "... Accenture's finding ..."
Yes, right.
Q. -- he says {F/1848.8.2/2}:
"The mystery is how a top up of £30 came to be in
the Horizon basket without having been credited to any
Drop & Go account. We have heard anecdotals of other
such occasions, but never with adequate information to
be able to investigate."
So, Dr Worden, what we see from that is that
something for which there had been a detailed fix
description set out in a document in April was still
a mystery to Post Office dealing with that and other
anecdotals in August of the same year?
A. Well, could we go back to the beginning of the fix
report. The fix report obviously involves a different
branch from the branch here.
Q. Indeed.
A. And the question is whether it is the identical problem
or -- but it seems a closely related problem certainly.
Q. They both have a problem with Drop & Go top up, yes?
A. And that's presumably one or two --
Q. In the same script?
A. Do we know it is the same script in each case?
Q. We looked at the script. Do you remember I showed you
the script, it is the CD balance top up script in both
cases.
A. We haven't looked at the actual script.
Q. No, we looked at the name of the script in both cases.
A. The name is the same, is it?
Q. Yes, "APADC script CDBalanceTopUp script".
A. Yes. So a fix was made to the script which did not fix
that -- some problem subsequently emerged.
Q. Dr Worden, can I suggest to you it is not wildly
reassuring, is it?
A. Fixes sometimes go wrong, there is no question,
especially with reference data, which is not a Fujitsu
thing, it is Atos/Post Office. Fixes do go wrong
sometimes.
MR GREEN: I'm most grateful. Would that be a convenient
moment, my Lord?
MR JUSTICE FRASER: We will have a 10-minute break. If we
come back just a couple of minutes before 12 o'clock,
please.
(11.48 am)
(A short break)
(11.59 am)
MR GREEN: Dr Worden, we have now looked at ten example KELs
and in your first report --
A. Sorry, do you mean example ...
Q. Ten example bugs, we have just been through the first
ten, and we have seen your approach. On the basis of
the approach you have taken overall you derived some
figures for the maximum possible number of bugs
corrected for KEL sampling, creation and retention?
A. I do yes.
Q. And that was on the basis obviously of your approach?
A. Yes, my limited sample that I was able to take in my
first report and in my second report.
Q. Understood. If we look at {D3/1/173}.
A. Right.
Q. There is a table there. At the bottom we see in row E2
you have given a label, the bottom row:
"Maximum possible number of bugs, corrected for KEL
sampling, creation, and retention."
A. I think actually there may be a typo in the formula.
The calculation is actually done right, but I think if
you look at the formulae it is not quite ...
Q. There is no R, it is obviously referring to L.
A. L, that's right. You have identified it precisely.
Q. While we are on errors in the table, did you notice at
all that the figure at the top row is wrong?
A. Top row?
Q. The mean number of branches in PO.
A. Shall we correct that?
Q. Well, did you notice it was wrong?
A. I think that was an average I did based on some kind of
trend from -- because there were a lot at one stage and
it came down.
Q. It is not a huge deal, Dr Worden, but would you accept
from me that to get the number you derived you actually
have to add in the figures for 1999 in the source data
by accident and average over 20 years? That's the only
way we were able to derive the same figure you derived.
A. Okay, fine.
Q. It is correctly done on the approach you have stated you
are doing. It is 13,317, so not a huge difference.
A. Okay.
Q. I only mention it because you mentioned, where is R? So
it is the other minor --
MR JUSTICE FRASER: So am I right, bottom right-hand corner
should be E2 = L/X?
A. Yes, I think that's right.
MR GREEN: And if we focus on the figures you have come up
with, you say your conservative estimate is 672 bugs.
A. Yes -- no, my conservative one, yes, correct.
Q. Is 672. And what you call your central estimate is 145?
A. Yes, right.
Q. Now if we turn there, please, to the way you have
derived those two.
A. Yes.
Q. The formula you have got is E2 = R/X?
A. And it should be L/X.
Q. It should be L/X, we know that. No problem there.
A. Yes.
Q. You say the probability that a KEL is created and not
archived given that a bug occurs, and you have got two
different probabilities of that happening, 0.69 and
0.30?
A. Yes.
Q. And just translating that into real life, the
conservative one would be more likely to be right if
there was a greater headwind or inefficiency in the
creation of KELs?
A. That is right. The conservative one says this process
is really pretty inefficient.
Q. Yes. And because you don't know about the facts of all
that, you have given two examples?
A. Yes. And indeed the whole table, if you like, is my
assumptions, which are only assumptions of fact, and if
the court finds different on any entry of the table it
is designed so that the court can put its own finding in
and recompute.
Q. But even on your approach, which fed into the figures,
yes, we have got 672 bugs conservative estimate and
central estimate of 145?
A. Yes. And the key thing that drives that is the size of
the sample of KELs I was able to sample.
Q. Dr Worden, we understand that it is a prisoner to your
approach but I'm just clarifying.
A. Yes.
Q. And in terms of number of affected branches by
particular bugs, could we look at {D1/2/3}, please.
Let's just have a glance at the numbers in the first few
fields there to get our eye in.
Receipts and payments mismatch affected about 60,
possibly 62 branches?
A. Yes.
Q. Callendar Square, 30.
A. Yes.
Q. Local suspense, 14.
A. Yes.
Q. And Dalmellington, 88. So that gives us a feel for
the --
A. Well, Dalmellington 88 I would put on a separate
category because, as I say, Dalmellington was not
something that came to Fujitsu's attention and so it
went on for a long time.
Q. Okay.
Bug 6(i) on page 5, 57 branches?
A. Well, that's not a bug as far as I see.
Q. Okay. {D1/2/5}
If we take an average of the first four bugs, which
I appreciate you disagree with Dalmellington, but the
average of that is 48 affected branches per bug of the
first four bugs?
A. Yes. I mean I should just say briefly it is not the
approach I took.
Q. I understand. I'm just following through the maths,
that's all, on an assumption.
A. Yes.
Q. And if we were to take that approach, 144 bugs affecting
48 branches each.
A. This is the central estimate?
Q. Yes, if we look at your central assumption of 145 bugs
affecting 48 branches per bug.
A. Yes.
Q. On average.
A. Yes.
Q. If that were a reasonable average, that would result in
6,960 incidents?
A. Yes.
Q. And if we looked at 672, which is what you describe as
your conservative estimate.
A. Yes.
Q. And we multiply that by 48, that would be 32,256 --
A. I agree with those figures.
MR JUSTICE FRASER: You are going really quite quickly.
MR GREEN: I'm so sorry, my Lord. The first one was 148 --
MR JUSTICE FRASER: So you multiply that by the 48 and you
get to the 6,960. And then your second one was taking
the 672, multiplying it by 48, and getting to 32,000.
MR GREEN: 256.
MR JUSTICE FRASER: Yes.
A. This is not a calculation I have made, of course.
MR GREEN: I understand, Dr Worden.
MR JUSTICE FRASER: That's rather why I'm trying to get
Mr Green to go a bit more slowly.
MR GREEN: I'm grateful, my Lord.
MR JUSTICE FRASER: Right.
MR GREEN: And if we used an average more favourable to the
Post Office of 40, we would get a figure of 5,800 for
the 145 and we'd get a figure of 26,880 incidents for
the conservative estimate of 672.
A. Yes.
Q. There are only 550 claimants and even with few multiple
branches and a few people having been affected by more
than one instance, on your definition of consistent, the
figures we have just been looking at are consistent with
the complaints made by the claimants in this case?
A. Let me think about that. In the sense of the
calculation you have done, I hesitate to comment.
Q. No, I'm just asking the question. Those figures are
consistent on your definition?
A. They are not consistent in terms of financial impact
which is the only thing I calculated.
Q. We have got your point on being corrected. Let's leave
that to one side.
A. Yes.
Q. On actual incidents of bugs affecting branch accounts,
we have got your point on subsequent correction, but
those figures are totally consistent --
A. Well, let's work it out. Which figure do you want to
take?
Q. Well, there are -- let's take 32,256.
A. Let's take the 32,000, okay. Then what I would say is
that claimants were in branches and held branches for
52,000 months, I think.
Q. So you do the average incidents across everyone and
scale it back?
A. What I would say is over the whole population of
Post Office there were 3 million monthly branch
accounts, and claimants had 50,000 of them, so we have
to do that division and I can't do it on the spot.
Q. We are back to Penny Black on that point, aren't we?
A. No, we are not. We are doing a multiplication, a plain
multiplication.
Q. Okay.
A. I would have to write it down. So what we are saying is
you start with 32,000 occurrences of a bug, and I say
claimants held branches for 50,000 months --
Q. This is branches hit, not occurrences, so this is --
A. Yes, absolutely. But each branch was hit in a month --
Q. At least once.
A. Yes. And we have to take 50,000, we divide it by
3 million, and what I get from that is I can cancel all
the thousands out and I get 32 x 50/3, so that is about
500. So it is consistent with one occurrence of a bug
to each claimant branch during their tenure.
Q. Thank you, Dr Worden. Consistent with a branch with one
occurrence of a bug -- one or more occurrence of a bug,
but at least one bug affecting a claimant branch and
that bug being a bug of a type that impacts branch
accounts?
A. What we have calculated is the mean, so some branches
are affected by more, some less etc, and that's what
that calculation would suggest, the conservative one.
I think that's one of the conservative numbers, isn't
it? The central estimate would give a smaller number.
Q. Yes.
Can we move forward to audits, please. Now, can we
look, please, at {D1/4/5} which is the joint report
number 3. If we look at paragraph 3.23.
A. Yes.
Q. You explain that your opinion in relation to
countermeasures is based on the fact that Horizon is
a tightly run ship -- sorry, you base your opinion that
Horizon is a tightly run ship:
"... on the high quality of documentation, design
review, and testing evident in many of the documents I
have read; on the Ernst & Young service audits of
Fujitsu which found a high level of controls to be
effectively implemented ..."
Yes?
A. Yes.
Q. That's salient because high level of access controls is
one of your robustness features?
A. Yes. There's something in the joint statement about if
there is a poor level of access controls that is a black
mark against robustness.
Q. Indeed. Are you aware that the type of audit that EY
was carrying out that I think you are referring to is --
there's one management letter for 2011 and then there
are the other service audits which you have referred to?
A. Yes.
Q. From 2012 onwards?
A. Yes.
Q. But there was nothing before -- there were no service
audits before 2012?
A. None have been disclosed certainly, yes.
Q. What we have, I will show you, is nothing on this before
2010, then we have the 2011 audit, and then we have
service audits which you have referred to from 2012
onwards.
A. That is right, yes.
Q. Now, let's look first if we may at the 2010 audit, it is
at {F/646.1/1}. This is a Royal Mail document.
If we go to page {F/646.1/2}. If you look at the
second paragraph?
A. "In order to make our audit approach ..."
Q. " ... we seek to rely on SAS 70 audits. These audits
are independent audit reports over the control
environments of the group's IT suppliers. Whilst we
were able to ..."
MR JUSTICE FRASER: Where are you reading from?
MR GREEN: The second paragraph, my Lord.
MR JUSTICE FRASER: The one that starts "In order to"?
MR GREEN: Exactly, my Lord:
"In order to make our audit approach as efficient as
possible, we seek to rely on SAS 70 audits. These
audits are independent audit reports over the control
environments of the group's IT suppliers. Whilst we
were able to place reliance on this third party testing
for one of the Group's suppliers, CSC, we were unable to
place reliance on Fujitsu, due to a SAS 70 audit report
not being available."
Yes? And we see there:
"The Fujitsu control environment is bespoke to POL
and therefore the cost of a SAS 70 is borne entirely by
POL, whereas for CSC the control environment is similar
for a number of companies and therefore the cost is
shared."
You see?
A. Yes.
Q. "The cost of Fujitsu obtaining a SAS 70 audit was
prohibitive; therefore we have performed our own
independent audit procedures to obtain assurance over
the Fujitsu IT general control environment."
Now, pausing there, the SAS 70 audit, do you know,
is a predecessor of the service audit that you are
referring to?
A. Well, it seems that the SAS audit is a general kind of
audit that many suppliers go through, yes.
Q. Do you know as a matter of your expertise and experience
in IT whether or not the SAS 70 audit was later
superseded by the ISAE 3402 audit?
A. I don't particularly know that.
Q. You don't know that?
A. I don't.
Q. If we just go back up for a moment, do you see in the
top paragraph halfway down on the right-hand side
towards the right-hand side, "Key individuals"? Halfway
down the first paragraph on the right-hand side?
A. Yes, right:
"... Group IT function ..."
Yes.
Q. "Key individuals within the Group IT function are
responsible for managing third party suppliers,
particularly the outsourced service provided, CSC, and
delivery of our audit information requests."
A. Yes.
Q. "Whilst some improvements were noted in the POL IT audit
process, we continue to face difficulties in obtaining
accurate information from Fujitsu, one of the outsourced
providers of POL IT systems."
A. Yes.
Q. Now, had you considered this document at any point?
A. I certainly considered this document. I must admit that
the introductory paragraphs -- I tended to go straight
down to the table of observations.
Q. I understand. But this one doesn't actually have
a table of observations.
A. Sorry. Well, this is just a letter, is it?
Q. Well, this is what we have got from Royal Mail as
a result of Royal Mail providing disclosure that was
invited by the court.
A. Right. I'm confused a bit. I thought it was the
management letter that --
Q. No, no. We will take it in stages. This is 2010.
A. Okay, yes. Sorry, I was confused about that.
Q. That's all right. If we come down, "Control
observations"?
MR JUSTICE FRASER: Have you seen this document before or
can't you remember?
A. I do not think I have if that's the case.
MR JUSTICE FRASER: All right.
Go on, Mr Green.
A. Obviously I'm thinking about the Ernst & Young
management letter which has the table and all that.
MR GREEN: Okay. Well, let's take it in stages because
there is a distinction between an audit and a service
audit, we will come to that.
A. Yes.
Q. Let's focus on this one, if we may. In relation to
control observations, it says:
"POL has made significant changes to its IT
environment in 2010."
A. So this is a year earlier really than the Ernst & Young
letter.
Q. Yes.
A. No, I haven't seen it.
Q. And it is reporting that:
"Post Office Limited has made significant changes
... resulting in the inclusion in scope of the Credence
application for the first time."
A. Yes.
Q. So from this we learn that Credence was outside any
scope of reporting prior to that?
A. Outside the scope of certain previous audits?
Q. Yes.
A. It seems so, yes.
Q. So not only do we not have any service audits prior to
this, but we also know that Credence itself wasn't part
of any audits if any were taking place.
A. Yes, whereas for instance POLSAP may have been.
Q. Exactly. It says:
"During 2010 POL also worked with Fujitsu to deliver
a new version of the Horizon application used at and in
support of Post Office branches."
A. Sorry, I'm not ...
Q. In the same paragraph.
A. Which paragraph are we on, sorry?
Q. Under "Control Observations" --
A. Yes.
Q. -- there is a paragraph immediately below that heading
and three lines down.
A. "POL also worked with Fujitsu ..."
Yes.
Q. It says:
"This new version of Horizon was also included in
scope."
So it is not clear from that whether the old version
of Horizon was included in any scope of previous audits.
A. That is right.
Q. Then it says:
"Following difficulties in performing the IT general
control procedures with Fujitsu in 2009 a new key
contact was identified to assist in the management of
the IT general controls procedures with Fujitsu.
However, challenges were again experienced in obtaining
audit evidence in a complete and timely manner from
Fujitsu, resulting in significant delays in completion
of the IT general control procedures."
Now, pausing there. If you are keeping proper
records of access controls, for example, those should be
readily available and collated in real time, shouldn't
they?
That's not meant to be a controversial question.
A. I do not think it is controversial.
Q. It is pretty clear they weren't?
A. Well, the challenges were experienced, and I don't know
what challenges they were.
Q. If we go to the next page {F/646.1/3}, please. At the
top of the page "Status on 2008-09 management letter
points":
"In 2008 and 2009 we noted third party users with
SAP_ALL access (unlimited access to the SAP systems). In
2010 we found that only select individuals and user-ids
had this access and controls had been established to
monitor actions of users with SAP_ALL access and to
periodically review the requirement ..."
So there had been a dramatic improvement on the face
of that to the prior situation, had there not?
A. It seems that before that certain third party users,
I don't know which third parties, had some SAP_ALL
access, which sounds a bit powerful, and in 2010 some
improvement was made. I don't know about dramatic but
certainly there was an improvement, yes.
Q. "Sounds a bit powerful", is that like Emperor Hirohito
saying "the war has developed not necessarily to Japan's
advantage" before surrendering?
A. Again, I don't know whether SAP_ALL access is read-only
access, for instance, or has some permissions to do
things. I don't know what SAP_ALL access is.
Q. Is there a clue in the brackets:
"... (unlimited access to the SAP systems)."
A. It doesn't tell me immediately that changes could be
made. Somebody could get in and look at things.
Q. But it is consistent with the possibility --
A. Absolutely.
Q. -- that that is the case?
A. Yes, it is consistent with that.
Q. If we look at "2010-11 Challenges":
"The challenges the Group faces in 2010-11 will be
the continued transformation of IT and the delineation
of IT services provided by CSC and Fujitsu."
A. Sorry, could I just skip back very briefly, about these
challenges getting stuff out of Fujitsu. This was the
time when Fujitsu were in the throes of (a) maintaining
old Horizon and getting new Horizon tested and so on, so
that might have something to do with the challenge.
Q. So you are trying to thinking up an excuse for
Fujitsu --
A. No, I'm not, I'm just trying to think about what was
going on.
Q. Let's go forward if we may, please. We are going to
look at the 2011 audit. Now, let's look first at the
management letter. This isn't a service audit, we will
have a look --
A. No, this is the management letter, fine.
Q. The management letter. Do you understand the difference
between an audit and a service audit under SAS 70 or
ISAE 3402?
A. Obviously they are very different kinds of audits. One
was the management of POL and it was part of their
overall audit, whereas the service audit was
specifically what it said it was and we have read all of
that.
Q. Yes, service audits are a bit different to audits
generally?
A. Yes.
Q. This is a management letter, 2011. It is on {F/869/1}.
You were here for Mr Coyne's re-examination?
A. Yes.
Q. And you heard his evidence about what was raised in this
audit?
A. Yes.
Q. If we look at page {F/869/2}, the purpose of the
management letter was not focused on IT systems because
this is a general audit?
A. Yes.
Q. "Our review of the company's systems of internal control
is carried out to help us express an opinion on the
accounts of the company as a whole."
A. Yes.
Q. "This work is not primarily directed towards the
discovery of weaknesses, the detection of fraud or other
irregularities ..."
A. I haven't got this. Where are we?
Q. At the beginning of the paragraph:
"This work is not primarily directed towards the
discovery of weaknesses, the detection of fraud or other
irregularities (other than those which would influence
us in forming that opinion) and should not, therefore,
be relied upon to show that no other weaknesses exist or
areas require attention."
If we look at the next page {F/869/3}, the executive
summary.
A. Yes.
Q. If you come down to the second paragraph, the end of the
second paragraph says:
"The recommendations we have made in this report
should be seen as refinements rather than fundamental
control deficiencies in comparison."
Yes?
A. Yes.
Q. Then it says:
"The main area we would encourage management to
focus on in the current year is improving the IT
governance and control environment."
A. Yes.
Q. So this was a concern at this point and I think that's
common ground now?
A. A ...?
Q. This was a concern they were expressing?
A. Yes, absolutely. There are two separate concerns. "IT
governance" seems to me to go to the recommendations
about POL controlling things, and "control environment"
is access to systems and so on and so forth, and there
are both of those there.
Q. Okay. We see this is the passage that Mr Coyne set out
in his -- referred to in his report and was
cross-examined about extensively?
A. Yes.
Q. And you heard both the cross-examination and
re-examination?
A. Yes.
Q. I'm not going to take you through all that, Dr Worden,
but you heard that there were a number of concerns
expressed in relation to generic accounts and certain
other things, yes?
A. Yes.
Q. And we are going to go now to the PEAK about the use of
APPSUP and have a look at that at {F/768/1}, if we may.
A. Right. I will get the PEAK folder.
Q. If we just look at that here. We have seen this several
times before.
A. Yes.
Q. If you see it starts -- in the "Progress Narrative", it
starts on 1st February 2011.
A. Yes.
Q. It says:
"Details entered are:
"Summary: SSC database users do not have correct
permissions."
A. Yes.
Q. Underneath "Impact Statement", we have user and date.
A. Sorry, where is impact?
Q. Just go up.
A. Yes, I see impact there.
Q. Would you like a hard copy of that PEAK?
A. I was expecting one but I may be able to get on with the
screen.
(Handed) Thank you.
Q. We will give you one anyway in case you prefer a hard
copy.
You can see about 40% of the way down the page the
"Impact Statement" box?
A. Yes.
Q. There's user, Dave Haywood. Date, 6th May 2015. Do you
see that?
A. Yes.
Q. So this is spanning a period from 1st February 2011 to
May 2015.
A. Yes.
Q. You didn't actually deal with APPSUP in your reports,
did you?
A. No, that is right, I didn't.
Q. And it is a very powerful tool?
A. What's a powerful tool?
Q. APPSUP. It is a very powerful --
A. APPSUP is a powerful -- well, it says here APPSUP is
a powerful role.
Q. Yes, it is a very powerful role, I should say.
A. Yes.
Q. And Mr Coyne identified it --
A. Yes.
Q. -- through his enquiries. And if you look underneath
Dave Haywood's name there is a box with four points
listed?
A. Yes. Number one is --
Q. Number one is:
"SSC users affected have more access than is
required to database resources. This is contrary to
security policy."
A. Yes.
Q. Your robustness measure has two facets to it. It is to
have an appropriately typed security policy and to
follow it?
A. That's part of it. And as I say, if there is great lax
in security policy that poses a threat to robustness.
Q. Indeed.
A. But I would emphasise if security policy is really flaky
then you start worrying about robustness.
Q. If you have an inadequate security policy, that poses
a threat to your robustness countermeasure?
A. And it is proportional in the sense of the more
inadequate it is, the bigger the threat.
Q. Yes. And if you have a perfectly acceptable security
policy but it is not followed, you have got the same
problem?
A. Yes, I mean security policies change over time and
sometimes --
Q. It is a simple question.
A. Yes.
Q. And if the matter upon which the security policy is not
followed is effectively an incredibly powerful role,
that amplifies the significance of the security policy
not being followed?
A. It does amplify it. If you are calculating impact, then
impact is something to do with how much more powerful
the role is and how much you trust the people that have
that role, and I think SSC were fairly trustworthy.
Q. You haven't actually met them?
A. No, I haven't, but I have read loads of PEAKs and KELs
by them.
Q. Number 2:
"There is currently no 'cost' to this issue."
A. Cost is in inverted commas, I don't know quite what that
means.
Q. Let's leave that.
MR JUSTICE FRASER: Where are you?
MR GREEN: Just under "Impact Statement" in that 1 to 4
list:
"3. Perceived impact: the customer is not aware of
this problem or change."
A. Yes.
Q. So Post Office is not aware of this?
A. It seems so.
Q. So they might be proceeding on the footing -- or would
be proceeding on the footing that the security policy
was being followed and there were not inappropriate or
incorrect permissions being given to SSC?
A. That is correct.
Q. If we look at this, the yellow box at the bottom on your
hard copy or on the screen, 1st February 2011, 11.57.35.
Mark Wright is the user:
"Development have delivered scripts to allow SSC
users to perform certain tidyup tasks (like clear failed
recoveries). However they have been delivered to work
against an SSC role which SSC users have not been
granted as SSC users have the APPSUP role."
A. Yes.
Q. So what had actually happened was there was a tiny
tidyup task script produced by development, which was
usable by SSC role.
A. Yes.
Q. The problem was that the people in SSC were using the
much wider APPSUP role and hadn't been granted the SSC
role because they didn't need to use it?
A. Yes. I mean I don't know how many different roles there
were in play.
Q. Yes, but --
A. Certainly APPSUP was powerful. SSC didn't have the role
for this script. That's clear here.
Q. But the significance of it, Dr Worden, is this, isn't
it, there is a rather small tidyup script -- I don't
mean to disrespect the ambit of that script -- but it is
not the largest sounding task, is it, tidyup? I mean it
might mean making some changes?
A. Well, failed recoveries, we have seen all these PEAKs
about failed recoveries, so it is significant.
Q. So it is significant?
A. Yes.
Q. And that has been assigned, a specific script has been
developed for that specific task which needed to be
addressed?
A. Yes.
Q. And the development had provided that script on the
footing that the permission was the SSC role would be
able to use it?
A. Yes.
Q. And the reason that there is a problem that we see
throughout this PEAK is because the people in SSC didn't
have the SSC role. They were using the APPSUP role?
A. "... delivered scripts ... However they have been
delivered to work against ..."
"An" SSC role, it says. So there may be several
different SSC roles.
MR JUSTICE FRASER: But whichever -- on the face of it,
whichever role the script has been designed to work
against --
A. They haven't got it.
MR JUSTICE FRASER: They haven't got it.
A. No, I think that is right.
MR GREEN: The next paragraph:
"Either SSC user creation/configuration needs to be
amended to make sure we have ALL required permissions of
the scripts will need amending to match how our users
are set up in live."
A. I think it is a typo.
MR JUSTICE FRASER: Should it be "all" and not "of", do you
think?
A. I think so.
MR JUSTICE FRASER: It does read like that. But there are
two options and they are in that line, is that right?
A. Yes.
MR JUSTICE FRASER: You either change the role so it matches
what the script has been designed to work against or you
change the scripts?
A. Yes.
MR GREEN: Exactly.
A. I think later in this PEAK there is concern about
development doing one thing with scripts and it takes
time. There is concern about delays in the process
getting the permissions right for the scripts, I think.
MR GREEN: Yes, quite. There is discussion of that in the
email -- discussion of that below.
A. In the PEAK?
Q. In the PEAK. It says:
"Please see email details below describing in more
detail."
Then we have the detail of the problem.
A. Sorry, where are we now?
Q. Still on the first page:
"(1) The user creation scripts provided by
development offer the option to create each user type
...
"(2) When we created SSC users for BDB/BRS etc. we
used ?appsup? as that is what ssc have always been and
what they migrated as on Horizon databases."
A. Yes, I'm not quite --
Q. So it looks as if APPSUP has been used throughout.
A. It looks like it, yes.
Q. "(3) It became clear that there is also an ssc role
which we now know is a requirement for the scripts you
refer to."
A. Yes.
Q. The scripts you refer to lose any permissions that are
in the APPSUP role and not in the SSC role?
A. These two sentences appear to imply that although it is
"an" SSC role, it is really referring to one SSC role.
Q. It looks like it, doesn't it.
Then:
"(5) We could grant you the ssc role as well and a
call could be passed to development to include in the
user creation script when ?ssc? is chosen as the group
but that seems wrong as well."
Then it says:
"It all comes down to user administration and the
incorrect assumption that adding a user is obvious and
doesn't need some more detailed documentation other than
the current doc which says just add the user with the
relevant roles and on the relevant servers ? head, brick
wall and all that."
A. Yes.
Q. "We can certainly add the SSC role to all users on
BDB/BRS in the short-term but I would need to be sure
that a call was with development for a formal review and
rethink."
Then there is discussion of this throughout the PEAK
and you are obviously quite familiar with this PEAK
because you have been referring to what happens later?
A. Yes, not massively but I have reviewed it.
Q. If we go to page {F/768/2}, Andrew Gibson at the top of
page 2 says:
"I thought the original issue was why have the SSC
users not had the SSC role granted? If it is a bug in
the creation scripts then yes, needs dev to fix but I
thought something was said the other day about the SSC
users not being set up correctly at the start?"
He is right about that in the sense that this is in
February 11, there may be some concern about whether it
was right for SSC users to have been set up in the
APPSUP role, yes?
A. Well, I mean, just more generally -- I don't disagree
but more generally this illustrates that it is
a complicated area and that PEAK is a kind of stream of
consciousness and it is quite difficult to pull the
right things out of it.
Q. Well, look at what Anne Chambers says on page 2, halfway
down. 1st February, Anne Chambers to Andrew Gibson.
She makes it pretty clear. She says:
"Unfortunately development write their scripts
explicitly to use ssc. So I think we're stuck with it
unless they deliver new scripts (which would not be a
popular or quick option)."
A. That is a reference to delays in it.
Q. Yes. Then look what she says there:
"When we go off piste we use APPSUP. Can we have
both??"
A. Yes.
Q. What do you think she meant by off piste?
A. Well, there is two possible things I think she might
have meant. One of them is when we do things we are not
supposed to do, and one of them is when we do things
that are abnormal and difficult and tricky and we have
to not use the usual tools, may have to do something
special, like going off piste in deep snow, not doing
what we usually do.
Q. And would you accept that your two categories are not
necessarily hermetically sealed?
A. Absolutely. It is complicated. Yes.
Q. I won't take you through this in too much detail but if
we go over the page to {F/768/3}, briefly. The third
yellow box down. There is no difference between you and
Mr Coyne in that the optional APPSUP role is extremely
powerful?
A. Yes.
Q. If we go to the bottom of the page --
A. Sorry, I was just trying to read the rest of this
paragraph again before we move down.
Q. Do you mind if we --
A. Sorry, go on.
Q. Because part of it is repeated where I'm taking you at
the bottom:
"As per the previous PEAK comments", do you see in
the bottom yellow box?
A. Yes.
Q. "As per the previous PEAK comments, the role 'APPSUP' is
extremely powerful and should only be used under extreme
circumstances and under MSC supervision. As such the
Branch Database design was that 3rd line support users
should be given the 'SSC' role, which is effectively
read access."
Yes?
A. Yes.
Q. And then next line down:
"SSC team members should only have to [access] BRSS
for normal support investigations unless the information
has not replicated in time. SSC should only given the
optional role 'APPSUP' temporarily (by Security Ops
authorisation/emergency MSC) if required to make
emergency data amendments in BRDB Live."
A. Yes.
Q. Then it says:
"It is a security breach if any user write access is
not audited on Branch Database, hence the emergency MSC
for any APPSUP role activity must have session logs
attached under the MSC."
Pausing there. You hadn't picked up on APPSUP
itself as a role in your reports?
A. I do not think it is mentioned in my first report, no.
Q. Or in your second, can you remember?
A. I'm not clear, I'm afraid.
Q. And you weren't aware that there was in fact a standing
MSC for particular changes to be made, were you?
A. A standing MSC, what do you mean by that?
Q. Were you here what we looked at the MSC at {F/1844/1}?
We won't go to it now because it is a huge document.
Were you aware of what the position on the MSCs was
when you were writing this report about this APPSUP --
A. The discussion of standing MSCs and so on I believe is
quite recent.
Q. Yes, but you weren't aware of it when you wrote your
report?
A. No, not then, no.
Q. If we go please to page {F/768/7}, you can see that in
April -- 10 April 2013, Andy Beardmore?
A. 11.20, yes?
Q. At 11.20.18:
"The initial motive for this PEAK was to ensure all
SSC users had the SSC role assigned to be able to
execute the data correction toolset on BRDB."
That is the tidyup one.
"Initially the SSC users were manually set up
incorrectly ... being given the same permissions as per
Horizon, and had too many privileges via the APPSUP
role."
Pausing there, we can see that this is a reference
to them all having the privileges of the APPSUP role --
A. He seems to be recapping what we have been through.
Q. Yes. And then if you see -- let's just follow it
through:
"Host-Dev have delivered the live scripts to ensure
new SSC users have the correct permissions, but a
follow-on MSC is required to adjust the privileges of
existing users. Graham Jennings rejected this response
as the approach is not consistent across the older
Horizon DB's. The fact is that HNG-X did not include
this change to these Horizon environments, so I believe
this to be a mute point for this PEAK but more of an
interest for PCI and other Audits. As such I am
transferring this PEAK to the new security architect
Dave Haywood for further consideration of tidying up any
existing SSC users on BRDB with APPSUP role, only to
have RESOURCE & SSC roles."
A. Yes.
Q. Now, it looks as if there's tidying up going on at that
stage but we can see immediately above that box there is
a 5th October 2012 release?
A. A reference to the release PEAK, yes.
Q. Do you see that release PEAK?
A. Yes.
Q. Will you accept from me that that release PEAK actually
stopped new people at SSC having the APPSUP role but not
existing, or do you not know about it?
A. I don't know, no.
Q. If we go to the bottom of the page, the last yellow box,
2nd July 2014, 11.17.20:
"Only new users are given the correct permissions.
Existing user permissions are copied into the new builds
and hence will not be corrected by Belfast Refresh.
Suggest an audit of Live and Test is required to:
"(1) identify existing AD accounts of Oracle users.
"(2) identify SSC users from (1).
"(3) run a one-time script (based on the permission
scripts already delivered) to set the SSC user
permissions correctly."
So July 2014 they are still looking at that. It
says:
"The above activity can be performed under MSC but
must be trialled in the Test environment before being
changed in Live to ensure no adverse side-effects are
encountered. Given the existing permission change
scripts for new users were delivered some years ago, the
probability of the change causing any unforseen issues
is thought to be low."
Then at the bottom Mr Haywood, 6th May 2015:
"The Business Impact has been updated:
"1. SSC users affected have more access than is
required to data resources. This is contrary to
security policy."
A. So he is currently repeating what's at the top of the
PEAK.
Q. Well, that's come from the top of the PEAK. What
happens is the PEAK is updated, do you see? Go back to
page 1. The peak is updated --
MR JUSTICE FRASER: Just wait until we get to page
{F/768/1}. Yes.
MR GREEN: On the first page, the PEAK is updated by
Mr Haywood in May 2015.
A. Yes, the same date on both.
Q. Yes. So we can see by the statement:
"SSC users affected have more access than is
required to data resources. This is contrary to
security policy."
Has come from his entry on 6th May 2015 on page 7?
A. It certainly looks like it, yes.
Q. That suggests, doesn't it, very clearly, that even in
2015 the security policy was still being breached as we
have seen?
A. It seems to have run through that period, yes.
Q. You haven't picked up on that because you hadn't read
that PEAK when you did your reports?
A. My report doesn't acknowledge that it ran for that long,
that is correct.
Q. And you hadn't picked up on it before then, or had you?
A. The final date -- no, I hadn't spotted it.
Q. And you hadn't actually reported on APPSUP itself?
A. I hadn't -- no, APPSUP I haven't --
Q. Okay. Can we just go quickly back, with that in mind,
to {F/869/1}, which is the EY audit 2011.
A. The Post Office general audit.
Q. That's it. The general audit, not the service audit.
I would like you to look at page {F/869/32}, please.
You can see -- do you see at the bottom ...
Let me just find -- sorry, can I do this slightly
differently. At the top of 32 -- sorry, can you come
and show me where it is because I was going to go to
a different one. (Pause) Thank you very much.
Sorry, do you mind if we just start at page
{F/869/33}.
A. Right. So 32 was POLSAP and 33 is HNG-X.
Q. Let's just come down, if we may, from -- because it is
the way the pages are paginated. HNG-X is in the middle
of 33, and underneath it says:
"There are inappropriate system privileges assigned
to the APPSUP role ..."
A. Yes.
Q. That's specifically what we have just been talking
about.
A. Yes.
Q. "... and the SYSTEM_MANAGER role at the Oracle database
level ..."
A. Yes.
Q. And then it says:
"There is inappropriate privileged access at the
Oracle database level on the Transaction Processing
System server ..."
Yes?
A. Yes.
Q. And the comment alongside that in the recommendation on
the right is:
Where it is unavoidable to remove SAP_ALL and
SAP_NEW access, it is recommended that a periodic review
of the activities executed by the accounts granted
permanent SAP_ALL and SAP_NEW access is performed to
gain assurance that no inappropriate or unauthorised
activity has been performed which may adversely impact
the financial statements."
Do you see that?
A. It seems to me the two columns have got out of sync here
because HNG-X is not to be lined up with a SAP
recommendation.
Q. Okay. So that appears to relate to what we have on page
{F/869/32}.
A. Yes, I think the SAP relations have come down from 32.
Q. Let's look at page 32.
A. Yes.
Q. What they are saying alongside that is they have
identified those profiles, and I will show you about
that a bit more in a minute. And across to the right on
page 32 you see, under "Recommendation":
"Where access is deemed to be inappropriate this
access should be revoked immediately."
A. That's way up the top.
Q. Yes.
A. Does that refer to the previous page, for instance?
Q. It is not immediately clear. That's why I was trying to
be fair, Dr Worden, by showing you both together.
A. No, but I'm saying we've had this hang-down of that thin
column from one page to the next. This one on 32 might
be a hang-over from 31. I'm just ...
Q. Well, the way it seems to work is if we look at the
bottom of 32, 32 is dealing with POLSAP.
A. And POLSAP is bleeding onto the next page.
Q. And it is bleeding onto the top of page 33. So the
bottom of 32 says:
"The SAP account was not locked. This does ..."
Then when we look at the next page:
" ... not meet recommended practice of removing all
profiles from SAP and locking the account."
A. Yes. It seems SAP goes right the way to the bottom of
33, because it is talking about SAP, all roles.
Q. Indeed. So if we go please now to page {F/869/29}.
Number 3, just reading down into this section:
"Strengthen the change management process.
"Rating: high."
A. Yes, we are on a different topic now.
Q. That is a different topic, okay?
A. Yes.
Q. And on page {F/869/30} they deal with HNG-X there?
A. Yes.
Q. This is on the change management topic at the moment.
A. Right.
Q. And it says:
"Based on a testing sample of 15 back end changes,
ten counter changes and five manual changes deployed to
the HNGX live estate during the audit period we noted
the following:
"For 15 back end changes, ten counter changes and
five manual changes evidence of testing by POL was not
retained."
A. Yes.
Q. Now if you have got a well documented system that
evidence will be retained, won't it?
A. Well, this is Post Office not doing their job rather
than Fujitsu not doing their job, I think.
Q. Understood. But if Post Office are testing it and
supposed --
A. They should keep proper records and they haven't done.
That's what it seems to say.
Q. -- they haven't. Because the point of retaining the
documentation is you can tell whether something has in
fact been done or not?
A. Yes.
Q. It then says:
"For ten counter changes, evidence of POL approval
of the change to be deployed across the counter estate
was not retained."
A. Yes, this is getting sign-off and retaining sign-off.
Q. And:
"... manual change, evidence of POL authorisation to
begin development (i.e. a signed off CT document) was
not retained."
Yes?
A. Yes.
Q. And if we go up to page {F/869/31}:
"For one manual change, approval was not
obtained --"
A. Sorry, I've lost you -- oh, right, we're coming forward
29, 30, 31. Yes.
Q. Yes, 31:
"For one manual change, approval was not obtained
from POL prior to the change being implemented."
Do you see that?
A. So all of this is saying POL need to be involved or
formally to record stuff.
Q. Yes. Then if we look immediately under that, we see
"All in-scope applications".
A. "... are not usually involved ..."
Yes.
Q. "... not usually involved in testing fixes or
maintenance changes to the in-Scope applications;
"We were unable to identify an internal control with
the third party service provider to authorise fixes and
maintenance changes prior to development for the
in-scope applications."
A. And the service provider is Fujitsu, is it?
Q. Yes.
"There is an increased risk that unauthorised and
inappropriate changes are deployed if they are not
adequately authorised tested and approved prior to
migration to the production environment."
A. Yes.
Q. So that's in relation to the change management point,
yes?
A. Yes.
Q. Then:
"We reviewed privileged access to IT functions
including access to user administration functionality
across all in-scope applications and their supporting
infrastructure."
A. Can I pause there. "Privileged access" to my mind is
associated with the DBA function rather than the SSC
function.
Q. Yes. So, so far we have hit the control environment
generally, the changes?
A. Change management, yes.
Q. Then this bit you are suggesting relates to the DBA
function rather than SSC?
A. I generally associate "privileged user" with that lot
really.
MR GREEN: Understood. My Lord, is that a convenient
moment?
MR JUSTICE FRASER: I think it probably is.
Just one quick question for my note really, because
I'm pretty sure I know -- I could come up with
a description myself but I thought I would ask you, how
would you describe script to a layman?
A. A script describes a sequence of steps to do a computer
business process.
MR JUSTICE FRASER: I know that. But would you describe it
as a line of code, or a line of instructions, or
a message?
A. Scripts become pretty much code actually, but they are
generally a bit more readable than Java or something.
MR JUSTICE FRASER: It is the sequence of instructions to
the system, isn't it?
A. Yes, and they may include branches and loops etc.
MR JUSTICE FRASER: All right.
Thank you very much. 2 o'clock.
MR GREEN: I'm most grateful.
(1.00 pm)
(The short adjournment)
(2.00 pm)
MR GREEN: Dr Worden, can we look please at {F/869/29}.
A. Yes.
Q. So we are back in the 2011 general audit, I'm going to
say general audit rather than service audit to
distinguish the two.
A. Sorry?
Q. The 2011 audit --
A. Right, okay.
Q. -- that we were looking at before.
A. Sure.
Q. And we are looking at {F/869/29}.
A. Yes.
Q. If we look at page 29, very kindly. So just following
down how it works. The section here is "Strengthen the
change management process", the general section.
A. Yes.
Q. You will see what the rating is, "Rating: High".
A. Rating high, yes.
Q. It says there as a general introduction:
"We reviewed the processes implemented to determine
that all program changes are appropriately authorised,
tested and approved prior to implementation into the
production environment for all applications in scope.
Our examination of this process revealed the following."
And the recommendation on the right-hand side -- it
is slightly odd because the main paragraphs are off to
the right and then the bullet points are to the left.
A. Yes, and the bullets, yes, full out.
Q. You can see it says:
"Management should enhance the current change
management process/policy to include ..."
One of the things is:
"The level of documentation retained ..."
Yes?
A. Yes.
Q. Which we have seen.
Then the way this section works, there are two
headings under this column.
A. The "Recommendation" column?
Q. In the "Background" column.
A. Yes, there is a POLSAP and an HNG-X, is that what you
mean?
Q. Yes. So you have got the general introduction. Then
they deal with POLSAP. If we go on to the next page
{F/869/30}.
A. We have HNG-X.
Q. Yes, HNG-X. And then if you go to the next page
{F/869/31}, they do a section on "All in-scope
applications".
A. Yes.
Q. And that's the bit where we saw increased risk of
unauthorised and inappropriate changes etc, at the
bottom?
A. Right.
Q. The next section we look at in the new box is:
"We reviewed privileged access to IT functions
including access to user administration functionality
across all in-scope applications and their supporting
infrastructure."
A. Yes.
Q. And on the right we see:
We recommend that management conducts a review of
privileged access to IT functions across all in-scope
applications and their ..."
Over the page {F/869/32}:
"... supporting infrastructure to determine whether
the level of privileged access granted is appropriate.
Where --"
A. Can we just --
Q. Let me just read it out.
A. Yes.
Q. "Where access is deemed to be inappropriate this access
should be revoked immediately."
A. Yes. There seems to be a slight implication on the
previous page, if we can turn back. {F/869/31}. It
says:
"... IT functions including access to user
administration functionality ..."
So as I say, my view of privileged access is people
like DBAs, whereas possibly one could consider SSC to be
users.
Q. It looks wider here, doesn't it, yes. The point they
are making there is where the access is deemed to be
inappropriate, this access should be revoked
immediately, if we look at page {F/869/32}.
A. And that is the privileged access, is it?
Q. Yes, it is the end of that paragraph. And we know from
what we have seen in the PEAK that that didn't happen in
relation to the APPSUP role until -- it certainly hadn't
happened by 2015?
A. A slight distinction. The APPSUP role certainly wasn't
fixed by then, but the privileged user thing might have
been separate from that.
Q. But APPSUP is a role with a privileged use, isn't it?
A. Again I'm not clear on that entirely. I think of
privileged users as DBAs and SSC.
Q. Let's look at page {F/869/33} to see whether it comes
into this section or not. When we see that they have
the APPSUP role as the first item --
A. Right. But that is the HNG-X --
Q. This is all under the same box, going down.
A. All under that box, okay, fine.
Q. So we can now be confident that they were thinking of
that. So if we go back --
A. Right, fine.
Q. -- to page {F/869/32}. "Recommendation" is:
"Where access is deemed to be inappropriate this
access should be revoked immediately."
And what we have seen from the APPSUP PEAK, we have
seen that that did not happen. In relation to APPSUP it
certainly had not happened by 2015 for existing users?
A. Yes, we have seen that delay.
Q. Okay. Could we please look at {F/1705/1}. The document
you are going to see in a minute on 1705 is
a Post Office account user access procedure.
A. Yes. Right.
Q. Okay?
A. "... Post Office ... follow to manage user access to its
assets ..."
Okay.
Q. "... based on its contractual requirements to protect
assets, systems and data."
A. Yes. And the date?
Q. I will just show.
A. It is pretty recent, yes.
Q. It is an ongoing document. You can see from the foot it
is 7 November 2017.
A. Yes, and it has a history presumably.
Q. Now, let's look at page {F/1705/4}, if we may, and we
look at the foot of that table at item 10.1.
A. Yes:
"Addition of TESQA & APPSUP access management."
Yes.
Q. So we can see that a TESQA and APPSUP access management
provision has been added into this version of the
document.
A. Yes.
Q. If we go then, please, to page {F/1705/12}, and we see
item 4.2.3, "Requests for TESQA & APPSUP access elevated
privileges".
A. Yes.
Q. "The APPSUP role ... are temporarily applied to user
accounts when required for investigations into TESQA &
BDB queries. The roles are then removed again once work
is complete. Temporary access is managed via change
control (TfS) and that it should reference an MSC as
justification on the requirement for the elevated
access."
A. Yes.
Q. Yes?
A. Yes.
Q. So that does show, doesn't it, a provision for
controlling access in the way that you think would be
appropriate reflected at least as a policy in that
paragraph there?
A. Yes.
Q. Now, we have already touched on the fact that the 2011
audit was a normal audit, as it were?
A. Yes.
Q. A general audit. But we do have service audits from
2012 onwards?
A. Yes, and we have that period covered now. Yes.
Q. Yes. You referred in your expert report to the service
audit specifically?
A. Yes.
Q. And we have got those. The first one is 2012 and that
is at {F/1041/1}.
A. Yes.
Q. While it is coming up, Dr Worden, you are aware,
I think, aren't you, that none of those audits
identifies a problem with APPSUP anywhere?
A. They didn't. They were a lot of clean bill of health
stuff.
Q. Did you notice that quite a lot of the wording was
either very similar or identical?
A. Absolutely, yes.
Q. There are identical passages, for example, for control
objectives in 2013 and 2014 and again in 2015 and 2016.
That doesn't surprise you from what you --
A. It doesn't surprise me. It seems to me that tests were
done each year but they were the same tests.
Q. Precisely. Let's look at the purpose of those audits.
Let's look at page {F/1041/9} of that document, please.
Now, this is the intended use --
A. Yes.
Q. -- of the service audit. It says:
"This report, including the description of tests of
controls and results thereof in the Description of Tests
and Results, is intended solely for the information and
use of Fujitsu, POL as the user of the IT support
processes and controls used by and on behalf of Fujitsu
to support the HNG-X and POLSAP applications during some
or all of the period 1 April 2012 to 31 December 2012
and the independent auditors of POL, who have a
sufficient understanding to consider it, along with
other information including information about controls
implemented by user entities themselves, when assessing
the risks of material misstatements of user entities'
financial statements."
A. Yes.
Q. So their focus is on the risks of material misstatements
in the user entities' financial statements?
A. Yes.
Q. That's what the service audits do, isn't it?
A. It seems to imply that, yes.
Q. And:
"This report is not intended to be and should not be
used by anyone other than these specified parties."
A. Yes.
Q. So it is not for assuring outsiders about this?
A. No.
Q. Then if we go to page {F/1041/67}, please. That's
section 7, "Description of Control Objectives, Controls,
Tests and Results of Tests".
We can see there at paragraph 7.2, it says:
"On the pages that follow, the description of
control objectives and the controls to achieve the
objectives have been specified by, and are the
responsibility of, Fujitsu."
A. Yes.
Q. So the way it works is the control objectives and the
controls, which are the benchmarks for a service audit,
and this is one of the distinguishing features of
service audits rather than general audits, these
benchmarks for these purposes are set by Fujitsu?
A. Yes. Fujitsu's description of the service is the first
half of the document.
Q. Yes.
A. And that's signed off by Fujitsu management.
Q. Yes. Then we see the next paragraph:
""The service auditor's examination was limited to
the IT general controls relevant to Fujitsu's operations
supporting IT services provided to POL to support the
POLSAP and HNG-X applications. Accordingly the service
auditor expresses no opinion on the operating
effectiveness of any aspects of application processing
and application controls, individually or in the
aggregate."
A. Yes.
Q. Now what do you understand to be excluded by that
phrase?
A. Well, in reviewing these reports I frankly hadn't seen
those words before and it is new to me. And it does
seem to me that this is an infrastructure report, so its
focus -- I mean this says the application processing,
which is probably SSC, is rather outside scope.
Q. And at {D3/6/45}, if we can go to that, which is your
second report, at paragraph 168. Actually if we go back
to page {D3/6/44} to give you the beginning of
paragraph 168:
"The service audit for 2014 consists of
a description by Fujitsu of the services ..."
Which is what you volunteered in your last answer:
" ... signed off by Fujitsu senior management, and a
number of tests of that description carried out by the
auditors."
Yes?
A. Yes.
Q. And the point I was just trying to identify from this is
that tests are identified by Fujitsu, which we have
seen, yes?
A. They are defined by Fujitsu.
Q. Precisely.
A. Right, yes.
Q. Then:
"Section 7.2.10 of this document describes Control
Objective 10, which is that 'Controls provide reasonable
assurance that access to system resources, including
computing platforms and operating systems, is restricted
to properly authorised individuals.'"
Yes?
A. Yes.
Q. And:
"In all seven tests of this control objective, there
were 'no deviations noted' by EY."
A. In that year, no.
Q. So that is the premise of the opinion you formed about
this area?
A. Yes.
Q. But you hadn't noticed the content of the APPSUP PEAK
when you reached that view?
A. I can't remember the exact timing. I hadn't noticed the
duration of the APPSUP PEAK, I certainly hadn't noticed
that.
Q. Had you noticed it at all? Because it is pretty
important if you had.
A. I think I had noticed the APPSUP PEAK quite early,
because Mr Coyne raised the issue and I think
I didn't^ notice it quite
early.^chk - did he or didn't he?
Q. But if Mr Coyne raised the issue and it was a very
powerful role, why didn't you address it and follow that
through with the APPSUP PEAK?
A. It is just in my second report I had come across this
piece of evidence of the service audits and I felt that
was an extra piece of information which was useful to
have, and I was talking about the service audits here
which I think don't talk about the APPSUP role, so it
didn't fit in here I do not think.
Q. Well, if it contradicted what was in here then it might
have fitted into that section of your report?
A. Well, I wasn't clear on the timing. I wasn't aware
that -- you know, the service audit was 2011, this was
a later one so, you know, I didn't see a clash at that
time. I didn't realise that the APPSUP PEAK went on to
2015. So there was not an immediate contradiction in my
mind.
Q. Can I suggest to you, Dr Worden, by the time you had
written your second report you had not read the APPSUP
PEAK?
A. I think I had, but exactly when I read what is not
entirely --
Q. If you had, you really should have drawn the court's
attention to it, shouldn't you?
A. I think Mr Coyne had.
Q. Well, why didn't you then? Why didn't you deal with it?
A. Perhaps I did not have anything else to say about it.
I mean I was -- I had to be very selective in my
supplemental report.
Q. Well, we can see the -- if we go back to --
A. I think I did mention it at some stage because I mention
evidence that Fujitsu were taking steps to address the
issues, and that was the PEAK that I think I quoted or
certainly I had in mind when I said there is evidence --
I think somewhere in my first report I said there's this
Ernst & Young audit report and there is also evidence
that at a certain time Fujitsu were taking steps to
address it.
Q. But the short point is you hadn't appreciated the
history on to 2015?
A. I hadn't appreciated the duration, no.
Q. And that changes your opinion, doesn't it?
A. I think it does.
Q. Radically?
A. I'm quite surprised at the duration of that issue. One
would have thought it would have been sorted quicker.
Q. There are two things, duration of the issue and power of
the role, in combination even more striking?
A. SSC needed powerful roles to do what they did.
Q. Hold on, Dr Worden. The problem that we have identified
is basically having a completely open back door, as it
were, with APPSUP?
A. For SSC.
Q. Basically for the whole of SSC.
A. The whole of SSC.
Q. And you are surprised by the duration of it?
A. I'm surprised it took that long to fix the problem, yes.
Q. Are you surprised that it appears to be unknown to
Post Office up to 2015?
A. Yes, I guess I am.
Q. And does the power of the APPSUP role reinforce the
significance of those two last answers?
A. Well, we are aware that the APPSUP role is powerful and
we are aware that the SSC needed a powerful role from
time to time, but the problem was it was allotted rather
permanently rather than temporarily.
Q. The point about it is, Dr Worden, when we contrast it
with the specific balancing transaction tool, which had
specific protections in it, it wrote to a journal for
every time it was used, yes?
A. Yes.
Q. So that you could see exactly when it was used?
A. Yes.
Q. And what for, yes?
A. Yes.
Q. When we contrast it with that, what we are talking about
is taking great care over which window lock you choose
with a balancing transaction tool whilst leaving your
back door wide open with the APPSUP role?
A. I don't entirely accept the analogy. The transaction
correction tool was built to address a specific need,
which actual -- you know, it came up once. But
nevertheless I think both experts have agreed that there
are times when SSC or times when Fujitsu had to do
things which are unanticipated and we can't see the
limits of those.
Q. And there are times when you have to open your back door
of your house, but it is quite sensible to control those
times and do it appropriately rather than leaving the
back door open?
A. Yes, well, I would not have called giving a permission
to experienced and long-term users of SSC opening your
back door.
Q. Let's look at {F/1041/83}. This is Control Objective 10
which you have referred to in that part of your expert's
report I just took you to.
A. Yes.
Q. If we look at 10.3, it says:
"We selected a sample of 12 platforms within the
in-scope applications. The Group Policy on failed access
attempts that manages access to all these servers was
set to disable accounts after 6 consecutive failed
access attempts; the POL setting should be to disable
accounts after 3 failed access attempts. The other
settings tested were in line with the POL requirements.
"No other deviations noted."
A. Yes. It seems to me that failed access attempts is
failed access attempts by anybody.
Q. Yes. So they are not actually -- what they are actually
looking at there is they are focusing on that aspect of
the access attempts, not specifically on who has which
roles?
A. That is right.
Q. If we go to your expert report at {D3/6/12}, you can see
heading 2.2 is "Mr Roll's second witness statement"?
A. Yes.
Q. You were aware Mr Roll wasn't a claimant?
A. Yes, absolutely.
Q. And you deal with Mr Roll's witness statement in this
section of your report.
A. Yes.
Q. Page {D3/6/23} is in the same section, and if we look
at -- if we go back a page {D3/6/22}, do you see at
paragraph 91 you say:
"In his paragraph 22, Mr Roll disagrees with my
paragraph 1144 ..."
A. Yes.
Q. "... where I said that SSC access to the counters is
strictly controlled."
A. Yes.
Q. If we go over the page {D3/6/23} you will see at
paragraph 93 you then move on to Mr Roll addressing
rebuilding of transaction data, which topic we will come
to in a minute.
So you are dealing with Mr Roll in this context.
And at the foot of paragraph 92, you say:
"In section 6 of this report, I describe evidence
from service audits of Fujitsu that these controls were
effective."
A. Yes.
Q. So this is the section where you are responding to
Mr Roll who disagreed with paragraph 1144 of your first
report?
A. Yes. And I made those comments based on the answers
I saw to the assessment by Ernst & Young under Control
Objective 10.
Q. And service audits started in 2012?
A. Ah yes, good point. Yes.
Q. And Mr Roll left many years before that?
A. I'm sorry about that, yes. There is a real timing
problem.
Q. So Mr Roll is probably owed a bit of an apology on that
one, is that fair?
A. Mm?
Q. Mr Roll is probably owed a bit of an apology on that
one?
A. I certainly didn't spot that timing issue, I'm very
sorry, yes.
Q. It doesn't appear either, not only were there no service
audits when Mr Roll was at Fujitsu back in Legacy days,
but also it strongly appears that the service audits
themselves do not deal with the issues of the APPSUP
role itself?
A. Yes. But the service audits do say access to system
resources regardless of who it is.
Q. Now, let's go back to a point from slightly earlier, if
we may.
When we were looking at the keystrokes in the
PEAK --
A. Yes.
Q. -- you suggested that those might be visible in an event
log.
A. I think so, yes.
Q. Do you mean visible to the SPM or visible to
Post Office?
A. Visible to this department TED or whatever they are
called. There is a Fujitsu application support strategy
document that defines the four levels and in front
level, first level, there is HSD, Horizon service desk,
and there are various other departments including TED,
and I can't remember the acronym, exactly what that
means, but they were looking at logs.
Q. Just to clarify, let's look at {F/1468/1}. So that is
the event log that the SPM -- this is Mrs Burke, as it
happens, but this is the event log that the SPM can
print out.
A. I am not talking about that event log.
Q. They are not going to see it.
A. No, I'm not talking about this kind of event log, no.
Q. Are you talking about an ARQ event log?
A. Absolutely not, no.
Q. So there is a third type?
A. There is a third kind, yes. There is lots of logging of
the Horizon system that goes on and there are these
people that spend their time looking at these logs.
There are event logs and transaction logs, for instance,
they look at, and I have probably not got all the kinds
of logs they look at.
Q. But one of the kind of logs they have is a log that has
the keystrokes in it?
A. I believe one of the event logs goes down to that level,
yes.
Q. And you think it is likely to be the source of the
keystrokes we saw there?
A. Yes. Obviously that source was quoted in a PEAK so it
is not a thing that somebody had gone out to a branch to
pick up.
Q. No, of course.
MR JUSTICE FRASER: And it is not an ARQ.
A. It is not ARQ data at all. It is stuff you can look at
on the day.
MR GREEN: On the day?
A. Yes.
Q. So if an individual subpostmaster was very anxious about
how something had happened, that would be very helpful
information, wouldn't it?
A. Obviously sometimes it is, and I think it was used
a great deal because TED was a whole department that was
scanning these things. They were scanning for things
that the subpostmaster didn't see and they were also
presumably called up when somebody said, "Subpostmaster
says this. Could you look at the logs".
Q. I'm not asking you to comment on the evidence of other
witnesses but I'm going to ask you if you can think of
an explanation, because what was said in Ms Mather's
statement was that you could -- Credence recorded
keystrokes, and then we were told that that was wrong,
and indeed Ms Van Den Bogard was re-examined on the very
point.
A. Yes.
Q. That we didn't have access to keystrokes.
A. Yes, but --
Q. So do you have any feel for who ought to know about the
existence of those documents, the keystrokes?
A. Well, the question of keystrokes on Credence is Credence
is a POL system. The question of keystrokes on a PEAK
is Fujitsu having access to keystrokes information. So
I suspect, I strongly think that is from the event logs
that Fujitsu were responsible for looking --
Q. Do you know the extent to which that data which Fujitsu
have in the Horizon system, or from it, is available
through Credence to Post Office?
A. Obviously certain of the same things go in the event
logs and they go in different forms in Credence.
Q. Yes.
A. I don't know the extent of --
Q. Those event logs do go into Credence, but you don't
know --
A. No, not the event logs.
Q. Sorry, the data in the event logs.
A. The data in different forms goes into Credence, yes.
Q. And you don't know which data from those event logs goes
into Credence and which doesn't?
A. I don't. But as I said before, my expectation was that
Credence doesn't go down to keystroke level.
MR JUSTICE FRASER: And the expression you used, and it
doesn't matter if you can't remember what it stands for,
is TED.
A. Yes, and you find this in the application support
strategy document.
MR JUSTICE FRASER: All right.
A. Which defines the four levels of support.
MR JUSTICE FRASER: Thank you very much. And that's the
sort of data that you were shown earlier, you think it
will come from TED.
A. I think it would have come from there, yes.
MR JUSTICE FRASER: Mr Green.
MR GREEN: I'm most grateful.
Can we go to remote access, if we may, Dr Worden.
Can we look at the transcript of {Day18/67:1}, for
a minute. I think the position you reached with
Mr Coyne in the joint statement was that more or less
Fujitsu or Post Office could do anything.
A. Well, we can look at that. That is 10.12. I was asked
to go and look it up and we didn't come back to it. In
joint statement 4, 10.12.
Q. We will come to that. It is literally my next point.
But just have a look at {Day18/67:6} and line 7.
A. 57 or 67?
Q. It is Day 18, page 67. I think it is lines 5 and 6
actually. It says:
"Answer: And we agreed in the joint statement that
more or less Fujitsu or Post Office could do anything."
A. Yes. We can see precisely what we agreed in a minute,
obviously.
Q. In relation to the --
A. We agreed the experts couldn't demonstrate that they
couldn't do everything. I mean, that's sloppy wording
by me there. I think the joint expert statement says it
better.
Q. Okay. You were asked -- I think you were hoping to see
where in the joint report you reflected the position in
relation to Mr Roll and Mr Parker in respect of access
at the counter, which they had in fact agreed to in
their second witness statements?
A. Sorry?
Q. Did you have a look at that? Do you remember the
homework?
A. I thought the homework was to find that statement which
is at 10.12 in the joint statement.
Q. {D1/5/8}, I'm grateful to Mr Miletic. At 10.12.
A. Yes.
Q. "Certain facilities and procedures used by Fujitsu to
repair the more common issues which arose in Horizon
were standardised and evidence of them persists.
However, to repair less common issues which arose from
time to time, standard tools and procedures might not
have been sufficient, and evidence might not persist of
what was done at the time. Even when evidence does
persist, it may be extremely difficult for the experts
to interpret it today, because of the scale and
complexity of Horizon."
That is the point you mentioned about difficulty of
plumbing the depths of the system.
A. That is right.
Q. And the fact it is a bit of a swamp.
A. There are layers and layers and layers which --
Q. Makes it very difficult?
A. Yes.
Q. "Therefore, it is usually difficult for experts to make
categorical negative statements of the form: X or Y
never happened."
A. Yes.
Q. Can we probe that in a tiny bit more detail, if we may.
If we look first at {D3/1/248}, please. We have your
table?
A. Yes.
Q. Just taking that in stages, if we may. The top half
above the horizontal light blue bar is about Post Office
access, isn't it?
A. Yes.
Q. The bottom half is your opinion about Fujitsu access?
A. Yes.
Q. So the first question is whether Fujitsu had the ability
to inject or insert?
A. Yes.
Q. And it is yes, and you explain why.
Then "Fixes", second column, is yes. And "Rebuilds"
is yes.
A. Yes.
Q. And then (b), you say:
"Without the knowledge of the subpostmaster."
You say:
"No. Any changes performed by privileged users
become visible at the branch."
Otherwise on that you say yes and yes.
A. Yes.
Q. Then row (c), "Without the consent of the
subpostmaster", and you say yes?
A. And we have the typo here.
Q. Then across that row, yes and yes.
So can we focus on (b)(i)?
A. Yes. I think that is effectively overridden by the
expert joint statement. In other words, that
categorical "never" statement shouldn't have been there.
Q. Okay. So you can't exclude that. That's where we are
now because of the joint statement?
A. Yes.
Q. And it certainly appears that that may well have been
possible?
A. Well, I think when the experts agreed in the joint
statement that the experts cannot determine whether or
not Fujitsu could do X, and X could have been some form
of remote access. But equally it follows logically that
X could mean doing that form of remote access without
the knowledge of the postmaster. That all follows
logically.
Q. It does.
MR JUSTICE FRASER: So logically is that now a yes?
A. I think that's now a yes.
MR JUSTICE FRASER: All right, thank you very much.
A. Or a don't know.
MR GREEN: There's an issue about how something might become
visible to a subpostmaster.
MR JUSTICE FRASER: Just before you move on, I don't want to
put words in your mouth. So that should be a don't know
or a yes, do you think?
A. Well, I think the don't know follows from the joint
statement, yes.
MR JUSTICE FRASER: So don't know.
A. Yes.
MR JUSTICE FRASER: All right. Mr Green.
MR GREEN: And that the reason for the qualification in that
box, if I can put it in those terms, in your original
report, is the possibility that it would be done in
a way that would become visible at the branch?
A. Yes, and there is some confusion in that paragraph (b)
because it's "changes performed by Privileged Users",
and my view since then is that privileged users aren't
DBAs and therefore they are not the whole story. It is
SSC we are really interested in, I think.
Q. Let's just trace it through, if we may. At the time you
wrote your report you agreed I think that privileged
users could edit and delete in Horizon Online?
A. I think so, yes.
Q. I think that's at paragraph 1122. That was needed for
system maintenance purposes but the same rationale would
apply to Legacy?
A. Yes.
Q. And I think the roles appear to have gone -- I have
a reference I can show you if you want -- but privileged
user roles appear to have gone through from Legacy into
Horizon Online?
A. You would expect DBA people to be around the whole time,
yes.
Q. To carry on?
A. Yes. For instance the Legacy databases in the back end
were preserved, quite a lot of them.
Q. Can we look please at {D3/1/246}, paragraph 1123. So
this is where you say:
"Any change to a transaction performed by a
Privileged User would be visible to branch staff. The
amended transaction would appear in reports and logs
that can be viewed in branch, although it would not be
flagged as a change by a Privileged User."
A. Yes.
Q. You say:
"Theoretically this is a problem, but Privileged
Users cannot change the audit record and so the changed
record in the BRDB would no longer match an audit
extract. This means that a subpostmaster could always
find out about changes made by SSC, via a request to the
helpdesk."
A. Yes.
Q. That assumes, doesn't it, there is a comparison between
the audit store or ARQ data and some data that the
subpostmaster has?
A. There could be. But my view on that paragraph would be
somewhat different now, I think. As we have said, the
audit data was generally used as a backstop and the
whole issue of what is visible to the subpostmaster ...
Q. Is pretty difficult, isn't it?
A. It is difficult, yes.
Q. But also the subpostmaster would not have been
expecting, even if hypothetically they had been provided
with ARQ data and tried to interpret it themselves and
compare it with information they had --
A. I do not think subpostmasters should be provided with
ARQ. I think that's very technical and not the sort of
thing that subpostmasters want to dig around.
Q. Even if Post Office itself had requested the ARQ data to
look at and try and consider --
A. Yes.
Q. -- and to show and explain to a subpostmaster so they
can try and see what happens as well?
A. Yes.
Q. Subpostmaster would need to have in mind the possibility
of remote access in order to be looking for that as
a possible explanation, wouldn't they?
A. I agree, yes.
Q. If we have a look, please, at {F/1422/1}. This is
Post Office's response to the Panorama program which the
BBC showed about this issue, and you can see the bold
points sort of summarising the thrust of what was said?
A. Yes.
Q. "The Post Office does not prosecute people for making
innocent mistakes and never has.
"There is no evidence that faults with the computer
system caused money to go missing at these Post Office
branches.
"There is evidence that user actions, including
dishonest conduct, were responsible for missing money."
So that is the thrust of the response. But if we go
over the page {F/1422/2}, and if you see halfway down
there is a section which is "The Horizon Computer
System" section?
A. Yes.
Q. If you look at the bottom of that section, it says:
"There is also no evidence of transactions recorded
by branches being altered through 'remote access' to the
system. Transactions as they are recorded by branches
cannot be edited and the Panorama programme did not show
anything that contradicts this."
A. Yes.
Q. Even though Mr Roll was actually interviewed on it.
A. I didn't see the programme and indeed I haven't actually
read this document.
Q. But in the face of the fact that that's what Post Office
were saying in response to a reputable bit of
investigative journalism by the BBC, there is no
prospect of a subpostmaster thinking if they were
hypothetically one day to be in the position of
comparing data: oh, I must just see if that was actually
one of those remote access changes, is there?
A. So you are saying that this document from Post Office
came to the attention of a subpostmaster -- is that
what's being put to me?
Q. Dr Worden, 2015, Post Office are denying --
A. Is that the document of this document?
Q. Yes.
A. Right.
Q. Post Office in 2015 are, in response to a BBC
documentary by Panorama, which Mr Roll is on saying
there could have been remote access, they are saying:
"There is also no evidence of transactions recorded
by branches being altered through 'remote access' to the
system. Transactions as they are recorded by branches
cannot be edited and the Panorama programme did not show
anything that contradicts this."
So if that is the Post Office's quite forceful
public position, it is completely unrealistic to expect
that even if a postmaster did get --
A. My reports have not been concerned with Post Office's
public position.
Q. But it is very unlikely that a subpostmaster or
subpostmistress in a difficult situation, even if they
were to get the necessary data provided to them, they
would not expect to look for that, would they?
A. As I say, this document and the considerations of
Post Office's public position have not entered into my
opinions.
MR JUSTICE FRASER: Mr Green, I think you are probably
crossing the line into submissions or arguing the case.
The only question really you could properly put I think
further to Dr Worden is: that statement says:
"Transactions as recorded by branches cannot be
edited ..."
On the basis of your expert knowledge as at today,
does that statement match your knowledge of the system
or not?
A. Transactions as recorded by branches go into the audit
store and they cannot be edited.
MR JUSTICE FRASER: In the audit store.
A. Well, they cannot be edited. And if they are edited
then -- I mean, the DBA can do anything, and we can't
say anything can't be done. So something could go into
BRDB, into the audit store, and then the BRDB version
could be, in principle -- on the basis of this expert
joint statement something like that could happen, but
then you see a discrepancy between the BRDB and the
audit database.
MR JUSTICE FRASER: Yes. But it is the audit database
information -- my understanding is, and tell me if I'm
wrong, it's the audit database information that can't be
edited.
A. Yes.
MR JUSTICE FRASER: There are different ways that the
transactions entered in the branch can be changed on the
BRDB, is that right?
A. My view is that on the BRDB there has to be somebody who
can do anything you like, because if Post Office went to
Fujitsu and said "We have got this problem with BRDB",
and Fujitsu said "We can't do that, we have thrown the
keys away", that would be wrong. So the experts can't
say anything could never be done.
But nevertheless the audit database is -- it is
a bit of a misnomer, it is not a database, because audit
records are sealed and not modifiable.
MR JUSTICE FRASER: I understand.
Mr Green, I don't see any help to me in you arguing
those sorts of submissions with an expert in IT.
MR GREEN: I understand, my Lord.
In relation to the uses of APPSUP itself, the APPSUP
role, just to clarify, the privileged user logs didn't
exist pre-2009, that is right, isn't it?
A. I'm not aware of any. Some record probably existed of
privileged user activity but it has not been disclosed
as far as I know.
Q. There is no disclosure of any privileged user logs
pre-2009?
A. Well, "the logs". But I'm saying I don't know that some
other form of record didn't exist. Generally I would
expect, a DBA doing special things, there to be some
record of his doing it.
Q. But the APPSUP role is a role that everyone at SSC
enjoyed?
A. But that's not DBAs.
Q. No, I'm asking you about use of APPSUP by SSC.
A. Yes. Fine.
Q. And the privileged user logs who would capture that
don't exist pre-2009, as far as we know?
A. Privileged user logs, do they capture APPSUP use? I'm
not sure. Privileged user logs are very difficult to
interpret. They are much worse than MSCs.
Q. I was coming to that point. But what had been called
the Privileged User Logs did not exist prior to 2009.
That is not meant to be controversial --
A. No, I do not think it is controversial.
Q. And they only recorded log in and log off until 2015?
A. From the ones I looked at the distinction wasn't so
clear, because what you would get in a day's privileged
user log was thousands and thousands of accesses, most
of which were system accesses, and scattered amongst
them you would see one or two accesses obviously from
a real person and those accesses would record typically
the name of one database table and I found that very
difficult to interpret.
Q. Well, hitherto it has been thought to be common ground
that the only recorded log on/log off until July 2015
and thereafter were fuller, and you and Mr Coyne were
looking at the ones after that to see what was in them.
Do you know or are you just guessing?
A. I can't recall precisely but I thought I had seen these
single database table names in all sorts of years, but I
frankly haven't gone back to that because I got so
little out of the privileged user access logs.
Q. If we look at {E2/1/18}, it is Mr Godeseth's second
witness statement which you referred to in your expert's
report. It is page 18 of that witness statement. If we
look at 59.6 when he is explaining how privileged users
are recorded, if we start at 59.4 --
A. Yes.
Q. He says:
"Since July 2015 all access and actions carried out
by privileged users are recorded on an Oracle audit
table. The audit table records information including:
"(a) user ID;
"(b) action; and
"(c) date and time of the action."
Yes?
A. Yes. That's not quite consistent with what I have seen
in privileged user access logs.
Q. I'm just going to check whether your memory is right
because it is possible to make a mistake if you haven't
got them all in front of you.
Look at 59.6:
"Prior to July 2015 the log on and log off
activities by Privileged Users were audited. The process
was for a Managed Service Change (MSC) 14 document to be
signed off and for the log on and log off records to be
attached to the MSC."
59.7:
"The reason for the change in July 2015 was that the
BRDB was upgraded to a newer version of Oracle and we
took the opportunity to make the change then."
A. Yes.
Q. That strongly suggests that the privileged user logs
weren't available -- privileged user logs prior to 2015
did not have anything more than log on and log off on
them?
A. That seems to suggest that, yes. But as I say, I really
didn't go much into these privileged user access logs
for two reasons. One is I thought they were to do with
DBA activities rather than SSC and application
activities, and the other is when I looked at them
I would get very little out of them.
Q. If we look at {D1/5/10}, please. Item 11.3 is:
"The logging of Privileged User Access (in PUA logs)
commenced in October 2009."
A. Yes.
Q. And you agreed that with Mr Coyne?
A. Yes.
Q. You also agreed that:
"Between 2009 and 2015 these logs only displayed the
fact that a privileged user had logged on or off but not
what actions they had taken whilst the privileged user
was logged in."
You agreed that?
A. Yes.
Q. And then:
"The use of the transaction correction tool cannot
be seen in these logs."
A. Yes. What I'm saying now is -- I agreed with that. My
memory of what I saw on the pre-2015 ones is unclear.
Q. You and Mr Coyne have agreed also that the privileged
user logs are hard to understand and not a useful source
of information, haven't you?
A. Is that somewhere?
Q. Let's have a look, please, at --
A. It is 11.5.
Q. 10.1 on page {D1/5/4}. Sorry you have agreed; you have
said --
MR JUSTICE FRASER: Where are we going?
MR GREEN: The foot of 10.1 on {D1/5/4}. You say,
penultimate bullet point, or second bullet point down
there:
"The privileged User Access logs are not a useful
source of evidence about remote access, including
balancing transactions."
A. Yes.
Q. You say the same about the managed service change logs?
A. Yes. I'm less clear about that now having looked at
those more recently.
Q. In fact when we saw the problem in the 2011
Ernst & Young letter in relation to the consents to
change not being recorded, do you remember the 10 and
the 5?
A. The 10 and the 5?
Q. Yes, Ernst & Young in 2011 did 10 -- looked for 10
approvals and found they --
A. Right, okay.
Q. -- hadn't been retained, and five others and those
hadn't been retained either?
A. Yes.
Q. The change approvals are supposed to be in the OCPs and
OCRs, aren't they?
A. I'm slightly unclear how the OCPs, OCRs and MSCs
overlapped in time, but generally you're right.
Q. They ought to be somewhere in those records if the
system is being documented properly?
A. I think that is right, yes.
Q. Now no one identified the APPSUP role to Mr Coyne, he
had to find it for himself. And if we look at his
second report at {D3/4.1/85}, it is paragraph 3.279,
page 85. It is 3.279.
A. Right. So this is that PEAK we have been to.
Q. Yes. He set out quite a lot of text there, yes?
A. Yes.
Q. And over the page {D2/4.1/86} at 3.281:
"... I can see that the APPSUP user group was used
2,175 times between 2009 and 2018 with user names
ACHAM01, JCHAR01, CTURR01, GMAXW01 and others."
A. Yes.
Q. And we know, don't we, that those appear to refer to
Anne Chambers and Mr Maxwell and so forth from SSC?
A. Yes, we do. And this is approximate -- I haven't done
a big survey of PUA logs, but the numbers are consistent
actually that one day's PUA log is a huge thing, it
usually has one or two real people in it, and I think
this 2,000 times in ten years is about one person per
working day, so it all fits.
Q. It all fits and you are content with that.
In response Mr Godeseth in his third statement at
{E2/14/6}, paragraph 19, you have at the top of the
page, he confirms there what the APPSUP role allows. He
says:
"Paragraph 3.277 describes the APPSUP role and
refers to a Peak in which there is a general discussion
on the level of permissions required by SSC staff to
fulfil their role. APPSUP is the more technically
accurate name for a role with privileged User access to
the BRDB and other parts of the system. Although the
APPSUP role could theoretically be used to inject, edit
or delete transaction data this Peak does not provide
any evidence of this actually happening. It is
discussing the administration of the APPSUP role rather
than its use in a particular situation to change live
transaction data."
Now, two points. A perfectly fair description of
what the PEAK is doing?
A. Yes.
Q. Which we have looked at, and a perfectly clear
description of what the APPSUP role does?
A. Yes. I mean I haven't deeply investigated the APPSUP
role, so --
Q. And if we look at Mr Parker in his third statement at
{E2/13/3}, at paragraph 13 he is commenting on its use.
A. Yes.
Q. He says:
"It is not a distinct or new type of remote access
..."
And refers across to Mr Godeseth.
A. Yes.
Q. And he says at the bottom:
"Those logs suggest that the APPSUP role has been
used 2,175 times to make emergency ..."
And if we go over the page {E2/13/4}.
A. Sorry, that's what Mr Coyne said?
Q. No, this is what Mr Parker is saying in response.
A. I didn't find the 2,000 number before we flipped.
Q. Sorry, let's go back. {E2/13/3}
A. Ah, "he says", yes, okay. So Parker referring to Coyne.
Yes.
Q. He says it has been used 2,175 times to make emergency
amendments to the BRDB.
{E2/13/4}
"This appears to assume that APPSUP is only used for
emergency amendments - an assumption which appears to be
drawn from his reading of Peak PC0208119. However, this
is an administrative Peak which concerns one topic
(changing the generic role for SSC database users, which
affected the running of development delivered scripts).
It does not refer to a particular support action on a
live branch."
Now, it is an administrative PEAK that he has
referred to, but neither Mr Godeseth nor Mr Parker had
consulted the transaction logs, we know that -- the
privileged user logs?
A. Had they not?
Q. No. And you tried to and agreed with Mr Coyne that they
are not very helpful. That's where we've ended up.
A. Yes, but I mean I would understand Mr Parker knows what
goes on in the support because he is important in SSC
and has a feel for what SSC does.
Q. So even in a situation where there is litigation and
multiple witness statements have been served, Mr Parker
and Mr Godeseth don't look at them, you look and see
they are not useful, and that overall situation is
because they don't really show clearly an answer to the
question of what this was used for?
A. Yes, and I was always confused by the fact that most of
these privileged user logs were about some system
access.
Q. I understand.
A. System to a system, and I couldn't get to the bottom of
what that -- in the time I devoted to it, I couldn't get
to the bottom of that.
Q. And if there's not a clear documentary record of what
the use is, it is very difficult for there to be proper
scrutiny or audit of that?
A. That's assuming that PUA logs are the only documentary
record.
Q. Well, we haven't seen any other, have we?
A. We haven't.
Q. So that was invented in the hoof?
A. I'm not inventing on the hoof, I was simply stating
an uncertainty I have. I'm not trying to --
Q. There might be all sorts of things but let's focus on
the evidence we have got.
A. Generally Horizon is big and complicated and there are
all sorts of things.
Q. If the documentation is the privileged user logs we have
got, there isn't really any proper basis, even when they
do come after July 2015, properly to scrutinise what the
tool is being used for or to audit its use?
A. Absolutely. From the disclosed evidence that is
correct.
Q. Now let's move to DBAs. You have touched on them
already. They can edit, delete and add as you have
already said. That's obviously both in Legacy and
Horizon Online for reasons you have already given.
A. Yes.
Q. If we go to {Day8/44 12}, if we look at page 44, line 12
it says:
"Question: You would agree that those people have
the role which allows them privileges to update, delete,
or insert into branch database tables whether they are
using the correction tool or not?"
A. Yes.
Q. And he says, this is the DBA role:
"Answer: Those people could log on to the database
and do an awful lot of damage."
A. Yes.
Q. And you agree with that?
A. Yes.
Q. If we look at re-examination on Day 8 --
MR JUSTICE FRASER: Is this of Mr Godeseth?
MR GREEN: Of Mr Godeseth {Day8/112:1}
A. I should say in my experience DBAs can do an awful lot
of damage.
Q. Yes. Page 112 at line 14:
"Question: And 'UNIX user', who would the UNIX user
be?
"Answer: Oh, sorry, UNIX user would be one of the
guys in Ireland."
A. Yes.
Q. So the DBA's role is the guys in Ireland as referred to
by Mr Godeseth?
A. Yes. This implies to me that some of the DBAs are in
Ireland, I don't know if they all are.
Q. You don't know where they are really?
A. No.
Q. And you haven't met them?
A. Certainly not.
Q. You don't know how trustworthy they are?
A. I just do not know them as individuals. I presume that
to get to that job you have to be pretty good.
Q. And one of the guys in Ireland, if you look down, you
can see that on the top of page 113:
"Question: Who are the 'guys in Ireland' exactly?
Could you just clarify -- I appreciate that this may not
be your daily fare but~...
"Answer: They are the people who support the
hardware, so UNIX is an operating system so they work at
a pretty low level on the systems.
"Question: When you say 'low level', I mean what do
you mean by that? Do you mean they have powerful user
rights, or they have weak user rights or ..?
"Answer: They have pretty powerful user rights, but
they are very -- very much driven by process as to how
they use them."
A. Yes, I should say here that they are the people who
support the hardware. That feels to me like a different
level from the DBAs.
Q. So that might be another -- so the UNIX people might be
on another level from the DBAs?
A. Yes.
Q. In a sense we may have three layers?
A. Yes, I am sure we do.
Q. Now, just before we break for the stenographer who has
asked to go a little later, can we just deal briefly
with OCPs and MSCs. You heard Mr Coyne say he had
reviewed the OCPs and identified that 7% were created
retrospectively, did that come as a surprise to you?
A. It was, and I have since investigated myself.
Q. Was that about right?
A. The investigation I have made, I did a search of the
OCPs for all those that mentioned "retrospective" and
there are 1,600 of them, that's about 7%. I also did
a search for all those that mentioned "retrospective"
and "FAD" and you come to about 40. So the OCPs
referring -- of these 7% of OCPs, I drew the conclusion
that the great majority were back end, and I checked
a few of them they are back end changes, and only the 40
referred to changes made at the branch.
Q. And you understood that OCPs would be raised by one
person and I think monitored by a different person, so
you have four eyes?
A. There is a lot of this separation of duties, four eyes
thing, yes.
Q. Let's look quickly at {F/292.4/1}. This is an OCP on
1st September 2005.
A. Yes.
Q. You can see, although we do see different names under
"Other details" on other OCPs, on this one we can see
Martin Harvey and Martin Harvey at the bottom.
A. Raised by, monitored by.
Q. So he is monitoring himself it looks like?
A. It appears to be.
Q. Let's just look and see what this actually is. It is a
"Bulk insert to tps_pol_fs_summaries_incomp table".
A. Yes.
Q. It says:
"Products 2542 & 2541 had missing mappings which has
caused several hundred branch details to not balance to
zero."
A. Yes.
Q. "The ref data has now been corrected and the balancing
transactions have been extracted and now need to be
loaded into to tps_pol_fs_summaries_incomp so the BLE
file can be generated and sent to POLFS."
A. Yes.
Q. He is correcting a balancing problem because of missing
mappings which is affecting several hundred branches?
A. Yes. The table named "tps_pol_fs summaries" implies to
me it is to do with TPS transaction processing system
which is pushing stuff over to Post Office, not directly
affecting branch accounts.
Q. Well, on any view, it says there that it is caused
several hundred branch details to not --
A. Yes, but the branch details are not in the BRD. Branch
details are held all over the place, including back end
and POL systems. By the reference to "tps",
I understood this to mean branch details in the back end
or in POL.
Q. But on any view, it is hundreds of branches and he
appears to be monitoring himself?
A. Yes, I --
MR GREEN: My Lord, is that a convenient moment?
MR JUSTICE FRASER: Let's have the answer.
MR GREEN: Sorry, I thought he said yes.
MR JUSTICE FRASER: I thought you were about to add
something.
A. Nothing real, just it does appear to say he is
monitoring himself.
MR GREEN: Is that a convenient moment?
MR JUSTICE FRASER: Yes, we will have the 10-minute break.
Come back in at 3.20 pm.
(3.10 pm)
(A short break)
(3.20 pm)
MR GREEN: Dr Worden, could we look please at {F/485.2/1},
that's an OCP for 2nd March 2009.
A. Yes.
Q. It is to insert corrective transactions at a branch,
yes?
A. Yes.
Q. That's the title. Just look over the page, please, at
{F/485.2/2}. This is under "Other details". And
Dr Worden, I acknowledge that there are lots where the
people are different, but you can see there "Raised by:
Anne Chambers" and "Monitored by: Anne Chambers"?
A. Yes.
Q. If we look at {F/540.01/1}.
A. "Purge Migration Prep Data". That is familiar.
Q. And if we look at page {F/540.01/2} of that, we see it
is "Raised by: Anne Chambers" and "Monitored by:
Anne Chambers"?
A. Yes.
Q. Last one, {F/616.1/1}. This is an OCP for
14th April 2010. This is the branch "unable to
rollover". If we kindly turn to page {F/616.1/3} of
that OCP, do you see --
A. Here we go again, yes. Right, same person.
Q. -- "Raised by: Mr Ramachandran" and "Monitored by:
Mr Ramachandran"?
A. Yes.
Q. And so it is certainly not recording the four eyes that
are involved in that respect in the way that you'd
expect it in all cases, is it?
A. No, it isn't.
Q. If we look at Mr Godeseth's statement in relation to the
balancing transaction tool {E2/1/16}. Do you see there
at paragraph 58.5 he says:
"As far as I am aware there has only been one usage
of the tool."
A. Yes.
Q. Now, if we look at {F/425/1}, we have got the low level
design --
A. Yes.
Q. -- in draft. Do you see "Document status: draft",
halfway down?
A. Yes, absolutely.
Q. Can we just pause there. This is a more general
question about IT system documentation generally. What
is in your experience the significance of developing
drafts and then having identified approved versions of
the documents?
A. Well, it is general good practice to do that.
Q. Why does it matter?
A. Well, a draft implies a review process and a refinement
process. An approval implies that review has taken
place.
Q. By the people who ought properly to review it?
A. Well, depending on how their system is, yes. There is
some structured system that says: here's how we do it
and here's how we review it and approve it.
Q. Would it be fair to say that in a well documented system
there shouldn't be frequent occurrences of people
working from draft documents that have not been
approved?
A. I think that's broadly true, yes.
Q. Let's look at this --
A. But -- well, IT life cycles are increasingly -- they
used to be a waterfall where you went through very
serious document stages and signed off each stage and so
on. IT life cycles have become much more iterative and
the overlap between the phases means that people do
things on a draft. For instance, there is much more
iterative development where you develop a prototype you
and refine it. So the style of IT development has
changed over the years to the extent that one overlaps
the phases much more than the old-fashioned waterfall
life cycle.
Q. That's probably changed quite a bit over the last ten
years, is that fair?
A. Yes, depending on different organisations, they have
taken it up in different ways. But the modern tenure is
actually 20 years really.
Q. This document is from 2007 and this is the low level
design for the transaction correction tool?
A. Yes.
Q. And if we go to page {F/425/8}, please. It says:
"This document provides the low level design for the
branch database transaction correction tool module."
A. Yes.
Q. "The utility will allow SSC to correct transactions by
inserting balancing records to
transactional/accounting/stock tables in the BRDB
system. It will also audit the changes made. There
will be no updating/deleting of records in the branch
database."
A. Yes.
Q. And then underneath:
"Warning: the use of this powerful tool has inherent
risks. If the SQL statement is incorrect or badly
written, it is possible to cause unintended
consequences, some of which may cause serious problems
to the branch database. It is expected that only
a small number of skilled staff will run this tool and
that they will have detailed guidance as to when and how
to use the tool."
A. Yes.
Q. So pausing there. The existence of this document and
the development -- careful development we see here of
the tool shows, firstly, that there was a need for the
tool?
A. Yes.
Q. Secondly, there was a recognition that it was a powerful
tool?
A. Yes.
Q. Thirdly, that because it was a powerful tool there was
a need for protections?
A. Yes.
Q. In the form of a limited number of people able to use
it, yes?
A. Yes.
Q. And clear guidance?
A. Yes.
Q. We also see, I think you know, that there is a table,
journal table to which it writes so its use can also be
audited?
A. Yes.
Q. We have seen from the Anne Chambers' comment about
wanting to go off piste with APPSUP that the APPSUP role
was valued by SSC, including by Anne Chambers. We have
seen that from the PEAK?
A. They felt they had to use it, yes.
Q. And the APPSUP tool was even more powerful because it
was unbounded as to which tables it could access?
A. I think so, yes.
Q. And it didn't have those protections?
A. I think you are right, yes.
Q. And Mr Coyne identifies this in his second expert report
at {D2/4/244}.
MR JUSTICE FRASER: Do you mean 4 or 4.1?
MR GREEN: My Lord, actually I have got the wrong reference
here but I think it is the same in both.
The short point is that we can see that -- perhaps
the easiest place to look at it is {F/594/1}. This is
a 2010 PEAK --
A. This is a BT, is it?
Q. -- which was to be created. This is a PEAK to amend the
tool.
A. Yes.
Q. And --
A. Well, more precisely to amend the templates, I think.
Q. To amend the templates. Well, the point is if there was
no perceived use for the tool in future it would be
surprising to spend a lot of time and effort developing
a template for its use?
A. Well, there are lots of templates, there are several
templates, and the previous document was referring to
the precision required in the SQL. That was the
precision in the templates rather than the tool itself
which just ran the templates.
Q. The short point is that a tool was -- the transaction
correction tool was carefully designed to meet a need,
it is common ground that that specific tool was only
used once?
A. Yes.
Q. And it is fair to infer that there would have been
occasions when that tool could have been used and the
APPSUP tool was used instead?
A. I want to be careful about that because they would only
go off piste, as Anne put it, when they really had to.
Q. How do you know that? That's speculation.
A. In one of the two interpretations, I think Fujitsu/SSC
staff would not want to do a labour intensive support
task if they had a tool to do the job, or templates to
do the job. That's the inference I'm making.
Q. The APPSUP role gave them a freedom they didn't enjoy
with using the transaction correction tool itself,
didn't it?
A. And it gave them a freedom that I infer they didn't want
to use more than they had to.
Q. Let's look at Mr Coyne's revised report at {D2/4.1/247},
please. If we look at paragraph 5.438.
A. Yes.
Q. He says in his opinion:
" ... it is my opinion that more than one BT has
been conducted ... for the following reasons."
Yes?
A. Yes.
Q. And he says the tool was created on 12th March.
A. The PC was created -- the PEAK was created.
Q. I'm so sorry, the PEAK was created on 12th March which
relates to the transaction tool. He says it has now
been used in live:
"The templates for use with this tool need to be
updated to correct some details. Gareth Seemungal is
aware of the corrections needed …"
A. Yes.
Q. "… The proposed fix would correct and update the BRDB
transaction correction tool templates, making it less
likely that mistakes will occur when SSC are trying to
resolve problems with transactions in BRDB."
Yes?
A. Yes.
Q. He says:
"This suggests that modifications and balancing
transactions conducted by Fujitsu support staff within
the BRDB is not unusual."
A. Well, I think that the transaction correction tool was
made to make a number of changes with different
templates to the branch database, most of which were not
transaction corrections.
Q. And you wouldn't disagree that it is a fair opinion for
Mr Coyne to have formed, what he said there?
A. As I said, the uncertainty in my mind is that there were
several templates and they were doing different things
and you only need one template to do a transaction
correction.
Q. We have seen what the purpose --
A. The low level design says it can do this table and that
table and so on.
Q. And the tables we saw would affect branch accounts?
A. No, there are a lot of tables there different from the
ones used in the one BT.
Q. You were able to use it to access tables that would
impact branch accounts, weren't you --
A. Certainly.
Q. And he says in his report, at (ii) he says:
"Fujitsu were able to insert balancing transactions
outside of utilising the branch correction tool referred
to above."
Yes?
A. I'm not sure what he is referring to there.
Q. If they used the APPSUP role they could do so. We have
agreed that.
A. We have agreed but if they have got a tool to do it, to
hand-craft some SQL to do it would be very time
consuming, and why would they want to do it if they had
a tool?
Q. What do you infer from the fact that a tool was not only
carefully developed to meet a need but also had its
templates revised but only appears to have been used
once for that purpose?
A. It was only used once for a balancing transaction, but
I think it was used other times for these other purposes
involving other tables.
Q. Is that something you specifically have seen or
conjecture?
A. It is not conjecture. Unfortunately my memory is a bit
unclear but I have seen -- I mean, for one thing the low
level design talks of other tables, other than the ones
used in the BT. That's the first piece of evidence.
And it talks about templates in the plural whereas one
template would have been needed to do a balancing
transaction. So that is the second piece of evidence.
Now the third one, I think somewhere I looked at
some records of how it was used and found there were
these other uses not to do with affecting branch
accounts.
Q. You are not sure what that was?
A. I'm not sure of the third piece of evidence. I am sure
of the first two.
Q. What we can say fairly is from the discussion in the
PEAK, the APPSUP PEAK, they clearly did very much value
having the APPSUP role?
A. Yes, they needed it sometimes.
Q. Can we look at a document which is dated 24th May 2019,
so it is obviously a recent document. It is at
{F/1848.8.3/1}.
There is absolutely no complaint whatsoever about
this being provided on 30 May, because it is a document
dated 24th May, but I mention the date it was
provisioned. Dr Worden, had you had a chance to look at
this or not?
A. I haven't looked at this. I do not think I have. It is
not familiar. I have tried to read a lot lately.
Q. It is a global user process management document.
A. Yes.
Q. It says:
"A process called Global User was brought in to
replace the One-Shot (single use) password process used
on Horizon. It allows roles in the business, such as
auditors, to be able to go out to any branch and use the
same log on to access any Horizon kit in Branch without
having to request a single use password at each branch."
A. Yes.
Q. "The individual requiring a Global User account has to
be approved by a Manager showing on the Global User
requester and approver list."
Yes?
And you see "Issue identified" by PwC. It says:
"PwC identified during an audit that the current
Global User list inherited from Fujitsu contained
employees who had left the Business. This raised
concerns over the security of access to Horizon.
Although this is a low risk in terms of Horizon access
(the individual would have to gain access into a Branch
first), it is still a risk and needed to be mitigated."
Do you see that?
A. Yes.
Q. Then the actions taken, second bullet point:
"32 individuals were identified as having left the
business."
But to be fair, half of these had only recently left
in April 2019. Yes?
A. Mm.
Q. Then under "Next Steps":
"There is no current owner of the process. NBSC
administer it but the actual Global User process to
maintain the data has not been owned by any area for
some years."
A. Yes.
Q. Pausing there. Let's start at the top, is that ideal?
A. It doesn't sound ideal, no.
Q. It is not great access control, is it?
A. Something has fallen between the cracks, yes.
Q. Dr Worden, just a more general point. It is right,
isn't it, that when something has been identified
correctly as a system problem and fully investigated, we
are likely to see more documentation about that than we
would otherwise?
A. Do you mean a system problem or a process problem like
this?
Q. Ignore process. We are back into system.
A. Right, okay.
Q. So on a PEAK or something like that. And I think to be
fair to you, I think there are circumstances in which
PEAKs will be generated by SSC where their own records
tell them that there has been a problem like a failed
reversal or something like that?
A. You are talking about records other than the PEAK?
Q. PEAKs or KELs, yes.
A. Yes.
Q. And the broad point is the more investigation that's
done and the better the problem is recognised as
a system problem, the more documentation we are likely
to see about it?
A. Well, I mean, Fujitsu's incentive when a problem arises
is to fix it as soon as possible. If they can fix it
simply then we won't see as much documentation as if it
is difficult and takes a lot of different investigation.
Often in PEAKs we see investigations going around the
houses and so on.
Q. Finally, Dr Worden, can we just look at your declaration
at the end of your first report, please. It is on
{D3/1/260}. At 1194 you have referred to guidance in
a case at the end of that paragraph.
A. Yes.
Q. Was that something that -- was that case something you
had looked at on your own initiative?
A. Not on my own initiative, no. I was pointed towards it.
Q. Did you identify the reference to that case and the case
report reference?
A. No, the document was supplied to me.
MR GREEN: Thank you very much. My Lord, I have no further
questions.
MR JUSTICE FRASER: All right. Mr de Garr Robinson, some
re-examination?
MR DE GARR ROBINSON: Yes, my Lord.
Re-examination by MR DE GARR ROBINSON
MR DE GARR ROBINSON: I would like to start, Dr Worden, by
asking you a few questions about your scaling
calculation.
A. Yes.
Q. This was covered on Tuesday. You were taken to
{F/1837/1}, so I would like to look at that, please.
A. Yes.
Q. The questions you were asked focused on columns E and F
of that table. Do you remember?
A. E and F, "2007" and "2007 Gaps".
Q. Yes. You explained, when you were asked how you had
arrived at your calculation in your first report, that
you took a column for 2007 which you knew had gaps,
having looked and seen that the gaps were not
significant, do you remember that?
A. That is right, yes.
Q. I think you called it eyeballing?
A. Yes.
Q. For your Lordship's note, this is at {Day18/196:1} to
page 198.
And at one stage it was put to you that you had
given false evidence about what you had actually done in
that calculation, and the premise upon which this was
put to you is that ...
This is different from the table I have just seen
(Pause)
What I asked to look at was {F/1837/1}.
A. The gaps has gone. It seems to be empty now.
Q. There we are. So we are at 1837. You see there is
a column which says "2007" and there is a column which
says "2007 Gaps". One of those columns is complete and
one of those columns has gaps in them. And what was
suggested to you was that given there were two columns
with these figures, with this configuration, one
complete and the other with some gaps in, you cannot
possibly have chosen to take the one with the gaps in
without making a mistake. Do you remember that?
A. I remember that, yes.
Q. And it was suggested that your explanation as to what
you had done couldn't be right. I would just like to
explore that surprising suggestion briefly.
As Mr Green said at page 176 of the transcript, the
spreadsheet we are looking at is an amended version of
the original spreadsheet that Mrs Van Den Bogard
actually referred to in her original statement. Do you
remember that?
A. I do yes.
Q. And the amended version, the version we are looking at
now, was produced in January.
A. Yes.
Q. So when you were doing your first report the spreadsheet
was different and it was disclosed with Mrs Van Den
Bogard's witness statement in November. For
your Lordship's note, that is at {H/137/1}.
Can we now go, please, to the document you may have
taken me to, which is {F/1837.1/1}. If we could go to
the top of that document, please.
You will see that column E says "2007" and column F
says "2007 Gaps", and it is column F that every now and
then contains an item.
A. Yes. And when there is a gap in E there is an item in
F.
Q. Perhaps we can scroll down a little bit until we see
one. There are not very many of them. We can stop now.
If we look at row 74 there is a figure of 6.
A. Yes.
Q. Is this the document that you used at the time you
produced your first report?
A. I think it was, yes.
Q. And when you said you eyeballed these columns, do you
recall what columns you eyeballed?
A. All columns, I presume, I think I eyeballed all columns.
And what is evident to me now is that where there is
a gap in 2007, the figure in "2007 Gaps" is taken over
from 2001 or whatever it may be. But my impression on
eyeballing was that there weren't many gaps.
Q. There weren't any gaps or --
A. There weren't many gaps.
Q. So you chose to take the figures in column E?
A. This was a long time ago and it has kind of been
superseded by the supplemental report where I did it
more properly.
Q. Can I just ask you what your reaction is to the
suggestion that you made a stupid mistake and should
actually have taken column F as your means of
calculation?
A. Well, obviously column F is not the column to take,
that's blindingly obvious.
Q. Thank you.
Now I would like to ask you about some questions you
were asked yesterday regarding ARQ requests. You gave
evidence, and this is at {Day19/17:1} onwards, that you
have always been aware that cost of requests over the
annual allowance of 720 ARQ requests was in the ballpark
of £250, do you remember that?
A. Yes.
Q. Now several things were suggested to you when you said
that. First of all, it was suggested that, in fact, the
true cost was £450. Secondly, it was suggested that
this is important because, as far as I could understand
from the line of questioning, £200 plus cost involves no
particular disincentive to make ARQ requests but a £450
cost creates a disincentive, and because of that it was
suggested it was quite misleading to talk of a figure of
over £200.
Stopping there, Dr Worden, I do not think you had
talked about a figure of £200. Is that something you
discussed in either of your two reports?
A. I do not think I did. The point which always occurred
to me and seemed to me obvious is if you are doing
100,000 TCs a year, to do any cost of £250 for each one
of them is ludicrous.
Q. I actually think that the point was intended to be
a criticism of me because I put that figure to Mr Coyne
in cross-examination and he agreed it.
The fourth point is that it was suggested to you
that when you said you thought the cost was in the
region of £250, you had no foundation for that figure
and you were simply giving answers which you thought
were consistent with Post Office's case rather than the
true facts, do you remember that?
A. I do I think, yes.
Q. So it is a serious allegation, an attempt to impugn your
veracity. You said that you had seen documents but
could not remember the particular document.
A. Yes.
Q. I don't know what documents you have seen but I wonder
whether the document I'm about to take you to might be
the one. Could we go to {F/1659.2/1} please. This is
a document which has been added to the trial bundles
overnight. There was no expectation that there be any
line of questions on this particular issue, so no one
thought to put this in the trial bundles originally.
Dr Worden, this is part of a contract between
Fujitsu and Post Office. If you look at page 1 you can
see the various different versions of that contract.
The earliest one on this version is 31st August 2006.
If we go over the page to {F/1659.2/2} we see what
I think is the current version, 12.0 on 3rd July 2017.
Now, I'm not aware of any clause in a contract between
Fujitsu and Post Office saying: if you go over the 720
ARQ allowance you pay X. Instead what I'm aware of is
an option to increase the allowance so as to allow you
to go over the 720 threshold. That option is provided
for on page {F/1659.2/689} perhaps we could look at
that.
MR JUSTICE FRASER: Have you seen this document before
Dr Worden?
A. I have not seen this, no.
MR DE GARR ROBINSON: Have you not?
A. No.
Q. If we look at paragraph 5.5 perhaps I could ask you to
read that Dr Worden.
(Pause).
A. Yes, read it.
Q. So you will see that there is a reference there to
a cost, if Post Office wishes to increase its allowance
of 720 ARQ request, you will see that the cost is
provided for £222 odd a day.
A. Yes.
Q. That was where my question to Mr Coyne came from, the
question which he accepted when I put it to him. But
the question I want to ask you, and it may be that you
have already answered it, is that might this be the
document from which you formed the impression?
A. I do not think it was actually. I think I have seen it
in several places, numbers of that ballpark and I'm
afraid I can't recall what those documents were.
Q. Very good. Let's move on to --
MR JUSTICE FRASER: I didn't mean to steal your thunder by
asking him if he had seen it before.
MR DE GARR ROBINSON: My Lord, I'm in a very forgiving mood,
so we will say nothing more about it.
Callendar Square. I will just ask a few questions
about Callendar Square. Mr Green took you to the
original Callendar Square PEAK with a view to looking at
how the story developed.
That was a PEAK that was I think started -- it was
opened on 15 September 2005. Then he asked you about
how long the Callendar Square bug had been in the system
and you agreed with him that it was since about 2000.
Do you remember that?
A. I agreed that the cause in Riposte had been May.
Q. The impression may have been given that the bug lay
undetected until the Callendar Square PEAK appeared and
I would like to ask you about that.
First of all, Mr Green drew your attention to
a document at {F/312.1/1} if we could go to that. You
will see at the top of the page this refers to
Callendar Square. It is dated 16/11/05. It refers to
Alan Brown, who I think is the subpostmaster of that
branch.
He says:
"PM HAS £3,800 THAT SYSTEM IS TELLING HIM HE MUST
SETTLE BEFORE HE CAN ROLL OVER. THIS IS FROM 8 WEEKS AGO
& IS DUE TO A WELL DOCUMENTED HORIZON SYSTEM PROBLEM.
CAN AIO CONTACT WITH REGARD TO THIS? SAYS AIO KNOWS
ABOUT IT HAVE TOLD PM HE MUST SETTLE."
The reference to "this is due to a well documented
Horizon system problem", what do you infer from that
about whether this bug was undetected or not?
A. This confirms other evidence I have seen that Fujitsu
were getting at Escher to fix this Riposte problem and
that was an ongoing debate between Fujitsu and Escher
and at one stage Escher said they had fixed it and it
turned out it wasn't fixed, and so that went on for five
years.
Q. I see. If we go to your first report please. That's
{D3/1/155}. If you look at paragraph 660 at the bottom
of the page, this is where you start your analysis of
the Callendar Square bug. You indicate it is described
in two KELs and several PEAKs and you identify them
there.
A. Yes.
Q. "First arose in 2000 and was not fixed until Release S90
in 2006."
I notice you refer to a number of PEAKs there. Some
questions have been asked of you over the last three
days which might have given the impression that you have
only been looking at KELs. When you produced your first
report to what extent had you had regard to PEAKs?
A. In this bug particularly so because one wanted to trace
the timeframe, time progression and you can see from
these PEAK numbers that they are rather early ones going
back to 0075 and so on and so forth. PEAK numbers
(inaudible). So, yes, I have looked at PEAKs in this
respect.
Q. Just extending further beyond just the Callendar Square
issue, did you look at PEAKs relating to other issues?
A. All sorts of issues. I have done a lot of surveying of
PEAKs to get the feel for the bulk of them, the balance
of population and so on, and I have general views about
this type of PEAK, that type of PEAK and so on. There
are PEAKs about harvester exceptions, that's one sort of
thing. There is PEAKs about receipts payments
mismatches and I have looked at a large number of these.
Q. Have you looked at large numbers of PEAKs when you
produced your first report?
A. Not large numbers at the time of my first report, no.
It has been more recent.
Q. What sort of scale of numbers had you looked at at that
stage?
A. In my first report?
Q. Yes.
A. I would say I have looked at the ones Mr Coyne had
raised in his report and I had looked at probably
a couple of dozen in connection with KELs.
Q. Now, one of the KELs that's referred to here in the
context of Callendar Square is J Ballantyne 5245K.
That's at {F/285/1}. For your Lordship's note, KEL is
cited in row 2 of the bug table in JS2 which is at
{D1/2/3}. You see that?
A. J Ballantyne, yes. "Time out waiting for lock." It is
I believe the Riposte cause; another symptom of the
Riposte problem.
Q. You will see halfway down:
"Original date 2000-11-02."
So the KEL was created on 2nd November 2000, is that
right?
A. Yes.
Q. You say another symptom of the Riposte problem. Perhaps
you could explain a little bit what you mean by that?
A. Well, I did explain and I will explain it again. That
there is a problem in Riposte which leads to a failure
to replicate -- failures to release a lock I think --
and then on certain occasions that leads to a short-term
failure to replicate. On other occasions there is
a so-called event storm during which there is a longer
term failure to replicate and during these failures to
replicate all sorts of different things may happen, for
instance they double transfer into a stock (inaudible),
a precise Callendar Square phenomenon; whereas other
things such as system freezes, I can't remember all the
other details, but there are many other symptoms of
then underlying Riposte problem and they have been noted
over this whole period.
MR JUSTICE FRASER: This is what you referred to yesterday
as Riposte lock, is that right?
A. Yes.
MR DE GARR ROBINSON: If we go to page {F/285/3} of the KEL.
And we go to the bottom section under the heading
"Solution".
A. Yes, rebooting was the quick fix. Rebooting, Cleardesk
were the sort of recommended things to do.
Q. Now, what does this indicate regarding the question
whether this bug was an undetected bug or not?
A. It was certainly not undetected for a long time. I mean
it was detected very early on and different
manifestations of it came up over this period.
Callendar Square was just one manifestation.
Q. Let's look at a PEAK that relates to the bug. This is
one of the PEAKs that was referred to in Anne Chambers'
2015 spreadsheet. You remember that?
A. Right.
Q. It is at {F/224.1/1}. It starts on 8 October 2004 so
it is a year before the Callendar Square PEAK, yes?
A. Yes.
Q. Now is this a PEAK that you have seen before?
A. I believe it is. I have certainly seen many like it.
On the face of it, it is about something happening in
the host, ie at the back end, but it may well -- some of
these you look at and you find they actually derive back
to the branch.
Q. I see. So this is an indication of what was happening
on the ground some time before the Callendar Square PEAK
itself was produced. If we look at page {F/224.1/1}, do
you see it says in the first box underneath the second
line:
8/10/04, 10.59:
"The host generated cash account line Comparisons
Report.
TPSC256 for processing date 07/10/04 shows a R & P
diff for FAD 162824 in CAP 28 where Receipts =
£1149340.21, Payments = 1148956.69 and Diff = 383.52."
A. Yes.
Q. Could you explain -- are you in a position to explain
what TPSC256 means?
A. It is a back end report. Cash account line comparisons.
It is one of the back end reports to do with TPS, which
is feeding transactions to the Post Office, and
sometimes these transactions have to be fixed in various
ways before they can go to the Post Office.
Q. So this report is generated. To whom is the report
produced?
A. Fujitsu look at the report I think and if there are
problems Fujitsu try and fix them.
Q. If we go down just a few lines, it says about four lines
down:
"This FAD also appears on TPSC268A with a difference
of exactly half the amount."
There is a question as to whether it is related.
Could you say what TPSC268A is?
A. There are several TPS reports and it is quite a long
list, I cannot say precisely which one is which. But
they do give different slices of information which is
going to Post Office.
Q. So this is an example of the Callendar Square bug. If
we could go over the page to page {F/224.1/2}?
A. Sorry, could I just interject there that you see
a smallish receipts/payment mismatch. One of the
manifestations of the Riposte problem was that when you
were doing balancing, one of the counters in the branch
was isolated and say had been isolated for half an hour
or something, so the transactions from that counter
would not get into your balance so you would have
a small payment receipts mismatch and I think this is
probably one of those. Again it is not Callendar Square
exactly, it is the Riposte bug leading to a counter
being isolated for a short while.
Q. I see. If you go to over the page to {F/224.1/2} you
see about two lines down from the top:
"MSU need to inform POL so they can take appropriate
action."
Do you know what that signifies. Who is MSU?
A. Management Support Unit and obviously because this is a
TPS problem there will be some discrepancy in POL and in
the stuff going to POLSAP, for instance, that has to be
fixed.
Q. We will see that the PEAK is closed on 12 October, which
is four days later. What does this tell us about what
was happening on the ground in relation to
manifestations of problems relating to the
Callendar Square bug even before the Callendar Square
PEAK was --
A. It shows that some of them were being detected by
routine monitoring and, for instance, I would also
suspect that any manifestation of the Riposte bug which
led to a double stock transfer in and a single stock
transfer out, that is a double entry accounting failure
and that would certainly be picked up at some stage. So
there are a lot of ways in which this phenomenon would
be automatically detected or easily detected at the back
end.
Q. Let's look at that very point. If we can go to
{F/253/1}, this is another PEAK referred to in the JSC2
bug table in relation to Callendar Square, it is fourth
on the list. It is PC0116670. This PEAK starts on
24th February 2005. It is a good number of months
before the Callendar Square PEAK. We can see at the top
right-hand side "call logger/deleted user/MSU". Can you
explain what that means?
A. Yes. This is somebody in the Management Support Unit
has raised this problem. It is to do with this
reconciliation report which is another of these TPS
reports about what's going to Post Office.
Q. Then we can see that, can't we, in the first box, four
lines down:
"Summary TPS reconciliation report."
I was going to ask you what that means but you have
already told me. There is a reference also to some
particular TPSC numbers, 256, 252, 268A. Those are the
reports we have just~--
A. Yes. That's showing the same error is popping up in
several reports.
Q. What does this PEAK tell us about Fujitsu's awareness of
the issue that was --
A. Well, it says that several manifestations of the Riposte
problem were easily detectable by Fujitsu and they would
be. They had systems set up to detect just this sort of
thing.
Q. And the manifestation which produces the symptoms that
we now call Callendar Square, would they be picked up?
A. I said that the symptoms that now we call
Callendar Square are this double stock transfer in,
single stock transfer out. That is a double entry
accounting mismatch failure and that will certainly be
detected at the back end when it gets to POLSAP or if
not before.
Q. Let's have a look at one final PEAK that's relevant to
Callendar Square. This is one that you referred to in
your report and it is in the bug table as well. It is
{F/210/1}. Perhaps we can have a look at that.
What is the date? It starts 3rd June 2004. So we
are more than a year before the Callendar Square PEAK.
If we go to the bottom of page {F/210/2} there is what
I believe is a yellow box.
A. I don't get the colours.
MR JUSTICE FRASER: Do you not get colours on this?
A. Not on the screen.
MR DE GARR ROBINSON: I don't either.
MR JUSTICE FRASER: Really? I didn't know that. I suppose
a bit late to find out during re-examination of the
final witness of a trial that started in March but --
MR DE GARR ROBINSON: My Lord, it is never too late to
enhance the system. I feel that we can all agree that.
MR GREEN: There is colour on the far end.
MR DE GARR ROBINSON: I see that Ms Keating has
a beautifully coloured screen, but I'm not being bitter
about it. My Lord, if we could look at
page {F/210/2} --
MR JUSTICE FRASER: As you said earlier, you are in
a forgiving mood. I'm sorry you don't have colour,
Dr Worden, I didn't realise. Are we going to the bottom
box?
MR DE GARR ROBINSON: Right at the bottom box. I'm going
read the last two lines and then perhaps we could go
over the page when I get to the relevant point:
"Eventlog from node 4 suggests that Riposte
replication had not been successful and so while node 3
had successfully TI the txns, this information was not
apparent to node 4 thus it was perceived by node 4 that
those txns were outstanding waiting to be TI. Therefore
when the user SMU001 logged onto node 4, he was
presented with Outstanding Transfer message which had to
be accepted or declined. The user chose to accept them
even though he tells me that at this stage he was a
little concerned because he was certain that user ASU010
had already TI on node 3. This has created a discrepancy
on their Cash Account £22,290.00. Also the Host has
reported a reconciliation error in TPSC256 for
£44,580.00."
A. I did remark on that I remember noticing the exact
double figure.
Q. It is clearly a function of the different reports, one
picks up the right figure, there is another report which
doubles it for various reasons.
A. Yes.
Q. Now if we go down to the third page {F/210/3}. There is
an entry for 8th June 2004 at 14.48. It says~--
A. Errors in the three reports.
Q. Errors in TPSC reports 252, 256, 268A. This confirms,
I believe, the evidence you have already given, which is
the actual Callendar Square symptom we are talking about
is picked up by these reports, yes?
A. Yes.
Q. Let's see how it was handled. If we go to page
{F/210/5}. Box: 11 June at 16.30. It has been
transferred to MSU. Then if we go down further the
page: 22 June at 15.38 and it has been transferred to
EDSC. Why am I telling you those things?
We go over to page {F/210/6}. 6 July, 11.44:
"I've checked with Mike King; the BIMS report for
this problem was sent to POL on 22/6 and should have
resulted in an error notice being sent to the branch
Mike says he will send a note to POL saying that the PM
has been chasing this issue; I've asked HSH..." which
I think must be the help desk.
"... to inform the PM that they should have received
an error notice and to check with the department that
issues them."
Then if we go on to page {F/210/7} you will see
5th August 2004 at 11.57.
A. He's confirmed he got it.
Q. That's three boxes down:
"PM [Mr Mogul] has confirmed that POL have issued
him with an Error Notice of £22290.00 which has enabled
him to clear the error from his account. He is happy for
this call to be closed."
Now the evidence you gave when asked about it by
Mr Green is that regardless of procedure in the majority
of cases if there is an R&P mismatch it will be sorted
out eventually. Mr Green queried whether you had any
basis for saying that. Are the PEAKs we have seen
relevant to that view --
A. Yes, they are very relevant particularly this one, it
shows that it is picked up on three reports at the back
end. There is a lot of going back and forth, but end of
the back and forth is the BIMS and Post Office being
alerted and the branch being sorted out.
Q. Thank you. If we could now have another look. It was
suggested by Mr Green that the problem may have
persisted even after it was fixed by Release S90 in
2006. If we could go to the document that Mr Green put
to you for that purpose. It is {F/565/1}.
You will see the original date, it was opened on
10th May 2002, halfway down, do you see that?
A. 10th May 2002, yes.
Q. Immediately below that there is a revision date,
11 January 2010?
A. All right, okay.
Q. Perhaps we can go to the last page of this document now
{F/565/3} and we see what must be the reason for the
update. It is the very last paragraph:
"Update: 11/01/2010."
There is a reference to a PEAK:
"If the message was seen on a Correspondence server
and the source of the message is Riposte then raise a
Peak call and route it to SSC to stop and restart the
Riposte service under OCP. If the errors are seen on
more than one Correspondence server at the same time
then further investigations should be carried out."
It was suggested to you that that update may suggest
that the Callendar Square manifestation continued after
the fix in 2006. You can take it from me, I have looked
at the PEAK that's referred to here, and that is not the
manifestation of the Callendar Square bug. But what
I want to ask you is whether you were aware of any
incident after the fix of the Callendar Square bug, any
incidents in which the Callendar Square symptoms
occurred again?
A. No.
Q. Thank you. Now, today we had some rather extraordinary
questions about the derivation or where the word "grey"
came from and I'm going to ask you about that. It
starts in appendix D3 of your first report. Could we go
please to -- what is the reference? I'm afraid I have
not written it down.
It will be {D3/2/129}. You were asked about
paragraph 5.93. Do you see that? You were commenting
on particular paragraphs of Mr Coyne's first report
where he refers to particular KELs, yes?
A. Yes.
Q. If we go to your analysis, the middle paragraph you say:
"This was caused by a complex 'grey' communications
failure which could not be reproduced - so diagnosis was
not complete."
And you were asked where you got the word "grey"
from?
A. I imagine it may well be from the KEL.
Q. I was going to ask you. If we can go to the KEL, that
is at {F/757/1}. I will just let you glance down the
heading but I don't really need much of substance, just
to refamiliarise yourself.
A. Comms became available. Yes.
Q. If I could ask you to go to page {F/757/2}. Under the
heading "May 2010 Update by Development."
A. We have black and white immediately.
Q. It says:
"When comms are black and white, i.e. always on or
always failing, it is fairly straightforward to recreate
a particular situation. However the sequence seen in the
log files is so complex it is not possible to replicate
the conditions."
Now, having seen that text, does that refresh your
memory as to where the word "grey" might have come from?
A. So "grey" is not actually in the KEL, is that right?
Q. Yes.
A. Well, obviously black and white, grey is between back
and white, and it is exactly as I described it, as an
intermittent fault. Grey would be one way of describing
it and I would probably have made up that word myself.
MR DE GARR ROBINSON: Right. Would you give me a moment
please Dr Worden.
My Lord, I have no further questions.
Questions by THE JUDGE
MR JUSTICE FRASER: I have just got a couple.
Dr Worden, this afternoon you were asked quite
a long sequence of questions about privileged user logs,
do you recall that?
A. Yes.
MR JUSTICE FRASER: It was only at about 3.05.
A. Yes.
MR JUSTICE FRASER: In the course of that you confirmed,
I think, that you found the privileged user logs unclear
when you've looked at them, is that right?
A. That is right.
MR JUSTICE FRASER: In one of your answers you said you
couldn't get to the bottom of it in the time that you
had devoted to it.
A. That is right.
MR JUSTICE FRASER: Can you just give me an idea of how long
you had devoted to trying to --
A. Looking at privileged user access logs, less than a day.
MR JUSTICE FRASER: All right. But a reasonable number of
hours I imagine?
A. Yes.
MR JUSTICE FRASER: I don't want to put words into your
mouth if that's --
A. What they are is this monster spreadsheet that gives you
one day's worth of data and I looked around.
MR JUSTICE FRASER: All right. That's very useful. Thank
you very much.
There are a couple of questions but it relates to
the same event. Now, relatively recently you served
your third report directly on the court?
A. Yes.
MR JUSTICE FRASER: I'm not going to be asking you any
questions at all about the content of that document.
But I just want to ask a couple of questions so that
I can understand the sequence because I have already had
an explanation from Mr de Garr Robinson and I have also
had a witness statement from the Post Office's
solicitors.
A. Yes.
MR JUSTICE FRASER: The documents that you relied on in
order to prepare or compile or draft that report are
PEAKs, KELs, OCRs, OCPs, etc?
A. Yes.
MR JUSTICE FRASER: When did you first get access to those
documents?
A. Well, PEAKs was -- the full set of PEAKs I can't recall
the exact date, but it was way back in 2018 and the OCPs
and OCRs, again I cannot recall the exact date, but
I have had them for some months I think and the idea of
automatically searching them in this way came to me
comparatively recently.
MR JUSTICE FRASER: But the actual documents you had had
a number of months, is that correct?
A. Yes.
MR JUSTICE FRASER: Then, you have been a witness I think,
an expert witness, in a number of other cases?
A. I have.
MR JUSTICE FRASER: Have you ever served one of your expert
reports directly on the court before?
A. I have never done that myself before. I had it done to
me.
MR JUSTICE FRASER: But you have never done it before?
A. A kind of late report, no. I mean the issue of serving
direct on the court rather than through lawyers, I don't
recall how that happened in the past. I suspect it was
all done through lawyers.
MR JUSTICE FRASER: But in this case everyone knows you sent
an email to my clerk?
A. I did, yes. That's what I was advised to do, that was
how I was advised to do it.
MR JUSTICE FRASER: You were advised to do it?
A. By Post Office lawyers, yes.
MR JUSTICE FRASER: All right. And the email -- the
covering email, did you show the drafting of that to
your instructing solicitors before you sent it or did
you just draft it yourself?
A. I just drafted it.
MR JUSTICE FRASER: And did you check or have it approved by
them?
A. No, I think I had been given some advice as to what it
should cover.
MR JUSTICE FRASER: All right. Okay. Well I don't have any
more questions about that, thank you very much. I don't
know if either of you have any follow up questions on
that, but if you do it is not to go to the content of
the third report.
MR GREEN: My Lord, no. My learned friend gave some
evidence about having checked the PEAK himself, I expect
I'm not allowed to cross-examine him on it? Perhaps
I will save that for closing submissions.
MR JUSTICE FRASER: Regardless of how forgiving he might be,
I'm not that forgiving.
MR GREEN: I'm grateful.
MR JUSTICE FRASER: Although I'm relatively forgiving. So,
Dr Worden, that is your evidence at an end. Thank you
very much.
A. Thank you.
MR JUSTICE FRASER: I do however have one point, which is
a point for you, Mr de Garr Robinson, I'm afraid. I'm
not going to go through it in enormous detail but just
to give you the references, yesterday at
page {Day19/204:1} you gave me an explanation about the
recent disclosure that was produced in late May which
concerned OCPs, OCRs etc.
MR DE GARR ROBINSON: It was some OCRs I believe, my Lord,
yes.
MR JUSTICE FRASER: In the course of that, and it is at
page 204, I will just read out what you said, you
described that they were maintained on the Fujitsu
system and you said:
"Much later Fujitsu discovered an old database had
been copied more than ten years previously on the system
somewhere and told the Post Office they had those
collection of documents and then the Post Office
produced them, etc."
Today, at 11.37, Mr Green put a document to
Dr Worden which is {F/1848.8.2/1} which is a PEAK
dealing with the Drop & Go discrepancy, which he said
was disclosed on 30 May 2019 and is a PEAK that is, on
its face, dated 21st August 2018. So it can't fall
within the category of documents on the old database
etc. Can the witness statement please specifically
deal --
MR DE GARR ROBINSON: It can. I asked about that. I knew
nothing about it until it came up. I have asked about
that and there is an account which can be --
MR JUSTICE FRASER: As long as that can also be included.
MR DE GARR ROBINSON: It can.
MR JUSTICE FRASER: Right. Thank you very much. Have you
got some more documents to give me?
MR GREEN: My Lord, we have compiled a bundle of the PEAKs
and KELs referred to during Dr Worden's~--
MR JUSTICE FRASER: Thank you very much.
MR GREEN: Apart from re-examination because we didn't know
what was coming.
MR JUSTICE FRASER: Don't worry about that, there has only
been a couple of things. Thank you. So I can with the
exception of re-examination that is my hard copy PEAK
and KEL data complete. Is there anything else
housekeeping, quasi housekeeping, any other points?
MR DE GARR ROBINSON: Not even quasi housekeeping, my Lord.
MR JUSTICE FRASER: Whatever that might be.
So, in terms of timetabling, I think there is a date
already been ordered for your submissions in writing.
We don't need to change that. It is the 1st and
2nd July, a day each. If there are to be any further
authorities, although I imagine even if there are they
would be limited given the subject matter of the Horizon
trial, but if there are if they could just be put in
an agreed bundle and I think for this tranche of the
trial that's it until then. Is that right?
MR DE GARR ROBINSON: My Lord, I hope so.
MR JUSTICE FRASER: Well, one never knows. But 1st and
2nd July, I look forward to seeing you all then. You
might have the chance to have your screens swapped.
MR DE GARR ROBINSON: I have got rather used it now,
my Lord.
MR JUSTICE FRASER: Thank you all very much and until then.
(4.26 pm)
(The court adjourned until 1 July 2019)
(10.30 am)
DR ROBERT PEEL WORDEN (continued)
Cross-examination by MR GREEN (continued)
MR JUSTICE FRASER: Just before we start, in relation to
timings, have you discussed when you are going to stop
so Mr de Garr Robinson can --
MR GREEN: My Lord, what I have said to my learned friend is
I will do pro rata exactly what I gave my learned
friend, so stop by 4 o'clock, being 10 minutes per day.
MR DE GARR ROBINSON: My Lord, I've indicated that that may
not be enough time, and my learned friend has very
kindly said he will try and cut it back as much as he
can.
MR JUSTICE FRASER: All right, that's excellent.
And then just a reference point, this is just for
the two of you to look at lunchtime, not now. On Day 18
at page 98 in one of the answers about ground rules, the
transcript says May 2015. I'm not sure that date can be
right, 2015.
MR DE GARR ROBINSON: No, it doesn't sound right.
MR JUSTICE FRASER: So if you just check it. It might have
been corrected in the finalised version.
MR GREEN: I understand it is 2018 but we will check.
MR JUSTICE FRASER: So just check it, that's all.
All right, Mr Green.
MR GREEN: I'm most grateful.
Dr Worden, yesterday we had arrived at a point where
you had seen the presentation, it has the £25,000 and
£2,500 outstanding?
A. The presentation about?
Q. The Fujitsu presentation about the Dalmellington bug.
A. Yes.
Q. Now I would like to invite you to look, please, at your
second expert's report.
A. Sorry, where is it? Here, yes.
Q. I would like you to look at page 41, please.
A. Page 41?
Q. Sorry, {D3/6/41}.
A. Okay, I'm getting there. Yes.
Q. Now, this is where you deal with the Dalmellington bug
in your second expert's report?
A. Yes, right. Okay.
Q. And it is in section 6.2.2, yes?
A. Yes.
Q. And it goes -- it runs through to page {D3/6/42} and
then over the page to {D3/6/43}, if you want to look.
A. Yes.
Q. So it is in these paragraphs 154 to 163. Can I just
take you through them because the first two paragraphs
that we see on page 41, which are paragraphs 154 and
155, those two paragraphs are directly referring to what
you have described as "the Dalmellington incident".
{D3/6/41}
A. Yes.
Q. And you would fairly accept that the phrase "the
Dalmellington incident" suggests one event?
A. Well, one event, but I think there is a type of event
that it refers to.
Q. Let's have a look, if we may.
Paragraphs 154 and 155, just to map out how this
section works, are actually talking about Dalmellington
itself.
A. The actual Dalmellington, yes.
Q. Yes, the actual Dalmellington. Then at 156 you move
from the specific reaction to that to the more general
position that you infer about Post Office and Fujitsu --
A. Yes, I mean -- sorry, in a sense a KEL implies a general
position in some way.
Q. I understand. But you are moving certainly at the
highest level from the specific to a more general
exposition of your views in the light of this because we
see at 156 you say:
"Even so, Post Office and Fujitsu were concerned
that Horizon should not induce the user to make such an
error, even in rare circumstances."
A. Yes.
Q. Then you say at 157:
"To make this point more clearly: in my opinion, for
many KELs ..."
So that is not limited to Dalmellington at all?
A. No, that's a rather general statement.
Q. So it is a general statement:
" ... it would have been obvious to Fujitsu that any
error in branch accounts would have been corrected in
due course, by the normal processes ..."
You see?
A. Yes.
Q. And the general statements continue into 158 over the
page on {D3/6/42}.
A. I think that is right. Can I read it?
Q. But you do then pick up Dalmellington at the bottom of
158 again.
A. "Dalmellington was such a case."
Q. Exactly. So you return from the general to the specific
at the bottom of 158, and you bring us back to
Mr Godeseth's second witness statement at paragraphs 55
onwards --
A. Yes.
Q. -- referring to Dalmellington, yes?
A. Yes.
Q. If we can just bring up Mr Godeseth's second witness
statement at 55 onwards. We are going to find that, if
we may at {E2/7/14}.
A. So the paragraph I quote is which?
Q. You say Mr Godeseth, his second witness statement at
paragraphs 55 onwards, in his Dalmellington section.
A. His Dalmellington section, yes.
Q. Yes?
A. Yes.
Q. And we can see at {E2/7/14}, his Dalmellington section
begins on page 14 of his witness statement at
paragraph 55.
A. Yes.
Q. Which is the one you have referenced.
A. Yes.
Q. And if we go over the page, please {E2/7/15}, we see on
page 15 the reference in paragraph 61 to "total 112
instances"?
A. Yes.
Q. Yes? And we also have Fujitsu's analysis --
A. Yes.
Q. -- expressly exhibited there.
A. Yes.
Q. So in your second report you are expressly referring to
the passage that you didn't refer to previously?
A. Well, I'm referring to that one, yes.
Q. Let's go back to your report, if we may. {D3/6/42}
A. Yes.
Q. We have established that at the bottom of 158 you come
back to Dalmellington and refer to that bit of
Mr Godeseth's statement. Then you say there at
paragraph 159:
"Further, but weaker, support from this view ..."
This is your theory?
A. Yes.
Q. But you refer specifically to a note by Anne Chambers?
A. Yes.
Q. And you only recite there -- well, you recite there what
she says?
A. Yes.
Q. And refer to the fact that she had looked for other
affected branches?
A. Yes.
Q. And you say:
"She said: 'I can only check back two months; I've
found 4 other instances ... and all but the last removed
the discrepancy by completing a rem out for the excess,
which corrected the system cash holding.'"
A. Yes.
Q. And then you would accept, I think, that notwithstanding
having gone to -- made express reference to that PEAK in
which four other instances are mentioned, at no point
between there and 163 do you mention the fact that 118
branches were affected -- sorry, 88 branches were
affected by 112 events?
A. Between which paragraphs?
Q. The ones we are on, 159/160, all the way down to 163.
A. Let me just check:
"... 'we are going to have to find ... and correct
their accounts'."
Yes. Okay, yes.
Q. Now, there are two possible explanations for you not
making reference to the fact that in this case the bug
concerned affected 88 branches rather than 1 or 4 or 5.
There are two possible explanations for not mentioning
the 112 instances or the 88 branches. One is that you
didn't know, and the other is that you did know and you
chose not to mention it. Which of those two is the
explanation?
A. That is a good question. I think I knew, but my
prevailing view is that remming errors are detected very
directly by an imbalance between a rem in and a rem out
and that therefore remming TCs do not involve a large
element of human judgment as to whose fault it was that
did this, or whether it was the bank etc. So remming
TCs in my opinion are rather fast and direct things and
I was not concerned -- for instance, by the time we have
the 118 it was many years and I don't know exactly --
for instance, I cannot recall the exact timing between
Anne Chambers PEAK and the whole sequence of several
years, but my understanding is that over the whole
sequence of several years these rems, these TCs
consequent on remming errors, were made rather rapidly.
And that is my whole background understanding of
Dalmellington and other incidents.
Now, if I fail to mention Dalmellington and other
incidents on this case, perhaps I should have done, but
I think it is clear from my reports that all remming
errors I believe get corrected by TCs --
Q. Pausing there, Dr Worden. It would have been helpful to
the court in identifying the errors which had
a potential to have an impact on branch accounts.
A. In my mind they didn't have the potential -- didn't
have -- had a small potential of having a lasting effect
on branch accounts. Certainly they had a transient
effect, there is no question of that.
Q. In terms of simply identifying whether they had the
potential to have an effect without your gloss of
lasting on it, it would be important, wouldn't it, for
the court to have an understanding of how many
branches -- what's the magnitude, order of magnitude of
the number of branches affected by that bug?
A. Yes, indeed, I could have for instance mentioned that
112 branches were affected by this bug versus 20,000
branches a year which are affected by manual remming
errors, but my opinion is that they are all corrected
quite rapidly. I'm sorry if I did not mention it there,
but the prevailing background of my opinion on the
remming issues is that there are large numbers of
remming errors during the year and they get corrected by
a TC which does not involve a huge element of human
judgment to see a discrepancy between two figures and
say this has to be corrected.
Q. But it is a striking figure, 88 branches, isn't it?
A. Well, compared with 20,000 it is not.
Q. And you are prepared to mention anything but you are not
prepared to mention that?
A. No, I'm saying if I failed to mention it here it is
an oversight and I apologise to the court.
MR JUSTICE FRASER: When you just said not compared to
20,000, where do you get your 20,000?
A. I get the figure of 20,000 from the table of TCs which
says -- quoted in my first report, which says there are
100,000 per year approximately and, of those,
approximately 20,000 are remming errors.
MR GREEN: Now, Dr Worden, can we now do an exercise of
going through the bugs table in joint 2?
A. Yes.
Q. And that begins at --
A. Shall I get joint 2 up?
Q. -- {D1/2/3}.
A. I have got joint 2. Okay.
Q. And if we look at -- if we go forward, please, we have
on page -- there are the first two, receipts and
payments and Callendar Square?
A. Yes.
Q. Then we go over the page to the suspense account bug.
A. Yes.
Q. Now, you accept that that's one of your branches that
had the potential to have a lasting impact?
A. Yes.
Q. We dealt with Dalmellington just now, that's number 4.
A. Yes.
Q. If we go to number 5, please {D1/2/5}. That is remming
in?
A. Yes.
Q. And your view in the "Worden Opinion" column is:
"As for the Dalmellington bug, above – PO had a
robust process for detecting and correcting remming
errors, whatever their origin.
"So, there were no lasting effects on branch
accounts."
A. Yes, we have just been over that.
Q. And that is the reason for not including them in lasting
errors --
A. Yes, that's why they are not in my 12, if you like.
Q. Now, I'm going to have to take all these not at a huge
level of detail, as you will understand.
A. Yes, sure.
Q. But can I ask you this question: there was a KEL in
relation to this bug, wasn't there? Can you remember?
A. Well, we have got acha4221Q, yes.
Q. Yes. Did you look at the PEAK that was mentioned in
that KEL?
A. I cannot recollect, honestly. I probably did because
when a KEL -- I mean, when I look at KELs, if it seems
to me that the KEL is clear as to what happened, the KEL
is a kind of distillation whereas the PEAK is
a long-running diary, if you like. So if the KEL is
clear I don't go on to the PEAK, but if the KEL leaves
me some room for doubt then I will go on and look at the
PEAK.
Q. Could we look at this on your own response at
{D3/2/170}, please, in your expert's report?
A. D3. That is a supplemental report, is it?
Q. This is actually in the appendix to your first report.
A. Right, okay.
Q. It is at {D3/2/170}.
A. Both my reports are D3. Sorry. Anyway, let's go to it.
Yes.
Q. So we can see your view in relation to this KEL?
A. And this is part of the table where I analyse the 62
KELs that Mr Coyne had cited, is that right?
Q. Yes, there are two tables, aren't there? There is what
you call the pound table --
A. Yes.
Q. -- and the Coyne table?
A. That is right.
Q. Yes? And we are here looking at -- the bottom box is
acha4221Q.
A. That is the one.
Q. Which is the KEL at {F/794/1}. And you have referred to
it there, you have summarised your view of it --
A. Yes --
Q. "The clerk went into --"
A. Can I just clarify, I believe the next to left-hand
column is kind of quotations out of the KEL and the
PEAK, or a PEAK, and the right-hand column is my
analysis.
Q. I'm grateful. So you quoted from the KEL. We can
actually see that made good, just to be fair to you,
Dr Worden, at page {D3/2/164} if you want briefly to --
so if we go up to page 164.
A. Go to my first report at 164? Or in the appendix or ...
Q. No, page 164 of this {D3/2/164}.
A. Sorry. D3/2 ... get used to this convention.
Q. This is in the same table, Dr Worden.
MR JUSTICE FRASER: Why are we going to 164?
MR GREEN: Just in fairness to Dr Worden, to remind him of
the --
A. Page number again, sorry?
Q. Let's stay on this page. Dr Worden, your heading for
that middle column, the large column, is "Quotes from
KEL and PEAKs"?
A. Yes.
Q. So what you have done is selected what you regarded as
relevant quotes from the KELs and PEAKs to include
there?
A. That is right.
Q. And we see what you have included. You say:
"The clerk went into the Delivery menu and scanned
two pouches (one of currency and one of coins)."
A. Sorry, are we back on the --
Q. Yes, we are back here on this page, which is {D3/2/170}.
A. On screen I don't have it.
MR JUSTICE FRASER: Okay, I'm just going to intervene to try
and streamline this. We should have 170 on the common
screen now.
A. 170. We do, yes.
MR JUSTICE FRASER: And you are being asked about the
quotation in the main substantive column.
A. Okay.
MR JUSTICE FRASER: The heading to that column being "Quotes
from PEAKs and KELs".
A. Yes. So we saw the heading and now we are looking at
the ...
MR JUSTICE FRASER: Yes, Mr Green.
MR GREEN: I'm most grateful. On the left-hand side we see
acha4221Q in the second lower box.
A. Yes.
Q. And in the main substantive column there is your quote
from the KELs and PEAKs.
A. Yes.
Q. It says:
"The clerk went into the Delivery menu and scanned
two pouches (one of currency and one of coins). The
second pouch was recorded twice on the system, resulting
in a loss of £80."
A. Yes.
Q. Did you look at the PEAK that was referred to in that
KEL?
A. I'm not sure if I did but I would suspect I didn't,
because my views on remming in and remming out errors
have been clear for some time and therefore I would have
probably found what I wanted in the KEL.
Q. I understand. Let's look, if we may, at that PEAK which
is {F/588/1}. A hard copy will be handed up by
Ms Donnelly.
A. Thank you.
Q. The PEAK number is PC0195380.
A. Can I just start at the top:
"Rem in transaction appears twice right."
Yes, right.
Q. Can you turn to page {F/588/2}, please.
A. Yes.
Q. And you have got the reference to the loss of £80 in the
penultimate box at the bottom.
A. The Anne Chambers grey box?
Q. Yes.
MR JUSTICE FRASER: 2nd March 2010 at 51.21.
A. Got that.
MR GREEN: Exactly, 15.21.46. Second paragraph:
"This has caused them a loss of £80. They cannot
reverse this transaction."
Do you see that?
A. Yes.
Q. Did you know why they couldn't reverse the transaction?
A. I don't know the detail of that, but ...
Q. I understand.
A. Obviously this is one of two ways it can be corrected,
by reversal or a TC.
Q. Let's go over the page, if we may, to {F/588/3}. When
we look there you can see halfway down the page at
3 March 2010, 10.56.59, Anne Chambers.
A. Yes.
Q. Do you see halfway across the first line:
"This problem can cause losses which are hard for
the branch to identify, so it does need to be fixed."
Do you see that?
A. Yes.
Q. And you hadn't seen this text because you don't think
you looked at the PEAK, that is right?
A. I do not think this text yet would change my opinion.
Q. But on my question --
A. In other words, I saw enough from the KEL, and this PEAK
has not yet changed my --
Q. I think the court has got your answer on the reason.
But it's factually correct, you hadn't seen this text?
A. I don't recall these words.
Q. Look at the box almost at the bottom, 3 March 2010,
18.15.47, Anne Chambers.
A. Sorry, 3 March 18.15. Yes:
"Just seen another example ..."
Q. "... of this in live ... this time they scanned the bar
codes, then pressed Previous instead of Enter after the
last barcode, and then went forward again. They now
have a loss of £25,000."
A. Yes.
Q. You would accept that that reference to £25,000 conveys
a very different order of magnitude of the potential
loss here, doesn't it?
A. I would. Obviously a remming error can be remming
an error. If you double up a rem then you double up the
amount of cash and that can be big or small depending on
lots of factors.
Q. And as you didn't look at this I'm not going to take you
to further parts of that.
Can we move forward now, please, to the other PEAK
referenced in the same KEL.
A. Yes.
Q. It is {F/695.1/1}. Did you look at this PEAK?
A. I don't think I did because, as I say, I feel
I understand remming TCs and I feel I understand --
generally the KELs give me --
Q. You can just say "for the same reason" each time. You
don't need to do it each time.
A. Yes, "for the same reason" is fine. Yes. I do not
think I have looked at the PEAK but --
Q. {F/695.1/3}, if we go there.
A. Page 3. Yes.
Q. If you look --
A. Sorry, could I just check the header of this PEAK and
get the problem statement. So it is remmed into
counters again. Okay. PM scanned it.
Right, thank you. Sorry.
Q. If you look, you see there is a large box in the bottom
half of the page --
A. Yes.
Q. -- which is 17th August 2010 at 15.48.59.
A. Yes.
Q. If you go halfway down that box --
A. This explains why rem reverse -- you can't reverse the
transaction. It says "rem reversal isn't allowed".
Q. Indeed. But look immediately under that.
A. "This is NOT another example ..."
Q. "This is NOT another example of the duplicate rem
problem that we have seen in the past, where use of the
Prev key accepted the same pouch twice. In this case
the pouch was processed on both counters ..."
Do you see that?
A. Yes. So one case was twice on one counter and the other
case was -- sorry, is that right?
Q. Yes.
A. The other case was two counters. Yes.
Q. If we go over the page {F/695.1/4}.
A. Yes.
Q. And we look at 18th August 2010, two-thirds of the way
down the page, 18.35.20, Anne Chambers.
A. Sorry, 18.35 and ...
Q. 20 seconds. It is a yellow box for you. Do you see
that?
A. This is about the BAL OSR logs?
Q. Yes. Immediately under that you will see the sentence
that says:
"Gareth Jenkins thinks that it should not be
possible to complete the rem in on both counters.
Please investigate."
A. Yes.
Q. Now, if he was right that it shouldn't be possible to
complete a rem in for the same pouch on two different
counters -- because they have unique barcode IDs, don't
they?
A. Yes.
Q. If he was right that it shouldn't be possible to do
that, that aspect was a bug in the system, wasn't it?
A. Yes.
Q. And if he was wrong in his understanding, it was
a defect in the system in allowing it to do it?
A. I see. Something shouldn't have happened.
Q. Yes.
A. Absolutely.
Q. But my question is a fair one, isn't it?
A. It is a fair one, yes --
Q. Even if you wouldn't say it in the same words.
A. Yes.
Q. And the consequence of that is that you get an error in
branch accounts as we have seen?
A. You get a transient error.
Q. Let's move on to the next one in the table which is 6.1.
A. Sorry, I have too much paper here.
Q. I will trace it through for you, Dr Worden, in the same
way as I did for number 5.
A. This is remming out, yes?
Q. We are going to go to {D1/2/5}.
A. Right. Can we just get it on the screen?
Q. Yes. This is just where it is in the --
A. Right, okay, I'm there --
Q. -- in the table of bugs. So we have done 5?
A. Yes, and we're doing 6(i) --
Q. We have done the first four above, and we have done 5,
now we are moving on to 6(i) which is at the bottom of
the page.
Your answer on 6(i) is:
"As for the Dalmellington bug, above – PO had a
robust process for detecting and correcting remming
errors, whatever their origin."
A. Yes.
Q. That is a direct paste from above, isn't it? It is the
same reasoning as number 5?
A. I don't -- I probably typed those words again, but ...
Q. Okay. But it is the same words and the same reason?
A. Very similar words because a very similar case, really.
Q. The words are identical. Anyway, it doesn't really
matter, they are the same.
A. No.
Q. And then underneath:
"So, there were no lasting affects on branch
accounts."
If we go over the page {D1/2/6}, that bit is not
there for that but we can see it pops back in on 6(ii)
underneath?
A. Oh yes, I missed that out on 6(i).
Q. That's just a mistake on 6(i)?
A. I think so, yes.
Q. You would have meant presumably to include the same --
A. I think I would, yes.
Q. -- test for all three. That's why I was asking you
about the pasting.
A. It wasn't -- yes, I do not think I kind of do that,
really.
Q. When we look at 6(i), did you look at the KEL for this
one, which is acha508S?
A. I believe I did, yes.
Q. Do you remember?
A. I believe I did. I would have done.
Q. Do you remember that it suggested that calls about
inconsistencies in stock rem outs should be redirected
to NBSC?
A. I don't recall that at this moment, no, but again I do
start with a strong prior expectation that remming
errors get fixed.
Q. I understand. And that's the basis on which you
approached your report?
A. That is right.
Q. And we all understand that.
Paragraph 96 -- sorry, there is a PEAK referred to
in that KEL, yes? Did you look at the PEAK, can you
remember --
A. No, I wouldn't have. I suspect not.
Q. Let's have a quick look at it, if we may. It is at
{F/384/1}. You have got a hard copy of that.
A. Right.
Q. Just in the interests of time, Dr Worden, let me take
you to page {F/384/3} of that, if I may?
A. Can I just read -- get the problem statement.
(Reads to self)
So I don't see -- cash problem reversing, sorry,
yes, let's get to that.
Q. If I can take you to page 3.
A. Yes.
Q. And we come down, it will be the third yellow box for
you.
A. Right.
Q. It is 15 February 2007 at 14.04.08.
A. Yes.
Q. It says there:
"Have talked to PM about the problem and
consequences, which she understands. POL will be
informed of the transaction correction required to
remove the excess cash in pouches (along with the 50 or
so similar branches)."
Do you see that?
A. Yes.
Q. And you hadn't read this, you think?
A. No. But, again, it doesn't -- reading it now doesn't
change my opinion.
Q. Your opinion we find in relation to that one is in the
table at {D3/2/165}.
A. Can we go there?
Q. It is the top box which is referring to acha508S.
A. Yes.
Q. The PEAK is referred to there, the PEAK we have just
seen at {F/384/1}.
A. Yes.
Q. And the quotes you have chosen to take from the KELs and
PEAKs doesn't give any hint that there were 50 other
affected branches, does it?
A. That is correct.
Q. Let's move on now, if we may, to the next one in the
bugs table in the joint report, which is 6(ii), which is
going back to {D1/2/6}.
Dr Worden, I'm only going to do the first ten
because time won't allow me to do 27 of these.
A. Right, okay.
Q. So we are looking at 6(ii).
A. Yes. So again my standard wording comes in.
Q. That's it. You will see there:
"'Remming out' (ii) Bug (not acknowledged)."
This isn't one that you had in either of your tables
in your appendix originally.
A. No.
Q. Did you have a look at the KEL in that case?
A. I believe I did, yes.
Q. Can we look at it now, please. This is at {F/276/1}.
A. Rem out ... Yes.
Q. This is the GMaxwell3853P KEL. If we look at the bottom
where it says "Solution - Atos".
A. Bug in the code, yes, right.
Q. "Development have identified a possible bug in the
counter code. However, due to the frequency of the
problem & the risks involved in making the necessary
changes it has been decided that a code change will not
be made."
A. Yes.
Q. You hadn't noticed that, had you?
A. I believe I had, but again the point about permanent
effects, lasting effects, on branch accounts is not
altered by that.
Q. And the point about this is there was a lasting bug?
A. There may have been a lasting bug, but they took
a decision based on its frequency and the difficulty of
making the change, perhaps the risk of making the
change, that it was not worth addressing. That actually
the remming process would pick it up and its
frequency -- they took a decision, I don't know what the
details were of their trade off. They took a decision
that fixing the code was not worthwhile.
Q. I'm just asking you: it is a lasting bug?
A. It is a lasting bug, yes.
Q. Let's go to number 7 now, if we may, please.
A. Sorry, it might have been fixed in the next release, for
instance, one doesn't have the history, but there we go.
Q. That is speculation in favour of the Post Office.
A. Absolutely. I'm sorry, I shouldn't have done that.
MR DE GARR ROBINSON: My Lord, I just wonder whether there
is a potential confusion in the question my learned
friend has asked. It may be my confusion.
Where my learned friend said "lasting bug", bearing
in mind the emphasis I placed during my submissions and
indeed in cross-examination on bugs with lasting effect,
it might be helpful if my learned friend could
distinguish between a bug that lasts and a bug which has
lasting effect. I believe he is putting the first
point, not the second.
MR GREEN: I think you knew what I meant, Dr Worden, didn't
you?
A. I did. And I'll clarify what I mean: it's a bug that
was not fixed, we cannot see was fixed, but it was a bug
without lasting effects in my opinion.
Q. For all the reasons we have heard?
A. Yes.
Q. Let's go to number 7. I'm grateful to my learned
friend. {D3/2/173} is your ...
MR JUSTICE FRASER: Number 7, "Local Suspense Issues".
Q. Local suspense issues, which are not the same as the
local suspense bug. This was a bug that occurred in
April 2010.
A. Mm.
Q. And if we look at the joint table for a moment at
{D1/2/6}, and we look under your opinion, it says:
"The KEL ... implies that PO and Fujitsu were able
to identify all occurrences of the problem, without
being notified by any Subpostmaster I would therefore
expect them to have corrected any impact on branch
accounts as part of normal error correction processes."
A. Yes.
Q. Then you say:
"I would not expect evidence of all corrections to
accounts to have survived to the present day. Peaks and
KELs are not used to record corrections of financial
impact."
A. Yes.
Q. Fujitsu, in fairness, analysed the KEL, you say here,
and said:
"... 'Temporary financial impact which would have
been cancelled out in the following period by
a corresponding discrepancy.'"
Do you see that?
A. Yes.
Q. Now, did you look at the KEL?
A. Well, I infer from that Fujitsu did it, but I had done
it previously.
Q. Let's go, please, to {F/637/1} which is the KEL
acha5259Q.
A. Right. Sorry, can I remind myself of the ...
"... local suspense cleared ... balance report ...
cash ..."
Q. Do you see if we look at the problem --
A. Yes.
Q. -- the summary was that the PM was forced to clear local
suspense several times resulting in the cash figure on
the balance report changing and possibly a discrepancy
in the new trading period.
A. Yes.
Q. So that certainly had the potential to cause an impact
on branch accounts at the time, subject to later
correction?
A. Yes.
Q. And probably did, yes?
A. I think it did, yes.
Q. If we look at the problem, please, at the bottom of the
page?
A. Counter logs.
Q. "Looking at the counter logs, after they pressed the
Stock Balancing/Report button the first time, there was
a ClassCastException ..."
A. Yes. I could explain, that is a Java thing that
shouldn't happen.
Q. So a Java error that shouldn't happen.
"... system error 0437 (trying to process a corrupt
ReportingService response), forcing them to start again.
"The reason for this exception is understood ..."
And it refers to --
MR JUSTICE FRASER: You have gone over to the next page.
MR GREEN: Sorry, I do apologise, yes.
MR JUSTICE FRASER: You don't have to apologise, we just
have to turn the page so we can see what you are
reading. {F/637/2}
"The reason for the exception is understood ..."
And there is a reference to a PEAK and a KEL.
"This problem particularly affected branches in the
first 2-3 weeks of April, and could start occurring
again."
Did you notice that?
A. I believe I did, and obviously that doesn't state the
number of branches affected.
Q. Do you remember whether there was an indication of the
number of branches?
A. No, I have no idea of the number of branches.
Q. Okay.
A. But --
Q. Let's look just below that, under "Solution - Atos",
second paragraph under that heading --
A. Oh, it says lower that 33 branches had this problem.
Q. Yes.
A. So I probably was aware of that at the time.
Q. Yes:
"33 branches which had this problem between 7th and
15th April have been identified."
A. Yes.
Q. So pausing there. We know that the problem particularly
affected branches in the first two to three weeks of
April --
A. And --
Q. -- not exclusively?
A. Yes.
Q. And could start occurring again, and for an eight day
period which they tested for, they had actually already
identified 33 branches?
A. Yes, so we are looking at a number bigger than that,
basically.
Q. We are. But you had not spotted that magnitude of
branches --
A. Well, my analysis was not about the number of branches
affected, it was about the lasting effect. I mean --
Q. And --
A. -- I think -- sorry, to state the obvious, there are
bugs in Horizon that have no affect on branch accounts
and they are very wide in scope.
Q. I think we have got your answer on the corrections so
let's just focus, if we may, just on this.
A. Sorry.
Q. Can you remember if you looked at the PEAK that's
referred to for that?
A. I doubt I would have again because ...
Q. So on the first page of that KEL you will see PEAK
PC0198077, do you see that?
A. Coming back again?
Q. Go back a page very kindly {F/637/1}. That's it.
You can see the PEAK --
A. Yes, there we go.
Q. -- 0198077. If we look at that PEAK, please, it is at
{F/630/1}. Ms Donnelly will give you a copy.
A. Thank you.
Q. Now, once you have got your eye in on page 1 ...
A. (Reads to self)
Yes. Just to say, "discrepancy" is not highly
specific. Carry on.
Q. Will you forgive me, Dr Worden, if we just try and
focus, because I'm quite tight on time to get through so
many --
A. I'm sorry, I just like to get the problem statement.
Q. And I want to be fair to you to do that.
On {F/630/2}, which is the second page of this PEAK,
there is a large box --
A. Right.
Q. -- occupying most of the top half of the page. If you
come just short of halfway down that, you can see --
maybe a third of the way down, do you see 2010-04-15 at
14.11.53, do you see that?
A. Yes.
Q. Martin White. It says:
"LOG: On logging on 15/04/2010 ..."
Do you see that?
A. Yes.
Q. "... produced a balance snapshot that showed nil
discrepancy and again the inflated cash figure."
Yes?
A. Yes.
Q. Now, it then says:
"The spmr had logged a couple of incidents with
NBSC, and was referred to the HSD ..."
With a reference number.
A. Yes.
Q. "The spmr was bounced back to NBSC as a balancing error
rather than a system problem."
A. Yes.
Q. So we know this was in fact a bug, and what happened
when this SPM was put through to the Horizon support
desk is they were bounced back and it was suggested that
it was a balancing error, yes?
A. Yes.
Q. And you would accept that from what we now know, that
judgment was incorrect?
A. It appears to be the case, certainly.
Q. And that shows us, doesn't it, at least the -- that's at
least consistent, in your meaning of the word
consistent, with Angela Van Den Bogard accepting that
there was sometimes user error bias, at least on
Post Office's behalf?
A. It is not to my mind a question of bias. What this
tells me is that HSD on this occasion made a mistake.
Q. And they made a mistake against the subpostmaster?
A. Yes, absolutely.
Q. And on your definition of consistent, that is consistent
with UEB?
A. Sorry, that is right.
Q. Now, if we go down to the bottom of this PEAK, this page
of the PEAK, it is 21 April 2010 at 10.18.57.
A. Yes.
Q. Bottom box, it is a yellow one on the page:
"NBSC has just advised that another office had
a similar problem, although the discrepancy has now been
sorted out. Details of the site and problem are below
for information."
A. Yes.
Q. So that is an example of your idea of the
countermeasures working effectively --
A. Well --
Q. -- on the face of it?
A. -- if they say it was sorted out --
Q. Exactly.
A. -- it looks as if it was sorted out.
Q. That is consistent with your view that there are lots of
occasions when it is sorted out?
A. Yes.
Q. Let's read on:
"Office: Hucclecote ..."
And look at the bottom paragraph:
"Office was dealing with the discrepancy in the
office following the TP rollover, and selected settle
centrally. The office reports that nothing happened and
they ended up doing this a further 2 times before they
could proceed. This has resulted in the office settling
the loss centrally 3 times. This showed as such as the
total on the final balance. The Trading Statement and
suspense account seemed to be correct though. On Monday
19th April the office reported they showed a cash gain
of double the original loss and after further
investigation a suspense account was produced that
showed 2 clear loss from local suspense entries."
{F/630/3}:
"We have cleared this by clearing gain from logical
suspense, which should clear the gain in the office."
A. Yes.
Q. So that is the resolution?
A. That appears to be, and it is a bit complicated, isn't
it?
Q. But at least it appears to be the resolution?
A. Yes.
Q. Let's look at the immediate entry below that on page 3.
A. "... solution we thought ... not resolved the problem
..."
So they thought they had fixed it, they hadn't.
Q. Let's take it in stages. Top of page 3, first new box
on page 3. 22 April 2010, 11.26.12.
A. Yes.
Q. "The solution we thought we had for Hucclecote SPSO, FAD
186523, has not resolved the problem, but has actually
doubled the discrepancy."
A. Yes. So it appears they again made a mistake, and this
perhaps illustrates that PEAKs are this kind of train of
investigation and there are false starts, whereas the
KEL usually distills what comes out of the end of it.
Q. You didn't find a reference to the fix going wrong and
doubling the SPM's discrepancy in the KEL, did you?
A. No, but frequently these things happen in PEAKs. They
do (inaudible) investigations, it is a false -- it's
a -- the trail leads nowhere, they start somewhere else
and so on. You have to read through the whole PEAK to
get the whole picture, whereas a KEL distills out what
was learnt eventually. And so that is why I have --
when the KEL tells me what happened, I generally don't
pick the way through all the PEAKs.
Q. Let's look at page {F/630/8}, if we may. Just two last
references on this PEAK and then we will move on to the
next bug. We come down to the second yellow box which
is 16th June 2010 at 9.37.08.
A. Sorry, I haven't fixed the time. Could you repeat it?
Q. It is the second yellow box.
A. Yes:
"... general issue ... error handling ..."
Yes.
Q. Second part of that box:
"There is a wider, general issue in relation to
error handling that is still not addressed, hence which
can and will still cause roll-over and subsequent
discrepancies."
A. Yes.
Q. You didn't see this either because you didn't look at
the PEAK?
A. No, I didn't look at the PEAK.
Q. "This wider issue is outstanding, and can also
contribute to screen freezes and double settlements and
hence further discrepancies."
A. Yes.
Q. "The wider issue can occur when any unhandled exception
occurs in the early stages of the roll-over process ...
this was just one example."
A. Yes. Sorry, are we still on the PEAK --
Q. Yes, still on the same PEAK.
A. -- where the KEL said it was a Java exception?
Q. Yes.
"The wider issue is addressed by the fix for this
PEAK."
That is in June.
A. Yes.
Q. Okay. Let's just go now to, finally, page {F/630/10} of
the same PEAK, it is the last reference on this one. If
you look, it is 17th September 2010, 16.31.53.
A. Yes. This quote does sound familiar to me, actually.
Q. "This problem has happened intermittently since April
but never at the levels seen then. Being investigated on
PC0204396. The good news is that no instances have been
seen since this fix was applied. Closing call."
A. Yes.
Q. So we have a period there that we can identify over
which it was happening intermittently as well?
A. Yes.
Q. And you had no feeling for any of that because you
hadn't read the PEAK?
A. My feeling was I'd read the KEL and I think I'd formed
the opinion it was a transient effect, and Fujitsu had
done that, so I didn't drill down.
Q. For the reasons you have given before?
A. Yes.
Q. Let's move if we may now to number 8 and we find that --
just to do it the same way again, if we go back to the
joint statement 2 table and we look at {D1/2/7}.
A. Row 8.
Q. It is row 8. The recovery issues are identified there.
A. Mm.
Q. Mr Coyne has made references to the text in certain
PEAKs.
A. Yes.
Q. And you have given your opinion there, you say they are
not indicative of errors in Horizon, they provide
guidance on how to correct discrepancies caused by human
errors or other errors.
A. Yes.
Q. You say:
"Because there were many such errors, there were
many calls to the help desk and many PEAKs and KELs."
Then it is basically your same theory, that:
Normally, correction of errors involved back office
reconciliation and issuing TCs."
And that's accurate.
A. It is a different theory really. Recoverable
transactions are a big subject and they are complicated
because the point at which a recoverable transaction can
go wrong is very variable through the sequence, and
therefore the number of recovery actions, the type of
recovery actions is complicated. Horizon was designed
so that with the assistance of the postmaster most of
these could be recovered, but there are things called
failed recoveries, which again were part of the design
of Horizon, and those were the failed recoveries but
particularly the ones where Fujitsu had to get involved.
But failed recoveries means the recovery process had
failed, that's the way Horizon was designed because
these things are so complicated you can't handle them
all automatically. So it is a big subject but there is
plenty of useful evidence about it.
Q. You say in your table at {D3/2/124}.
A. This is the 959T KEL, is it?
Q. Yes. You say:
"This is another complex KEL with strong overlap
with previous KEL."
A. Yes. This KEL is cited in a large number of PEAKs.
Q. And in fact when we go back to the table at {D1/2/7},
Mr Coyne has actually quoted from one of the PEAKs we
see there, the first one he quotes from. Do you see
"PC0198352"?
A. Yes.
Q. And he has quoted:
"This problem caused a loss at the branch for which
they should not be liable."
Pausing there. This did have the potential to cause
the type of discrepancy which you have given evidence
about being later corrected, didn't it?
A. The word "problem" doesn't imply a bug in Horizon.
Q. You didn't read these PEAKs yourself, did you?
A. I have read a fair sample of recovery PEAKs. Maybe not
these ones, but I have read a fair sample.
Q. If we go over the page {D1/2/8}, do you see Mr Coyne
points out there that this KEL is referred to by 2,473
PEAKs --
A. Yes, that's --
Q. -- from 2010 to 2018.
MR JUSTICE FRASER: Where are we looking?
MR GREEN: At the top of that page under the "Coyne Opinion
as to branch account impact", my Lord.
MR JUSTICE FRASER: Yes.
A. That is correct.
Q. Just pausing there, Dr Worden. If something is handled
by NBSC and corrected straightaway, it doesn't make it
necessarily up the line to SSC, does it?
A. No. I mean there are various levels of recoverable
transactions. There is a recoverable transaction that
the subpostmaster can follow the instructions and can
fix it himself, there is the ones where he needs help
from NBSC, there's ones where he needs help from further
down, and there are failed recoveries where PEAKs are
involved. All of those things happen.
Q. In the case of a failed recovery, it can be sorted by
NBSC in some way or by a transaction correction without
referring to SSC?
A. That's a good question. I think the failed recovery
port usually involves not just NBSC, it involves MSU,
and there is quite a complicated process of guiding the
transaction through various states until it gets to the
F99 state.
Q. Can I just invite you to look at what Mr Coyne said --
A. Yes.
Q. -- having actually tried to identify through the
available disclosure how many PEAKs were referenced and
set them out. He says it is referred to by 2,473 other
PEAKs from over that range:
" ... each of these may (but may not) indicate a
similar issue with the horizon recovery process and
potentially creating a discrepancy within branch
accounts."
If we accept his definition of discrepancy and not
yours, yes?
A. This is all about temporary discrepancies in branch
accounts.
Q. Park the temporary discrepancy point about which we have
heard a lot.
A. Yes.
Q. What he has said there is correct in the number of PEAKs
as far as you know?
A. It is correct, yes.
Q. And it is scrupulously fair in how he has described it?
A. Well, "issue with the Horizon recovery process",
I believe these issues are how Horizon was designed.
Q. But what he's said there, he has carefully put "issue",
leaving open the availability of an argument between
experts about what the nature of the issue is, but what
he has scrupulously done there is perfectly fair, isn't
it?
A. I think so. I mean the difference between the experts
is that, to summarise something Mr Coyne said in his
oral evidence, he believes that these recovery processes
can be automatic. Now, I don't believe that. I believe
recovery of recoverable transactions is very complicated
and needs human intervention and things like failed
recoveries are inevitable.
Q. We can come back to that.
Can we look at now over the page -- I apologise,
stay on page 8, if we may.
MR JUSTICE FRASER: Are we going on to number 9?
MR GREEN: We are going on to number 9 at {D1/2/8}.
A. Reversals.
Q. Now, the description Mr Coyne gives is fair one, isn't
it, where he says:
"In April 2003 due to a failure in regression
testing, Horizon version S30 was released by Fujitsu and
this introduced a bug where the value of transactions
reversed by subpostmasters was shown twice in the amount
of the reversal in branch accounts."
That's a fair summary?
A. I think that's correct, yes.
Q. And --
A. Sorry, can I --
Q. You have said, beside it:
"Transaction reversals are a complex area which,
like recoverable transactions are less familiar to
subpostmasters and are more prone to human error."
A. Yes.
Q. "They lead to many calls to the helpline and to many
KELs and PEAKs - not necessarily related to any fault in
Horizon."
A. Yes.
Q. Now, you then refer to Mr Coyne's supplemental report at
3.99 to 3.101. He refers there to cash remming reversal
issue, and you say:
"Whether or not this was caused by a fault in
Horizon, all remming errors are detected by Horizon and
corrected by TCs ... therefore ... no lasting effect on
branch accounts."
So a slightly different context but the same point
about correcting remming errors is your response to what
he said?
A. That is my response to those paragraphs of his report.
Q. And the correction by transaction corrections is a point
that we can trace all the way back to Dalmellington?
A. Dalmellington is an example of it, yes.
Q. Then if we go over the page {D1/2/9}, we get to number
10, which I think is one that you accept in your list?
A. I do, yes.
Q. Can I just ask you about the entry in your appendix
table at {D3/2/129}, 5.93.
A. Obeng.
Q. This is a Catherine Obeng KEL.
A. Yes.
Q. And what you say about it, you have given your opinion
there. You say:
"This is further evidence of the failed recovery
report doing its job ..."
A. Yes.
Q. ... alerting Fujitsu -- "
MR JUSTICE FRASER: "Allowing".
MR GREEN: I'm so sorry.
MR JUSTICE FRASER: Or is it --
MR GREEN: My Lord, I think in 5.93 I think it says
"alerting".
MR JUSTICE FRASER: I'm so sorry. Yes.
MR GREEN: "... alerting Fujitsu to failed recoveries, so
they can investigate them and make any necessary
corrections to accounts."
A. Yes. Perhaps I should have said have "guided the
transactions to the correct state".
Q. Then you say:
"This was caused by a complex 'grey' communications
failure which could not be reproduced ..."
A. I presume I got the word "grey" from somewhere, but the
meaning I would mean is intermittent, come and go.
Q. Is this your wording, Dr Worden?
A. "Grey" is not my natural choice of terminology so I must
have got it from the KEL or the PEAK or something.
Q. Let's have a look at where you may have got it from.
Let's look at the appendix to Mr Parker's statement,
{E2/11/43}.
A. This is Fujitsu's analysis?
Q. The words here are:
"This is further evidence of the failed recovery
report doing its job ..."
A. Yes.
Q. Just to give you the wording you had in yours:
"This is further evidence of the failed recovery
report doing its job."
A. Yes.
Q. Mr Parker has the word "and", you have a dash.
And then:
"... alerting Fujitsu to failed recoveries to enable
them to investigate them and make any necessary
corrections ..."
A. Yes.
Q. And then a couple of lines down, you see:
"The incident was caused by a complex 'grey'
communications failure ..."
You took that from Mr Parker's appendix, did you?
A. No, I wrote my bit before that.
Q. So he may have taken it from you, we don't know?
A. He may have taken it. He definitely would know if they
took it from me.
Q. I see. But you are not sure where you got it from,
"grey"?
A. I think I must have got it from a KEL or PEAK somewhere.
Q. You are pretty sure that Mr Parker got it from you
rather than --
A. Absolutely, because I know the chronology. I only saw
the witness statement when it was issued, I had written
my report, and it is obvious from the terminology that
they use that they sometimes picked up my wording.
Q. I understand.
MR JUSTICE FRASER: And "grey" means intermittent?
A. To me, yes.
MR JUSTICE FRASER: And is that correctly -- or does that
match your understanding of what the words in brackets
of Mr Parker mean, where he I think describes grey?
A. "... network kept switching between good and bad; not
solid good or solid bad ..."
So that is very much the sense, yes.
MR JUSTICE FRASER: That's the same as your intermittent?
A. Yes, intermittent, yes.
MR GREEN: Can we look at a discrete issue in relation to
Drop & Go, if we may, for a moment, please, and look
please at {F/1848.8.2/1}. This is one of the more
recent PEAKs disclosed, this was disclosed on
30 May 2019. We are going to provide you with a copy.
I think we may have a copy of that.
A. Drop & Go I think is a business parcel service where you
can somehow jump the queue if you have got a card.
(Handed) Thank you.
Q. If we get that up on the common screen.
Sorry, do you want a tab, Dr Worden?
A. All right, thank you.
Q. To be fair to you, Dr Worden, this was only disclosed on
30 May. Do you know if you have had a chance to look at
this?
A. I do not think I have seen this PEAK. I have gone and
looked at what Drop & Go is, but not this PEAK.
Q. I understand. We can see it is created on
21st August 2018. You see it is opened just under the
"Progress Narrative", the start of the main box, date
21st August 2018, 15.43.56.
A. Yes, it is "Failed Drop & Go & Go Top Up". I understand
that is you have a card for Drop & Go and you top it up,
and some process decrements it when you send parcels and
it enables you to do them quickly.
Q. Now could we go over the page, please, to
{F/1848.8.2/2}, and you will see there:
"The mystery is how a top up of £30 came to be in
the Horizon basket without having been credited to any
Drop & Go account."
A. Yes.
Q. "We have heard anecdotals of other such occasions, but
never with adequate information to be able to
investigate."
A. Yes.
Q. You are aware, aren't you, I think, one of the closure
codes for SSC was that they didn't have adequate
information to investigate?
A. Yes, and that was a kind of a black mark for the low
level support, I think.
Q. If we go over the page to {F/1848.8.2/3}, please, this
is an instance of KEL cardc235Q. Do you see that?
A. Yes.
Q. Then it says:
"As stated in the KEL 'This may be an issue with
script ADCScript-CDBalanceTopUp or a user error ...'"
A. Yes. So they don't know if it is reference data error
or user error.
Q. They don't know whether it is a problem with the script
or a user error.
A. That is right, yes.
Q. And then immediately under that, Dr Worden, do you see
it says:
"Here are the keystrokes and messages from the
counter ..."
A. Yes.
Q. "... which might help Atos."
A. Yes.
Q. And we can actually see individual keystrokes being
entered?
A. Yes.
Q. And set out there?
A. Yes.
Q. And whatever we might have made of those lines of text
before, we can see they are actually described as
"keystrokes and messages from the counter"?
A. Yes.
Q. So:
"Button: WS-F-Home ..."
Etc. Do you see:
"Button: enter ..."
A. Yes.
Q. "Button: 0/OK to continue."
A. Yes.
Q. So, if you had understood from Post Office's evidence at
some point that keystrokes would have been available to
Post Office, this is the sort of thing that that would
look like, isn't it?
A. Yes, it is. But I do not think that is what it is.
Q. What do you think this is?
A. I think in frontline support Fujitsu had an operation
called TED, which I can't remember what the initials
stand for, but they look at event logs, and I think
keystrokes are in event logs and used by Fujitsu when
they are investigating a bug or a mystery of some kind.
Q. So you think that somewhere in the system through event
logs you can find these keystrokes?
A. I think so. I'm pretty sure of it.
Q. Pretty sure, thank you.
A. Yes.
Q. Now, what we see in relation to this, if I can refocus
your attention on the script that was identified in the
KEL.
A. Yes, the ADC script.
Q. Yes, it is the ADC script. It is the CD balance top up
script, isn't it?
A. Yes.
Q. If we go please to the fix, we find that at {F/1787.1/1}
A. Sorry, are we -- have we got there?
Q. That will come up in a minute. It is a document on
{F/1787.1/1}.
A. Right, okay.
Q. You will see here "Drop & Go Top Up Live Issue Fix".
A. Yes, that seems to be the same thing ... date and ...
yes.
Q. If we go over the page, please, you will see there is
a contents page?
A. So this is --
Q. Okay?
A. -- an Atos ...
Q. Then we go over the page to page {F/1787.1/3}. And this
was also disclosed on 30 May, so you may not have seen
this before?
A. No, I haven't seen this before. It is interesting.
Q. But if we look at page {F/1787.1/3}.
A. We're on page 3, yes.
MR JUSTICE FRASER: Can you just tell me the date of this
document?
MR GREEN: This document, my Lord, is dated 6th April 2018.
If we look under the table "Branch: Hasland":
"The Balance & Top Up APADC script ..."
And then in brackets we can see a number, and then:
"... CDBalanceTopUp ..."
So it is the same script, isn't it?
A. Yes. It is interesting that the fix report is concerned
with the specific branch where the problem came up.
There we are.
Q. Let's just take it in stages, if we may. It says that
the script had a bug in it --
A. Yes.
Q. -- and that it incorrectly allowed the transaction to
progress after an unrecoverable time out had been
identified?
A. Yes.
Q. This is resolved in version 6.12.
A. Yes.
Q. Do you see that?
A. Yes.
Q. They had also noticed a problem, immediately under that,
issue 2, that the same logic had been used for another
transaction, the open account transaction?
A. Right. I don't know what the open account transaction
is.
Q. Let's leave that on one side for a moment.
What we notice about this, Dr Worden, is that this
document, with quite a detailed explanation of having
identified the bug in the fix, is dated 6th April 2018,
isn't it?
A. I believe so.
Q. Then if we go back to {F/1848.8.2}, which is the PEAK
that we were looking at.
A. It is later, yes.
Q. It is later.
A. Yes.
Q. It is 21st August 2018.
A. Yes.
Q. And at that point we can see, if we go back to page 1 of
the PEAK, very kindly, we can see that Henk Bakker at
the Post Office, this is all a mystery to him
{F/1848.8.2/1}.
Because if we go over the page --
A. "... Accenture's finding ..."
Yes, right.
Q. -- he says {F/1848.8.2/2}:
"The mystery is how a top up of £30 came to be in
the Horizon basket without having been credited to any
Drop & Go account. We have heard anecdotals of other
such occasions, but never with adequate information to
be able to investigate."
So, Dr Worden, what we see from that is that
something for which there had been a detailed fix
description set out in a document in April was still
a mystery to Post Office dealing with that and other
anecdotals in August of the same year?
A. Well, could we go back to the beginning of the fix
report. The fix report obviously involves a different
branch from the branch here.
Q. Indeed.
A. And the question is whether it is the identical problem
or -- but it seems a closely related problem certainly.
Q. They both have a problem with Drop & Go top up, yes?
A. And that's presumably one or two --
Q. In the same script?
A. Do we know it is the same script in each case?
Q. We looked at the script. Do you remember I showed you
the script, it is the CD balance top up script in both
cases.
A. We haven't looked at the actual script.
Q. No, we looked at the name of the script in both cases.
A. The name is the same, is it?
Q. Yes, "APADC script CDBalanceTopUp script".
A. Yes. So a fix was made to the script which did not fix
that -- some problem subsequently emerged.
Q. Dr Worden, can I suggest to you it is not wildly
reassuring, is it?
A. Fixes sometimes go wrong, there is no question,
especially with reference data, which is not a Fujitsu
thing, it is Atos/Post Office. Fixes do go wrong
sometimes.
MR GREEN: I'm most grateful. Would that be a convenient
moment, my Lord?
MR JUSTICE FRASER: We will have a 10-minute break. If we
come back just a couple of minutes before 12 o'clock,
please.
(11.48 am)
(A short break)
(11.59 am)
MR GREEN: Dr Worden, we have now looked at ten example KELs
and in your first report --
A. Sorry, do you mean example ...
Q. Ten example bugs, we have just been through the first
ten, and we have seen your approach. On the basis of
the approach you have taken overall you derived some
figures for the maximum possible number of bugs
corrected for KEL sampling, creation and retention?
A. I do yes.
Q. And that was on the basis obviously of your approach?
A. Yes, my limited sample that I was able to take in my
first report and in my second report.
Q. Understood. If we look at {D3/1/173}.
A. Right.
Q. There is a table there. At the bottom we see in row E2
you have given a label, the bottom row:
"Maximum possible number of bugs, corrected for KEL
sampling, creation, and retention."
A. I think actually there may be a typo in the formula.
The calculation is actually done right, but I think if
you look at the formulae it is not quite ...
Q. There is no R, it is obviously referring to L.
A. L, that's right. You have identified it precisely.
Q. While we are on errors in the table, did you notice at
all that the figure at the top row is wrong?
A. Top row?
Q. The mean number of branches in PO.
A. Shall we correct that?
Q. Well, did you notice it was wrong?
A. I think that was an average I did based on some kind of
trend from -- because there were a lot at one stage and
it came down.
Q. It is not a huge deal, Dr Worden, but would you accept
from me that to get the number you derived you actually
have to add in the figures for 1999 in the source data
by accident and average over 20 years? That's the only
way we were able to derive the same figure you derived.
A. Okay, fine.
Q. It is correctly done on the approach you have stated you
are doing. It is 13,317, so not a huge difference.
A. Okay.
Q. I only mention it because you mentioned, where is R? So
it is the other minor --
MR JUSTICE FRASER: So am I right, bottom right-hand corner
should be E2 = L/X?
A. Yes, I think that's right.
MR GREEN: And if we focus on the figures you have come up
with, you say your conservative estimate is 672 bugs.
A. Yes -- no, my conservative one, yes, correct.
Q. Is 672. And what you call your central estimate is 145?
A. Yes, right.
Q. Now if we turn there, please, to the way you have
derived those two.
A. Yes.
Q. The formula you have got is E2 = R/X?
A. And it should be L/X.
Q. It should be L/X, we know that. No problem there.
A. Yes.
Q. You say the probability that a KEL is created and not
archived given that a bug occurs, and you have got two
different probabilities of that happening, 0.69 and
0.30?
A. Yes.
Q. And just translating that into real life, the
conservative one would be more likely to be right if
there was a greater headwind or inefficiency in the
creation of KELs?
A. That is right. The conservative one says this process
is really pretty inefficient.
Q. Yes. And because you don't know about the facts of all
that, you have given two examples?
A. Yes. And indeed the whole table, if you like, is my
assumptions, which are only assumptions of fact, and if
the court finds different on any entry of the table it
is designed so that the court can put its own finding in
and recompute.
Q. But even on your approach, which fed into the figures,
yes, we have got 672 bugs conservative estimate and
central estimate of 145?
A. Yes. And the key thing that drives that is the size of
the sample of KELs I was able to sample.
Q. Dr Worden, we understand that it is a prisoner to your
approach but I'm just clarifying.
A. Yes.
Q. And in terms of number of affected branches by
particular bugs, could we look at {D1/2/3}, please.
Let's just have a glance at the numbers in the first few
fields there to get our eye in.
Receipts and payments mismatch affected about 60,
possibly 62 branches?
A. Yes.
Q. Callendar Square, 30.
A. Yes.
Q. Local suspense, 14.
A. Yes.
Q. And Dalmellington, 88. So that gives us a feel for
the --
A. Well, Dalmellington 88 I would put on a separate
category because, as I say, Dalmellington was not
something that came to Fujitsu's attention and so it
went on for a long time.
Q. Okay.
Bug 6(i) on page 5, 57 branches?
A. Well, that's not a bug as far as I see.
Q. Okay. {D1/2/5}
If we take an average of the first four bugs, which
I appreciate you disagree with Dalmellington, but the
average of that is 48 affected branches per bug of the
first four bugs?
A. Yes. I mean I should just say briefly it is not the
approach I took.
Q. I understand. I'm just following through the maths,
that's all, on an assumption.
A. Yes.
Q. And if we were to take that approach, 144 bugs affecting
48 branches each.
A. This is the central estimate?
Q. Yes, if we look at your central assumption of 145 bugs
affecting 48 branches per bug.
A. Yes.
Q. On average.
A. Yes.
Q. If that were a reasonable average, that would result in
6,960 incidents?
A. Yes.
Q. And if we looked at 672, which is what you describe as
your conservative estimate.
A. Yes.
Q. And we multiply that by 48, that would be 32,256 --
A. I agree with those figures.
MR JUSTICE FRASER: You are going really quite quickly.
MR GREEN: I'm so sorry, my Lord. The first one was 148 --
MR JUSTICE FRASER: So you multiply that by the 48 and you
get to the 6,960. And then your second one was taking
the 672, multiplying it by 48, and getting to 32,000.
MR GREEN: 256.
MR JUSTICE FRASER: Yes.
A. This is not a calculation I have made, of course.
MR GREEN: I understand, Dr Worden.
MR JUSTICE FRASER: That's rather why I'm trying to get
Mr Green to go a bit more slowly.
MR GREEN: I'm grateful, my Lord.
MR JUSTICE FRASER: Right.
MR GREEN: And if we used an average more favourable to the
Post Office of 40, we would get a figure of 5,800 for
the 145 and we'd get a figure of 26,880 incidents for
the conservative estimate of 672.
A. Yes.
Q. There are only 550 claimants and even with few multiple
branches and a few people having been affected by more
than one instance, on your definition of consistent, the
figures we have just been looking at are consistent with
the complaints made by the claimants in this case?
A. Let me think about that. In the sense of the
calculation you have done, I hesitate to comment.
Q. No, I'm just asking the question. Those figures are
consistent on your definition?
A. They are not consistent in terms of financial impact
which is the only thing I calculated.
Q. We have got your point on being corrected. Let's leave
that to one side.
A. Yes.
Q. On actual incidents of bugs affecting branch accounts,
we have got your point on subsequent correction, but
those figures are totally consistent --
A. Well, let's work it out. Which figure do you want to
take?
Q. Well, there are -- let's take 32,256.
A. Let's take the 32,000, okay. Then what I would say is
that claimants were in branches and held branches for
52,000 months, I think.
Q. So you do the average incidents across everyone and
scale it back?
A. What I would say is over the whole population of
Post Office there were 3 million monthly branch
accounts, and claimants had 50,000 of them, so we have
to do that division and I can't do it on the spot.
Q. We are back to Penny Black on that point, aren't we?
A. No, we are not. We are doing a multiplication, a plain
multiplication.
Q. Okay.
A. I would have to write it down. So what we are saying is
you start with 32,000 occurrences of a bug, and I say
claimants held branches for 50,000 months --
Q. This is branches hit, not occurrences, so this is --
A. Yes, absolutely. But each branch was hit in a month --
Q. At least once.
A. Yes. And we have to take 50,000, we divide it by
3 million, and what I get from that is I can cancel all
the thousands out and I get 32 x 50/3, so that is about
500. So it is consistent with one occurrence of a bug
to each claimant branch during their tenure.
Q. Thank you, Dr Worden. Consistent with a branch with one
occurrence of a bug -- one or more occurrence of a bug,
but at least one bug affecting a claimant branch and
that bug being a bug of a type that impacts branch
accounts?
A. What we have calculated is the mean, so some branches
are affected by more, some less etc, and that's what
that calculation would suggest, the conservative one.
I think that's one of the conservative numbers, isn't
it? The central estimate would give a smaller number.
Q. Yes.
Can we move forward to audits, please. Now, can we
look, please, at {D1/4/5} which is the joint report
number 3. If we look at paragraph 3.23.
A. Yes.
Q. You explain that your opinion in relation to
countermeasures is based on the fact that Horizon is
a tightly run ship -- sorry, you base your opinion that
Horizon is a tightly run ship:
"... on the high quality of documentation, design
review, and testing evident in many of the documents I
have read; on the Ernst & Young service audits of
Fujitsu which found a high level of controls to be
effectively implemented ..."
Yes?
A. Yes.
Q. That's salient because high level of access controls is
one of your robustness features?
A. Yes. There's something in the joint statement about if
there is a poor level of access controls that is a black
mark against robustness.
Q. Indeed. Are you aware that the type of audit that EY
was carrying out that I think you are referring to is --
there's one management letter for 2011 and then there
are the other service audits which you have referred to?
A. Yes.
Q. From 2012 onwards?
A. Yes.
Q. But there was nothing before -- there were no service
audits before 2012?
A. None have been disclosed certainly, yes.
Q. What we have, I will show you, is nothing on this before
2010, then we have the 2011 audit, and then we have
service audits which you have referred to from 2012
onwards.
A. That is right, yes.
Q. Now, let's look first if we may at the 2010 audit, it is
at {F/646.1/1}. This is a Royal Mail document.
If we go to page {F/646.1/2}. If you look at the
second paragraph?
A. "In order to make our audit approach ..."
Q. " ... we seek to rely on SAS 70 audits. These audits
are independent audit reports over the control
environments of the group's IT suppliers. Whilst we
were able to ..."
MR JUSTICE FRASER: Where are you reading from?
MR GREEN: The second paragraph, my Lord.
MR JUSTICE FRASER: The one that starts "In order to"?
MR GREEN: Exactly, my Lord:
"In order to make our audit approach as efficient as
possible, we seek to rely on SAS 70 audits. These
audits are independent audit reports over the control
environments of the group's IT suppliers. Whilst we
were able to place reliance on this third party testing
for one of the Group's suppliers, CSC, we were unable to
place reliance on Fujitsu, due to a SAS 70 audit report
not being available."
Yes? And we see there:
"The Fujitsu control environment is bespoke to POL
and therefore the cost of a SAS 70 is borne entirely by
POL, whereas for CSC the control environment is similar
for a number of companies and therefore the cost is
shared."
You see?
A. Yes.
Q. "The cost of Fujitsu obtaining a SAS 70 audit was
prohibitive; therefore we have performed our own
independent audit procedures to obtain assurance over
the Fujitsu IT general control environment."
Now, pausing there, the SAS 70 audit, do you know,
is a predecessor of the service audit that you are
referring to?
A. Well, it seems that the SAS audit is a general kind of
audit that many suppliers go through, yes.
Q. Do you know as a matter of your expertise and experience
in IT whether or not the SAS 70 audit was later
superseded by the ISAE 3402 audit?
A. I don't particularly know that.
Q. You don't know that?
A. I don't.
Q. If we just go back up for a moment, do you see in the
top paragraph halfway down on the right-hand side
towards the right-hand side, "Key individuals"? Halfway
down the first paragraph on the right-hand side?
A. Yes, right:
"... Group IT function ..."
Yes.
Q. "Key individuals within the Group IT function are
responsible for managing third party suppliers,
particularly the outsourced service provided, CSC, and
delivery of our audit information requests."
A. Yes.
Q. "Whilst some improvements were noted in the POL IT audit
process, we continue to face difficulties in obtaining
accurate information from Fujitsu, one of the outsourced
providers of POL IT systems."
A. Yes.
Q. Now, had you considered this document at any point?
A. I certainly considered this document. I must admit that
the introductory paragraphs -- I tended to go straight
down to the table of observations.
Q. I understand. But this one doesn't actually have
a table of observations.
A. Sorry. Well, this is just a letter, is it?
Q. Well, this is what we have got from Royal Mail as
a result of Royal Mail providing disclosure that was
invited by the court.
A. Right. I'm confused a bit. I thought it was the
management letter that --
Q. No, no. We will take it in stages. This is 2010.
A. Okay, yes. Sorry, I was confused about that.
Q. That's all right. If we come down, "Control
observations"?
MR JUSTICE FRASER: Have you seen this document before or
can't you remember?
A. I do not think I have if that's the case.
MR JUSTICE FRASER: All right.
Go on, Mr Green.
A. Obviously I'm thinking about the Ernst & Young
management letter which has the table and all that.
MR GREEN: Okay. Well, let's take it in stages because
there is a distinction between an audit and a service
audit, we will come to that.
A. Yes.
Q. Let's focus on this one, if we may. In relation to
control observations, it says:
"POL has made significant changes to its IT
environment in 2010."
A. So this is a year earlier really than the Ernst & Young
letter.
Q. Yes.
A. No, I haven't seen it.
Q. And it is reporting that:
"Post Office Limited has made significant changes
... resulting in the inclusion in scope of the Credence
application for the first time."
A. Yes.
Q. So from this we learn that Credence was outside any
scope of reporting prior to that?
A. Outside the scope of certain previous audits?
Q. Yes.
A. It seems so, yes.
Q. So not only do we not have any service audits prior to
this, but we also know that Credence itself wasn't part
of any audits if any were taking place.
A. Yes, whereas for instance POLSAP may have been.
Q. Exactly. It says:
"During 2010 POL also worked with Fujitsu to deliver
a new version of the Horizon application used at and in
support of Post Office branches."
A. Sorry, I'm not ...
Q. In the same paragraph.
A. Which paragraph are we on, sorry?
Q. Under "Control Observations" --
A. Yes.
Q. -- there is a paragraph immediately below that heading
and three lines down.
A. "POL also worked with Fujitsu ..."
Yes.
Q. It says:
"This new version of Horizon was also included in
scope."
So it is not clear from that whether the old version
of Horizon was included in any scope of previous audits.
A. That is right.
Q. Then it says:
"Following difficulties in performing the IT general
control procedures with Fujitsu in 2009 a new key
contact was identified to assist in the management of
the IT general controls procedures with Fujitsu.
However, challenges were again experienced in obtaining
audit evidence in a complete and timely manner from
Fujitsu, resulting in significant delays in completion
of the IT general control procedures."
Now, pausing there. If you are keeping proper
records of access controls, for example, those should be
readily available and collated in real time, shouldn't
they?
That's not meant to be a controversial question.
A. I do not think it is controversial.
Q. It is pretty clear they weren't?
A. Well, the challenges were experienced, and I don't know
what challenges they were.
Q. If we go to the next page {F/646.1/3}, please. At the
top of the page "Status on 2008-09 management letter
points":
"In 2008 and 2009 we noted third party users with
SAP_ALL access (unlimited access to the SAP systems). In
2010 we found that only select individuals and user-ids
had this access and controls had been established to
monitor actions of users with SAP_ALL access and to
periodically review the requirement ..."
So there had been a dramatic improvement on the face
of that to the prior situation, had there not?
A. It seems that before that certain third party users,
I don't know which third parties, had some SAP_ALL
access, which sounds a bit powerful, and in 2010 some
improvement was made. I don't know about dramatic but
certainly there was an improvement, yes.
Q. "Sounds a bit powerful", is that like Emperor Hirohito
saying "the war has developed not necessarily to Japan's
advantage" before surrendering?
A. Again, I don't know whether SAP_ALL access is read-only
access, for instance, or has some permissions to do
things. I don't know what SAP_ALL access is.
Q. Is there a clue in the brackets:
"... (unlimited access to the SAP systems)."
A. It doesn't tell me immediately that changes could be
made. Somebody could get in and look at things.
Q. But it is consistent with the possibility --
A. Absolutely.
Q. -- that that is the case?
A. Yes, it is consistent with that.
Q. If we look at "2010-11 Challenges":
"The challenges the Group faces in 2010-11 will be
the continued transformation of IT and the delineation
of IT services provided by CSC and Fujitsu."
A. Sorry, could I just skip back very briefly, about these
challenges getting stuff out of Fujitsu. This was the
time when Fujitsu were in the throes of (a) maintaining
old Horizon and getting new Horizon tested and so on, so
that might have something to do with the challenge.
Q. So you are trying to thinking up an excuse for
Fujitsu --
A. No, I'm not, I'm just trying to think about what was
going on.
Q. Let's go forward if we may, please. We are going to
look at the 2011 audit. Now, let's look first at the
management letter. This isn't a service audit, we will
have a look --
A. No, this is the management letter, fine.
Q. The management letter. Do you understand the difference
between an audit and a service audit under SAS 70 or
ISAE 3402?
A. Obviously they are very different kinds of audits. One
was the management of POL and it was part of their
overall audit, whereas the service audit was
specifically what it said it was and we have read all of
that.
Q. Yes, service audits are a bit different to audits
generally?
A. Yes.
Q. This is a management letter, 2011. It is on {F/869/1}.
You were here for Mr Coyne's re-examination?
A. Yes.
Q. And you heard his evidence about what was raised in this
audit?
A. Yes.
Q. If we look at page {F/869/2}, the purpose of the
management letter was not focused on IT systems because
this is a general audit?
A. Yes.
Q. "Our review of the company's systems of internal control
is carried out to help us express an opinion on the
accounts of the company as a whole."
A. Yes.
Q. "This work is not primarily directed towards the
discovery of weaknesses, the detection of fraud or other
irregularities ..."
A. I haven't got this. Where are we?
Q. At the beginning of the paragraph:
"This work is not primarily directed towards the
discovery of weaknesses, the detection of fraud or other
irregularities (other than those which would influence
us in forming that opinion) and should not, therefore,
be relied upon to show that no other weaknesses exist or
areas require attention."
If we look at the next page {F/869/3}, the executive
summary.
A. Yes.
Q. If you come down to the second paragraph, the end of the
second paragraph says:
"The recommendations we have made in this report
should be seen as refinements rather than fundamental
control deficiencies in comparison."
Yes?
A. Yes.
Q. Then it says:
"The main area we would encourage management to
focus on in the current year is improving the IT
governance and control environment."
A. Yes.
Q. So this was a concern at this point and I think that's
common ground now?
A. A ...?
Q. This was a concern they were expressing?
A. Yes, absolutely. There are two separate concerns. "IT
governance" seems to me to go to the recommendations
about POL controlling things, and "control environment"
is access to systems and so on and so forth, and there
are both of those there.
Q. Okay. We see this is the passage that Mr Coyne set out
in his -- referred to in his report and was
cross-examined about extensively?
A. Yes.
Q. And you heard both the cross-examination and
re-examination?
A. Yes.
Q. I'm not going to take you through all that, Dr Worden,
but you heard that there were a number of concerns
expressed in relation to generic accounts and certain
other things, yes?
A. Yes.
Q. And we are going to go now to the PEAK about the use of
APPSUP and have a look at that at {F/768/1}, if we may.
A. Right. I will get the PEAK folder.
Q. If we just look at that here. We have seen this several
times before.
A. Yes.
Q. If you see it starts -- in the "Progress Narrative", it
starts on 1st February 2011.
A. Yes.
Q. It says:
"Details entered are:
"Summary: SSC database users do not have correct
permissions."
A. Yes.
Q. Underneath "Impact Statement", we have user and date.
A. Sorry, where is impact?
Q. Just go up.
A. Yes, I see impact there.
Q. Would you like a hard copy of that PEAK?
A. I was expecting one but I may be able to get on with the
screen.
(Handed) Thank you.
Q. We will give you one anyway in case you prefer a hard
copy.
You can see about 40% of the way down the page the
"Impact Statement" box?
A. Yes.
Q. There's user, Dave Haywood. Date, 6th May 2015. Do you
see that?
A. Yes.
Q. So this is spanning a period from 1st February 2011 to
May 2015.
A. Yes.
Q. You didn't actually deal with APPSUP in your reports,
did you?
A. No, that is right, I didn't.
Q. And it is a very powerful tool?
A. What's a powerful tool?
Q. APPSUP. It is a very powerful --
A. APPSUP is a powerful -- well, it says here APPSUP is
a powerful role.
Q. Yes, it is a very powerful role, I should say.
A. Yes.
Q. And Mr Coyne identified it --
A. Yes.
Q. -- through his enquiries. And if you look underneath
Dave Haywood's name there is a box with four points
listed?
A. Yes. Number one is --
Q. Number one is:
"SSC users affected have more access than is
required to database resources. This is contrary to
security policy."
A. Yes.
Q. Your robustness measure has two facets to it. It is to
have an appropriately typed security policy and to
follow it?
A. That's part of it. And as I say, if there is great lax
in security policy that poses a threat to robustness.
Q. Indeed.
A. But I would emphasise if security policy is really flaky
then you start worrying about robustness.
Q. If you have an inadequate security policy, that poses
a threat to your robustness countermeasure?
A. And it is proportional in the sense of the more
inadequate it is, the bigger the threat.
Q. Yes. And if you have a perfectly acceptable security
policy but it is not followed, you have got the same
problem?
A. Yes, I mean security policies change over time and
sometimes --
Q. It is a simple question.
A. Yes.
Q. And if the matter upon which the security policy is not
followed is effectively an incredibly powerful role,
that amplifies the significance of the security policy
not being followed?
A. It does amplify it. If you are calculating impact, then
impact is something to do with how much more powerful
the role is and how much you trust the people that have
that role, and I think SSC were fairly trustworthy.
Q. You haven't actually met them?
A. No, I haven't, but I have read loads of PEAKs and KELs
by them.
Q. Number 2:
"There is currently no 'cost' to this issue."
A. Cost is in inverted commas, I don't know quite what that
means.
Q. Let's leave that.
MR JUSTICE FRASER: Where are you?
MR GREEN: Just under "Impact Statement" in that 1 to 4
list:
"3. Perceived impact: the customer is not aware of
this problem or change."
A. Yes.
Q. So Post Office is not aware of this?
A. It seems so.
Q. So they might be proceeding on the footing -- or would
be proceeding on the footing that the security policy
was being followed and there were not inappropriate or
incorrect permissions being given to SSC?
A. That is correct.
Q. If we look at this, the yellow box at the bottom on your
hard copy or on the screen, 1st February 2011, 11.57.35.
Mark Wright is the user:
"Development have delivered scripts to allow SSC
users to perform certain tidyup tasks (like clear failed
recoveries). However they have been delivered to work
against an SSC role which SSC users have not been
granted as SSC users have the APPSUP role."
A. Yes.
Q. So what had actually happened was there was a tiny
tidyup task script produced by development, which was
usable by SSC role.
A. Yes.
Q. The problem was that the people in SSC were using the
much wider APPSUP role and hadn't been granted the SSC
role because they didn't need to use it?
A. Yes. I mean I don't know how many different roles there
were in play.
Q. Yes, but --
A. Certainly APPSUP was powerful. SSC didn't have the role
for this script. That's clear here.
Q. But the significance of it, Dr Worden, is this, isn't
it, there is a rather small tidyup script -- I don't
mean to disrespect the ambit of that script -- but it is
not the largest sounding task, is it, tidyup? I mean it
might mean making some changes?
A. Well, failed recoveries, we have seen all these PEAKs
about failed recoveries, so it is significant.
Q. So it is significant?
A. Yes.
Q. And that has been assigned, a specific script has been
developed for that specific task which needed to be
addressed?
A. Yes.
Q. And the development had provided that script on the
footing that the permission was the SSC role would be
able to use it?
A. Yes.
Q. And the reason that there is a problem that we see
throughout this PEAK is because the people in SSC didn't
have the SSC role. They were using the APPSUP role?
A. "... delivered scripts ... However they have been
delivered to work against ..."
"An" SSC role, it says. So there may be several
different SSC roles.
MR JUSTICE FRASER: But whichever -- on the face of it,
whichever role the script has been designed to work
against --
A. They haven't got it.
MR JUSTICE FRASER: They haven't got it.
A. No, I think that is right.
MR GREEN: The next paragraph:
"Either SSC user creation/configuration needs to be
amended to make sure we have ALL required permissions of
the scripts will need amending to match how our users
are set up in live."
A. I think it is a typo.
MR JUSTICE FRASER: Should it be "all" and not "of", do you
think?
A. I think so.
MR JUSTICE FRASER: It does read like that. But there are
two options and they are in that line, is that right?
A. Yes.
MR JUSTICE FRASER: You either change the role so it matches
what the script has been designed to work against or you
change the scripts?
A. Yes.
MR GREEN: Exactly.
A. I think later in this PEAK there is concern about
development doing one thing with scripts and it takes
time. There is concern about delays in the process
getting the permissions right for the scripts, I think.
MR GREEN: Yes, quite. There is discussion of that in the
email -- discussion of that below.
A. In the PEAK?
Q. In the PEAK. It says:
"Please see email details below describing in more
detail."
Then we have the detail of the problem.
A. Sorry, where are we now?
Q. Still on the first page:
"(1) The user creation scripts provided by
development offer the option to create each user type
...
"(2) When we created SSC users for BDB/BRS etc. we
used ?appsup? as that is what ssc have always been and
what they migrated as on Horizon databases."
A. Yes, I'm not quite --
Q. So it looks as if APPSUP has been used throughout.
A. It looks like it, yes.
Q. "(3) It became clear that there is also an ssc role
which we now know is a requirement for the scripts you
refer to."
A. Yes.
Q. The scripts you refer to lose any permissions that are
in the APPSUP role and not in the SSC role?
A. These two sentences appear to imply that although it is
"an" SSC role, it is really referring to one SSC role.
Q. It looks like it, doesn't it.
Then:
"(5) We could grant you the ssc role as well and a
call could be passed to development to include in the
user creation script when ?ssc? is chosen as the group
but that seems wrong as well."
Then it says:
"It all comes down to user administration and the
incorrect assumption that adding a user is obvious and
doesn't need some more detailed documentation other than
the current doc which says just add the user with the
relevant roles and on the relevant servers ? head, brick
wall and all that."
A. Yes.
Q. "We can certainly add the SSC role to all users on
BDB/BRS in the short-term but I would need to be sure
that a call was with development for a formal review and
rethink."
Then there is discussion of this throughout the PEAK
and you are obviously quite familiar with this PEAK
because you have been referring to what happens later?
A. Yes, not massively but I have reviewed it.
Q. If we go to page {F/768/2}, Andrew Gibson at the top of
page 2 says:
"I thought the original issue was why have the SSC
users not had the SSC role granted? If it is a bug in
the creation scripts then yes, needs dev to fix but I
thought something was said the other day about the SSC
users not being set up correctly at the start?"
He is right about that in the sense that this is in
February 11, there may be some concern about whether it
was right for SSC users to have been set up in the
APPSUP role, yes?
A. Well, I mean, just more generally -- I don't disagree
but more generally this illustrates that it is
a complicated area and that PEAK is a kind of stream of
consciousness and it is quite difficult to pull the
right things out of it.
Q. Well, look at what Anne Chambers says on page 2, halfway
down. 1st February, Anne Chambers to Andrew Gibson.
She makes it pretty clear. She says:
"Unfortunately development write their scripts
explicitly to use ssc. So I think we're stuck with it
unless they deliver new scripts (which would not be a
popular or quick option)."
A. That is a reference to delays in it.
Q. Yes. Then look what she says there:
"When we go off piste we use APPSUP. Can we have
both??"
A. Yes.
Q. What do you think she meant by off piste?
A. Well, there is two possible things I think she might
have meant. One of them is when we do things we are not
supposed to do, and one of them is when we do things
that are abnormal and difficult and tricky and we have
to not use the usual tools, may have to do something
special, like going off piste in deep snow, not doing
what we usually do.
Q. And would you accept that your two categories are not
necessarily hermetically sealed?
A. Absolutely. It is complicated. Yes.
Q. I won't take you through this in too much detail but if
we go over the page to {F/768/3}, briefly. The third
yellow box down. There is no difference between you and
Mr Coyne in that the optional APPSUP role is extremely
powerful?
A. Yes.
Q. If we go to the bottom of the page --
A. Sorry, I was just trying to read the rest of this
paragraph again before we move down.
Q. Do you mind if we --
A. Sorry, go on.
Q. Because part of it is repeated where I'm taking you at
the bottom:
"As per the previous PEAK comments", do you see in
the bottom yellow box?
A. Yes.
Q. "As per the previous PEAK comments, the role 'APPSUP' is
extremely powerful and should only be used under extreme
circumstances and under MSC supervision. As such the
Branch Database design was that 3rd line support users
should be given the 'SSC' role, which is effectively
read access."
Yes?
A. Yes.
Q. And then next line down:
"SSC team members should only have to [access] BRSS
for normal support investigations unless the information
has not replicated in time. SSC should only given the
optional role 'APPSUP' temporarily (by Security Ops
authorisation/emergency MSC) if required to make
emergency data amendments in BRDB Live."
A. Yes.
Q. Then it says:
"It is a security breach if any user write access is
not audited on Branch Database, hence the emergency MSC
for any APPSUP role activity must have session logs
attached under the MSC."
Pausing there. You hadn't picked up on APPSUP
itself as a role in your reports?
A. I do not think it is mentioned in my first report, no.
Q. Or in your second, can you remember?
A. I'm not clear, I'm afraid.
Q. And you weren't aware that there was in fact a standing
MSC for particular changes to be made, were you?
A. A standing MSC, what do you mean by that?
Q. Were you here what we looked at the MSC at {F/1844/1}?
We won't go to it now because it is a huge document.
Were you aware of what the position on the MSCs was
when you were writing this report about this APPSUP --
A. The discussion of standing MSCs and so on I believe is
quite recent.
Q. Yes, but you weren't aware of it when you wrote your
report?
A. No, not then, no.
Q. If we go please to page {F/768/7}, you can see that in
April -- 10 April 2013, Andy Beardmore?
A. 11.20, yes?
Q. At 11.20.18:
"The initial motive for this PEAK was to ensure all
SSC users had the SSC role assigned to be able to
execute the data correction toolset on BRDB."
That is the tidyup one.
"Initially the SSC users were manually set up
incorrectly ... being given the same permissions as per
Horizon, and had too many privileges via the APPSUP
role."
Pausing there, we can see that this is a reference
to them all having the privileges of the APPSUP role --
A. He seems to be recapping what we have been through.
Q. Yes. And then if you see -- let's just follow it
through:
"Host-Dev have delivered the live scripts to ensure
new SSC users have the correct permissions, but a
follow-on MSC is required to adjust the privileges of
existing users. Graham Jennings rejected this response
as the approach is not consistent across the older
Horizon DB's. The fact is that HNG-X did not include
this change to these Horizon environments, so I believe
this to be a mute point for this PEAK but more of an
interest for PCI and other Audits. As such I am
transferring this PEAK to the new security architect
Dave Haywood for further consideration of tidying up any
existing SSC users on BRDB with APPSUP role, only to
have RESOURCE & SSC roles."
A. Yes.
Q. Now, it looks as if there's tidying up going on at that
stage but we can see immediately above that box there is
a 5th October 2012 release?
A. A reference to the release PEAK, yes.
Q. Do you see that release PEAK?
A. Yes.
Q. Will you accept from me that that release PEAK actually
stopped new people at SSC having the APPSUP role but not
existing, or do you not know about it?
A. I don't know, no.
Q. If we go to the bottom of the page, the last yellow box,
2nd July 2014, 11.17.20:
"Only new users are given the correct permissions.
Existing user permissions are copied into the new builds
and hence will not be corrected by Belfast Refresh.
Suggest an audit of Live and Test is required to:
"(1) identify existing AD accounts of Oracle users.
"(2) identify SSC users from (1).
"(3) run a one-time script (based on the permission
scripts already delivered) to set the SSC user
permissions correctly."
So July 2014 they are still looking at that. It
says:
"The above activity can be performed under MSC but
must be trialled in the Test environment before being
changed in Live to ensure no adverse side-effects are
encountered. Given the existing permission change
scripts for new users were delivered some years ago, the
probability of the change causing any unforseen issues
is thought to be low."
Then at the bottom Mr Haywood, 6th May 2015:
"The Business Impact has been updated:
"1. SSC users affected have more access than is
required to data resources. This is contrary to
security policy."
A. So he is currently repeating what's at the top of the
PEAK.
Q. Well, that's come from the top of the PEAK. What
happens is the PEAK is updated, do you see? Go back to
page 1. The peak is updated --
MR JUSTICE FRASER: Just wait until we get to page
{F/768/1}. Yes.
MR GREEN: On the first page, the PEAK is updated by
Mr Haywood in May 2015.
A. Yes, the same date on both.
Q. Yes. So we can see by the statement:
"SSC users affected have more access than is
required to data resources. This is contrary to
security policy."
Has come from his entry on 6th May 2015 on page 7?
A. It certainly looks like it, yes.
Q. That suggests, doesn't it, very clearly, that even in
2015 the security policy was still being breached as we
have seen?
A. It seems to have run through that period, yes.
Q. You haven't picked up on that because you hadn't read
that PEAK when you did your reports?
A. My report doesn't acknowledge that it ran for that long,
that is correct.
Q. And you hadn't picked up on it before then, or had you?
A. The final date -- no, I hadn't spotted it.
Q. And you hadn't actually reported on APPSUP itself?
A. I hadn't -- no, APPSUP I haven't --
Q. Okay. Can we just go quickly back, with that in mind,
to {F/869/1}, which is the EY audit 2011.
A. The Post Office general audit.
Q. That's it. The general audit, not the service audit.
I would like you to look at page {F/869/32}, please.
You can see -- do you see at the bottom ...
Let me just find -- sorry, can I do this slightly
differently. At the top of 32 -- sorry, can you come
and show me where it is because I was going to go to
a different one. (Pause) Thank you very much.
Sorry, do you mind if we just start at page
{F/869/33}.
A. Right. So 32 was POLSAP and 33 is HNG-X.
Q. Let's just come down, if we may, from -- because it is
the way the pages are paginated. HNG-X is in the middle
of 33, and underneath it says:
"There are inappropriate system privileges assigned
to the APPSUP role ..."
A. Yes.
Q. That's specifically what we have just been talking
about.
A. Yes.
Q. "... and the SYSTEM_MANAGER role at the Oracle database
level ..."
A. Yes.
Q. And then it says:
"There is inappropriate privileged access at the
Oracle database level on the Transaction Processing
System server ..."
Yes?
A. Yes.
Q. And the comment alongside that in the recommendation on
the right is:
Where it is unavoidable to remove SAP_ALL and
SAP_NEW access, it is recommended that a periodic review
of the activities executed by the accounts granted
permanent SAP_ALL and SAP_NEW access is performed to
gain assurance that no inappropriate or unauthorised
activity has been performed which may adversely impact
the financial statements."
Do you see that?
A. It seems to me the two columns have got out of sync here
because HNG-X is not to be lined up with a SAP
recommendation.
Q. Okay. So that appears to relate to what we have on page
{F/869/32}.
A. Yes, I think the SAP relations have come down from 32.
Q. Let's look at page 32.
A. Yes.
Q. What they are saying alongside that is they have
identified those profiles, and I will show you about
that a bit more in a minute. And across to the right on
page 32 you see, under "Recommendation":
"Where access is deemed to be inappropriate this
access should be revoked immediately."
A. That's way up the top.
Q. Yes.
A. Does that refer to the previous page, for instance?
Q. It is not immediately clear. That's why I was trying to
be fair, Dr Worden, by showing you both together.
A. No, but I'm saying we've had this hang-down of that thin
column from one page to the next. This one on 32 might
be a hang-over from 31. I'm just ...
Q. Well, the way it seems to work is if we look at the
bottom of 32, 32 is dealing with POLSAP.
A. And POLSAP is bleeding onto the next page.
Q. And it is bleeding onto the top of page 33. So the
bottom of 32 says:
"The SAP account was not locked. This does ..."
Then when we look at the next page:
" ... not meet recommended practice of removing all
profiles from SAP and locking the account."
A. Yes. It seems SAP goes right the way to the bottom of
33, because it is talking about SAP, all roles.
Q. Indeed. So if we go please now to page {F/869/29}.
Number 3, just reading down into this section:
"Strengthen the change management process.
"Rating: high."
A. Yes, we are on a different topic now.
Q. That is a different topic, okay?
A. Yes.
Q. And on page {F/869/30} they deal with HNG-X there?
A. Yes.
Q. This is on the change management topic at the moment.
A. Right.
Q. And it says:
"Based on a testing sample of 15 back end changes,
ten counter changes and five manual changes deployed to
the HNGX live estate during the audit period we noted
the following:
"For 15 back end changes, ten counter changes and
five manual changes evidence of testing by POL was not
retained."
A. Yes.
Q. Now if you have got a well documented system that
evidence will be retained, won't it?
A. Well, this is Post Office not doing their job rather
than Fujitsu not doing their job, I think.
Q. Understood. But if Post Office are testing it and
supposed --
A. They should keep proper records and they haven't done.
That's what it seems to say.
Q. -- they haven't. Because the point of retaining the
documentation is you can tell whether something has in
fact been done or not?
A. Yes.
Q. It then says:
"For ten counter changes, evidence of POL approval
of the change to be deployed across the counter estate
was not retained."
A. Yes, this is getting sign-off and retaining sign-off.
Q. And:
"... manual change, evidence of POL authorisation to
begin development (i.e. a signed off CT document) was
not retained."
Yes?
A. Yes.
Q. And if we go up to page {F/869/31}:
"For one manual change, approval was not
obtained --"
A. Sorry, I've lost you -- oh, right, we're coming forward
29, 30, 31. Yes.
Q. Yes, 31:
"For one manual change, approval was not obtained
from POL prior to the change being implemented."
Do you see that?
A. So all of this is saying POL need to be involved or
formally to record stuff.
Q. Yes. Then if we look immediately under that, we see
"All in-scope applications".
A. "... are not usually involved ..."
Yes.
Q. "... not usually involved in testing fixes or
maintenance changes to the in-Scope applications;
"We were unable to identify an internal control with
the third party service provider to authorise fixes and
maintenance changes prior to development for the
in-scope applications."
A. And the service provider is Fujitsu, is it?
Q. Yes.
"There is an increased risk that unauthorised and
inappropriate changes are deployed if they are not
adequately authorised tested and approved prior to
migration to the production environment."
A. Yes.
Q. So that's in relation to the change management point,
yes?
A. Yes.
Q. Then:
"We reviewed privileged access to IT functions
including access to user administration functionality
across all in-scope applications and their supporting
infrastructure."
A. Can I pause there. "Privileged access" to my mind is
associated with the DBA function rather than the SSC
function.
Q. Yes. So, so far we have hit the control environment
generally, the changes?
A. Change management, yes.
Q. Then this bit you are suggesting relates to the DBA
function rather than SSC?
A. I generally associate "privileged user" with that lot
really.
MR GREEN: Understood. My Lord, is that a convenient
moment?
MR JUSTICE FRASER: I think it probably is.
Just one quick question for my note really, because
I'm pretty sure I know -- I could come up with
a description myself but I thought I would ask you, how
would you describe script to a layman?
A. A script describes a sequence of steps to do a computer
business process.
MR JUSTICE FRASER: I know that. But would you describe it
as a line of code, or a line of instructions, or
a message?
A. Scripts become pretty much code actually, but they are
generally a bit more readable than Java or something.
MR JUSTICE FRASER: It is the sequence of instructions to
the system, isn't it?
A. Yes, and they may include branches and loops etc.
MR JUSTICE FRASER: All right.
Thank you very much. 2 o'clock.
MR GREEN: I'm most grateful.
(1.00 pm)
(The short adjournment)
(2.00 pm)
MR GREEN: Dr Worden, can we look please at {F/869/29}.
A. Yes.
Q. So we are back in the 2011 general audit, I'm going to
say general audit rather than service audit to
distinguish the two.
A. Sorry?
Q. The 2011 audit --
A. Right, okay.
Q. -- that we were looking at before.
A. Sure.
Q. And we are looking at {F/869/29}.
A. Yes.
Q. If we look at page 29, very kindly. So just following
down how it works. The section here is "Strengthen the
change management process", the general section.
A. Yes.
Q. You will see what the rating is, "Rating: High".
A. Rating high, yes.
Q. It says there as a general introduction:
"We reviewed the processes implemented to determine
that all program changes are appropriately authorised,
tested and approved prior to implementation into the
production environment for all applications in scope.
Our examination of this process revealed the following."
And the recommendation on the right-hand side -- it
is slightly odd because the main paragraphs are off to
the right and then the bullet points are to the left.
A. Yes, and the bullets, yes, full out.
Q. You can see it says:
"Management should enhance the current change
management process/policy to include ..."
One of the things is:
"The level of documentation retained ..."
Yes?
A. Yes.
Q. Which we have seen.
Then the way this section works, there are two
headings under this column.
A. The "Recommendation" column?
Q. In the "Background" column.
A. Yes, there is a POLSAP and an HNG-X, is that what you
mean?
Q. Yes. So you have got the general introduction. Then
they deal with POLSAP. If we go on to the next page
{F/869/30}.
A. We have HNG-X.
Q. Yes, HNG-X. And then if you go to the next page
{F/869/31}, they do a section on "All in-scope
applications".
A. Yes.
Q. And that's the bit where we saw increased risk of
unauthorised and inappropriate changes etc, at the
bottom?
A. Right.
Q. The next section we look at in the new box is:
"We reviewed privileged access to IT functions
including access to user administration functionality
across all in-scope applications and their supporting
infrastructure."
A. Yes.
Q. And on the right we see:
We recommend that management conducts a review of
privileged access to IT functions across all in-scope
applications and their ..."
Over the page {F/869/32}:
"... supporting infrastructure to determine whether
the level of privileged access granted is appropriate.
Where --"
A. Can we just --
Q. Let me just read it out.
A. Yes.
Q. "Where access is deemed to be inappropriate this access
should be revoked immediately."
A. Yes. There seems to be a slight implication on the
previous page, if we can turn back. {F/869/31}. It
says:
"... IT functions including access to user
administration functionality ..."
So as I say, my view of privileged access is people
like DBAs, whereas possibly one could consider SSC to be
users.
Q. It looks wider here, doesn't it, yes. The point they
are making there is where the access is deemed to be
inappropriate, this access should be revoked
immediately, if we look at page {F/869/32}.
A. And that is the privileged access, is it?
Q. Yes, it is the end of that paragraph. And we know from
what we have seen in the PEAK that that didn't happen in
relation to the APPSUP role until -- it certainly hadn't
happened by 2015?
A. A slight distinction. The APPSUP role certainly wasn't
fixed by then, but the privileged user thing might have
been separate from that.
Q. But APPSUP is a role with a privileged use, isn't it?
A. Again I'm not clear on that entirely. I think of
privileged users as DBAs and SSC.
Q. Let's look at page {F/869/33} to see whether it comes
into this section or not. When we see that they have
the APPSUP role as the first item --
A. Right. But that is the HNG-X --
Q. This is all under the same box, going down.
A. All under that box, okay, fine.
Q. So we can now be confident that they were thinking of
that. So if we go back --
A. Right, fine.
Q. -- to page {F/869/32}. "Recommendation" is:
"Where access is deemed to be inappropriate this
access should be revoked immediately."
And what we have seen from the APPSUP PEAK, we have
seen that that did not happen. In relation to APPSUP it
certainly had not happened by 2015 for existing users?
A. Yes, we have seen that delay.
Q. Okay. Could we please look at {F/1705/1}. The document
you are going to see in a minute on 1705 is
a Post Office account user access procedure.
A. Yes. Right.
Q. Okay?
A. "... Post Office ... follow to manage user access to its
assets ..."
Okay.
Q. "... based on its contractual requirements to protect
assets, systems and data."
A. Yes. And the date?
Q. I will just show.
A. It is pretty recent, yes.
Q. It is an ongoing document. You can see from the foot it
is 7 November 2017.
A. Yes, and it has a history presumably.
Q. Now, let's look at page {F/1705/4}, if we may, and we
look at the foot of that table at item 10.1.
A. Yes:
"Addition of TESQA & APPSUP access management."
Yes.
Q. So we can see that a TESQA and APPSUP access management
provision has been added into this version of the
document.
A. Yes.
Q. If we go then, please, to page {F/1705/12}, and we see
item 4.2.3, "Requests for TESQA & APPSUP access elevated
privileges".
A. Yes.
Q. "The APPSUP role ... are temporarily applied to user
accounts when required for investigations into TESQA &
BDB queries. The roles are then removed again once work
is complete. Temporary access is managed via change
control (TfS) and that it should reference an MSC as
justification on the requirement for the elevated
access."
A. Yes.
Q. Yes?
A. Yes.
Q. So that does show, doesn't it, a provision for
controlling access in the way that you think would be
appropriate reflected at least as a policy in that
paragraph there?
A. Yes.
Q. Now, we have already touched on the fact that the 2011
audit was a normal audit, as it were?
A. Yes.
Q. A general audit. But we do have service audits from
2012 onwards?
A. Yes, and we have that period covered now. Yes.
Q. Yes. You referred in your expert report to the service
audit specifically?
A. Yes.
Q. And we have got those. The first one is 2012 and that
is at {F/1041/1}.
A. Yes.
Q. While it is coming up, Dr Worden, you are aware,
I think, aren't you, that none of those audits
identifies a problem with APPSUP anywhere?
A. They didn't. They were a lot of clean bill of health
stuff.
Q. Did you notice that quite a lot of the wording was
either very similar or identical?
A. Absolutely, yes.
Q. There are identical passages, for example, for control
objectives in 2013 and 2014 and again in 2015 and 2016.
That doesn't surprise you from what you --
A. It doesn't surprise me. It seems to me that tests were
done each year but they were the same tests.
Q. Precisely. Let's look at the purpose of those audits.
Let's look at page {F/1041/9} of that document, please.
Now, this is the intended use --
A. Yes.
Q. -- of the service audit. It says:
"This report, including the description of tests of
controls and results thereof in the Description of Tests
and Results, is intended solely for the information and
use of Fujitsu, POL as the user of the IT support
processes and controls used by and on behalf of Fujitsu
to support the HNG-X and POLSAP applications during some
or all of the period 1 April 2012 to 31 December 2012
and the independent auditors of POL, who have a
sufficient understanding to consider it, along with
other information including information about controls
implemented by user entities themselves, when assessing
the risks of material misstatements of user entities'
financial statements."
A. Yes.
Q. So their focus is on the risks of material misstatements
in the user entities' financial statements?
A. Yes.
Q. That's what the service audits do, isn't it?
A. It seems to imply that, yes.
Q. And:
"This report is not intended to be and should not be
used by anyone other than these specified parties."
A. Yes.
Q. So it is not for assuring outsiders about this?
A. No.
Q. Then if we go to page {F/1041/67}, please. That's
section 7, "Description of Control Objectives, Controls,
Tests and Results of Tests".
We can see there at paragraph 7.2, it says:
"On the pages that follow, the description of
control objectives and the controls to achieve the
objectives have been specified by, and are the
responsibility of, Fujitsu."
A. Yes.
Q. So the way it works is the control objectives and the
controls, which are the benchmarks for a service audit,
and this is one of the distinguishing features of
service audits rather than general audits, these
benchmarks for these purposes are set by Fujitsu?
A. Yes. Fujitsu's description of the service is the first
half of the document.
Q. Yes.
A. And that's signed off by Fujitsu management.
Q. Yes. Then we see the next paragraph:
""The service auditor's examination was limited to
the IT general controls relevant to Fujitsu's operations
supporting IT services provided to POL to support the
POLSAP and HNG-X applications. Accordingly the service
auditor expresses no opinion on the operating
effectiveness of any aspects of application processing
and application controls, individually or in the
aggregate."
A. Yes.
Q. Now what do you understand to be excluded by that
phrase?
A. Well, in reviewing these reports I frankly hadn't seen
those words before and it is new to me. And it does
seem to me that this is an infrastructure report, so its
focus -- I mean this says the application processing,
which is probably SSC, is rather outside scope.
Q. And at {D3/6/45}, if we can go to that, which is your
second report, at paragraph 168. Actually if we go back
to page {D3/6/44} to give you the beginning of
paragraph 168:
"The service audit for 2014 consists of
a description by Fujitsu of the services ..."
Which is what you volunteered in your last answer:
" ... signed off by Fujitsu senior management, and a
number of tests of that description carried out by the
auditors."
Yes?
A. Yes.
Q. And the point I was just trying to identify from this is
that tests are identified by Fujitsu, which we have
seen, yes?
A. They are defined by Fujitsu.
Q. Precisely.
A. Right, yes.
Q. Then:
"Section 7.2.10 of this document describes Control
Objective 10, which is that 'Controls provide reasonable
assurance that access to system resources, including
computing platforms and operating systems, is restricted
to properly authorised individuals.'"
Yes?
A. Yes.
Q. And:
"In all seven tests of this control objective, there
were 'no deviations noted' by EY."
A. In that year, no.
Q. So that is the premise of the opinion you formed about
this area?
A. Yes.
Q. But you hadn't noticed the content of the APPSUP PEAK
when you reached that view?
A. I can't remember the exact timing. I hadn't noticed the
duration of the APPSUP PEAK, I certainly hadn't noticed
that.
Q. Had you noticed it at all? Because it is pretty
important if you had.
A. I think I had noticed the APPSUP PEAK quite early,
because Mr Coyne raised the issue and I think
I didn't^ notice it quite
early.^chk - did he or didn't he?
Q. But if Mr Coyne raised the issue and it was a very
powerful role, why didn't you address it and follow that
through with the APPSUP PEAK?
A. It is just in my second report I had come across this
piece of evidence of the service audits and I felt that
was an extra piece of information which was useful to
have, and I was talking about the service audits here
which I think don't talk about the APPSUP role, so it
didn't fit in here I do not think.
Q. Well, if it contradicted what was in here then it might
have fitted into that section of your report?
A. Well, I wasn't clear on the timing. I wasn't aware
that -- you know, the service audit was 2011, this was
a later one so, you know, I didn't see a clash at that
time. I didn't realise that the APPSUP PEAK went on to
2015. So there was not an immediate contradiction in my
mind.
Q. Can I suggest to you, Dr Worden, by the time you had
written your second report you had not read the APPSUP
PEAK?
A. I think I had, but exactly when I read what is not
entirely --
Q. If you had, you really should have drawn the court's
attention to it, shouldn't you?
A. I think Mr Coyne had.
Q. Well, why didn't you then? Why didn't you deal with it?
A. Perhaps I did not have anything else to say about it.
I mean I was -- I had to be very selective in my
supplemental report.
Q. Well, we can see the -- if we go back to --
A. I think I did mention it at some stage because I mention
evidence that Fujitsu were taking steps to address the
issues, and that was the PEAK that I think I quoted or
certainly I had in mind when I said there is evidence --
I think somewhere in my first report I said there's this
Ernst & Young audit report and there is also evidence
that at a certain time Fujitsu were taking steps to
address it.
Q. But the short point is you hadn't appreciated the
history on to 2015?
A. I hadn't appreciated the duration, no.
Q. And that changes your opinion, doesn't it?
A. I think it does.
Q. Radically?
A. I'm quite surprised at the duration of that issue. One
would have thought it would have been sorted quicker.
Q. There are two things, duration of the issue and power of
the role, in combination even more striking?
A. SSC needed powerful roles to do what they did.
Q. Hold on, Dr Worden. The problem that we have identified
is basically having a completely open back door, as it
were, with APPSUP?
A. For SSC.
Q. Basically for the whole of SSC.
A. The whole of SSC.
Q. And you are surprised by the duration of it?
A. I'm surprised it took that long to fix the problem, yes.
Q. Are you surprised that it appears to be unknown to
Post Office up to 2015?
A. Yes, I guess I am.
Q. And does the power of the APPSUP role reinforce the
significance of those two last answers?
A. Well, we are aware that the APPSUP role is powerful and
we are aware that the SSC needed a powerful role from
time to time, but the problem was it was allotted rather
permanently rather than temporarily.
Q. The point about it is, Dr Worden, when we contrast it
with the specific balancing transaction tool, which had
specific protections in it, it wrote to a journal for
every time it was used, yes?
A. Yes.
Q. So that you could see exactly when it was used?
A. Yes.
Q. And what for, yes?
A. Yes.
Q. When we contrast it with that, what we are talking about
is taking great care over which window lock you choose
with a balancing transaction tool whilst leaving your
back door wide open with the APPSUP role?
A. I don't entirely accept the analogy. The transaction
correction tool was built to address a specific need,
which actual -- you know, it came up once. But
nevertheless I think both experts have agreed that there
are times when SSC or times when Fujitsu had to do
things which are unanticipated and we can't see the
limits of those.
Q. And there are times when you have to open your back door
of your house, but it is quite sensible to control those
times and do it appropriately rather than leaving the
back door open?
A. Yes, well, I would not have called giving a permission
to experienced and long-term users of SSC opening your
back door.
Q. Let's look at {F/1041/83}. This is Control Objective 10
which you have referred to in that part of your expert's
report I just took you to.
A. Yes.
Q. If we look at 10.3, it says:
"We selected a sample of 12 platforms within the
in-scope applications. The Group Policy on failed access
attempts that manages access to all these servers was
set to disable accounts after 6 consecutive failed
access attempts; the POL setting should be to disable
accounts after 3 failed access attempts. The other
settings tested were in line with the POL requirements.
"No other deviations noted."
A. Yes. It seems to me that failed access attempts is
failed access attempts by anybody.
Q. Yes. So they are not actually -- what they are actually
looking at there is they are focusing on that aspect of
the access attempts, not specifically on who has which
roles?
A. That is right.
Q. If we go to your expert report at {D3/6/12}, you can see
heading 2.2 is "Mr Roll's second witness statement"?
A. Yes.
Q. You were aware Mr Roll wasn't a claimant?
A. Yes, absolutely.
Q. And you deal with Mr Roll's witness statement in this
section of your report.
A. Yes.
Q. Page {D3/6/23} is in the same section, and if we look
at -- if we go back a page {D3/6/22}, do you see at
paragraph 91 you say:
"In his paragraph 22, Mr Roll disagrees with my
paragraph 1144 ..."
A. Yes.
Q. "... where I said that SSC access to the counters is
strictly controlled."
A. Yes.
Q. If we go over the page {D3/6/23} you will see at
paragraph 93 you then move on to Mr Roll addressing
rebuilding of transaction data, which topic we will come
to in a minute.
So you are dealing with Mr Roll in this context.
And at the foot of paragraph 92, you say:
"In section 6 of this report, I describe evidence
from service audits of Fujitsu that these controls were
effective."
A. Yes.
Q. So this is the section where you are responding to
Mr Roll who disagreed with paragraph 1144 of your first
report?
A. Yes. And I made those comments based on the answers
I saw to the assessment by Ernst & Young under Control
Objective 10.
Q. And service audits started in 2012?
A. Ah yes, good point. Yes.
Q. And Mr Roll left many years before that?
A. I'm sorry about that, yes. There is a real timing
problem.
Q. So Mr Roll is probably owed a bit of an apology on that
one, is that fair?
A. Mm?
Q. Mr Roll is probably owed a bit of an apology on that
one?
A. I certainly didn't spot that timing issue, I'm very
sorry, yes.
Q. It doesn't appear either, not only were there no service
audits when Mr Roll was at Fujitsu back in Legacy days,
but also it strongly appears that the service audits
themselves do not deal with the issues of the APPSUP
role itself?
A. Yes. But the service audits do say access to system
resources regardless of who it is.
Q. Now, let's go back to a point from slightly earlier, if
we may.
When we were looking at the keystrokes in the
PEAK --
A. Yes.
Q. -- you suggested that those might be visible in an event
log.
A. I think so, yes.
Q. Do you mean visible to the SPM or visible to
Post Office?
A. Visible to this department TED or whatever they are
called. There is a Fujitsu application support strategy
document that defines the four levels and in front
level, first level, there is HSD, Horizon service desk,
and there are various other departments including TED,
and I can't remember the acronym, exactly what that
means, but they were looking at logs.
Q. Just to clarify, let's look at {F/1468/1}. So that is
the event log that the SPM -- this is Mrs Burke, as it
happens, but this is the event log that the SPM can
print out.
A. I am not talking about that event log.
Q. They are not going to see it.
A. No, I'm not talking about this kind of event log, no.
Q. Are you talking about an ARQ event log?
A. Absolutely not, no.
Q. So there is a third type?
A. There is a third kind, yes. There is lots of logging of
the Horizon system that goes on and there are these
people that spend their time looking at these logs.
There are event logs and transaction logs, for instance,
they look at, and I have probably not got all the kinds
of logs they look at.
Q. But one of the kind of logs they have is a log that has
the keystrokes in it?
A. I believe one of the event logs goes down to that level,
yes.
Q. And you think it is likely to be the source of the
keystrokes we saw there?
A. Yes. Obviously that source was quoted in a PEAK so it
is not a thing that somebody had gone out to a branch to
pick up.
Q. No, of course.
MR JUSTICE FRASER: And it is not an ARQ.
A. It is not ARQ data at all. It is stuff you can look at
on the day.
MR GREEN: On the day?
A. Yes.
Q. So if an individual subpostmaster was very anxious about
how something had happened, that would be very helpful
information, wouldn't it?
A. Obviously sometimes it is, and I think it was used
a great deal because TED was a whole department that was
scanning these things. They were scanning for things
that the subpostmaster didn't see and they were also
presumably called up when somebody said, "Subpostmaster
says this. Could you look at the logs".
Q. I'm not asking you to comment on the evidence of other
witnesses but I'm going to ask you if you can think of
an explanation, because what was said in Ms Mather's
statement was that you could -- Credence recorded
keystrokes, and then we were told that that was wrong,
and indeed Ms Van Den Bogard was re-examined on the very
point.
A. Yes.
Q. That we didn't have access to keystrokes.
A. Yes, but --
Q. So do you have any feel for who ought to know about the
existence of those documents, the keystrokes?
A. Well, the question of keystrokes on Credence is Credence
is a POL system. The question of keystrokes on a PEAK
is Fujitsu having access to keystrokes information. So
I suspect, I strongly think that is from the event logs
that Fujitsu were responsible for looking --
Q. Do you know the extent to which that data which Fujitsu
have in the Horizon system, or from it, is available
through Credence to Post Office?
A. Obviously certain of the same things go in the event
logs and they go in different forms in Credence.
Q. Yes.
A. I don't know the extent of --
Q. Those event logs do go into Credence, but you don't
know --
A. No, not the event logs.
Q. Sorry, the data in the event logs.
A. The data in different forms goes into Credence, yes.
Q. And you don't know which data from those event logs goes
into Credence and which doesn't?
A. I don't. But as I said before, my expectation was that
Credence doesn't go down to keystroke level.
MR JUSTICE FRASER: And the expression you used, and it
doesn't matter if you can't remember what it stands for,
is TED.
A. Yes, and you find this in the application support
strategy document.
MR JUSTICE FRASER: All right.
A. Which defines the four levels of support.
MR JUSTICE FRASER: Thank you very much. And that's the
sort of data that you were shown earlier, you think it
will come from TED.
A. I think it would have come from there, yes.
MR JUSTICE FRASER: Mr Green.
MR GREEN: I'm most grateful.
Can we go to remote access, if we may, Dr Worden.
Can we look at the transcript of {Day18/67:1}, for
a minute. I think the position you reached with
Mr Coyne in the joint statement was that more or less
Fujitsu or Post Office could do anything.
A. Well, we can look at that. That is 10.12. I was asked
to go and look it up and we didn't come back to it. In
joint statement 4, 10.12.
Q. We will come to that. It is literally my next point.
But just have a look at {Day18/67:6} and line 7.
A. 57 or 67?
Q. It is Day 18, page 67. I think it is lines 5 and 6
actually. It says:
"Answer: And we agreed in the joint statement that
more or less Fujitsu or Post Office could do anything."
A. Yes. We can see precisely what we agreed in a minute,
obviously.
Q. In relation to the --
A. We agreed the experts couldn't demonstrate that they
couldn't do everything. I mean, that's sloppy wording
by me there. I think the joint expert statement says it
better.
Q. Okay. You were asked -- I think you were hoping to see
where in the joint report you reflected the position in
relation to Mr Roll and Mr Parker in respect of access
at the counter, which they had in fact agreed to in
their second witness statements?
A. Sorry?
Q. Did you have a look at that? Do you remember the
homework?
A. I thought the homework was to find that statement which
is at 10.12 in the joint statement.
Q. {D1/5/8}, I'm grateful to Mr Miletic. At 10.12.
A. Yes.
Q. "Certain facilities and procedures used by Fujitsu to
repair the more common issues which arose in Horizon
were standardised and evidence of them persists.
However, to repair less common issues which arose from
time to time, standard tools and procedures might not
have been sufficient, and evidence might not persist of
what was done at the time. Even when evidence does
persist, it may be extremely difficult for the experts
to interpret it today, because of the scale and
complexity of Horizon."
That is the point you mentioned about difficulty of
plumbing the depths of the system.
A. That is right.
Q. And the fact it is a bit of a swamp.
A. There are layers and layers and layers which --
Q. Makes it very difficult?
A. Yes.
Q. "Therefore, it is usually difficult for experts to make
categorical negative statements of the form: X or Y
never happened."
A. Yes.
Q. Can we probe that in a tiny bit more detail, if we may.
If we look first at {D3/1/248}, please. We have your
table?
A. Yes.
Q. Just taking that in stages, if we may. The top half
above the horizontal light blue bar is about Post Office
access, isn't it?
A. Yes.
Q. The bottom half is your opinion about Fujitsu access?
A. Yes.
Q. So the first question is whether Fujitsu had the ability
to inject or insert?
A. Yes.
Q. And it is yes, and you explain why.
Then "Fixes", second column, is yes. And "Rebuilds"
is yes.
A. Yes.
Q. And then (b), you say:
"Without the knowledge of the subpostmaster."
You say:
"No. Any changes performed by privileged users
become visible at the branch."
Otherwise on that you say yes and yes.
A. Yes.
Q. Then row (c), "Without the consent of the
subpostmaster", and you say yes?
A. And we have the typo here.
Q. Then across that row, yes and yes.
So can we focus on (b)(i)?
A. Yes. I think that is effectively overridden by the
expert joint statement. In other words, that
categorical "never" statement shouldn't have been there.
Q. Okay. So you can't exclude that. That's where we are
now because of the joint statement?
A. Yes.
Q. And it certainly appears that that may well have been
possible?
A. Well, I think when the experts agreed in the joint
statement that the experts cannot determine whether or
not Fujitsu could do X, and X could have been some form
of remote access. But equally it follows logically that
X could mean doing that form of remote access without
the knowledge of the postmaster. That all follows
logically.
Q. It does.
MR JUSTICE FRASER: So logically is that now a yes?
A. I think that's now a yes.
MR JUSTICE FRASER: All right, thank you very much.
A. Or a don't know.
MR GREEN: There's an issue about how something might become
visible to a subpostmaster.
MR JUSTICE FRASER: Just before you move on, I don't want to
put words in your mouth. So that should be a don't know
or a yes, do you think?
A. Well, I think the don't know follows from the joint
statement, yes.
MR JUSTICE FRASER: So don't know.
A. Yes.
MR JUSTICE FRASER: All right. Mr Green.
MR GREEN: And that the reason for the qualification in that
box, if I can put it in those terms, in your original
report, is the possibility that it would be done in
a way that would become visible at the branch?
A. Yes, and there is some confusion in that paragraph (b)
because it's "changes performed by Privileged Users",
and my view since then is that privileged users aren't
DBAs and therefore they are not the whole story. It is
SSC we are really interested in, I think.
Q. Let's just trace it through, if we may. At the time you
wrote your report you agreed I think that privileged
users could edit and delete in Horizon Online?
A. I think so, yes.
Q. I think that's at paragraph 1122. That was needed for
system maintenance purposes but the same rationale would
apply to Legacy?
A. Yes.
Q. And I think the roles appear to have gone -- I have
a reference I can show you if you want -- but privileged
user roles appear to have gone through from Legacy into
Horizon Online?
A. You would expect DBA people to be around the whole time,
yes.
Q. To carry on?
A. Yes. For instance the Legacy databases in the back end
were preserved, quite a lot of them.
Q. Can we look please at {D3/1/246}, paragraph 1123. So
this is where you say:
"Any change to a transaction performed by a
Privileged User would be visible to branch staff. The
amended transaction would appear in reports and logs
that can be viewed in branch, although it would not be
flagged as a change by a Privileged User."
A. Yes.
Q. You say:
"Theoretically this is a problem, but Privileged
Users cannot change the audit record and so the changed
record in the BRDB would no longer match an audit
extract. This means that a subpostmaster could always
find out about changes made by SSC, via a request to the
helpdesk."
A. Yes.
Q. That assumes, doesn't it, there is a comparison between
the audit store or ARQ data and some data that the
subpostmaster has?
A. There could be. But my view on that paragraph would be
somewhat different now, I think. As we have said, the
audit data was generally used as a backstop and the
whole issue of what is visible to the subpostmaster ...
Q. Is pretty difficult, isn't it?
A. It is difficult, yes.
Q. But also the subpostmaster would not have been
expecting, even if hypothetically they had been provided
with ARQ data and tried to interpret it themselves and
compare it with information they had --
A. I do not think subpostmasters should be provided with
ARQ. I think that's very technical and not the sort of
thing that subpostmasters want to dig around.
Q. Even if Post Office itself had requested the ARQ data to
look at and try and consider --
A. Yes.
Q. -- and to show and explain to a subpostmaster so they
can try and see what happens as well?
A. Yes.
Q. Subpostmaster would need to have in mind the possibility
of remote access in order to be looking for that as
a possible explanation, wouldn't they?
A. I agree, yes.
Q. If we have a look, please, at {F/1422/1}. This is
Post Office's response to the Panorama program which the
BBC showed about this issue, and you can see the bold
points sort of summarising the thrust of what was said?
A. Yes.
Q. "The Post Office does not prosecute people for making
innocent mistakes and never has.
"There is no evidence that faults with the computer
system caused money to go missing at these Post Office
branches.
"There is evidence that user actions, including
dishonest conduct, were responsible for missing money."
So that is the thrust of the response. But if we go
over the page {F/1422/2}, and if you see halfway down
there is a section which is "The Horizon Computer
System" section?
A. Yes.
Q. If you look at the bottom of that section, it says:
"There is also no evidence of transactions recorded
by branches being altered through 'remote access' to the
system. Transactions as they are recorded by branches
cannot be edited and the Panorama programme did not show
anything that contradicts this."
A. Yes.
Q. Even though Mr Roll was actually interviewed on it.
A. I didn't see the programme and indeed I haven't actually
read this document.
Q. But in the face of the fact that that's what Post Office
were saying in response to a reputable bit of
investigative journalism by the BBC, there is no
prospect of a subpostmaster thinking if they were
hypothetically one day to be in the position of
comparing data: oh, I must just see if that was actually
one of those remote access changes, is there?
A. So you are saying that this document from Post Office
came to the attention of a subpostmaster -- is that
what's being put to me?
Q. Dr Worden, 2015, Post Office are denying --
A. Is that the document of this document?
Q. Yes.
A. Right.
Q. Post Office in 2015 are, in response to a BBC
documentary by Panorama, which Mr Roll is on saying
there could have been remote access, they are saying:
"There is also no evidence of transactions recorded
by branches being altered through 'remote access' to the
system. Transactions as they are recorded by branches
cannot be edited and the Panorama programme did not show
anything that contradicts this."
So if that is the Post Office's quite forceful
public position, it is completely unrealistic to expect
that even if a postmaster did get --
A. My reports have not been concerned with Post Office's
public position.
Q. But it is very unlikely that a subpostmaster or
subpostmistress in a difficult situation, even if they
were to get the necessary data provided to them, they
would not expect to look for that, would they?
A. As I say, this document and the considerations of
Post Office's public position have not entered into my
opinions.
MR JUSTICE FRASER: Mr Green, I think you are probably
crossing the line into submissions or arguing the case.
The only question really you could properly put I think
further to Dr Worden is: that statement says:
"Transactions as recorded by branches cannot be
edited ..."
On the basis of your expert knowledge as at today,
does that statement match your knowledge of the system
or not?
A. Transactions as recorded by branches go into the audit
store and they cannot be edited.
MR JUSTICE FRASER: In the audit store.
A. Well, they cannot be edited. And if they are edited
then -- I mean, the DBA can do anything, and we can't
say anything can't be done. So something could go into
BRDB, into the audit store, and then the BRDB version
could be, in principle -- on the basis of this expert
joint statement something like that could happen, but
then you see a discrepancy between the BRDB and the
audit database.
MR JUSTICE FRASER: Yes. But it is the audit database
information -- my understanding is, and tell me if I'm
wrong, it's the audit database information that can't be
edited.
A. Yes.
MR JUSTICE FRASER: There are different ways that the
transactions entered in the branch can be changed on the
BRDB, is that right?
A. My view is that on the BRDB there has to be somebody who
can do anything you like, because if Post Office went to
Fujitsu and said "We have got this problem with BRDB",
and Fujitsu said "We can't do that, we have thrown the
keys away", that would be wrong. So the experts can't
say anything could never be done.
But nevertheless the audit database is -- it is
a bit of a misnomer, it is not a database, because audit
records are sealed and not modifiable.
MR JUSTICE FRASER: I understand.
Mr Green, I don't see any help to me in you arguing
those sorts of submissions with an expert in IT.
MR GREEN: I understand, my Lord.
In relation to the uses of APPSUP itself, the APPSUP
role, just to clarify, the privileged user logs didn't
exist pre-2009, that is right, isn't it?
A. I'm not aware of any. Some record probably existed of
privileged user activity but it has not been disclosed
as far as I know.
Q. There is no disclosure of any privileged user logs
pre-2009?
A. Well, "the logs". But I'm saying I don't know that some
other form of record didn't exist. Generally I would
expect, a DBA doing special things, there to be some
record of his doing it.
Q. But the APPSUP role is a role that everyone at SSC
enjoyed?
A. But that's not DBAs.
Q. No, I'm asking you about use of APPSUP by SSC.
A. Yes. Fine.
Q. And the privileged user logs who would capture that
don't exist pre-2009, as far as we know?
A. Privileged user logs, do they capture APPSUP use? I'm
not sure. Privileged user logs are very difficult to
interpret. They are much worse than MSCs.
Q. I was coming to that point. But what had been called
the Privileged User Logs did not exist prior to 2009.
That is not meant to be controversial --
A. No, I do not think it is controversial.
Q. And they only recorded log in and log off until 2015?
A. From the ones I looked at the distinction wasn't so
clear, because what you would get in a day's privileged
user log was thousands and thousands of accesses, most
of which were system accesses, and scattered amongst
them you would see one or two accesses obviously from
a real person and those accesses would record typically
the name of one database table and I found that very
difficult to interpret.
Q. Well, hitherto it has been thought to be common ground
that the only recorded log on/log off until July 2015
and thereafter were fuller, and you and Mr Coyne were
looking at the ones after that to see what was in them.
Do you know or are you just guessing?
A. I can't recall precisely but I thought I had seen these
single database table names in all sorts of years, but I
frankly haven't gone back to that because I got so
little out of the privileged user access logs.
Q. If we look at {E2/1/18}, it is Mr Godeseth's second
witness statement which you referred to in your expert's
report. It is page 18 of that witness statement. If we
look at 59.6 when he is explaining how privileged users
are recorded, if we start at 59.4 --
A. Yes.
Q. He says:
"Since July 2015 all access and actions carried out
by privileged users are recorded on an Oracle audit
table. The audit table records information including:
"(a) user ID;
"(b) action; and
"(c) date and time of the action."
Yes?
A. Yes. That's not quite consistent with what I have seen
in privileged user access logs.
Q. I'm just going to check whether your memory is right
because it is possible to make a mistake if you haven't
got them all in front of you.
Look at 59.6:
"Prior to July 2015 the log on and log off
activities by Privileged Users were audited. The process
was for a Managed Service Change (MSC) 14 document to be
signed off and for the log on and log off records to be
attached to the MSC."
59.7:
"The reason for the change in July 2015 was that the
BRDB was upgraded to a newer version of Oracle and we
took the opportunity to make the change then."
A. Yes.
Q. That strongly suggests that the privileged user logs
weren't available -- privileged user logs prior to 2015
did not have anything more than log on and log off on
them?
A. That seems to suggest that, yes. But as I say, I really
didn't go much into these privileged user access logs
for two reasons. One is I thought they were to do with
DBA activities rather than SSC and application
activities, and the other is when I looked at them
I would get very little out of them.
Q. If we look at {D1/5/10}, please. Item 11.3 is:
"The logging of Privileged User Access (in PUA logs)
commenced in October 2009."
A. Yes.
Q. And you agreed that with Mr Coyne?
A. Yes.
Q. You also agreed that:
"Between 2009 and 2015 these logs only displayed the
fact that a privileged user had logged on or off but not
what actions they had taken whilst the privileged user
was logged in."
You agreed that?
A. Yes.
Q. And then:
"The use of the transaction correction tool cannot
be seen in these logs."
A. Yes. What I'm saying now is -- I agreed with that. My
memory of what I saw on the pre-2015 ones is unclear.
Q. You and Mr Coyne have agreed also that the privileged
user logs are hard to understand and not a useful source
of information, haven't you?
A. Is that somewhere?
Q. Let's have a look, please, at --
A. It is 11.5.
Q. 10.1 on page {D1/5/4}. Sorry you have agreed; you have
said --
MR JUSTICE FRASER: Where are we going?
MR GREEN: The foot of 10.1 on {D1/5/4}. You say,
penultimate bullet point, or second bullet point down
there:
"The privileged User Access logs are not a useful
source of evidence about remote access, including
balancing transactions."
A. Yes.
Q. You say the same about the managed service change logs?
A. Yes. I'm less clear about that now having looked at
those more recently.
Q. In fact when we saw the problem in the 2011
Ernst & Young letter in relation to the consents to
change not being recorded, do you remember the 10 and
the 5?
A. The 10 and the 5?
Q. Yes, Ernst & Young in 2011 did 10 -- looked for 10
approvals and found they --
A. Right, okay.
Q. -- hadn't been retained, and five others and those
hadn't been retained either?
A. Yes.
Q. The change approvals are supposed to be in the OCPs and
OCRs, aren't they?
A. I'm slightly unclear how the OCPs, OCRs and MSCs
overlapped in time, but generally you're right.
Q. They ought to be somewhere in those records if the
system is being documented properly?
A. I think that is right, yes.
Q. Now no one identified the APPSUP role to Mr Coyne, he
had to find it for himself. And if we look at his
second report at {D3/4.1/85}, it is paragraph 3.279,
page 85. It is 3.279.
A. Right. So this is that PEAK we have been to.
Q. Yes. He set out quite a lot of text there, yes?
A. Yes.
Q. And over the page {D2/4.1/86} at 3.281:
"... I can see that the APPSUP user group was used
2,175 times between 2009 and 2018 with user names
ACHAM01, JCHAR01, CTURR01, GMAXW01 and others."
A. Yes.
Q. And we know, don't we, that those appear to refer to
Anne Chambers and Mr Maxwell and so forth from SSC?
A. Yes, we do. And this is approximate -- I haven't done
a big survey of PUA logs, but the numbers are consistent
actually that one day's PUA log is a huge thing, it
usually has one or two real people in it, and I think
this 2,000 times in ten years is about one person per
working day, so it all fits.
Q. It all fits and you are content with that.
In response Mr Godeseth in his third statement at
{E2/14/6}, paragraph 19, you have at the top of the
page, he confirms there what the APPSUP role allows. He
says:
"Paragraph 3.277 describes the APPSUP role and
refers to a Peak in which there is a general discussion
on the level of permissions required by SSC staff to
fulfil their role. APPSUP is the more technically
accurate name for a role with privileged User access to
the BRDB and other parts of the system. Although the
APPSUP role could theoretically be used to inject, edit
or delete transaction data this Peak does not provide
any evidence of this actually happening. It is
discussing the administration of the APPSUP role rather
than its use in a particular situation to change live
transaction data."
Now, two points. A perfectly fair description of
what the PEAK is doing?
A. Yes.
Q. Which we have looked at, and a perfectly clear
description of what the APPSUP role does?
A. Yes. I mean I haven't deeply investigated the APPSUP
role, so --
Q. And if we look at Mr Parker in his third statement at
{E2/13/3}, at paragraph 13 he is commenting on its use.
A. Yes.
Q. He says:
"It is not a distinct or new type of remote access
..."
And refers across to Mr Godeseth.
A. Yes.
Q. And he says at the bottom:
"Those logs suggest that the APPSUP role has been
used 2,175 times to make emergency ..."
And if we go over the page {E2/13/4}.
A. Sorry, that's what Mr Coyne said?
Q. No, this is what Mr Parker is saying in response.
A. I didn't find the 2,000 number before we flipped.
Q. Sorry, let's go back. {E2/13/3}
A. Ah, "he says", yes, okay. So Parker referring to Coyne.
Yes.
Q. He says it has been used 2,175 times to make emergency
amendments to the BRDB.
{E2/13/4}
"This appears to assume that APPSUP is only used for
emergency amendments - an assumption which appears to be
drawn from his reading of Peak PC0208119. However, this
is an administrative Peak which concerns one topic
(changing the generic role for SSC database users, which
affected the running of development delivered scripts).
It does not refer to a particular support action on a
live branch."
Now, it is an administrative PEAK that he has
referred to, but neither Mr Godeseth nor Mr Parker had
consulted the transaction logs, we know that -- the
privileged user logs?
A. Had they not?
Q. No. And you tried to and agreed with Mr Coyne that they
are not very helpful. That's where we've ended up.
A. Yes, but I mean I would understand Mr Parker knows what
goes on in the support because he is important in SSC
and has a feel for what SSC does.
Q. So even in a situation where there is litigation and
multiple witness statements have been served, Mr Parker
and Mr Godeseth don't look at them, you look and see
they are not useful, and that overall situation is
because they don't really show clearly an answer to the
question of what this was used for?
A. Yes, and I was always confused by the fact that most of
these privileged user logs were about some system
access.
Q. I understand.
A. System to a system, and I couldn't get to the bottom of
what that -- in the time I devoted to it, I couldn't get
to the bottom of that.
Q. And if there's not a clear documentary record of what
the use is, it is very difficult for there to be proper
scrutiny or audit of that?
A. That's assuming that PUA logs are the only documentary
record.
Q. Well, we haven't seen any other, have we?
A. We haven't.
Q. So that was invented in the hoof?
A. I'm not inventing on the hoof, I was simply stating
an uncertainty I have. I'm not trying to --
Q. There might be all sorts of things but let's focus on
the evidence we have got.
A. Generally Horizon is big and complicated and there are
all sorts of things.
Q. If the documentation is the privileged user logs we have
got, there isn't really any proper basis, even when they
do come after July 2015, properly to scrutinise what the
tool is being used for or to audit its use?
A. Absolutely. From the disclosed evidence that is
correct.
Q. Now let's move to DBAs. You have touched on them
already. They can edit, delete and add as you have
already said. That's obviously both in Legacy and
Horizon Online for reasons you have already given.
A. Yes.
Q. If we go to {Day8/44 12}, if we look at page 44, line 12
it says:
"Question: You would agree that those people have
the role which allows them privileges to update, delete,
or insert into branch database tables whether they are
using the correction tool or not?"
A. Yes.
Q. And he says, this is the DBA role:
"Answer: Those people could log on to the database
and do an awful lot of damage."
A. Yes.
Q. And you agree with that?
A. Yes.
Q. If we look at re-examination on Day 8 --
MR JUSTICE FRASER: Is this of Mr Godeseth?
MR GREEN: Of Mr Godeseth {Day8/112:1}
A. I should say in my experience DBAs can do an awful lot
of damage.
Q. Yes. Page 112 at line 14:
"Question: And 'UNIX user', who would the UNIX user
be?
"Answer: Oh, sorry, UNIX user would be one of the
guys in Ireland."
A. Yes.
Q. So the DBA's role is the guys in Ireland as referred to
by Mr Godeseth?
A. Yes. This implies to me that some of the DBAs are in
Ireland, I don't know if they all are.
Q. You don't know where they are really?
A. No.
Q. And you haven't met them?
A. Certainly not.
Q. You don't know how trustworthy they are?
A. I just do not know them as individuals. I presume that
to get to that job you have to be pretty good.
Q. And one of the guys in Ireland, if you look down, you
can see that on the top of page 113:
"Question: Who are the 'guys in Ireland' exactly?
Could you just clarify -- I appreciate that this may not
be your daily fare but~...
"Answer: They are the people who support the
hardware, so UNIX is an operating system so they work at
a pretty low level on the systems.
"Question: When you say 'low level', I mean what do
you mean by that? Do you mean they have powerful user
rights, or they have weak user rights or ..?
"Answer: They have pretty powerful user rights, but
they are very -- very much driven by process as to how
they use them."
A. Yes, I should say here that they are the people who
support the hardware. That feels to me like a different
level from the DBAs.
Q. So that might be another -- so the UNIX people might be
on another level from the DBAs?
A. Yes.
Q. In a sense we may have three layers?
A. Yes, I am sure we do.
Q. Now, just before we break for the stenographer who has
asked to go a little later, can we just deal briefly
with OCPs and MSCs. You heard Mr Coyne say he had
reviewed the OCPs and identified that 7% were created
retrospectively, did that come as a surprise to you?
A. It was, and I have since investigated myself.
Q. Was that about right?
A. The investigation I have made, I did a search of the
OCPs for all those that mentioned "retrospective" and
there are 1,600 of them, that's about 7%. I also did
a search for all those that mentioned "retrospective"
and "FAD" and you come to about 40. So the OCPs
referring -- of these 7% of OCPs, I drew the conclusion
that the great majority were back end, and I checked
a few of them they are back end changes, and only the 40
referred to changes made at the branch.
Q. And you understood that OCPs would be raised by one
person and I think monitored by a different person, so
you have four eyes?
A. There is a lot of this separation of duties, four eyes
thing, yes.
Q. Let's look quickly at {F/292.4/1}. This is an OCP on
1st September 2005.
A. Yes.
Q. You can see, although we do see different names under
"Other details" on other OCPs, on this one we can see
Martin Harvey and Martin Harvey at the bottom.
A. Raised by, monitored by.
Q. So he is monitoring himself it looks like?
A. It appears to be.
Q. Let's just look and see what this actually is. It is a
"Bulk insert to tps_pol_fs_summaries_incomp table".
A. Yes.
Q. It says:
"Products 2542 & 2541 had missing mappings which has
caused several hundred branch details to not balance to
zero."
A. Yes.
Q. "The ref data has now been corrected and the balancing
transactions have been extracted and now need to be
loaded into to tps_pol_fs_summaries_incomp so the BLE
file can be generated and sent to POLFS."
A. Yes.
Q. He is correcting a balancing problem because of missing
mappings which is affecting several hundred branches?
A. Yes. The table named "tps_pol_fs summaries" implies to
me it is to do with TPS transaction processing system
which is pushing stuff over to Post Office, not directly
affecting branch accounts.
Q. Well, on any view, it says there that it is caused
several hundred branch details to not --
A. Yes, but the branch details are not in the BRD. Branch
details are held all over the place, including back end
and POL systems. By the reference to "tps",
I understood this to mean branch details in the back end
or in POL.
Q. But on any view, it is hundreds of branches and he
appears to be monitoring himself?
A. Yes, I --
MR GREEN: My Lord, is that a convenient moment?
MR JUSTICE FRASER: Let's have the answer.
MR GREEN: Sorry, I thought he said yes.
MR JUSTICE FRASER: I thought you were about to add
something.
A. Nothing real, just it does appear to say he is
monitoring himself.
MR GREEN: Is that a convenient moment?
MR JUSTICE FRASER: Yes, we will have the 10-minute break.
Come back in at 3.20 pm.
(3.10 pm)
(A short break)
(3.20 pm)
MR GREEN: Dr Worden, could we look please at {F/485.2/1},
that's an OCP for 2nd March 2009.
A. Yes.
Q. It is to insert corrective transactions at a branch,
yes?
A. Yes.
Q. That's the title. Just look over the page, please, at
{F/485.2/2}. This is under "Other details". And
Dr Worden, I acknowledge that there are lots where the
people are different, but you can see there "Raised by:
Anne Chambers" and "Monitored by: Anne Chambers"?
A. Yes.
Q. If we look at {F/540.01/1}.
A. "Purge Migration Prep Data". That is familiar.
Q. And if we look at page {F/540.01/2} of that, we see it
is "Raised by: Anne Chambers" and "Monitored by:
Anne Chambers"?
A. Yes.
Q. Last one, {F/616.1/1}. This is an OCP for
14th April 2010. This is the branch "unable to
rollover". If we kindly turn to page {F/616.1/3} of
that OCP, do you see --
A. Here we go again, yes. Right, same person.
Q. -- "Raised by: Mr Ramachandran" and "Monitored by:
Mr Ramachandran"?
A. Yes.
Q. And so it is certainly not recording the four eyes that
are involved in that respect in the way that you'd
expect it in all cases, is it?
A. No, it isn't.
Q. If we look at Mr Godeseth's statement in relation to the
balancing transaction tool {E2/1/16}. Do you see there
at paragraph 58.5 he says:
"As far as I am aware there has only been one usage
of the tool."
A. Yes.
Q. Now, if we look at {F/425/1}, we have got the low level
design --
A. Yes.
Q. -- in draft. Do you see "Document status: draft",
halfway down?
A. Yes, absolutely.
Q. Can we just pause there. This is a more general
question about IT system documentation generally. What
is in your experience the significance of developing
drafts and then having identified approved versions of
the documents?
A. Well, it is general good practice to do that.
Q. Why does it matter?
A. Well, a draft implies a review process and a refinement
process. An approval implies that review has taken
place.
Q. By the people who ought properly to review it?
A. Well, depending on how their system is, yes. There is
some structured system that says: here's how we do it
and here's how we review it and approve it.
Q. Would it be fair to say that in a well documented system
there shouldn't be frequent occurrences of people
working from draft documents that have not been
approved?
A. I think that's broadly true, yes.
Q. Let's look at this --
A. But -- well, IT life cycles are increasingly -- they
used to be a waterfall where you went through very
serious document stages and signed off each stage and so
on. IT life cycles have become much more iterative and
the overlap between the phases means that people do
things on a draft. For instance, there is much more
iterative development where you develop a prototype you
and refine it. So the style of IT development has
changed over the years to the extent that one overlaps
the phases much more than the old-fashioned waterfall
life cycle.
Q. That's probably changed quite a bit over the last ten
years, is that fair?
A. Yes, depending on different organisations, they have
taken it up in different ways. But the modern tenure is
actually 20 years really.
Q. This document is from 2007 and this is the low level
design for the transaction correction tool?
A. Yes.
Q. And if we go to page {F/425/8}, please. It says:
"This document provides the low level design for the
branch database transaction correction tool module."
A. Yes.
Q. "The utility will allow SSC to correct transactions by
inserting balancing records to
transactional/accounting/stock tables in the BRDB
system. It will also audit the changes made. There
will be no updating/deleting of records in the branch
database."
A. Yes.
Q. And then underneath:
"Warning: the use of this powerful tool has inherent
risks. If the SQL statement is incorrect or badly
written, it is possible to cause unintended
consequences, some of which may cause serious problems
to the branch database. It is expected that only
a small number of skilled staff will run this tool and
that they will have detailed guidance as to when and how
to use the tool."
A. Yes.
Q. So pausing there. The existence of this document and
the development -- careful development we see here of
the tool shows, firstly, that there was a need for the
tool?
A. Yes.
Q. Secondly, there was a recognition that it was a powerful
tool?
A. Yes.
Q. Thirdly, that because it was a powerful tool there was
a need for protections?
A. Yes.
Q. In the form of a limited number of people able to use
it, yes?
A. Yes.
Q. And clear guidance?
A. Yes.
Q. We also see, I think you know, that there is a table,
journal table to which it writes so its use can also be
audited?
A. Yes.
Q. We have seen from the Anne Chambers' comment about
wanting to go off piste with APPSUP that the APPSUP role
was valued by SSC, including by Anne Chambers. We have
seen that from the PEAK?
A. They felt they had to use it, yes.
Q. And the APPSUP tool was even more powerful because it
was unbounded as to which tables it could access?
A. I think so, yes.
Q. And it didn't have those protections?
A. I think you are right, yes.
Q. And Mr Coyne identifies this in his second expert report
at {D2/4/244}.
MR JUSTICE FRASER: Do you mean 4 or 4.1?
MR GREEN: My Lord, actually I have got the wrong reference
here but I think it is the same in both.
The short point is that we can see that -- perhaps
the easiest place to look at it is {F/594/1}. This is
a 2010 PEAK --
A. This is a BT, is it?
Q. -- which was to be created. This is a PEAK to amend the
tool.
A. Yes.
Q. And --
A. Well, more precisely to amend the templates, I think.
Q. To amend the templates. Well, the point is if there was
no perceived use for the tool in future it would be
surprising to spend a lot of time and effort developing
a template for its use?
A. Well, there are lots of templates, there are several
templates, and the previous document was referring to
the precision required in the SQL. That was the
precision in the templates rather than the tool itself
which just ran the templates.
Q. The short point is that a tool was -- the transaction
correction tool was carefully designed to meet a need,
it is common ground that that specific tool was only
used once?
A. Yes.
Q. And it is fair to infer that there would have been
occasions when that tool could have been used and the
APPSUP tool was used instead?
A. I want to be careful about that because they would only
go off piste, as Anne put it, when they really had to.
Q. How do you know that? That's speculation.
A. In one of the two interpretations, I think Fujitsu/SSC
staff would not want to do a labour intensive support
task if they had a tool to do the job, or templates to
do the job. That's the inference I'm making.
Q. The APPSUP role gave them a freedom they didn't enjoy
with using the transaction correction tool itself,
didn't it?
A. And it gave them a freedom that I infer they didn't want
to use more than they had to.
Q. Let's look at Mr Coyne's revised report at {D2/4.1/247},
please. If we look at paragraph 5.438.
A. Yes.
Q. He says in his opinion:
" ... it is my opinion that more than one BT has
been conducted ... for the following reasons."
Yes?
A. Yes.
Q. And he says the tool was created on 12th March.
A. The PC was created -- the PEAK was created.
Q. I'm so sorry, the PEAK was created on 12th March which
relates to the transaction tool. He says it has now
been used in live:
"The templates for use with this tool need to be
updated to correct some details. Gareth Seemungal is
aware of the corrections needed …"
A. Yes.
Q. "… The proposed fix would correct and update the BRDB
transaction correction tool templates, making it less
likely that mistakes will occur when SSC are trying to
resolve problems with transactions in BRDB."
Yes?
A. Yes.
Q. He says:
"This suggests that modifications and balancing
transactions conducted by Fujitsu support staff within
the BRDB is not unusual."
A. Well, I think that the transaction correction tool was
made to make a number of changes with different
templates to the branch database, most of which were not
transaction corrections.
Q. And you wouldn't disagree that it is a fair opinion for
Mr Coyne to have formed, what he said there?
A. As I said, the uncertainty in my mind is that there were
several templates and they were doing different things
and you only need one template to do a transaction
correction.
Q. We have seen what the purpose --
A. The low level design says it can do this table and that
table and so on.
Q. And the tables we saw would affect branch accounts?
A. No, there are a lot of tables there different from the
ones used in the one BT.
Q. You were able to use it to access tables that would
impact branch accounts, weren't you --
A. Certainly.
Q. And he says in his report, at (ii) he says:
"Fujitsu were able to insert balancing transactions
outside of utilising the branch correction tool referred
to above."
Yes?
A. I'm not sure what he is referring to there.
Q. If they used the APPSUP role they could do so. We have
agreed that.
A. We have agreed but if they have got a tool to do it, to
hand-craft some SQL to do it would be very time
consuming, and why would they want to do it if they had
a tool?
Q. What do you infer from the fact that a tool was not only
carefully developed to meet a need but also had its
templates revised but only appears to have been used
once for that purpose?
A. It was only used once for a balancing transaction, but
I think it was used other times for these other purposes
involving other tables.
Q. Is that something you specifically have seen or
conjecture?
A. It is not conjecture. Unfortunately my memory is a bit
unclear but I have seen -- I mean, for one thing the low
level design talks of other tables, other than the ones
used in the BT. That's the first piece of evidence.
And it talks about templates in the plural whereas one
template would have been needed to do a balancing
transaction. So that is the second piece of evidence.
Now the third one, I think somewhere I looked at
some records of how it was used and found there were
these other uses not to do with affecting branch
accounts.
Q. You are not sure what that was?
A. I'm not sure of the third piece of evidence. I am sure
of the first two.
Q. What we can say fairly is from the discussion in the
PEAK, the APPSUP PEAK, they clearly did very much value
having the APPSUP role?
A. Yes, they needed it sometimes.
Q. Can we look at a document which is dated 24th May 2019,
so it is obviously a recent document. It is at
{F/1848.8.3/1}.
There is absolutely no complaint whatsoever about
this being provided on 30 May, because it is a document
dated 24th May, but I mention the date it was
provisioned. Dr Worden, had you had a chance to look at
this or not?
A. I haven't looked at this. I do not think I have. It is
not familiar. I have tried to read a lot lately.
Q. It is a global user process management document.
A. Yes.
Q. It says:
"A process called Global User was brought in to
replace the One-Shot (single use) password process used
on Horizon. It allows roles in the business, such as
auditors, to be able to go out to any branch and use the
same log on to access any Horizon kit in Branch without
having to request a single use password at each branch."
A. Yes.
Q. "The individual requiring a Global User account has to
be approved by a Manager showing on the Global User
requester and approver list."
Yes?
And you see "Issue identified" by PwC. It says:
"PwC identified during an audit that the current
Global User list inherited from Fujitsu contained
employees who had left the Business. This raised
concerns over the security of access to Horizon.
Although this is a low risk in terms of Horizon access
(the individual would have to gain access into a Branch
first), it is still a risk and needed to be mitigated."
Do you see that?
A. Yes.
Q. Then the actions taken, second bullet point:
"32 individuals were identified as having left the
business."
But to be fair, half of these had only recently left
in April 2019. Yes?
A. Mm.
Q. Then under "Next Steps":
"There is no current owner of the process. NBSC
administer it but the actual Global User process to
maintain the data has not been owned by any area for
some years."
A. Yes.
Q. Pausing there. Let's start at the top, is that ideal?
A. It doesn't sound ideal, no.
Q. It is not great access control, is it?
A. Something has fallen between the cracks, yes.
Q. Dr Worden, just a more general point. It is right,
isn't it, that when something has been identified
correctly as a system problem and fully investigated, we
are likely to see more documentation about that than we
would otherwise?
A. Do you mean a system problem or a process problem like
this?
Q. Ignore process. We are back into system.
A. Right, okay.
Q. So on a PEAK or something like that. And I think to be
fair to you, I think there are circumstances in which
PEAKs will be generated by SSC where their own records
tell them that there has been a problem like a failed
reversal or something like that?
A. You are talking about records other than the PEAK?
Q. PEAKs or KELs, yes.
A. Yes.
Q. And the broad point is the more investigation that's
done and the better the problem is recognised as
a system problem, the more documentation we are likely
to see about it?
A. Well, I mean, Fujitsu's incentive when a problem arises
is to fix it as soon as possible. If they can fix it
simply then we won't see as much documentation as if it
is difficult and takes a lot of different investigation.
Often in PEAKs we see investigations going around the
houses and so on.
Q. Finally, Dr Worden, can we just look at your declaration
at the end of your first report, please. It is on
{D3/1/260}. At 1194 you have referred to guidance in
a case at the end of that paragraph.
A. Yes.
Q. Was that something that -- was that case something you
had looked at on your own initiative?
A. Not on my own initiative, no. I was pointed towards it.
Q. Did you identify the reference to that case and the case
report reference?
A. No, the document was supplied to me.
MR GREEN: Thank you very much. My Lord, I have no further
questions.
MR JUSTICE FRASER: All right. Mr de Garr Robinson, some
re-examination?
MR DE GARR ROBINSON: Yes, my Lord.
Re-examination by MR DE GARR ROBINSON
MR DE GARR ROBINSON: I would like to start, Dr Worden, by
asking you a few questions about your scaling
calculation.
A. Yes.
Q. This was covered on Tuesday. You were taken to
{F/1837/1}, so I would like to look at that, please.
A. Yes.
Q. The questions you were asked focused on columns E and F
of that table. Do you remember?
A. E and F, "2007" and "2007 Gaps".
Q. Yes. You explained, when you were asked how you had
arrived at your calculation in your first report, that
you took a column for 2007 which you knew had gaps,
having looked and seen that the gaps were not
significant, do you remember that?
A. That is right, yes.
Q. I think you called it eyeballing?
A. Yes.
Q. For your Lordship's note, this is at {Day18/196:1} to
page 198.
And at one stage it was put to you that you had
given false evidence about what you had actually done in
that calculation, and the premise upon which this was
put to you is that ...
This is different from the table I have just seen
(Pause)
What I asked to look at was {F/1837/1}.
A. The gaps has gone. It seems to be empty now.
Q. There we are. So we are at 1837. You see there is
a column which says "2007" and there is a column which
says "2007 Gaps". One of those columns is complete and
one of those columns has gaps in them. And what was
suggested to you was that given there were two columns
with these figures, with this configuration, one
complete and the other with some gaps in, you cannot
possibly have chosen to take the one with the gaps in
without making a mistake. Do you remember that?
A. I remember that, yes.
Q. And it was suggested that your explanation as to what
you had done couldn't be right. I would just like to
explore that surprising suggestion briefly.
As Mr Green said at page 176 of the transcript, the
spreadsheet we are looking at is an amended version of
the original spreadsheet that Mrs Van Den Bogard
actually referred to in her original statement. Do you
remember that?
A. I do yes.
Q. And the amended version, the version we are looking at
now, was produced in January.
A. Yes.
Q. So when you were doing your first report the spreadsheet
was different and it was disclosed with Mrs Van Den
Bogard's witness statement in November. For
your Lordship's note, that is at {H/137/1}.
Can we now go, please, to the document you may have
taken me to, which is {F/1837.1/1}. If we could go to
the top of that document, please.
You will see that column E says "2007" and column F
says "2007 Gaps", and it is column F that every now and
then contains an item.
A. Yes. And when there is a gap in E there is an item in
F.
Q. Perhaps we can scroll down a little bit until we see
one. There are not very many of them. We can stop now.
If we look at row 74 there is a figure of 6.
A. Yes.
Q. Is this the document that you used at the time you
produced your first report?
A. I think it was, yes.
Q. And when you said you eyeballed these columns, do you
recall what columns you eyeballed?
A. All columns, I presume, I think I eyeballed all columns.
And what is evident to me now is that where there is
a gap in 2007, the figure in "2007 Gaps" is taken over
from 2001 or whatever it may be. But my impression on
eyeballing was that there weren't many gaps.
Q. There weren't any gaps or --
A. There weren't many gaps.
Q. So you chose to take the figures in column E?
A. This was a long time ago and it has kind of been
superseded by the supplemental report where I did it
more properly.
Q. Can I just ask you what your reaction is to the
suggestion that you made a stupid mistake and should
actually have taken column F as your means of
calculation?
A. Well, obviously column F is not the column to take,
that's blindingly obvious.
Q. Thank you.
Now I would like to ask you about some questions you
were asked yesterday regarding ARQ requests. You gave
evidence, and this is at {Day19/17:1} onwards, that you
have always been aware that cost of requests over the
annual allowance of 720 ARQ requests was in the ballpark
of £250, do you remember that?
A. Yes.
Q. Now several things were suggested to you when you said
that. First of all, it was suggested that, in fact, the
true cost was £450. Secondly, it was suggested that
this is important because, as far as I could understand
from the line of questioning, £200 plus cost involves no
particular disincentive to make ARQ requests but a £450
cost creates a disincentive, and because of that it was
suggested it was quite misleading to talk of a figure of
over £200.
Stopping there, Dr Worden, I do not think you had
talked about a figure of £200. Is that something you
discussed in either of your two reports?
A. I do not think I did. The point which always occurred
to me and seemed to me obvious is if you are doing
100,000 TCs a year, to do any cost of £250 for each one
of them is ludicrous.
Q. I actually think that the point was intended to be
a criticism of me because I put that figure to Mr Coyne
in cross-examination and he agreed it.
The fourth point is that it was suggested to you
that when you said you thought the cost was in the
region of £250, you had no foundation for that figure
and you were simply giving answers which you thought
were consistent with Post Office's case rather than the
true facts, do you remember that?
A. I do I think, yes.
Q. So it is a serious allegation, an attempt to impugn your
veracity. You said that you had seen documents but
could not remember the particular document.
A. Yes.
Q. I don't know what documents you have seen but I wonder
whether the document I'm about to take you to might be
the one. Could we go to {F/1659.2/1} please. This is
a document which has been added to the trial bundles
overnight. There was no expectation that there be any
line of questions on this particular issue, so no one
thought to put this in the trial bundles originally.
Dr Worden, this is part of a contract between
Fujitsu and Post Office. If you look at page 1 you can
see the various different versions of that contract.
The earliest one on this version is 31st August 2006.
If we go over the page to {F/1659.2/2} we see what
I think is the current version, 12.0 on 3rd July 2017.
Now, I'm not aware of any clause in a contract between
Fujitsu and Post Office saying: if you go over the 720
ARQ allowance you pay X. Instead what I'm aware of is
an option to increase the allowance so as to allow you
to go over the 720 threshold. That option is provided
for on page {F/1659.2/689} perhaps we could look at
that.
MR JUSTICE FRASER: Have you seen this document before
Dr Worden?
A. I have not seen this, no.
MR DE GARR ROBINSON: Have you not?
A. No.
Q. If we look at paragraph 5.5 perhaps I could ask you to
read that Dr Worden.
(Pause).
A. Yes, read it.
Q. So you will see that there is a reference there to
a cost, if Post Office wishes to increase its allowance
of 720 ARQ request, you will see that the cost is
provided for £222 odd a day.
A. Yes.
Q. That was where my question to Mr Coyne came from, the
question which he accepted when I put it to him. But
the question I want to ask you, and it may be that you
have already answered it, is that might this be the
document from which you formed the impression?
A. I do not think it was actually. I think I have seen it
in several places, numbers of that ballpark and I'm
afraid I can't recall what those documents were.
Q. Very good. Let's move on to --
MR JUSTICE FRASER: I didn't mean to steal your thunder by
asking him if he had seen it before.
MR DE GARR ROBINSON: My Lord, I'm in a very forgiving mood,
so we will say nothing more about it.
Callendar Square. I will just ask a few questions
about Callendar Square. Mr Green took you to the
original Callendar Square PEAK with a view to looking at
how the story developed.
That was a PEAK that was I think started -- it was
opened on 15 September 2005. Then he asked you about
how long the Callendar Square bug had been in the system
and you agreed with him that it was since about 2000.
Do you remember that?
A. I agreed that the cause in Riposte had been May.
Q. The impression may have been given that the bug lay
undetected until the Callendar Square PEAK appeared and
I would like to ask you about that.
First of all, Mr Green drew your attention to
a document at {F/312.1/1} if we could go to that. You
will see at the top of the page this refers to
Callendar Square. It is dated 16/11/05. It refers to
Alan Brown, who I think is the subpostmaster of that
branch.
He says:
"PM HAS £3,800 THAT SYSTEM IS TELLING HIM HE MUST
SETTLE BEFORE HE CAN ROLL OVER. THIS IS FROM 8 WEEKS AGO
& IS DUE TO A WELL DOCUMENTED HORIZON SYSTEM PROBLEM.
CAN AIO CONTACT WITH REGARD TO THIS? SAYS AIO KNOWS
ABOUT IT HAVE TOLD PM HE MUST SETTLE."
The reference to "this is due to a well documented
Horizon system problem", what do you infer from that
about whether this bug was undetected or not?
A. This confirms other evidence I have seen that Fujitsu
were getting at Escher to fix this Riposte problem and
that was an ongoing debate between Fujitsu and Escher
and at one stage Escher said they had fixed it and it
turned out it wasn't fixed, and so that went on for five
years.
Q. I see. If we go to your first report please. That's
{D3/1/155}. If you look at paragraph 660 at the bottom
of the page, this is where you start your analysis of
the Callendar Square bug. You indicate it is described
in two KELs and several PEAKs and you identify them
there.
A. Yes.
Q. "First arose in 2000 and was not fixed until Release S90
in 2006."
I notice you refer to a number of PEAKs there. Some
questions have been asked of you over the last three
days which might have given the impression that you have
only been looking at KELs. When you produced your first
report to what extent had you had regard to PEAKs?
A. In this bug particularly so because one wanted to trace
the timeframe, time progression and you can see from
these PEAK numbers that they are rather early ones going
back to 0075 and so on and so forth. PEAK numbers
(inaudible). So, yes, I have looked at PEAKs in this
respect.
Q. Just extending further beyond just the Callendar Square
issue, did you look at PEAKs relating to other issues?
A. All sorts of issues. I have done a lot of surveying of
PEAKs to get the feel for the bulk of them, the balance
of population and so on, and I have general views about
this type of PEAK, that type of PEAK and so on. There
are PEAKs about harvester exceptions, that's one sort of
thing. There is PEAKs about receipts payments
mismatches and I have looked at a large number of these.
Q. Have you looked at large numbers of PEAKs when you
produced your first report?
A. Not large numbers at the time of my first report, no.
It has been more recent.
Q. What sort of scale of numbers had you looked at at that
stage?
A. In my first report?
Q. Yes.
A. I would say I have looked at the ones Mr Coyne had
raised in his report and I had looked at probably
a couple of dozen in connection with KELs.
Q. Now, one of the KELs that's referred to here in the
context of Callendar Square is J Ballantyne 5245K.
That's at {F/285/1}. For your Lordship's note, KEL is
cited in row 2 of the bug table in JS2 which is at
{D1/2/3}. You see that?
A. J Ballantyne, yes. "Time out waiting for lock." It is
I believe the Riposte cause; another symptom of the
Riposte problem.
Q. You will see halfway down:
"Original date 2000-11-02."
So the KEL was created on 2nd November 2000, is that
right?
A. Yes.
Q. You say another symptom of the Riposte problem. Perhaps
you could explain a little bit what you mean by that?
A. Well, I did explain and I will explain it again. That
there is a problem in Riposte which leads to a failure
to replicate -- failures to release a lock I think --
and then on certain occasions that leads to a short-term
failure to replicate. On other occasions there is
a so-called event storm during which there is a longer
term failure to replicate and during these failures to
replicate all sorts of different things may happen, for
instance they double transfer into a stock (inaudible),
a precise Callendar Square phenomenon; whereas other
things such as system freezes, I can't remember all the
other details, but there are many other symptoms of
then underlying Riposte problem and they have been noted
over this whole period.
MR JUSTICE FRASER: This is what you referred to yesterday
as Riposte lock, is that right?
A. Yes.
MR DE GARR ROBINSON: If we go to page {F/285/3} of the KEL.
And we go to the bottom section under the heading
"Solution".
A. Yes, rebooting was the quick fix. Rebooting, Cleardesk
were the sort of recommended things to do.
Q. Now, what does this indicate regarding the question
whether this bug was an undetected bug or not?
A. It was certainly not undetected for a long time. I mean
it was detected very early on and different
manifestations of it came up over this period.
Callendar Square was just one manifestation.
Q. Let's look at a PEAK that relates to the bug. This is
one of the PEAKs that was referred to in Anne Chambers'
2015 spreadsheet. You remember that?
A. Right.
Q. It is at {F/224.1/1}. It starts on 8 October 2004 so
it is a year before the Callendar Square PEAK, yes?
A. Yes.
Q. Now is this a PEAK that you have seen before?
A. I believe it is. I have certainly seen many like it.
On the face of it, it is about something happening in
the host, ie at the back end, but it may well -- some of
these you look at and you find they actually derive back
to the branch.
Q. I see. So this is an indication of what was happening
on the ground some time before the Callendar Square PEAK
itself was produced. If we look at page {F/224.1/1}, do
you see it says in the first box underneath the second
line:
8/10/04, 10.59:
"The host generated cash account line Comparisons
Report.
TPSC256 for processing date 07/10/04 shows a R & P
diff for FAD 162824 in CAP 28 where Receipts =
£1149340.21, Payments = 1148956.69 and Diff = 383.52."
A. Yes.
Q. Could you explain -- are you in a position to explain
what TPSC256 means?
A. It is a back end report. Cash account line comparisons.
It is one of the back end reports to do with TPS, which
is feeding transactions to the Post Office, and
sometimes these transactions have to be fixed in various
ways before they can go to the Post Office.
Q. So this report is generated. To whom is the report
produced?
A. Fujitsu look at the report I think and if there are
problems Fujitsu try and fix them.
Q. If we go down just a few lines, it says about four lines
down:
"This FAD also appears on TPSC268A with a difference
of exactly half the amount."
There is a question as to whether it is related.
Could you say what TPSC268A is?
A. There are several TPS reports and it is quite a long
list, I cannot say precisely which one is which. But
they do give different slices of information which is
going to Post Office.
Q. So this is an example of the Callendar Square bug. If
we could go over the page to page {F/224.1/2}?
A. Sorry, could I just interject there that you see
a smallish receipts/payment mismatch. One of the
manifestations of the Riposte problem was that when you
were doing balancing, one of the counters in the branch
was isolated and say had been isolated for half an hour
or something, so the transactions from that counter
would not get into your balance so you would have
a small payment receipts mismatch and I think this is
probably one of those. Again it is not Callendar Square
exactly, it is the Riposte bug leading to a counter
being isolated for a short while.
Q. I see. If you go to over the page to {F/224.1/2} you
see about two lines down from the top:
"MSU need to inform POL so they can take appropriate
action."
Do you know what that signifies. Who is MSU?
A. Management Support Unit and obviously because this is a
TPS problem there will be some discrepancy in POL and in
the stuff going to POLSAP, for instance, that has to be
fixed.
Q. We will see that the PEAK is closed on 12 October, which
is four days later. What does this tell us about what
was happening on the ground in relation to
manifestations of problems relating to the
Callendar Square bug even before the Callendar Square
PEAK was --
A. It shows that some of them were being detected by
routine monitoring and, for instance, I would also
suspect that any manifestation of the Riposte bug which
led to a double stock transfer in and a single stock
transfer out, that is a double entry accounting failure
and that would certainly be picked up at some stage. So
there are a lot of ways in which this phenomenon would
be automatically detected or easily detected at the back
end.
Q. Let's look at that very point. If we can go to
{F/253/1}, this is another PEAK referred to in the JSC2
bug table in relation to Callendar Square, it is fourth
on the list. It is PC0116670. This PEAK starts on
24th February 2005. It is a good number of months
before the Callendar Square PEAK. We can see at the top
right-hand side "call logger/deleted user/MSU". Can you
explain what that means?
A. Yes. This is somebody in the Management Support Unit
has raised this problem. It is to do with this
reconciliation report which is another of these TPS
reports about what's going to Post Office.
Q. Then we can see that, can't we, in the first box, four
lines down:
"Summary TPS reconciliation report."
I was going to ask you what that means but you have
already told me. There is a reference also to some
particular TPSC numbers, 256, 252, 268A. Those are the
reports we have just~--
A. Yes. That's showing the same error is popping up in
several reports.
Q. What does this PEAK tell us about Fujitsu's awareness of
the issue that was --
A. Well, it says that several manifestations of the Riposte
problem were easily detectable by Fujitsu and they would
be. They had systems set up to detect just this sort of
thing.
Q. And the manifestation which produces the symptoms that
we now call Callendar Square, would they be picked up?
A. I said that the symptoms that now we call
Callendar Square are this double stock transfer in,
single stock transfer out. That is a double entry
accounting mismatch failure and that will certainly be
detected at the back end when it gets to POLSAP or if
not before.
Q. Let's have a look at one final PEAK that's relevant to
Callendar Square. This is one that you referred to in
your report and it is in the bug table as well. It is
{F/210/1}. Perhaps we can have a look at that.
What is the date? It starts 3rd June 2004. So we
are more than a year before the Callendar Square PEAK.
If we go to the bottom of page {F/210/2} there is what
I believe is a yellow box.
A. I don't get the colours.
MR JUSTICE FRASER: Do you not get colours on this?
A. Not on the screen.
MR DE GARR ROBINSON: I don't either.
MR JUSTICE FRASER: Really? I didn't know that. I suppose
a bit late to find out during re-examination of the
final witness of a trial that started in March but --
MR DE GARR ROBINSON: My Lord, it is never too late to
enhance the system. I feel that we can all agree that.
MR GREEN: There is colour on the far end.
MR DE GARR ROBINSON: I see that Ms Keating has
a beautifully coloured screen, but I'm not being bitter
about it. My Lord, if we could look at
page {F/210/2} --
MR JUSTICE FRASER: As you said earlier, you are in
a forgiving mood. I'm sorry you don't have colour,
Dr Worden, I didn't realise. Are we going to the bottom
box?
MR DE GARR ROBINSON: Right at the bottom box. I'm going
read the last two lines and then perhaps we could go
over the page when I get to the relevant point:
"Eventlog from node 4 suggests that Riposte
replication had not been successful and so while node 3
had successfully TI the txns, this information was not
apparent to node 4 thus it was perceived by node 4 that
those txns were outstanding waiting to be TI. Therefore
when the user SMU001 logged onto node 4, he was
presented with Outstanding Transfer message which had to
be accepted or declined. The user chose to accept them
even though he tells me that at this stage he was a
little concerned because he was certain that user ASU010
had already TI on node 3. This has created a discrepancy
on their Cash Account £22,290.00. Also the Host has
reported a reconciliation error in TPSC256 for
£44,580.00."
A. I did remark on that I remember noticing the exact
double figure.
Q. It is clearly a function of the different reports, one
picks up the right figure, there is another report which
doubles it for various reasons.
A. Yes.
Q. Now if we go down to the third page {F/210/3}. There is
an entry for 8th June 2004 at 14.48. It says~--
A. Errors in the three reports.
Q. Errors in TPSC reports 252, 256, 268A. This confirms,
I believe, the evidence you have already given, which is
the actual Callendar Square symptom we are talking about
is picked up by these reports, yes?
A. Yes.
Q. Let's see how it was handled. If we go to page
{F/210/5}. Box: 11 June at 16.30. It has been
transferred to MSU. Then if we go down further the
page: 22 June at 15.38 and it has been transferred to
EDSC. Why am I telling you those things?
We go over to page {F/210/6}. 6 July, 11.44:
"I've checked with Mike King; the BIMS report for
this problem was sent to POL on 22/6 and should have
resulted in an error notice being sent to the branch
Mike says he will send a note to POL saying that the PM
has been chasing this issue; I've asked HSH..." which
I think must be the help desk.
"... to inform the PM that they should have received
an error notice and to check with the department that
issues them."
Then if we go on to page {F/210/7} you will see
5th August 2004 at 11.57.
A. He's confirmed he got it.
Q. That's three boxes down:
"PM [Mr Mogul] has confirmed that POL have issued
him with an Error Notice of £22290.00 which has enabled
him to clear the error from his account. He is happy for
this call to be closed."
Now the evidence you gave when asked about it by
Mr Green is that regardless of procedure in the majority
of cases if there is an R&P mismatch it will be sorted
out eventually. Mr Green queried whether you had any
basis for saying that. Are the PEAKs we have seen
relevant to that view --
A. Yes, they are very relevant particularly this one, it
shows that it is picked up on three reports at the back
end. There is a lot of going back and forth, but end of
the back and forth is the BIMS and Post Office being
alerted and the branch being sorted out.
Q. Thank you. If we could now have another look. It was
suggested by Mr Green that the problem may have
persisted even after it was fixed by Release S90 in
2006. If we could go to the document that Mr Green put
to you for that purpose. It is {F/565/1}.
You will see the original date, it was opened on
10th May 2002, halfway down, do you see that?
A. 10th May 2002, yes.
Q. Immediately below that there is a revision date,
11 January 2010?
A. All right, okay.
Q. Perhaps we can go to the last page of this document now
{F/565/3} and we see what must be the reason for the
update. It is the very last paragraph:
"Update: 11/01/2010."
There is a reference to a PEAK:
"If the message was seen on a Correspondence server
and the source of the message is Riposte then raise a
Peak call and route it to SSC to stop and restart the
Riposte service under OCP. If the errors are seen on
more than one Correspondence server at the same time
then further investigations should be carried out."
It was suggested to you that that update may suggest
that the Callendar Square manifestation continued after
the fix in 2006. You can take it from me, I have looked
at the PEAK that's referred to here, and that is not the
manifestation of the Callendar Square bug. But what
I want to ask you is whether you were aware of any
incident after the fix of the Callendar Square bug, any
incidents in which the Callendar Square symptoms
occurred again?
A. No.
Q. Thank you. Now, today we had some rather extraordinary
questions about the derivation or where the word "grey"
came from and I'm going to ask you about that. It
starts in appendix D3 of your first report. Could we go
please to -- what is the reference? I'm afraid I have
not written it down.
It will be {D3/2/129}. You were asked about
paragraph 5.93. Do you see that? You were commenting
on particular paragraphs of Mr Coyne's first report
where he refers to particular KELs, yes?
A. Yes.
Q. If we go to your analysis, the middle paragraph you say:
"This was caused by a complex 'grey' communications
failure which could not be reproduced - so diagnosis was
not complete."
And you were asked where you got the word "grey"
from?
A. I imagine it may well be from the KEL.
Q. I was going to ask you. If we can go to the KEL, that
is at {F/757/1}. I will just let you glance down the
heading but I don't really need much of substance, just
to refamiliarise yourself.
A. Comms became available. Yes.
Q. If I could ask you to go to page {F/757/2}. Under the
heading "May 2010 Update by Development."
A. We have black and white immediately.
Q. It says:
"When comms are black and white, i.e. always on or
always failing, it is fairly straightforward to recreate
a particular situation. However the sequence seen in the
log files is so complex it is not possible to replicate
the conditions."
Now, having seen that text, does that refresh your
memory as to where the word "grey" might have come from?
A. So "grey" is not actually in the KEL, is that right?
Q. Yes.
A. Well, obviously black and white, grey is between back
and white, and it is exactly as I described it, as an
intermittent fault. Grey would be one way of describing
it and I would probably have made up that word myself.
MR DE GARR ROBINSON: Right. Would you give me a moment
please Dr Worden.
My Lord, I have no further questions.
Questions by THE JUDGE
MR JUSTICE FRASER: I have just got a couple.
Dr Worden, this afternoon you were asked quite
a long sequence of questions about privileged user logs,
do you recall that?
A. Yes.
MR JUSTICE FRASER: It was only at about 3.05.
A. Yes.
MR JUSTICE FRASER: In the course of that you confirmed,
I think, that you found the privileged user logs unclear
when you've looked at them, is that right?
A. That is right.
MR JUSTICE FRASER: In one of your answers you said you
couldn't get to the bottom of it in the time that you
had devoted to it.
A. That is right.
MR JUSTICE FRASER: Can you just give me an idea of how long
you had devoted to trying to --
A. Looking at privileged user access logs, less than a day.
MR JUSTICE FRASER: All right. But a reasonable number of
hours I imagine?
A. Yes.
MR JUSTICE FRASER: I don't want to put words into your
mouth if that's --
A. What they are is this monster spreadsheet that gives you
one day's worth of data and I looked around.
MR JUSTICE FRASER: All right. That's very useful. Thank
you very much.
There are a couple of questions but it relates to
the same event. Now, relatively recently you served
your third report directly on the court?
A. Yes.
MR JUSTICE FRASER: I'm not going to be asking you any
questions at all about the content of that document.
But I just want to ask a couple of questions so that
I can understand the sequence because I have already had
an explanation from Mr de Garr Robinson and I have also
had a witness statement from the Post Office's
solicitors.
A. Yes.
MR JUSTICE FRASER: The documents that you relied on in
order to prepare or compile or draft that report are
PEAKs, KELs, OCRs, OCPs, etc?
A. Yes.
MR JUSTICE FRASER: When did you first get access to those
documents?
A. Well, PEAKs was -- the full set of PEAKs I can't recall
the exact date, but it was way back in 2018 and the OCPs
and OCRs, again I cannot recall the exact date, but
I have had them for some months I think and the idea of
automatically searching them in this way came to me
comparatively recently.
MR JUSTICE FRASER: But the actual documents you had had
a number of months, is that correct?
A. Yes.
MR JUSTICE FRASER: Then, you have been a witness I think,
an expert witness, in a number of other cases?
A. I have.
MR JUSTICE FRASER: Have you ever served one of your expert
reports directly on the court before?
A. I have never done that myself before. I had it done to
me.
MR JUSTICE FRASER: But you have never done it before?
A. A kind of late report, no. I mean the issue of serving
direct on the court rather than through lawyers, I don't
recall how that happened in the past. I suspect it was
all done through lawyers.
MR JUSTICE FRASER: But in this case everyone knows you sent
an email to my clerk?
A. I did, yes. That's what I was advised to do, that was
how I was advised to do it.
MR JUSTICE FRASER: You were advised to do it?
A. By Post Office lawyers, yes.
MR JUSTICE FRASER: All right. And the email -- the
covering email, did you show the drafting of that to
your instructing solicitors before you sent it or did
you just draft it yourself?
A. I just drafted it.
MR JUSTICE FRASER: And did you check or have it approved by
them?
A. No, I think I had been given some advice as to what it
should cover.
MR JUSTICE FRASER: All right. Okay. Well I don't have any
more questions about that, thank you very much. I don't
know if either of you have any follow up questions on
that, but if you do it is not to go to the content of
the third report.
MR GREEN: My Lord, no. My learned friend gave some
evidence about having checked the PEAK himself, I expect
I'm not allowed to cross-examine him on it? Perhaps
I will save that for closing submissions.
MR JUSTICE FRASER: Regardless of how forgiving he might be,
I'm not that forgiving.
MR GREEN: I'm grateful.
MR JUSTICE FRASER: Although I'm relatively forgiving. So,
Dr Worden, that is your evidence at an end. Thank you
very much.
A. Thank you.
MR JUSTICE FRASER: I do however have one point, which is
a point for you, Mr de Garr Robinson, I'm afraid. I'm
not going to go through it in enormous detail but just
to give you the references, yesterday at
page {Day19/204:1} you gave me an explanation about the
recent disclosure that was produced in late May which
concerned OCPs, OCRs etc.
MR DE GARR ROBINSON: It was some OCRs I believe, my Lord,
yes.
MR JUSTICE FRASER: In the course of that, and it is at
page 204, I will just read out what you said, you
described that they were maintained on the Fujitsu
system and you said:
"Much later Fujitsu discovered an old database had
been copied more than ten years previously on the system
somewhere and told the Post Office they had those
collection of documents and then the Post Office
produced them, etc."
Today, at 11.37, Mr Green put a document to
Dr Worden which is {F/1848.8.2/1} which is a PEAK
dealing with the Drop & Go discrepancy, which he said
was disclosed on 30 May 2019 and is a PEAK that is, on
its face, dated 21st August 2018. So it can't fall
within the category of documents on the old database
etc. Can the witness statement please specifically
deal --
MR DE GARR ROBINSON: It can. I asked about that. I knew
nothing about it until it came up. I have asked about
that and there is an account which can be --
MR JUSTICE FRASER: As long as that can also be included.
MR DE GARR ROBINSON: It can.
MR JUSTICE FRASER: Right. Thank you very much. Have you
got some more documents to give me?
MR GREEN: My Lord, we have compiled a bundle of the PEAKs
and KELs referred to during Dr Worden's~--
MR JUSTICE FRASER: Thank you very much.
MR GREEN: Apart from re-examination because we didn't know
what was coming.
MR JUSTICE FRASER: Don't worry about that, there has only
been a couple of things. Thank you. So I can with the
exception of re-examination that is my hard copy PEAK
and KEL data complete. Is there anything else
housekeeping, quasi housekeeping, any other points?
MR DE GARR ROBINSON: Not even quasi housekeeping, my Lord.
MR JUSTICE FRASER: Whatever that might be.
So, in terms of timetabling, I think there is a date
already been ordered for your submissions in writing.
We don't need to change that. It is the 1st and
2nd July, a day each. If there are to be any further
authorities, although I imagine even if there are they
would be limited given the subject matter of the Horizon
trial, but if there are if they could just be put in
an agreed bundle and I think for this tranche of the
trial that's it until then. Is that right?
MR DE GARR ROBINSON: My Lord, I hope so.
MR JUSTICE FRASER: Well, one never knows. But 1st and
2nd July, I look forward to seeing you all then. You
might have the chance to have your screens swapped.
MR DE GARR ROBINSON: I have got rather used it now,
my Lord.
MR JUSTICE FRASER: Thank you all very much and until then.
(4.26 pm)
(The court adjourned until 1 July 2019)