Friday 14 June 2019

Horizon trial day 20: transcript

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
   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".
   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
   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
   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
   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
   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
   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
   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.
   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
   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
   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
   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
   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
   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
   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
           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)
   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,
   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
   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
   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
   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
   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
   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
   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
           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,
   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."
   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."
           "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
   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 ..."
   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
   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
           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
   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
   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.
   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
           If we accept his definition of discrepancy and not
       yours, yes?
   A.  This is all about temporary discrepancies in branch
   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
   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
   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
   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,
   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,
   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
   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
   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
   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
   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
   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 ...
   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
   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
   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
   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
           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
   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
   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,
   (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
   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.
   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 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
   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
   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
   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 ..."
   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
   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
           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 ..."
   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
   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
   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 ..."
   Q.  It says:
           "This new version of Horizon was also included in
           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
           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
           "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
   Q.  Yes, service audits are a bit different to audits
   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
   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
   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."
   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
   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
   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
           (Handed) Thank you.
   Q.  We will give you one anyway in case you prefer a hard
           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
   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
   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
   Q.  Let's leave that.
   MR JUSTICE FRASER:  Where are you?
   MR GREEN:  Just under "Impact Statement" in that 1 to 4
           "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
   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
   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
           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.
           "(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
           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
   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
   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."
   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
   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
           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
           "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
           "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
   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
   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
   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 ..."
   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
   Q.  Okay.  So that appears to relate to what we have on page
   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
   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."
   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 ..."
   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,
   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
   A.  Can I pause there.  "Privileged access" to my mind is
       associated with the DBA function rather than the SSC
   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
   MR GREEN:  Understood.  My Lord, is that a convenient
   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 ..."
   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
   Q.  Yes.  So you have got the general introduction.  Then
       they deal with POLSAP.  If we go on to the next page
   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
   A.  Yes.
   Q.  And that's the bit where we saw increased risk of
       unauthorised and inappropriate changes etc, at the
   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
   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
           "... 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
   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 ..."
   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."
   Q.  So we can see that a TESQA and APPSUP access management
       provision has been added into this version of the
   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
   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
   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
   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
   A.  Yes.
   Q.  Now what do you understand to be excluded by that
   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
   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.'"
   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
   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
   Q.  Can I suggest to you, Dr Worden, by the time you had
       written your second report you had not read the APPSUP
   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
   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
   A.  Yes.
   Q.  So this is the section where you are responding to
       Mr Roll who disagreed with paragraph 1144 of your first
   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
   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
   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
   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,
   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
   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 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,
   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
   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
   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
   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
   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
   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,
   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
   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
           "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
   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
   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
   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
   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."
   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."
           "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
   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
           "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
           "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.
   Q.  He says it has been used 2,175 times to make emergency
       amendments to the BRDB.
           "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
   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
   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
   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
           "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
   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
   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,
   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
   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
   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
   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
   A.  Yes.
   Q.  Secondly, there was a recognition that it was a powerful
   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
   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
   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."
   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."
   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
   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."
   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
   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
   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
           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."
           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
           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
   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
   MR JUSTICE FRASER:  All right.  Mr de Garr Robinson, some
   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
   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
           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
   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
   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
   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.
   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
           He says:
           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
   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
   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
   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
   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
   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
   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
           8/10/04, 10.59:
           "The host generated cash account line Comparisons
           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
   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
           "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
           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
   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
   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
   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
   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
   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"
   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
   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
   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
   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
   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,
   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 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)