10 May 2023 – Stephen Parker
Hide video Show video
(10.00 am)
Mr Beer: Good morning, sir, can you see answering hear me?
Sir Wyn Williams: Yes, I can, thank you very much.
Mr Beer: May I call Stephen Parker, please.
Stephen Parker
STEPHEN PARKER (affirmed).
Questioned by Mr Beer
Mr Beer: Good morning, Mr Parker, my name is Jason Beer and I ask questions on behalf of the Inquiry. Can you give us your full name, please?
Stephen Parker: Stephen Paul Parker.
Mr Beer: Thank you very much for coming to the Inquiry to assist us today and thank you also for the provision of a witness statement. Can we look at that to start with, please. It’s dated 27 March of this year, and if you turn to page 38 of it, you should see a signature.
Stephen Parker: I do and that’s mine.
Mr Beer: Is that your signature?
Stephen Parker: Yes, it is.
Mr Beer: Are the contents of that witness statement true to the best of your knowledge and belief?
Stephen Parker: Yes, they are.
Mr Beer: Thank you. For the purpose of the transcript – there’s no need to display it – that statement is WITN00680100.
Mr Parker, I’m only going to ask you questions today about the issues that arise in what we call Phase 3 of the Inquiry. We may ask you to return at a later stage in the Inquiry to answer questions about Phase 5 of the Inquiry and, in particular, the role that you took and the evidence that you gave in the GLO trial, the Bates trial, including the making of three witness statements on 16 November 2018, 29 January 2019 and the 28 February 2019, and then when you gave oral evidence before Mr Justice Fraser on the 11 April 2019.
I’m going to be asking you some questions today about some individual cases which are going to be considered in Phase 4 of the Inquiry because it’s not currently our intention that you should come along and give evidence in Phase 4; do you understand?
Stephen Parker: I do.
Mr Beer: Thank you. Just as a general question, however, those three witness statements that I mentioned, the November 2018, the January 2019 and February 2019 witness statements, when you were making your current witness statement, did you have them in front of you when you were making it?
Stephen Parker: I did, and I cribbed some of the wording to save rewriting it.
Mr Beer: When you say “cribbed” to you mean cut and paste it?
Stephen Parker: Not exactly cut and paste. Cut and minor changes.
Mr Beer: Okay. Did you write stuff afresh?
Stephen Parker: Oh, yes, yes. Most of it was. I mean, we’re probably only talking about one or two minor paragraphs that were actually copied.
Mr Beer: I understand. Can we start, please, with your career and qualifications. You tell us in your witness statement that you left school at 16; is that right?
Stephen Parker: That’s correct, yes.
Mr Beer: Do you have any professional qualifications –
Stephen Parker: I don’t, no.
Mr Beer: – that are relevant to what we’re going to speak about today?
Stephen Parker: No.
Mr Beer: I think you moved to ICL, as it was then called, in 1985; is that right?
Stephen Parker: That’s correct, yes.
Mr Beer: You stayed there until you retired in December 2019, it had changed name in the meantime. So you worked for the company, you were a company man for some 34 years; is that right?
Stephen Parker: That’s correct, yes.
Mr Beer: You tell us in your witness statement that in that time you received what you describe as “industry specific, technical and skilled training”. Can you in broad terms tell us what you mean by that?
Stephen Parker: It was generally training on particular programming languages or methodologies. Some people skills training for team leading and management purposes. Just general IT industry training.
Mr Beer: Was it externally provided or in-house or a bit of both?
Stephen Parker: A bit of both.
Mr Beer: Can we look at the roles, in general terms, that you performed when you moved to the SSC, and I think you were there for 22 years by my calculations; is that right?
Stephen Parker: Yes.
Mr Beer: Can we look at a couple of documents alongside each other, please. I think we can do this. They’ll come up on the screen for you.
To start with, can we look at your Inquiry witness statement, please, at page 2. It’s really paragraphs 4 and 5 that I’m interested in there. Thank you. At the same time can we look at FUJ00082231. Can we look at page 2 of that witness statement, please, and, in particular, paragraph 7. So on the left-hand side you’ve got your High Court witness statement, on the right-hand side you’ve got the Inquiry witness statement; do you understand?
Stephen Parker: I do indeed.
Mr Beer: You’ll see that paragraph 4 of the Inquiry witness statement, on the right-hand side, is, give or take a few words, the same as the first sentence in paragraph 7 of your High Court witness statement?
Stephen Parker: Yes, indeed.
Mr Beer: “I began working in July ‘97”, “I began working in July ‘97”, yes?
Stephen Parker: Yes.
Mr Beer: If you look at paragraph 5 of the witness statement on the right-hand side, your Inquiry witness statement, the one beginning “My technical role”, and compare it to the rest of paragraph 7 on the left-hand side –
Stephen Parker: Yeah.
Mr Beer: – do you see any difference?
Stephen Parker: You’ll probably need to point out to me the difference you’re interested in.
Mr Beer: Just look at the witness statement on the left-hand side. You say:
“Within this role [the third line] I was the lead designer and part of the development team.”
Yes?
Stephen Parker: Yes.
Mr Beer: Then, on the right-hand side, paragraph 5, you say:
“Within this role I also developed some of the support tools used by the SSC and was for a few years the lead designer and part of the development team …”
Stephen Parker: Yes.
Mr Beer: So it’s that. The insertion of the “I was for a few years”, rather than “I was the lead designer”.
Stephen Parker: Yes. I understand where you are here. I couldn’t remember exactly how long I was the lead designer for and the development of things like the SSC, live website, were a cooperative effort. I took over that role in order to sort out some problems we had with the website, and carried on in that role for a period of time. But my role in that gradually diminished, as other people started to take over some of the website’s development. It’s difficult for me to quantify for you the exact periods when I was leading it and when I was just contributing to it.
Mr Beer: My question is, why has “I was the lead designer and part of the development team” become “I was for a few years the lead designer and part of the development team”?
Stephen Parker: I have no particular reason for that, it was just the way I was writing it at – in the second witness statement.
Mr Beer: If you had the witness statement in front of you, the High Court witness statement in front of you, which seems to be the case from what you said earlier and certainly for these paragraphs, because of materially the same language, what motivated you to insert the phrase “for a few years”?
Stephen Parker: I think because I didn’t want to give the impression that that was all I did for a long period. I sort of wanted to just clarify that slightly.
Mr Beer: What would you say to the suggestion that to the High Court you were seeking to emphasise or maximise the extent, importance and duration of your role, whereas to the Inquiry you’re seeking to reduce or minimise it?
Stephen Parker: That wasn’t on – that wasn’t on my mind when I made that change.
Mr Beer: So was it you remembered, after 2019, that it was only for a few years that you were the lead designer?
Stephen Parker: That’s fair, yes.
Mr Beer: Can we take the left-hand witness statement down and just look at paragraph 7 of the right-hand witness statement, please. You say:
“Between December 2009 and March 2010 I was a full-time Problem Manager/Operational Manager of the SSC, responsible for the management of incidents through the whole support process.”
That wasn’t the ultimate head of the SSC; is that right?
Stephen Parker: That’s correct.
Mr Beer: Who was, at this time, December 2009 to March 2010, the head of the SSC, the manager?
Stephen Parker: Tony Little.
Mr Beer: So had Mr Peach left by then?
Stephen Parker: Yes, I’m not sure exactly when Mr Peach left. But, I mean, effectively, when Tony Little took over, I acted in the problem/incident management role for him while he was trying to concentrate on other parts of the SSC.
Mr Beer: Was Mr Little previously a member of the SSC?
Stephen Parker: No, he wasn’t.
Mr Beer: Where was he brought in from?
Stephen Parker: It was another part of Fujitsu. I can’t remember now exactly what his previous job title was.
Mr Beer: Was this always an interim role until the appointment of the manager of the SSC had been made?
Stephen Parker: No, I don’t believe it was. I believe – I mean, I don’t know the intention behind whoever bought Tony in but there was nothing originally which suggested it was of a short-term nature.
Mr Beer: In the event, it did turn out to be of a short-term nature because in March 2010 you took over as manager of the SSC?
Stephen Parker: Correct, yes.
Mr Beer: We can see that if we scroll down to paragraph 8, please?
“In March 2010 I became the manager.”
Yes?
Stephen Parker: Yes, indeed.
Mr Beer: You remained in that position as manager of the SSC from March 2010 until you retired in December 2019?
Stephen Parker: That’s correct, yes.
Mr Beer: Yes, we can take that witness statement down.Yes, we can take that witness statement down.
You tell us in your evidence that your first working contact with what became Horizon, it was then known as Pathway, was way back in July 1997; is that right?
Stephen Parker: ‘87? No.
Mr Beer: ‘97. Did I say ‘87?
Stephen Parker: I believe so, but it was ‘97.
Mr Beer: You were then working as a support consultant in the SSC?
Stephen Parker: Yes, that’s correct.
Mr Beer: Were you providing first line support then?
Stephen Parker: No, that was third line support.
Mr Beer: That was third line, okay. So you were inside what became Fujitsu from almost the very start of the Horizon project?
Stephen Parker: Indeed, yes.
Mr Beer: To whom were you providing third line support from July ‘97, until the end of rollout in 2000?
Stephen Parker: Sorry, do you mean – I mean, we were providing support for the Horizon service to the Post Office.
Mr Beer: So there was no other project in which you were engaged? You were full time on that?
Stephen Parker: Yes.
Mr Beer: In that time, what’s your recollection of the nature and extent of the faults that were reported to you?
Stephen Parker: Very little, to be honest, after all these years. I couldn’t relate to you any particular faults. I would say it was a busy job, which is – I would expect to have been normal for the rollout of a new system.
Mr Beer: Can you recall whether the, I’m going to call it birth of Horizon was particularly problematic or regarded as particularly problematic within Fujitsu?
Stephen Parker: I don’t remember anybody using terms like that, no.
Mr Beer: So it was just another IT system no greater or fewer faults than might be expected?
Stephen Parker: Correct, yes.
Mr Beer: Can we look, please, at WITN04600100.
That’s the wrong reference: WITN04600104. Thank you. You’ll see that this document is entitled “Schedule of Corrective Actions [for the] CSR+ Development Audit”. Does that description of the CSR+ development audit ring any bells with you now?
Stephen Parker: The – I remember the term CSR+ but not the development audit, no.
Mr Beer: Now, if we just scroll down we can see the distribution list and we can see that you’re not on it. I’m not going to suggest that you saw or reviewed this document at the time. If we just look at the “Abstract” at the top of the page, it describes accurately what the document is:
“This document presents the Observations and Recommendations resulting from the referenced Internal Audit(s) along with the agreed corrective action, the action owner, and the date by which the action is to be complete. A status field is included for quick reference purposes.”
Can we look at page 9, please, of the document. The document is presented in this sort of spreadsheet format and there are a series of issues which are called “Reported Observations” and then a recommendation for each of them, and then in the right-hand column what has been agreed in terms of the action to be taken and a commentary on that.
Can we just look at the reference against 4.2.1. It reads:
“The audit identified that EPOSS continues to be unstable. PinICL evidence illustrated the numbers of PinICLs raised since the 1998 Task Force and the rate of their being raised.
“The EPOSS Solutions Report [then there’s a reference back to it] made specific recommendations to consider the redesign and rewrite of EPOSS, in part or in whole, to address the then known shortcomings. In light of the continued evidence of poor product quality these recommendations should be reconsidered.”
Thinking back to that three-year, or so, period that you were working in the SSC, whilst Horizon was being rolled out, essentially, tested and rolled out, between July ‘97 and, say, mid-2000, did you know that there had been an audit that had identified that the EPOSS system was unstable.
Stephen Parker: I don’t remember now being aware of that, I would have thought I would have heard something quite honestly. But it’s not in my memory.
Mr Beer: Is that because you would have thought you would have heard something because the correct functioning of EPOSS is essential to the correct functioning of the system as a whole?
Stephen Parker: Yes, yes.
Mr Beer: EPOSS is absolutely fundamental to this system?
Stephen Parker: Yes, indeed.
Mr Beer: Again, can you remember whether you knew that an EPOSS report had recommended consideration of a redesign and rewrite of EPOSS, either in whole or in part?
Stephen Parker: I have no specific memory of that.
Mr Beer: That would be quite a big issue, wouldn’t it?
Stephen Parker: I would agree, that would be a big issue, yes.
Mr Beer: A total rewrite of EPOSS?
Stephen Parker: Would be a considerable amount of work, yes.
Mr Beer: Did you know by May 2000 – ie the date of this report, so we’re well into rollout now – that the recommendation was that the earlier taskforce report and its recommendations to rewrite in whole or in part should be reconsidered?
Stephen Parker: I wasn’t aware of that, no.
Mr Beer: If we go over to page 10, please, and look at the bottom right-hand box. The one dated 10 May, I think:
“Following response received from MJBC: ‘As discussed this should be closed. Effectively as a management team we have accepted the ongoing cost of maintenance rather than the cost of a rewrite. Rewrites of the product will only be considered if we need to reopen the code to introduce significant changes in functionality. We will continue to monitor the code quality (based on product defects) as we progress through the final passes of testing and the introduction of the modified CI4 codeset into live usage in the network. PJ can we make sure this is specifically covered in our reviews of B&TC test cycles. Closed.’”
Did you know that the quality of the EPOSS code based on what were described as product defects, was supposed to remain under review during the introduction of the modified codeset into live usage in the network?
Stephen Parker: I wasn’t – I can’t remember that, no.
Mr Beer: We heard last week from Mrs Anne Chambers, she told the Inquiry that she would have expected this monitoring to have been done by the leaders of the SSC team. You were, I think, the deputy team leader in the month we’re looking at here, May 2000. Did you know that a monitoring exercise should be undertaken?
Stephen Parker: I don’t remember a monitoring exercise but I would have expected that to have been done just as much by the service managers, development team and the SSC. So I wouldn’t have thought it was just purely an SSC function.
Mr Beer: You said – you gave three people there –
Stephen Parker: I did.
Mr Beer: – three bits of the organisation –
Stephen Parker: Yes.
Mr Beer: – that you would expect to do the monitoring –
Stephen Parker: Yes.
Mr Beer: – one of whom was SSC?
Stephen Parker: Correct.
Mr Beer: Starting with SSC, can you remember whether, in fact, any such monitoring of product defects with the EPOSS code –
Stephen Parker: I don’t remember that monitoring being done.
Mr Beer: Right. The other two, I think you said service managers –
Stephen Parker: Service managers, yes, and also development.
Mr Beer: Just dealing with the service managers, who were you referring to in your description of service managers?
Stephen Parker: There is a Service Management Team who each manage particular aspects of – or each manage particular aspects of the service, so whether it was data centre service or counter service, or whichever, there would be specific service managers for those areas.
Mr Beer: So which of those would you, if this recommendation was – or this decision was to be carried into effect, to have been doing the monitoring?
Stephen Parker: I would have thought if there was a major recommendation like that, they would have probably just picked a specific person and asked them to get on with it. I can’t remember which part – what the official name was of the service manager who would look after the counter aspects of the service.
Mr Beer: You mentioned the development team, that they would or might also have a role –
Stephen Parker: Yes.
Mr Beer: – in carrying a decision like this into effect?
Stephen Parker: Yes.
Mr Beer: Why would they have a role in carrying a decision like this into effect?
Stephen Parker: Because they would be seeing the incident, incidents being forwarded to them from the SSC. They would also see the actual incidents coming in to them from the test teams looking at testing the actual, like, EPOSS code.
Mr Beer: Wouldn’t the obvious repository for a decision like this to be carried into effect be the SSC?
Stephen Parker: I wouldn’t have said so, no.
Mr Beer: Why not?
Stephen Parker: Because a particular project like that would probably require a separate person to actually concentrate on that, rather than the ongoing incident load on the support chain.
Mr Beer: But could not a decision like this be carried into effect by saying to everyone in the SSC, “If you see a defect, if you have a defect reported to you that may be concerned with or an investigation is concerned with the EPOSS code, log it, pass it to the deputy manager, [to you], or [by now you], the manager”?
Stephen Parker: That would be one way of approaching it, yes. I don’t remember that being done in this case.
Mr Beer: Can you remember anything at all about any ongoing monitoring by any person at all within Fujitsu of defects in the code for the EPOSS?
Stephen Parker: At any time or at this time?
Mr Beer: At this time and, I don’t know, for six months, a year or two afterwards?
Stephen Parker: I don’t remember that, no.
Mr Beer: You see, Mr Parker, there’s been a taskforce set up into EPOSS in 1998 which recommends a total or partial rewrite of the system. This review in May 2000 said “You should reconsider, Fujitsu, that recommendation”, and the decision was “Don’t do that, we’re going to do it through ongoing monitoring”. I’m trying to find out who was going the ongoing monitoring?
Stephen Parker: I understand. I can’t remember. No, I’m sorry, I just can’t help you with that. I don’t remember that going on.
Mr Beer: Would you agree that a fundamental problem with the functionality of the EPOSS code is something that should have been monitored?
Stephen Parker: Yes, I would, yes.
Mr Beer: Okay, can we turn, then, to – that can come down, thank you – the lines of support that were available, just to get these out there on the transcript. You tell us on page 4 of your Inquiry witness statement, from paragraph 13 onwards, about each of the four lines of support, and you start at paragraph 13 with first line support. Just trying to summarise this, rather than reading it through, is it right that, essentially for first line support, there were three elements to it: two supplied by Fujitsu and one supplied by the Post Office itself?
Stephen Parker: Yes. I say cautiously yes, because I’ve realised since that I have omitted one of the teams from that paragraph 13, which was the Incident Management Team, IMT, which was also within the HSD.
Mr Beer: Okay. Is that a subset of the HSD?
Stephen Parker: Yes, it is.
Mr Beer: So far as the Fujitsu side of the house is concerned, there were two elements. The Horizon Service Desk, the HSD?
Stephen Parker: Yes, yes.
Mr Beer: That’s sometimes called the Horizon System Desk or HSH, yes?
Stephen Parker: It had various names, yes.
Mr Beer: And sometimes the Horizon Incident Team?
Stephen Parker: Yes. I believe that was the same as HSD, yes.
Mr Beer: Then the subset of it that you just mentioned was?
Stephen Parker: The IMT, the Incident Management Team.
Mr Beer: What did the Incident Management Team do?
Stephen Parker: I have trouble now remembering their exact function. I just remember the name.
Mr Beer: Then the second element provided by Fujitsu was the Communications Management Team, you describe it as, in paragraph 13.
Stephen Parker: Yes, correct.
Mr Beer: Sorry, you describe it in paragraph 13 as the “Communications Monitoring Team”?
Stephen Parker: Yes.
Mr Beer: Is that a typo, should that be “Communications Management Team”?
Stephen Parker: It was probably my memory rather than a typo. With these sorts of acronyms, occasionally the actual meaning of it gets lost in time.
Mr Beer: The only reason I ask is, if we just go on to paragraph 15, you describe it there as the “Communications Management Team” –
Stephen Parker: Right, right.
Mr Beer: – and every other document I can find calls it “Communications Management” rather than “Monitoring”.
Stephen Parker: In which case, it should be “Management Team”, yes.
Mr Beer: Okay. Then, so far as the Post Office side of the house was concerned, it was the NBSC; yes?
Stephen Parker: Yes.
Mr Beer: You describe it back in paragraph 13 as the “National Business Support Centre”.
Stephen Parker: Yes.
Mr Beer: Again, other documents describe it as the “Network Business Support Centre”. Can you recall, or –
Stephen Parker: I suspect now the latter is probably the accurate one.
Mr Beer: Okay, thank you. Dealing with those three elements of first line support, then, Horizon Service Desk, Communications Management Team, both Fujitsu and then the NBSC, Post Office, how would a subpostmaster know which of those three elements of first line support he or she should contact, if they’ve got an issue?
Stephen Parker: I don’t know what information was given to subpostmasters in terms of where to call. I would have expected them to have been given one number and then been onwardly routed, but I don’t know what the guidance was and given to me.
Mr Beer: So if they had a discrepancy, a failure to balance, for example, which of those three would you expect them to either contact or be routed to?
Stephen Parker: NBSC, initially.
Mr Beer: Why NBSC initially?
Stephen Parker: Depending upon whether it was a business issue or a suspected problem with Horizon.
Mr Beer: How would a subpostmaster know whether their discrepancy was a business issue –
Stephen Parker: They wouldn’t.
Mr Beer: How would they know who to call, then?
Stephen Parker: Well, I can only go back to saying I don’t know how they were told to call in but I would have expected them to have a single point of contact, which then they talked to, and then it would be onwardly routed appropriately.
Mr Beer: Did you know anything about that routing, how had person –
Stephen Parker: No, I didn’t.
Mr Beer: – would decide whether this was a business issue or a software issue –
Stephen Parker: No, I didn’t.
Mr Beer: – or a hardware issue?
Stephen Parker: No.
Mr Beer: Did you ever form an impression of how technically knowledgeable the average subpostmaster, assistant or Crown Office employee in the Post Office was?
Stephen Parker: I would just – no, I didn’t. My only thought on that would be, like any – in a population that’s going to actually vary wildly.
Mr Beer: So fairly representative of the population at large?
Stephen Parker: I would have thought so, yes.
Mr Beer: Many of the subpostmasters who would have given evidence to the Chair in Phase 1 of this Inquiry last year said that, when they were speaking to the Helpdesk staff, they appeared to be using scripts when they spoke to them. Were you aware of that practice, the use of a script by the Helpdesk?
Stephen Parker: I was aware of that practice. I didn’t ever get involved in writing of such scripts, and it’s a fairly common, like – and process within helpdesks to have a script of some sort.
Mr Beer: Did you ever see any of the scripts that the Helpdesk was reading out down the phone?
Stephen Parker: Don’t remember seeing any of them.
Mr Beer: Can you remember, with that in mind at all, whether what the content of the scripts was, how they worked?
Stephen Parker: Only to the extent that I would occasionally see in incidents which came to the SSC, a clear series of questions and answers in that incident text, and I assumed those would come from that kind of a process.
Mr Beer: So it would say, “Ask question A” –
Stephen Parker: “Answer” –
Mr Beer: – “If answer is A1 then ask this”?
Stephen Parker: Not to that extent but I would see – you would see a series of “Ask this, answer that” within the text.
Mr Beer: Who was responsible within Fujitsu for producing the scripts, to your knowledge?
Stephen Parker: To my knowledge, I would expect it to be some of the senior technicians within the HSD.
Mr Beer: So ie the HSD produced its own scripts for itself?
Stephen Parker: I believe so, yes.
Mr Beer: Okay. Was there any SSC involvement in looking at, amending or approving the HSD scripts?
Stephen Parker: I can’t say we never saw one but there was certainly no such process. It would be a rarity for us to see and comment on such scripts.
Mr Beer: So you were seeing them almost by chance because a bit of them had been – or the answers to a bit of them had been cut and pasted into a PEAK?
Stephen Parker: Correct, yes.
Mr Beer: In your time in the SSC, did the SSC ever draw up the scripts for HSD? So that, for example, they – I’m sorry – that so, for example, they ensured accuracy that was in line with the SSC’s current understanding of an issue?
Stephen Parker: I don’t recall those, no.
Mr Beer: Were the scripts paper based, to your knowledge, or on a computer system?
Stephen Parker: I don’t know.
Mr Beer: Where would the scripts, to your knowledge, be held, ie within which department within Fujitsu?
Stephen Parker: Within the Helpdesk within HSD.
Mr Beer: What was the system or systems that HSD used to go about its business?
Stephen Parker: They would have a call logging system, which was, in the early days, PowerHelp; in the latter days, TfS.
Mr Beer: Just dealing with those in turn. PowerHelp.
Stephen Parker: Yes.
Mr Beer: You described it as a call logging system?
Stephen Parker: Yes.
Mr Beer: To your knowledge, would that contain any scripts which HSD staff were asked or required to read out?
Stephen Parker: It would be a logical place to put them but I don’t know.
Mr Beer: TfS, does the same answer apply to that?
Stephen Parker: It does, yes.
Mr Beer: You were telling me about the systems that were in place.
Stephen Parker: Mm-hm.
Mr Beer: Those were the first level, a call logging system. What other HSD systems were there?
Stephen Parker: They would have access to the SSC’s KEL system. I remember at some point in the process they also had their own Knowledge Base and I think I’ve been reading recently it was called HSD1 but I only remember that through very recent reading. And they would have access to reference kits, reference counters, in order to try out scenarios.
Mr Beer: So dealing with those in turn, on what system were the KELs kept, so far as HSD was concerned?
Stephen Parker: HSD had access to the SSC KEL, which I believe they used. Because I saw queries going through it.
Mr Beer: Did they have read-only access to it?
Stephen Parker: No, they were able to generate KELs, although the SSC would approve them and check the content.
Mr Beer: Did the KELs contain any script, the KEL system contain any scripts?
Stephen Parker: I don’t remember it doing so unless the HSH generated one. I don’t remember seeing scripts in the KEL.
Mr Beer: To what extent did you have access to their systems, like PowerHelp?
Stephen Parker: We were able to examine PowerHelp in order to see what had been logged in there because not all information came over the interface between PowerHelp and PEAK. I don’t – I think I probably used that a couple of times, quite rarely. That’s about what I remember about PowerHelp.
Mr Beer: Did HSD have access to PinICLs and PEAKs?
Stephen Parker: I think they did, yes.
Mr Beer: Were there any scripts kept on PinICLs and PEAKs?
Stephen Parker: Not for the purposes of Helpdesk support, no. I say it that way because PEAK was also used in latter years in order to create sequences for software delivery and release management type purposes. So you would sequences of actions but they were not to do with the first line Helpdesk.
Mr Beer: If I, as the investigator, now wanted to find scripts within Fujitsu, where should I look?
Stephen Parker: I would be – I think my first port of call would have been PowerHelp but I’m aware that the PowerHelp system is no longer in existence.
Mr Beer: Where else might you look, or might I look?
Stephen Parker: I would only be going back to people who worked at the HSD at the time to ask where they were actually kept because, as I say, I’m not sure. I would expect PowerHelp but I’m not sure.
Mr Beer: You mention that they had their own Knowledge Base. To your knowledge, were any scripts kept within that Knowledge Base?
Stephen Parker: I don’t know.
Mr Beer: Did you, within the SSC, have access to HSD’s Knowledge Base?
Stephen Parker: I don’t think we did, no.
Mr Beer: Looking at other functions of the HSD, did it, the HSD, have any form of remote access, however one might define that term?
Stephen Parker: No, the HSD had no remote access.
Mr Beer: Turning to the second element of the Fujitsu first line support provision, the Communications Management Team, what did it do?
Stephen Parker: As I remember, the Communications Management Team were more concerned with network issues, computer network issues.
Mr Beer: What do you mean by that, computer network issues?
Stephen Parker: Communication between computers within each outlet, between those outlets and the data centres.
Mr Beer: Where was it based?
Stephen Parker: Stevenage.
Mr Beer: How many people worked in the Communications Management Team?
Stephen Parker: I don’t know.
Mr Beer: Did it, the Communications Management Team, have any form of remote access, however one might define that term?
Stephen Parker: No.
Mr Beer: Can we turn to the third element, the element provided by the Post Office, the NBSC. Where was the NBSC based?
Stephen Parker: I’m not sure. I think it was Chesterfield but I’m not sure.
Mr Beer: How would the HSD communicate with the NBSC?
Stephen Parker: My assumption would be via – I was going to say via phone calls but no, I don’t know. I don’t know what the linkage was there.
Mr Beer: How would the SSC communicate with the NBSC?
Stephen Parker: Generally via the HSD.
Mr Beer: So you would route it back down from first to third line support –
Stephen Parker: (The witness nodded)
Mr Beer: – expect Fujitsu’s first line support to link it to NBSC –
Stephen Parker: To then liaise with the NBSC, yes.
Mr Beer: Did it to your knowledge, the NBSC, have any form of remote access?
Stephen Parker: I don’t believe so but I never had a lot to do with that and I don’t think I ever had anything to do with that environment.
Mr Beer: Can we turn, then, to second line support and go forward to paragraph 17 of your witness statement, please. Thank you.
You tell us that second line support was provided by the System Management Centre, the SMC, and you describe, non-exhaustively, a list of its responsibilities. Where was the System Management Centre based?
Stephen Parker: Also Stevenage.
Mr Beer: Did it, the System Management Centre, have any form of remote access, however so defined?
Stephen Parker: Yes, they did, via –
Mr Beer: What was the extent of it?
Stephen Parker: I can’t remember all of the things they were able to do but it was, as I mentioned, I think, in my witness statement, it was via Tivoli scripts, as they were called, which would perform particular actions on parts of the Horizon System.
Mr Beer: What was, in general terms, the purpose of the SMC performing those functions via Tivoli?
Stephen Parker: Just general support of the Horizon service.
Mr Beer: What do you mean by “general support”? What was their access and what were they doing that you didn’t do in third line?
Stephen Parker: The nature of the scripts they had was to perform very tightly controlled specific actions, and I can’t remember a great deal of them. I can’t really give you a list of those things.
Mr Beer: Can we turn to third line support, then, the SSC itself. That witness statement can come down. Thank you.
Can we look at a document, please, FUJ00120446.
This is the ICL Pathway “CS Support Services Operations Manual”, version 2. Can you see that from the top?
Stephen Parker: I can.
Mr Beer: It’s dated, we can see, 29 January 2001, and we can see a description of the document in its “Abstract”:
“This is the top level procedures document describing the activities carried out by the Support Services Unit within ICL Pathway Customer Service.”
Just on that description of support services unit, what did that refer to? Is that the SSC or is it something greater than that?
Stephen Parker: I don’t remember the SSC ever being described that way but, given that it’s CS support services and Peter Burden wrote it, it could be describing any of the units SSC, MSC, et cetera.
Mr Beer: Okay, so it’s a group of support –
Stephen Parker: I would assume so, yes.
Mr Beer: Including the SSC?
Stephen Parker: Yes, I would assume so, yes.
Mr Beer: I think we can see at the foot of the page, the distribution list. It was distributed to the SSC manager which by this time, January 2001, would have been you?
Stephen Parker: Not in 2001, no. That would have been Mik Peach.
Mr Beer: No, I’m so sorry, Mr Peach –
Stephen Parker: Yes.
Mr Beer: – and you were his deputy?
Stephen Parker: Yes.
Mr Beer: Thank you. Can we go to page 8, please, and paragraph 4.1. If we just scroll up a little bit so we can see the heading. A little bit more, “system Support Centre”:
“This section of the manual describes the operations and responsibilities of the SSC.”
You’ll see under the “Overview” it sets out an overview of the tasks of the SSC covering the responsibilities of the SSC both to the lower and upper levels of support; can you see that?
Stephen Parker: I can.
Mr Beer: If we scroll down, please, to 4.1.1. It lists the responsibilities of the SSC to the first and second line limbs of support ie looking downwards. You’ll see from number 5 that one of the SSC’s responsibilities was to:
“Ensure that the incident is resolved within the total time allowed by the contract between the customer and Pathway.”
So that means ensure the incident is resolved within the total time allowed by the contract between the Post Office and Fujitsu?
Stephen Parker: Yes, that’s right.
Mr Beer: Were there any SLAs, service level agreements, that you were aware of that set out the total time allowed by the contract for the resolution of incidents?
Stephen Parker: There were targets for the resolution of incidents. I don’t remember there ever being any SLAs.
Mr Beer: Where were the targets recorded?
Stephen Parker: I remember there being documents with them in but I couldn’t point you to them immediately.
Mr Beer: So, even if there wasn’t an SLA, there were, nonetheless, targets which placed the responsibility on the SSC to make sure that Fujitsu’s contractual obligations to the Post Office were met in terms of timeliness?
Stephen Parker: In terms of timeliness, yes.
Mr Beer: That responsibility included responsibility on the SSC to ensure that first and second line support met such targets too, did it?
Stephen Parker: I don’t remember a particular text on that but, I mean, certainly the SSC would assist first line, second line, to ensure that they could resolve their incidents, yes.
Mr Beer: Was the meeting of those targets an important driver to the work of the SSC?
Stephen Parker: I wouldn’t describe it as an important driver. I would describe it as a means of measuring the effectiveness of the SSC, yes.
Mr Beer: How was it monitored?
Stephen Parker: Mik Peach actually produced statistics on the SSC’s processing of incidents, and reported them back via various means, including a web-based portal.
Mr Beer: Reported them to whom?
Stephen Parker: It would have been reported to both – well, it would have been reported initially into the Fujitsu structure, so the service managers and Mik’s immediate superior, and the development teams, et cetera. I mean, it was a generally available measure within Fujitsu.
Mr Beer: When you took over in 2010, did you do that?
Stephen Parker: By 2010, we were relying more on the automatic generation of that information via PEAK.
Mr Beer: Were you aware of contractual penalties for failure to meet such targets?
Stephen Parker: Not targets on general incidents through the SSC. There were SLAs on other parts of the service, which the SSC would be involved in processing incidents for.
Mr Beer: Were you aware of contractual penalties concerning those?
Stephen Parker: Yes, I was.
Mr Beer: Did they have an impact, an important impact, on the work of the SSC?
Stephen Parker: They had an impact on the work of the SSC in determining priorities applied to the workload as it came in, yes.
Mr Beer: Was there a desire to close incidents in order to meet such targets?
Stephen Parker: No. I mean, we would want to close incidents when we get to the root cause, not just in order to fulfil timescales.
Mr Beer: If we go over the page, please, to subparagraph 7, thank you. One of the responsibilities of the SSC at 7 was to:
“… create and maintain a register of known deficiencies within the Pathway system and the solution to these problems, where known.”
At 8, the SSC was to:
“… allow HSH [which we’ve been calling HSD] and the SMC access to this register so they can fulfil their function of filtering out known errors.”
Was that obligation essentially fulfilled through KEL?
Stephen Parker: Yes.
Mr Beer: How were HSH required to use the KEL system to filter out known errors?
Stephen Parker: Don’t quite understand the question. I mean, the –
Mr Beer: How would first line support use KEL to filter out known errors?
Stephen Parker: In the same way that third line support would use the actual KEL, by specifying keyword searches to retrieve relevant KELs.
Mr Beer: So, when you retrieved the relevant KEL, how was it used to filter out known errors, as this document describes it?
Stephen Parker: By examining the text in there and matching it to the symptoms that were presented in the incident and making a technical decision, whether or not it was the same problem.
Mr Beer: In what respect is that filtering out known errors?
Stephen Parker: It would – it’s filtering out known errors in that it wouldn’t be necessary then for the HSH to forward that incident through the – upwards through the support chain. They would recognise that that incident is already known about, there is already a solution to it and, hence, they wouldn’t need to actually forward it – forward it on.
Mr Beer: Was there, over time, a tendency by first line support to escalate issues to the SSC inappropriately when, in fact, there was a fix in a KEL?
Stephen Parker: That sort of thing always happens to some degree. I wouldn’t describe the HSD’s forwarding as being any worse or better than like anything else. I mean, you always get some instance whereby a previous level of support will miss a known error and fail to filter it.
Mr Beer: Was there any pressure placed by the SSC on first line support not to escalate issues by reference to the KELs?
Stephen Parker: There would be meetings where we would occasionally discuss particular issues and assist the HSH in fulfilling their filtering responsibilities. There would be – that would be an ongoing process.
Mr Beer: If we go down the page, please, to the SSC’s responsibilities to fourth line support. It says:
“The responsibilities of the SSC to fourth line support [so looking upwards] are …”
Then it sets them out over 13 subparagraphs.
Paragraph 2 places an obligation on the SSC:
“… to filter out all calls for which the problem is already known to the support community and for which a solution is already known or has been generated. This includes problems for which the SSC knows a resolution but has not yet incorporated the resolution into the KEL.”
Is that right?
Stephen Parker: Yes, that is right.
Mr Beer: At 3, there was:
“… a responsibility to retain to you duplicate incidents in the PinICL systems and ensure that when the resolved incident is received by the SSC, the duplicated calls are closed. Duplicates incidents are repetitions of an incident that has already been passed to fourth line support.”
Yes?
Stephen Parker: Yes, indeed.
Mr Beer: Then over the page, please, at 11. The SSC is required to:
“… ensure that for any code error a probable solution is indicated prior to passing the incident to fourth line support and, wherever possible, the proposed solution has undergone limited testing.”
Was the SSC under pressure to avoid passing problems up to fourth line support?
Stephen Parker: No, I mean, if we identified a new issue, then it would be passed on to the fourth line.
Mr Beer: So if a problem was resolved under existing KEL guidance, that wouldn’t be passed up?
Stephen Parker: It shouldn’t be, no.
Mr Beer: If there was insufficient evidence of a system fault, that wouldn’t be passed up, would it?
Stephen Parker: It shouldn’t be, but I would caveat that by saying that, in some cases, we may want to talk to development about a fault in order to see if they could give us any help with ways to identify what the fault was.
Mr Beer: Might that take place on an informal basis?
Stephen Parker: It would be on an informal basis, yes.
Mr Beer: But if no fault with the system could be positively identified, that would be written up as a user error, wouldn’t it?
Stephen Parker: Not necessarily user error. User error was just a categorisation.
Mr Beer: If no fault in the system could be identified, what was the code for closing the incident then? Was there a code which said, “No fault can be identified but do not categorise this as a user error; the position is simply unknown”?
Stephen Parker: Without referring to a document, I can’t remember all of the closure categories.
Mr Beer: If there was insufficient evidence of a fault or no evidence of a fault, would that be referred back to the subpostmaster sometimes for more information or evidence?
Stephen Parker: Yes, it would.
Mr Beer: What would happen if the subpostmaster couldn’t produce any more information or evidence?
Stephen Parker: If the information we had was inadequate to diagnose what the problem was then that call would have to be closed but that would only be done after we’ve exhausted any lines of enquiry.
Mr Beer: Who would be chasing those lines of enquiry?
Stephen Parker: Occasionally I would expect the postmaster, maybe, or a Problem Manager.
Mr Beer: When you refer to the Problem Manager, who are you referring to then?
Stephen Parker: Well, it’s part of the problem management process, which was used within the support chains, which is that if you get multiple incidents with potentially the same root cause, then a Problem Manager would start to collate those and progress the problem.
Mr Beer: Where did the Problem Manager sit within the four lines of support?
Stephen Parker: There would be – the Problem Manager function would be within all of the Service Delivery Units so there would be a function for that purpose within HSH or within, like, other teams.
Mr Beer: Within the SSC?
Stephen Parker: Problem management would also happen within the SSC, yes.
Mr Beer: That’s a different issue. Problem management may also happen within the SSC, that’s small “p”, small “m”.
Stephen Parker: Yes, understand.
Mr Beer: You were referring to the Problem Manager which I interpreted to mean a capital “P” and a capital “M”. Was there a person within each of the four lines of support who was called a Problem Manager?
Stephen Parker: I can’t be sure because the theory is the problem can be raised by, like, anybody. So there’s a problem initiator within the process. I can’t – I think the Service Delivery Managers just also performed the function of Problem Manager. So, I mean, that was certainly true in my case: as a Service Delivery Manager for the SSC, I would also occasionally take on the role of a Problem Manager.
Mr Beer: You’re talking there about collecting or collating, bringing together into a basket a series of problems of the same or a similar nature.
Stephen Parker: Correct.
Mr Beer: You said occasionally you would do it.
Stephen Parker: Correct, yes.
Mr Beer: Was there a systematic and/or written policy that prescribed how this would be done?
Stephen Parker: Yes, there was.
Mr Beer: How would it be done, then? You get a PinICL that is escalated or a PEAK that’s escalated to SSC?
Stephen Parker: Yes.
Mr Beer: The first one that they’ve seen.
Stephen Parker: Yes.
Mr Beer: It’s dealt with by SSC diagnostician number 1, on their shift. A week later another one comes in to diagnostician 2. Another problem comes in to HSH, doesn’t get escalated for one reason or another. Week 4, a problem of a same or similar nature comes into diagnostician 4. How are they all collected together in a basket? What was the system for linking them?
Stephen Parker: Within the SSC, it would be recognised by the fact a KEL has been raised with an incident reference on it, and then any – as further incidents come in, which reflected the same KEL –
Mr Beer: Hold on. That assumes that the problem that you’re confronted with is a known error.
Stephen Parker: If it’s got as far as the SSC, then we would have raised a KEL for an incident, even if we hadn’t necessarily been able to get to the bottom of it.
Mr Beer: So Known Error Logs were raised in respect of unknown errors?
Stephen Parker: Where we could say – yes, yes.
Mr Beer: So were they called “Unknown Error Logs”?
Stephen Parker: No.
Mr Beer: So what was the effect of raising an unknown error on a Known Error Log, then?
Stephen Parker: The effect would be to allow visibility of the fact this problem has happened before, the steps taken.
Mr Beer: So in my example, week one, diagnostician one, gets a new error that hasn’t been seen before. They create a KEL for that, do they?
Stephen Parker: (The witness nodded) After investigation, yes.
Mr Beer: Yes. And they can’t find what the fault is –
Stephen Parker: Yes.
Mr Beer: – and the incident is closed?
Stephen Parker: Yes.
Mr Beer: Week 2, somebody calls in with what is, in fact, the same or a similar problem.
Stephen Parker: Mm-hm.
Mr Beer: How is that linked to what happened the week before?
Stephen Parker: By virtue of searching the KEL and finding the information on there.
Mr Beer: How does one search a KEL or the KEL system?
Stephen Parker: You use technical knowledge to define a series – one or more keywords which describe the problem and then put those into the KEL system, and they may be combined with – the various terms can be combined together that they should all be present or just some of them present. The system would return a series of matching KELs in a priority order of how well they matched the criteria and then the diagnostician would then look and examine each one further to see if it matches the incident they are working on.
Mr Beer: We can take the document down from the screen. Thank you.
We’re going to hear some evidence from Mr Peach, Mik Peach, next week, assuming he gives evidence in accordance with his witness statement, that the KEL system was written primarily by you; is that correct?
Stephen Parker: Yes, it is.
Mr Beer: So you wrote the code for it, did you?
Stephen Parker: I wrote the code for it until other people took over later on. So I think currently, and certainly while I was managing the unit, John Simpkins enhanced the KEL and it was – it wasn’t just me. I mean, other people provided parts of the development effort for the KEL at various times.
Mr Beer: You mentioned, essentially, a search function within it –
Stephen Parker: Yes.
Mr Beer: – that would return a series of hits –
Stephen Parker: Yes.
Mr Beer: – essentially on relevance grounds.
Stephen Parker: Yes.
Mr Beer: Is that right?
Stephen Parker: Yes.
Mr Beer: Was what was searched the entirety of the text of the KEL –
Stephen Parker: Um –
Mr Beer: – or was it the subject line or the summary line?
Stephen Parker: No, it was the entirety of the text.
Mr Beer: So every single word on the KEL, there was essentially a free text search of all of those KELs?
Stephen Parker: I’ll clarify that slightly. It was a free text search of the symptoms, the problems and the solution. There were certain fields on there like release number or other specific criteria like that, which I don’t – which were not part of the free text search.
Mr Beer: Was there any system of auditing or monitoring to ensure that information recorded on a KEL was accurate and enabled future free text searching to occur appropriately?
Stephen Parker: There was when the KELs were created outside the SSC. So the SSC would perform an approval function when a KEL had been written outside the SSC. Within the SSC it would just be discussions amongst peers about “You raised this KEL, I would suggest this wording change”, et cetera.
Mr Beer: The Inquiry has heard some evidence that not all problems that were called in were, on searching the KEL system, returned by the – or matched with the appropriate KEL and that, where there were KELs in place, these were not always spotted by those who were handling the PinICLs or the PEAKs. Did anyone ever examine how the KEL system was operating in practice?
Stephen Parker: We certainly didn’t do any monitoring of how the – ongoing monitoring of how the KEL system was working in practice. We would expect that if somebody found, or a KEL that they had a problem with, they would either change it themselves and we would approve it, or they would contact us to have a KEL changed.
Mr Beer: Were KELs accessible to the Post Office?
Stephen Parker: No.
Mr Beer: Thank you.
Sir, that would be an appropriate moment to take a break before we look at some example KELs to see the system working in practice.
Sir Wyn Williams: All right, what time shall we start again?
Mr Beer: 11.30, please.
Sir Wyn Williams: All right, that’s fine.
Mr Beer: Thank you, sir.
(11.15 am)
(A short break)
(11.30 am)
Mr Beer: Sir, good morning, can you see and hear me?
Sir Wyn Williams: I can indeed.
Mr Beer: Thank you. Mr Parker, we were going to look at some example KELs to see the system operating in practice. Can we start, please, with FUJ00059025. Thank you. This is a KEL which advised on how to reboot and reload a counter. You can see that it was raised by a Pat Carroll on 15 June 1999 and was last updated by you on 28 January 2004.
If we just look at the “Problem”:
“Counters are being rebooted or reloaded by switching off the base unit and this may prejudice the integrity of the messages held on the counter making the possibility of an altogether more serious and resource consuming failure greater.”
Now, the Inquiry has heard evidence so far of subpostmasters being advised to reboot as a response to their suggestion that they think that there is a problem with the system, which is causing a discrepancy in data. Was that advice that you knew was given, just switch the system on and off again or reboot the system?
Stephen Parker: To my mind, they are two different things, rebooting the system, I would have expected the Control Alt Del method to be used because that is a tidy way of doing it. I wouldn’t have expected people to just turn on and turn off base units because there are some risks inherent with any computer system if you do that.
Mr Beer: This records counters being rebooted or reloaded by switching off the base unit?
Stephen Parker: Yes, it does, yes.
Mr Beer: That’s the wrong thing to do, is what you’re saying?
Stephen Parker: Yes.
Mr Beer: It says that this may prejudice the integrity of messages held on the counter. In what way might it prejudice the integrity of messages held on the counter?
Stephen Parker: Simply turning off a computer system with a spinning disk-drive in it can cause failures in the disk storage.
Mr Beer: So, essentially, this KEL is saying that some subpostmasters were rebooting in a way that would cause new problems or could cause new problems?
Stephen Parker: Which could cause new problems, yes.
Mr Beer: What would the “altogether more serious and resource consuming failure” be?
Stephen Parker: I don’t remember exactly why that sentence or that ending of the sentence is on there. My interpretation of it is you would get a symptom, which was known as a CRC error which was a disk error, which could prevent the application from working. It would – in fact, I believe, if I remember correctly, it would stop it dead.
Mr Beer: So a total shutdown?
Stephen Parker: It wasn’t a total shutdown but the underlying system would just stop.
Mr Beer: Is that the altogether more serious issue that’s referred to, do you think?
Stephen Parker: That’s all I can assume. As I say, I don’t remember the exact reason that final part of the sentence was put on there.
Mr Beer: So presumably, given the contents of this KEL that message would have been passed out to all subpostmasters who were using Horizon, “Don’t reboot or reload your system by switching off at the base unit; always reboot using control, alt, delete keys?”
Stephen Parker: I would expect that to have happened, yes.
Mr Beer: How would your expectation have been carried into reality? This KEL is sitting within the SSC, saying, “This is the problem, this is what happens if the subpostmaster does the wrong thing”. How would that – these words in the KEL get translated into an estate-wide message to subpostmasters?
Stephen Parker: My recollection is sketchy but I believe this particular problem was notified directly to the HSH in order to ensure they were giving out that particular advice. I’m not sure exactly how it was communicated to the Post Office because that wouldn’t have been something I was involved in.
Mr Beer: Who would have been involved in it? You’ve got a KEL that’s saying there’s a problem here, and there are serious consequences for subpostmasters if they do something. What was the system to ensure that they didn’t do that something?
Stephen Parker: I would expect that either the SSC on raising the KEL would have told one of the service managers responsible for that part of the service and that would have then been like onwards – onward communicated as appropriate to the Post Office, is one route. The other would be direct contact from HSH on to the Post Office. I would expect the former to have been more likely.
Mr Beer: Where would we find a record of that? Because there’s nothing on this KEL to suggest –
Stephen Parker: Understand.
Mr Beer: – that happened.
Stephen Parker: Mm.
Mr Beer: Where would we find evidence?
Stephen Parker: I don’t know how the service managers recorded that kind of thing.
Mr Beer: When you say, “The service managers” who are you referring to there?
Stephen Parker: There were a number of service managers responsible for different parts of the Horizon service and they were within Fujitsu, and so we would have – it would have been via one of them that that information was actually relayed to the Post Office.
Mr Beer: We’ve got on this Pat Carroll and you?
Stephen Parker: Yes.
Mr Beer: How would these service managers have learnt from this KEL that that’s what they needed to do?
Stephen Parker: We – a member of the SSC, probably Mik, would have gone to see them.
Mr Beer: So Mik would – when you say gone to see them, spoken to them, emailed them, or seen them face-to-face?
Stephen Parker: Probably seen them face-to-face. They were mainly based in the same building.
Mr Beer: What I’m trying to uncover is what was the system for communicating known faults with Horizon back to the subpostmaster community?
Stephen Parker: We had no means to – we had no means to do that.
Mr Beer: Did anyone, to your knowledge, in your 22 years in the SSC, think there’s an issue with that? There’s a problem with that?
Stephen Parker: If there was a serious problem, then it would go via problem managers to the Post Office. If it was a minor issue, then the existence of the KEL would be recognised by HSH when postmasters called in and the guidance would be given directly to them at that time.
Mr Beer: That’s after the problem has occurred?
Stephen Parker: It is. Yes.
Mr Beer: That’s no good, is it?
Stephen Parker: It is – for minor incidents, I think it is adequate. For major things, no, but it would have then gone via problem managers.
Mr Beer: Where does this sit in your spectrum of minor to major?
Stephen Parker: If – and I don’t remember whether the turn off at counter advice was being given by HSH. If it was being given by the Helpdesk then I would consider it to be a major problem.
Mr Beer: Was there any record kept or system operated that said “We’ve got a problem that we’ve identified here in the SSC, there needs to be the following contact with the following parts of Fujitsu or the Post Office to ensure that the right people know to cascade a message back to subpostmasters. We are not going to do it on this occasion because it’s a minor problem. We are going to do it on this occasion because it’s a major problem”?
Stephen Parker: That would go via service managers.
Mr Beer: The service manager here is somebody in the SSC?
Stephen Parker: No, it’s an external group – no, sorry, external is wrong – external to the SSC, internal to Fujitsu, group of people who had responsibility for various parts of the service.
Mr Beer: So to take this one as an example, which part of the system or service did this concern and to which service manager should this have gone?
Stephen Parker: This bit of advice concerns the counter. I cannot remember which service manager that was.
Mr Beer: So was there a record kept in the SSC to say, “We’ve passed this on to service manager X or service manager Y for cascading”, as I call it?
Stephen Parker: That would be potentially recorded in SSC period reporting.
Mr Beer: What is SSC period reporting?
Stephen Parker: That is reporting live generated on a monthly basis to service managers and other parts of the Horizon environment on the activities of the SSC.
Mr Beer: So like a performance report?
Stephen Parker: There was performance data in there, yes.
Mr Beer: Can we move on, please, to FUJ00058645. You’ll see that this is a KEL and appears to be concerning an early issue with a Riposte bug. The KEL was raised by Bob Foster on 4 July 2000 and was last updated by you on 28 September 2000.
You’ll see from the “Problem” that a person called – well, let’s read it:
“This message relates to the Riposte programs node identifier which identifies the counter within that office ie node:1 for the gateway node:2 for counter 2 and so on. The Invalid Node ID event is caused from an incoming message arriving from a neighbour and Riposte detecting that node ID is invalid. The subsequent event ‘network message received from an unknown source’ is likely to refer to the same message. Mark has spoken with Escher regarding this problem.”
Just stopping there, the “Mark” referred to there, would that be Mark Jarosz?
Stephen Parker: I would think so. He was generally the person who would speak directly with Escher at this time, yes.
Mr Beer: “His understanding is that isolated occurrences of this event (that is not once per message received from the Correspondence server), are likely to be caused by a bug in Riposte. Unfortunately without a reproducible case it is very difficult to progress this problem. His …”
Would that be Mark’s recommendation?
Stephen Parker: That would be my assumption yes.
Mr Beer: Rather than Escher’s?
“… is that we do not pursue any attempts to reproduce this problem with Riposte 5.4 …”
That is a release, is it?
Stephen Parker: It is.
Mr Beer: “… rather, we wait to see if it still happens with Riposte 6 …”
That’s another release?
Stephen Parker: It is.
Mr Beer: “The two reasons for this recommendation are (1) The connection protocol has changed significantly at Riposte 6 and hence so has maintenance of connection state. Therefore the problem may have been solved. (2) The relatively low frequency of an occurrence, [less than] 10 per day, is mostly benign. Mark will review the provision of additional diagnostics information in Riposte 6 with Escher to facilitate diagnosis of problems with connection state.”
So would it be right that the effect of this bug was that messages could be discarded?
Stephen Parker: I don’t remember enough about it. I was never a counter specialist, so I can’t really give you any good technical detail on that.
Mr Beer: Reading or rereading the problem there, can you tell from that that one of the consequences of the bug appear to be the discarding of messages?
Stephen Parker: I can’t be sure.
Mr Beer: Scrolling down to “Solution”:
“These events” –
Stephen Parker: (The witness laughed)
Mr Beer: – “indicate that a message has been discarded.”
Stephen Parker: Right.
Mr Beer: “Advice from Mark Jarosz is that given the small number of messages are being discarded we should treat this event in the same manner as the ‘network message from an unknown source’. That is relatively benign but we need to solve it should it be seen at Riposte 6.”
So, looking at that, it would seem that the effect of the bug was the discarding of messages; yes?
Stephen Parker: That’s what it says indeed.
Mr Beer: It’s described as relatively benign. Do you know what that means?
Stephen Parker: I can only assume that – my assumption from that would be that, because of the – that some messages are just not important to the operation of the system. So, therefore, some of them being discarded may be relatively benign. I can’t really help you, like, any more than that.
Mr Beer: The “Evidence” section at the foot of the page:
“None required for CI3 counters. Should this occur in a data centre or CI4 counter then please raise a call with the SSC and obtain event logs from the system reporting the error.”
So is that saying only raise calls in the case of CI4 counters?
Stephen Parker: It is, yes.
Mr Beer: What would happen to the CI3 counters, then?
Stephen Parker: Then the inference here is that no calls would be forwarded to us for seeing the same thing on a CI3 counter.
Mr Beer: So it’s telling the lower levels of support for CI3 counters “Don’t send them to us”?
Stephen Parker: Yes.
Mr Beer: Why was that?
Stephen Parker: From the previous advice from Mark, that it’s relatively benign, it’s going to – it’s likely to be fixed or at least the nature of it changed in the next version of Riposte being delivered. I have no way of knowing the proximity of that delivery. If it was going to happen that week, then probably you’re just not going to see a great deal of issues. If that release is not being delivered for six months, then it would be a – I think it would be something which you would see more issues from.
Mr Beer: So essentially a wait and see approach was being taken. This was essentially a problem for Escher, “Let’s see whether their release fixes it”?
Stephen Parker: That’s my reading of it, yes.
Mr Beer: Was the SSC and Fujitsu, more generally, significantly reliant on Escher?
Stephen Parker: For the Riposte messaging part of the service, yes.
Mr Beer: Was the Riposte messaging service a critical element of the system?
Stephen Parker: Yes.
Mr Beer: Was that a source of frustration?
Stephen Parker: No, I wouldn’t – I wouldn’t describe it that way. Any issues that needed to be communicated to Escher would go via Mark to Escher and we would get answers back. So I wouldn’t describe it as a – something that was particularly frustrating.
Mr Beer: Did it limit the ability of the SSC to understand the root causes of any bugs because such knowledge was vested in Escher?
Stephen Parker: No, Escher – yes. Sorry, Escher would give us information when requested, they gave us training when requested. They were just another supplier into the Horizon service, really.
Mr Beer: So were they, to your understanding, an open and transparent subcontractor?
Stephen Parker: I didn’t have enough dealings with them to make that judgement.
Mr Beer: Were, to your knowledge in the 22 years that you worked in the SSC, there ever any problems with Escher or was it a smooth and harmonious relationship?
Stephen Parker: I can’t remember any particular – any particular issues.
Mr Beer: The Inquiry heard evidence last week from Mrs Anne Chambers that a problem with the KEL system was that service tickets would be passed to the SSC with the wrong KEL quoted on them. Was that a problem of which you were aware?
Stephen Parker: Yes.
Mr Beer: Was this escalated as a difficulty within Fujitsu?
Stephen Parker: It wasn’t escalated as a difficulty within Fujitsu but, I mean, it would be the subject of discussion between the SSC and the HSH, both to point out to them where they may have found an incorrect KEL and/or for us to improve KELs to ensure that they were much easier for HSH to find.
Mr Beer: So what was done to rectify the problem with the use of the KEL system, then?
Stephen Parker: It was an ongoing process of discussion between the various lines of support.
Mr Beer: Ongoing until you retired?
Stephen Parker: At various times, yes, I think that was probably true.
Mr Beer: Did that indicate to you that there was a structural or systemic problem here?
Stephen Parker: No.
Mr Beer: Why not?
Stephen Parker: Because –
Mr Beer: The same problem comes up for 22 years?
Stephen Parker: It’s the same category of problem, it’s not the same problem. I mean, the interpretation of the information on a KEL is down to the person reading it. If we found a situation where that interpretation was consistently wrong, we would fix it. We would change the KEL to ensure that it was better understood by other support units.
Mr Beer: That assumes that the problem lies with the content of the KEL?
Stephen Parker: It does. Correct.
Mr Beer: Was that always the problem –
Stephen Parker: No, it –
Mr Beer: – the way that the SSC were writing their KELs?
Stephen Parker: No, that was not always the problem. It was also true that sometimes the HSH technician could be using search terms which were too broad or were incorrect.
Mr Beer: Mrs Chambers also gave evidence that the SSC at third line and Development at fourth line did not always know how many branches had reported a particular problem that was the same or similar because tickets were not escalated up to the SSC; they had been stopped, intercepted at a lower level. Was that a known issue in your time at the SSC?
Stephen Parker: It – I wouldn’t describe it as an issue. I mean, that was a function of the problem management part of the service.
Mr Beer: So it wasn’t a problem that the SSC didn’t know the extent and severity of a problem because calls were not being escalated to it?
Stephen Parker: The previous level of support, or the HSH, would be recording on master calls the prevalence of the same issue being logged and, if they deemed that there was a significant problem there, then they would escalate it through the problem management process.
Mr Beer: How would they know, in HSH, the extent or prevalence of an issue that was, in fact, a system problem that was the same or similar?
Stephen Parker: From having knowledge of the KEL, associating it with a master call, hearing the postmasters or other source of information bringing up the same issue again.
Mr Beer: What if all the subpostmaster could say is that “I’ve got an unexplained discrepancy”?
Stephen Parker: That’s such a wide explanation – sorry, that’s such a wide description of the symptoms that we would then have to go back to them and get them to describe it in greater detail, or rather the HSH or NBSC would.
Mr Beer: Can we turn to paragraph 57 of your statement, please, which is on page 19. Paragraph 57, you say:
“The 2nd line support groups were expected to answer any incidents with their operating remit (for example all user or known errors). They were also expected to send only one example of a suspected new software fault to 3rd line, retaining any duplicates at 2nd line for closure once the main incident was resolved.”
Why was that the system?
Stephen Parker: Because you don’t want to flood third line with multiple incidents of the same sort.
Mr Beer: Even though the prevalence of the same fault would be important information for the SSC to have to ascribe a seriousness or criticality?
Stephen Parker: We could obtain that information from the line of support, which was tasked with retaining that particular type of incident.
Mr Beer: Did that happen?
Stephen Parker: Yes, it did.
Mr Beer: You would look back to second line and say, “How many incidents of this nature have you got” –
Stephen Parker: Yes.
Mr Beer: – “so we can ascribe a value to how important this is”?
Stephen Parker: Yes. It would – or they would occasionally, literally ring up saying, “Look, we’ve had now 75 of these things, we see it as a major issue”.
Mr Beer: Wouldn’t knowing the range of ways in which a suspected new software fault had occurred be relevant information?
Stephen Parker: It may be, depending upon the type of fault being investigated, in which case we could go back to SMC, HSH, and say “Right, give us all of the references for duplicate calls so we can have a look through them and get extra detail from them”.
Mr Beer: How would you know whether asking for sight of the duplicates would assist you or wouldn’t assist you? If you didn’t have –
Stephen Parker: It would depend on the nature of the problem. If we have analysed an incident and managed to get to the root cause of it, then clearly there is no usefulness in, like, analysing further. If we have not got to the root cause of it, then it would be worthwhile to gather details of other incidents so that we could examine the evidence on them to help us get to the root cause.
Mr Beer: If we go forwards to paragraph 69 of your statement, please, which is on page 22. Can we scroll down. You say:
“When the root causes of problems were identified, the SSC would check the Horizon System for the fingerprint left by the problem and identify which outlets were impacted.”
Was that done in each and every case with every bug?
Stephen Parker: It would depend upon the nature of the bug. For anything – certainly for any bug with a financial impact, yes.
Mr Beer: How would you know whether a bug did or didn’t have a financial impact –
Stephen Parker: By the –
Mr Beer: – in all cases?
Stephen Parker: By the root cause analysis of the bug, we would know that this does or does not have a financial impact.
Mr Beer: The first line of paragraph 69 reads as if, for all cases in which a root cause was identified, the SSC would check the system to see how prevalent the fault was and how many branches it impacted. Was that only done in cases where there was an assessment that it had a financial impact?
Stephen Parker: I would probably revise that to say “major problems”. So something with a significant impact to service would always be traced back to determine where that impact was.
Mr Beer: You just said something with a significant impact to service would always be traced back to determine where that impact was. The question I’m asking is: did you determine how wide an impact a fault had? How would you know how wide an impact a fault had without looking?
Stephen Parker: You wouldn’t know without looking that is true. On the – a root cause analysis would tell you exactly which type of service would be impacted by this. By the criticality of that service, you could then understand how serious this was, and you could then go back and search and find where that impact had been seen.
Mr Beer: Who would make the decision on whether the impact on the subpostmaster community was significant enough or not to investigate the impact on the subpostmaster community?
Stephen Parker: Generally it would be a member of the SSC or a service manager.
Mr Beer: Again, you referred to a service manager there. That would be the person that was responsible for the bit of the estate that had gone wrong?
Stephen Parker: Correct. And I would add that that – I would expect that service manager to be in contact with and – Post Office as well, over that issue. I forgot to mention that in my previous comment.
Mr Beer: Why would you expect the service manager to be the person in contact with the Post Office to make a decision on how wide an impact a fault had on the live estate?
Stephen Parker: Because that was one of the responsibilities of their role: to be liaison with a similar – similarly situated representative of the Post Office.
Mr Beer: Can we go back to paragraph 60, please, which is at the foot of page 20. You say, “The use of response codes”; can you assist us with what a response code was, please?
Stephen Parker: A response code was the numeric representation of a particular response text. So you mentioned earlier user error, that would have a particular number.
Mr Beer: A closure code, like 4039, whatever?
Stephen Parker: Yeah.
Mr Beer: You say:
“The use of response codes as a measure of support effectiveness could also lead to inappropriate response codes being used in order to be ‘be kind’ to, or prevent contention with, other lines of support. For example, ‘Advice after investigation’ being used in preference to ‘No fault in product’ or ‘Advice and [advice] given’.”
Are you saying that people in SSC used an incorrect response code in order to be generous to their colleagues in first and second line support? Have I read that right?
Stephen Parker: The use of a response code is always subjective to the person but, yes, I mean, you are right. Sometimes response codes would be used, I believe, inappropriately in order to not cause contention.
Mr Beer: What do you mean by “cause contention”?
Stephen Parker: The various lines of support would – one of the measures of their service would be what volume of calls they managed to filter out and stop going to the next line of support, and a response code on a returning incident is part of that measure.
Mr Beer: Were duplicates part of that measure, ie inappropriately passing up duplicates? Were they considered black marks and counted against second line support?
Stephen Parker: Yes, they were.
Mr Beer: Can we turn to the issue of remote access and go back to FUJ00120446. You remember we looked at this earlier, the operations manual dated 29 January 2001. Can we go to page 14, please and look at paragraph 4.3. Under “Operational change”, it records that:
“The SSC has access to the live system which can be used to correct data on the system when this has been corrupted in some way. The procedure for doing this is as follows …”
It then describes a process for authorising a change, yes?
Stephen Parker: Yes, it does.
Mr Beer: If we can display that page and the next page, please. Thank you. On the right-hand page you’ll see it goes up to 12. There is actually a 13th but I don’t want to display three pages at once. It sets out a detailed process for each stage in the process in order to make an operational change, yes?
Stephen Parker: It does.
Mr Beer: One of the stages in the process is that at least two people must be present when making changes to the live system. Normally, these are SSC staff but can be one staff member and one person from the fourth line support unit responsible for the area in which the data change will take place, or one staff member and one OSD staff member. What’s OSD?
Stephen Parker: OSD was one of the acronyms which were used for staff in Belfast who supported the service systems and the operating systems running on them.
Mr Beer: Looking at paragraph 5 – sorry, I missed that last answer. So it was somebody in Belfast?
Stephen Parker: That’s correct, yes.
Mr Beer: How could somebody in Belfast be present when somebody in the SSC was making a change?
Stephen Parker: They couldn’t. Unless they happened to be working over in the UK at the time. During the early stages of Horizon, there were a lot of people working in the UK from Belfast, setting up server systems within the building, setting up networking systems within the building or maintaining them, so I assume that’s why the author mentioned them as a possibility.
Mr Beer: Fourth line support were in the same building, were they?
Stephen Parker: For some of the time, yes. Later, yes. Earlier, there was a period of time, I believe, when fourth line were still located in Feltham, when we were located in Bracknell, but that was a relatively actively short period.
Mr Beer: What happened in practice? Was this, in fact, the four-eyes procedure, always done with two people from SSC?
Stephen Parker: Yes, it was. The only caveat that I haven’t read here is that this – the four-eyes procedure was used for a change that was going to have a financial impact, which I don’t remember you reading out in this document.
Mr Beer: I don’t think it does. If you look at 4.3, “Operational change”, we’ve got the whole of the paragraph on the page there. Then if we go to the top of the right-hand page, it just goes straight into the procedure.
Stephen Parker: Yeah. In that case, I think that’s misleading, in that the four-eyes rule, two people observing a change, was for financial changes.
Mr Beer: Whereas this describes it for any change?
Stephen Parker: Yes, which I think is misleading.
Mr Beer: Looking at number 5 on the right-hand page, it says:
“The authoriser wherever possible produces a script to make the data change and test the script on the SSC reference rig prior to running it on the live system.”
That didn’t happen, did it?
Stephen Parker: It did happen, yes. It would depend on the nature of the problem and whether or not a script was appropriate.
Mr Beer: What would determine whether a script was appropriate?
Stephen Parker: What the actions are that are being taken, whether it was possible to actually run them via a script or not.
Mr Beer: Is that why it’s written “wherever possible”?
Stephen Parker: I don’t know. I mean, I would assume so.
Mr Beer: The procedure then suggests that the SSC manager or SSC website controller would check e-signatures and file the OCR. Was that process honoured?
Stephen Parker: I believe so, yes.
Mr Beer: In your time –
Stephen Parker: In my time –
Mr Beer: – was it honoured?
Stephen Parker: – no. In my time as SSC manager, we had stopped the use of e-signatures because they weren’t considered to be giving us any extra accountability. So we were relying on the username/password type access, guaranteeing that it was the person who was entering a particular approval.
Mr Beer: Looking at the left-hand side of the page, the introductory paragraph:
“The SSC has access to the live system which can be used to correct data when this has been corrupted in some way.”
Was this procedure used only when data had been corrupted?
Stephen Parker: No.
Mr Beer: So that’s slightly misleading too, then?
Stephen Parker: I think it is, yes.
Mr Beer: It was used for simple corrections?
Stephen Parker: Yes, it was.
Mr Beer: Do you know why that is, that this description of this use of remote access to make changes to data, it doesn’t accurately reflect reality?
Stephen Parker: I don’t know why the author phrased it in that way, no.
Mr Beer: Who was Mr Burden, Peter Burden?
Stephen Parker: Pete Burden was Mik Peach’s manager at the time but also the manager of other the parts of what was then Customer Service.
Mr Beer: Can we go to page 20 and look at paragraph 4.8., which is a third of the way down – thank you:
“All diagnostic staff in the SSC have access to the live system via PCs that are connected to a private Local Area Network. Branch panels enable staff to use these PCs to access the test rigs.
“The build script for these PCs was written by OSD, but is held in the SSC. The PC build was performed in accordance with the Access Control Policy.
“Access from the PCs to the live system is controlled by secure ID, uses firewalls, and an encrypted link, and conforms to the Access Control Policy.
“The SSC access to the system is for two purposes:
“Assist in diagnosis of problems on the live system
“Correct data which has become corrupted.
“In the second case, SSC staff may only correct data in response to an authorised OCR and only then when there are two or more people present.”
Again, this passage suffers from those, I think, defects that you mentioned earlier?
Stephen Parker: I think so, yes.
Mr Beer: Both of them. What system was in place to ensure that SSC staff in fact only accessed the live estate to correct data in response to an authorised OCR?
Stephen Parker: The – it was enforced only by process.
Mr Beer: What does that mean?
Stephen Parker: I mean, everybody was aware that that was the requirement and that whenever an OCR was approved of that nature, then they knew that was what they were required to do.
Mr Beer: People are aware of the speed limit. That doesn’t mean that they always abide by it, does it?
Stephen Parker: I agree with you but I am not aware of any times that members of the SSC did not abide by that rule.
Mr Beer: How would you know if you weren’t checking?
Stephen Parker: I would know by – well, having seen the OCR and talking to the person who actually executed it.
Mr Beer: No, that’s a different issue. That’s where they have used the OCR system, you know that they’ve used the OCR system.
Stephen Parker: Correct, yes.
Mr Beer: I’m talking about what audit or monitoring was there to see whether people accessed the live estate outside of the system that’s described in 13 subparagraphs here?
Stephen Parker: Do you mean access the live system in order to make a financial change?
Mr Beer: Yes.
Stephen Parker: Okay. There is – there were certain audit points in place, which should log most cases where that may happen but, ultimately, you are depending on the people concerned to understand the requirements and the importance of not doing it.
Mr Beer: So you’ve got to trust that they follow the process?
Stephen Parker: You’ve got to trust that they follow the process.
Mr Beer: Sometimes with access to systems, an employer checks whether their trust in their employees is well placed or not; was that done?
Stephen Parker: I don’t know.
Mr Beer: In your 22 years, have you any evidence that it was done?
Stephen Parker: I remember there were various audits of the processes, procedures and access carried out by external auditors. But that’s the only thing I can actually think of.
Mr Beer: I’m talking about not an audit of the written documents; I’m talking about an audit of whether access to the live estate, to correct or change, in some way, financial data, occurred; in your 22 years, was that ever done?
Stephen Parker: I’m not aware of how it could be done but, no, I don’t recall it being done.
Mr Beer: Well, it could be done, couldn’t it, just outside of the process that’s set out here?
Stephen Parker: Oh, sorry. You’re saying that could a member of the SSC make such a change without anybody’s knowledge?
Mr Beer: Yes. Answer to that, obviously yes?
Stephen Parker: The answer is yes, but I would caveat that by saying I was never aware of any such thing happening, and the nature of the people within the SSC is that the chances of them being able to achieve that without somebody else realising there was something going on are almost nil.
Mr Beer: Why?
Stephen Parker: Because you’re in a peer group of experienced technicians who would recognise when something wasn’t being done.
Mr Beer: How would they see?
Stephen Parker: By traces within the system.
Mr Beer: What traces within what system?
Stephen Parker: I can’t define those exactly to you because it would depend upon the nature of the change being made.
Mr Beer: If there was a trace left, it was therefore auditable, wasn’t it?
Stephen Parker: It would be capable of being audited. I don’t know, because we’re talking on a hypothetical thing here, whether such a thing would be in the audit trail or not.
Mr Beer: In your time, were you ever aware of there being an issue or concern over the extent of SSC’s access to the live estate?
Stephen Parker: There were a number of debates about access rights that the SSC had at different times. I think it’s fair to say that it’s fairly common that there’s an issue between what the ideal security of a system is and what level of security meets the actual operational needs of that system. So – and this was always ongoing and it was an amicable discussion between SSC and security people.
Mr Beer: Were you ever told that there was a concern that SSC staff had unauditable and unrestricted access to the live estate?
Stephen Parker: I wasn’t aware of anything unauditable. I mean, there was issues in the early days of Horizon with the methods used to connect to counters, because they weren’t adequately auditable. But that was worked upon and systems put in place by the time network banking services came in as part of Horizon.
Mr Beer: Can we look at page 31 of your witness statement, please, and can we look at paragraph 85 on page 31. You say in the first line:
“One would have to concede that where the SSC used Riposte tools and remote access to have a positive effect on outlet information, the opposite must also be possible.”
What did you mean by that sentence?
Stephen Parker: What I go on to clarify in the following sentence: that if some errors were made in the replaying of message store transactions, then, like, issues could come out of that.
Mr Beer: So you’re talking there about innocent errors by a diagnostician when seeking to correct a fault?
Stephen Parker: That’s correct, yes.
Mr Beer: They themselves, in fact, creating new ones?
Stephen Parker: That’s correct, yes.
Mr Beer: Not malign access?
Stephen Parker: Correct.
Mr Beer: Did the possibility of malign access ever occur to you?
Stephen Parker: The possibility occurred to me, but that was within the remit of the security staff. My concern, as an SSC manager, was that we should only have the level of access which was required for our work because that protected staff as much as it protected the service.
Mr Beer: Can we look back further up the page to paragraph 84.2. You say:
“Remote counter access would be used when Message Store intervention required that the records being re-inserted originated from the outlet counter. For context, records within the Riposte message store included details of the originating …”
That’s branch code; is that right?
Stephen Parker: That’s correct, yes.
Mr Beer: “… and counter ID …”
So that’s which counter within the branch.
Stephen Parker: Within the branch, yes.
Mr Beer: “Some types of records (normally transactions) could only be accepted by the system if they to very originated from an ID within the outlet.”
Do I understand from that that the SSC were, in fact, using branch IDs in order to make corrections.
Stephen Parker: No, they were not using branch IDs. They were potentially replaying transactions from the counter itself.
Mr Beer: But using a branch ID in order to do so?
Stephen Parker: That was an effect of it being run on a particular counter, those replayed transactions took on that counter’s ID.
Mr Beer: So would the footprint that was left show only the branch user ID?
Stephen Parker: Unless a member of the SSC – yes. Sorry, yes.
Mr Beer: So anyone looking back afterwards would not be able to see that this correction or this access was by somebody from the SSC?
Stephen Parker: Unless the member of the SSC ensured that there was an identifier within the messages going back which indicated SSC activity, which was also part of our process.
Mr Beer: But doesn’t what you’ve written here mean that, in these cases, the only visible record would be the originating branch code and counter ID, that the involvement of the SSC in the correction would not be visible?
Stephen Parker: That was not my intention when writing it. That inference could be taken but, as I’ve said, any change being made where the SSC had to insert data, we would attempt to market in such a way that it was obvious that it was done by the SSC.
Mr Beer: When you say, “We would attempt to”?
Stephen Parker: It was process; it wasn’t … policed by the system.
Mr Beer: Okay. So it was reliant on the operator and the second pair of eyes –
Stephen Parker: It was.
Mr Beer: – to use some code that left their footprint?
Stephen Parker: That’s correct, yes.
Mr Beer: Just going back, please, to FUJ00120446, and look at page 14, please, and at the foot of the page, 4.3. I just want to see the bit of the process here which requires them to use an SSC code in a way that leaves a footprint, so that it doesn’t appear, on the face of the record, to have been a branch and branch counter ID. I don’t think that’s in 1 or 2, is it?
Stephen Parker: It’s not, no.
Mr Beer: If we just go over the page, I don’t think it’s in 1 to 5 there, is it?
Stephen Parker: Not that I can see, no.
Mr Beer: Then if we look at the bottom part of the page, I don’t think it’s in 6 to 12, is it?
Stephen Parker: No.
Mr Beer: Then if we go over the page to 13, it’s not in 13, is it?
Stephen Parker: No.
Mr Beer: A policy that sets out, in rather elaborate detail, the process by which changes were made to the live estate, including where changes were made to financial data, ought to set out the requirement that you have just identified?
Stephen Parker: I would agree it should. I cannot explain why it doesn’t. But such requirements were in other documents and, in particular, in the SSC work instructions.
Mr Beer: The SSC work instructions –
Stephen Parker: Yes.
Mr Beer: – ie that you must always use an SSC ID to leave a footprint, I’m calling it?
Stephen Parker: It must always be identifiable as an SSC change, yes.
Mr Beer: Can we look, please, at FUJ00088036. Remembering that the document that we were just looking at was 29 January 2001, we’ve now moved forwards to 2 August 2002. You can see from the title of the document and the “Abstract” what it is. It:
“… describes the requirements and outline design for secure operational access to Counters and Servers. The design is based on modifying the OpenSSH product to provide a command logging facility, these logs being maintained for audit purposes.”
If we scroll down, please, we can see who originated the document, who contributed to it, yes?
Stephen Parker: Indeed, yes.
Mr Beer: We can see at the foot of the page that Mr Peach was an approval authority?
Stephen Parker: Yes.
Mr Beer: If we go over the page, please, and scroll down, we can see that you’re recorded as a reviewer of it?
Stephen Parker: That’s correct, yes.
Mr Beer: Would that be accurate if it’s on here that you’ve reviewed it, you would have reviewed it?
Stephen Parker: Yes, it would.
Mr Beer: Can we go to page 9, please, under the “Introduction” at 1.1.1:
“SFS mandates the use of Tivoli Remote Console for the remote administration of Data Centre platforms. This records an auditable trail of log-ins to all boxes accessed by the user. It is a matter of considerable discussion and correspondence that TRC is slow and difficult to administer. This has lead over time to BOC personnel …”
That’s people in Belfast?
Stephen Parker: I assume so. I must admit, I don’t remember them being called BOC but –
Mr Beer: If you go back to page 4, please, and look at the list of acronyms?
Stephen Parker: Belfast Operation Centre.
Mr Beer: Belfast Operation Centre.
Stephen Parker: Belfast Operation Centre, so, yes, it would have been them, yes.
Mr Beer: Go back to page 9, please. I think I was up to:
“This has lead over time to BOC personnel relying heavily on the use of unauthorised tools (predominantly Rclient) to remotely administer the live estate. Its use is fundamental for the checking of errors. The tool does not however record individual user access to systems but simply records events on the remote box that administrator access has been used. No other information has been provided including success/fail so it is not possible to simply audit failures. The use of such techniques puts Pathway in contravention of contractual undertakings to the Post Office. After the proposals in this [system outlying document] have been implemented a CP …”
Change process?
Stephen Parker: Yes, that’s correct.
Mr Beer: “… will be raised to phase out TRC (or limit its use to exceptional situations).”
Can you help us, what were the Belfast Operations Centre using Rclient for.
Stephen Parker: My assumption would – it’s a method of logging on to data centre servers or any other computer within the system in order to perform maintenance activities or diagnostic activities.
Mr Beer: Why were they using this unauthorised tool?
Stephen Parker: I believe it was primarily because there was no approved and auditable tool that was operationally good enough for them to use.
Mr Beer: Do you know why that was, almost two years into the operation of the system?
Stephen Parker: I don’t, no.
Mr Beer: Would you describe that as optimal or suboptimal?
Stephen Parker: Suboptimal.
Mr Beer: The system didn’t record individual user access. So did that mean that what I’ve called a footprint was not left?
Stephen Parker: Yes, it would.
Mr Beer: It meant that no audit was possible?
Stephen Parker: It would, yes.
Mr Beer: But why was it in contravention of contractual undertakings to the Post Office?
Stephen Parker: I don’t remember what was in the contract about this kind of security.
Mr Beer: But would you presume that there was some guarantee or undertaking or promise about the security of the system. That’s what’s being spoken of and this unauthorised and unauditable approach was in breach of it?
Stephen Parker: That would be my reading of it but I don’t know.
Mr Beer: Do you know whether the Post Office knew about these breaches of contract by Fujitsu?
Stephen Parker: I don’t know.
Mr Beer: Can we turn to the position with third line support, please, and look at page 13. This is under the heading “Requirements”, subheading “Areas of concern” and then 4.1.2, “Third line support”:
“Third line support staff receives repeat instances of calls that should have been filtered out by second line. Handling repeat calls is not an effective use of third line support resource. The current support practices were developed on a needs must basis. Third line support diagnosticians had no alternative other than to adopt the approach taken, given the need to support the deployed Horizon solution.
“The consequences of limited audit and system admin access afforded to third line support staff provide the opportunity to:
“Commit fraudulent acts;
“Maliciously or inadvertently affect the stability of the new network banking and Debit Card online services;
“In addition a complete audit would allow Pathway to defend the SSC against accusations of fraud or misuse.”
This is a very serious issue that’s being raised here, isn’t it?
Stephen Parker: It is, yes.
Mr Beer: Why were the current support practices developed on a needs must basis?
Stephen Parker: Because there was a necessity to support the service as it was at that time.
Mr Beer: Why weren’t they developed on a planned, designed basis?
Stephen Parker: I don’t know. I was nowhere near the design of that part of the service.
Mr Beer: Can you recall what prompted the inclusion of these paragraphs in this report? Why was it being looked at now? Was it the rollout of network banking?
Stephen Parker: I believe so, yes.
Mr Beer: Why was the rollout of network banking a trigger or a catalyst to identify the possibility of fraudulent acts, or malicious or inadvertent, affecting the stability of the system?
Stephen Parker: I’m not sure. I remember it happening at that time but I don’t remember exactly why that was necessary then, rather than not being done previously.
Mr Beer: Who developed these ad hoc practices on a needs must basis? Presumably that was you and your colleagues within the SSC?
Stephen Parker: Within the SSC or within the support environment in general.
Mr Beer: So who developed, then, within the SSC, these ad hoc access practices?
Stephen Parker: I don’t remember.
Mr Beer: Were you involved?
Stephen Parker: I don’t believe so, no. As I say, I have no, like, memory of that.
Mr Beer: But it would have been known about by the then manager; would that be right?
Stephen Parker: Yes.
Mr Beer: Mr Peach?
Stephen Parker: Yes.
Mr Beer: The document that we’ve just looked at, the January 2001 document with its 13 stages, it might be read as saying, “We’ve got a detailed and complex process that appropriately restricts access to the live estate by SSC staff”?
Stephen Parker: It might be read that way, yes.
Mr Beer: Here, that process is being described as problematic, isn’t it?
Stephen Parker: The tools being used at the – at that time, yes.
Mr Beer: Was this information shared with the Post Office, to your knowledge?
Stephen Parker: I don’t know.
Mr Beer: In your view, ought it to have been shared with the Post Office?
Stephen Parker: Not a decision for me to make, really. I’d go no further than that.
Mr Beer: Can we go to page 15, please. At 4.3.2, under the heading, “Third line and operational support”:
“All support access to the Horizon systems is from physically secure [sites]. Individuals involved in the support process undergo more frequent security vetting checks.”
Was that true?
Stephen Parker: I believe so.
Mr Beer: How frequent were your vetting checks?
Stephen Parker: I don’t remember. I mean, I know I was initially vetted on joining Pathway but I wouldn’t necessarily know if other vetting checks had been done.
Mr Beer: To your knowledge, were you ever re-vetted?
Stephen Parker: To my knowledge, no.
Mr Beer: “Other than the above controls …”
That’s secure – a secure site and frequently vetted – more frequently vetted individuals:
“Other than the above controls are vested in manual procedures, requiring managerial sign off controlling access to post office counters where update of data is required.”
Is that essentially describing, in a sentence, the 13 steps that we looked at in the 2001 document?
Stephen Parker: I believe so. But not having written it, I don’t know what was on the author’s mind, really.
Mr Beer: No, that would be an unfair question to ask: what was on the author’s mind? But looking at it, manual procedures requiring managerial sign-off is essentially the steps that we looked at, the 13 of them –
Stephen Parker: Yes.
Mr Beer: – in the previous document?
Stephen Parker: Yes.
Mr Beer: “Otherwise, third line support has:
“Unrestricted and unaudited privileged access (system admin) to all systems including post office counter PCs …”
When I asked you earlier whether you were ever made aware of a concern that SSC staff had unrestricted and unaudited privileged access to all systems, you said no. Presumably, you hadn’t remembered this.
Stephen Parker: Correct.
Mr Beer: Again, in the terms of level of seriousness of concern, this ranks quite highly in the spectrum, doesn’t it?
Stephen Parker: It does, if you had no trust in the staff, yes.
Mr Beer: If you trust your staff, you don’t need any checks at all; is that what you’re saying?
Stephen Parker: No. But the – having trusted, vetted staff mitigates that problem to an extent.
Mr Beer: You’re focusing, are you not, on malicious or malign access –
Stephen Parker: I am, yes.
Mr Beer: – as opposed to the leaving of a footprint for audit purposes?
Stephen Parker: Yes, that’s true.
Mr Beer: That could be examined and tested, for example, in any court proceedings?
Stephen Parker: That’s true and I would much prefer anything that the SSC had to do to be auditable, yes.
Mr Beer: Does that reflect the reality in the SSC that, other than locks and keys on the building and what was said to be frequent or more frequent security checks, other than that, the people in third line support had unrestricted and unaudited access to all systems, including post office counter PCs?
Stephen Parker: I would certainly say that that applied to most but there was audit for some things in place but I can’t define for you what they were. But, certainly for the post office counter PCs, as specified there, that is true.
Mr Beer: Skipping over the second bullet point:
“The current support practices were developed on a needs must basis; third line support diagnosticians had no alternative other than to adopt the approach taken given the need to support the deployed Horizon solution.”
Remembering back, did that reflect the position at the time that “We don’t like this, but we’ve got no option. We need this privileged access in order to make the system work”?
Stephen Parker: It does, yes.
Mr Beer: Did anyone ask the question, “Did anyone not think of this when they were designing and building the system”?
Stephen Parker: I don’t remember such a comment, but I would expect people to think, “Why?” I probably can’t say, like, any more.
Mr Beer: Did it, to your memory, consciously feel uncomfortable?
Stephen Parker: No, it didn’t feel uncomfortable. You got on with the job with the tools you had.
Mr Beer: The document continues:
“There are however no automatic controls in place to audit or restrict user access.”
That, in a sentence, is describing what should be in place, namely embedded automatic system controls that, at the same time, restrict access but also provide an audit trail afterwards.
Stephen Parker: That would be my reading, yes.
Mr Beer: “This exposes Fujitsu … to the following potential risks:
“Opportunity for financial fraud;
“Operational risk – errors as a result of manual actions causing loss of service to outlets;
“Infringements of the Data Protection Act.”
Was this needs must third line support access developed because of the number of bugs, errors and defects in Horizon Legacy that became apparent as it was rolled out?
Stephen Parker: No. I mean, as soon as you’ve got, what – you’ve got one error which needs you to access a particular component of the system, you have to find a way of accessing it.
Mr Beer: How many members of staff were in the SSC from, say, mid-2000?
Stephen Parker: I can’t remember exactly but I’d say about mid-20s.
Mr Beer: Did that number remain static or did it grow?
Stephen Parker: It changed over time, up and down.
Mr Beer: There were turnovers of staff?
Stephen Parker: There were. We didn’t have a massive staff, massive staff turnover, but yes.
Mr Beer: This document, in terms of operational risks, describes errors as a result of manual actions causing loss of service to outlets. That’s what I described earlier as an inadvertent error, rather then a malign or malicious conduct. Did Fujitsu ever explore whether this unauthorised access had destabilised the Horizon platform in any way?
Stephen Parker: I don’t know.
Mr Beer: To your knowledge, did it?
Stephen Parker: I don’t remember it being done.
Mr Beer: Can we go over the page to page 16, please, and paragraph 4.6, “Controlled access to sensitive data”:
“There are three categories of sensitive data within the Pathway solution:
“Personal data – subject to the rules of the Data Protection Act regarding its storage, confidentiality, accuracy and use;
“Business sensitive data;
“Cryptographic keys/data;
“None of the above sensitive data should be made available outside of the Pathway secure environment. Due to the potential sensitivity of cryptographic keys/data there is a further restriction that diagnostics can contain this data;
“[Namely] It can only be reviewed by a defined group – initially the SSC third line support group and development;
“[Secondly] In a secure location – currently 6th floor in Bracknell and the secure room in FEL01.”
Is it right that the policy document appears to be addressing the issue of access to sensitive data by limiting the access of it to those who were within a secure room in Bracknell?
Stephen Parker: Yes.
Mr Beer: If one of the unauthorised tools, whether that’s Rclient or one of the others, was being used by Fujitsu staff, could that only be used in the secure space at Bracknell or could it be used elsewhere?
Stephen Parker: It could only be used within secure spaces in – around Horizon. I mean, the SSC in itself had a secure floor. I believe, but I don’t know, the Belfast Operations had similar.
Mr Beer: Thank you.
Sir, I’m about to move to a different subtopic. I wonder whether that would be an appropriate moment to break until 2.00.
Sir Wyn Williams: Yes, by all means.
So we’ll convene again at 2.00.
Mr Beer: Thank you very much, sir.
(12.57 pm)
(The Short Adjournment)
(2.00 pm)
Mr Beer: Good afternoon, sir. Can you see and hear me?
Sir Wyn Williams: Yes, I can, thank you.
Mr Beer: Thank you very much.
Mr Parker, can we pick up where we left off by looking at POL00029282. You recall we’ve looked at some documents on remote access from 2001, 2002 and we’re now moved to 2004. Can you see that this document is entitled “Customer Service Operational Change Procedure”. The abstract of it says that it:
“… describes the procedure for Operational Changes where the changes are made to the live operation.”
It’s dated 18 March 2004 as version 1. The contributors to it are you and Mr Peach, yes?
Stephen Parker: Yes.
Mr Beer: Does that mean that you wrote it or did Mike Stewart and/or Mik Peach write it?
Stephen Parker: I think it was the latter, Mike and Mik would have written it. I would have just contributed ideas or suggestions.
Mr Beer: I see. Can you remember what the reason for – the necessity for this document was?
Stephen Parker: Other than ensuring that the process was correctly documented, no.
Mr Beer: Did this represent a change in process or was this recording what happened?
Stephen Parker: Without rereading the whole document, I’m not sure whether it was a change or not.
Mr Beer: Can we look, maybe to help you answer that question, at page 6. Can you see from the introduction it appears to be a description of existing process rather than highlighting change to a process?
Stephen Parker: I think that’s right, yes.
Mr Beer: Then can we go to page 7, please. You’ll see that it says, in the first line:
“Anyone can raise an OCP, except those who have logged onto the SSC website using the ‘OCPview’ user.”
What does that mean, please? Can you remember now?
Stephen Parker: When logging on to the SSC website you needed to supply a username/password and OCPview was I believe one of those usernames.
Mr Beer: Why couldn’t you raise one if you’d logged on using OCPview?
Stephen Parker: My assumption is from this sentence was that it was a read-only user so that you couldn’t interfere or change OCPs. I would also say that when we said earlier this is not a changed document or from the previous one, my memory of the previous one was that OCRs were raised on paper at that time, whereas this reflects the fact that they were being raised via the SSC website.
Mr Beer: I see. I understand.
Stephen Parker: Apart from that, I doubt there’s a great deal of difference.
Mr Beer: Then if we can go to page 9, please. At the end of this section on generating an OCP, it says:
“NOTE – an OCP is raised in order to make a change to the live system. If the change is likely to affect a system build, then the relevant part of the form must be set to YES. If the change is being made to the system in order to overcome an operational deficiency which should be permanently fixed in the system code, then there MUST be a call raised to report the problem, and the call reference added to the OCP.”
Was there any monitoring in place at Fujitsu to ensure that those who had power to access the live system acted in accordance with this policy?
Stephen Parker: There was no constraint. It was just you were expected, and to use the process. I don’t know of any way that you could stop people from not using that process.
Mr Beer: What about retrospectively? Was any audit done to ensure that any changes that were made, whether using this OCP system or not, were monitored for errors, regression or unintended consequences?
Stephen Parker: Certainly after making any change, you would be looking at the system carefully to make sure, as you say, there’s no regression or adverse impact to the system. That would be standard process. That would just be due diligence, really.
Mr Beer: That’s on an individual basis?
Stephen Parker: Mm.
Mr Beer: I’m looking at – or I’m asking about more a system-wide approach.
Stephen Parker: I don’t think I was aware of a system-wide approach, no.
Mr Beer: Can we turn, please, to FUJ00138355.
Sir Wyn Williams: Mr Beer, before we do that, could we just go back to the first page, please?
Mr Beer: Yes, of course.
Sir Wyn Williams: I don’t want to make any point that you’re going to cover but unless – Mr Parker, if you see, just below your name and Mr Peach’s, there’s the heading “External distribution” and we have the name “John Bruce (Post Office Limited)”. Now, I may have missed it but I don’t think in the last document we looked at about these processes there was an external distribution at the Post Office. Have I got that right?
Stephen Parker: I’m sorry I don’t remember.
Sir Wyn Williams: All right, that’s fine. But on this occasion, clearly there was. So that from this moment on, the Post Office were aware of this document, on the face of it?
Stephen Parker: Yes.
Sir Wyn Williams: Do you know who Mr Bruce was?
Stephen Parker: I remember the name but I don’t know his position within the Post Office.
Sir Wyn Williams: All right. Thank you.
Sorry, Mr Beer. I just wanted to follow that up slightly.
Mr Beer: Sir, yes. Can I follow up your follow-up and look at page 2 of the document, please.
Scroll down, please.
We can see maybe the purpose for which the document may have been shared with the Post Office, because under the bottom section of that table it says “Optional Review/Issued for Information”, and, again, the name of Mr Bruce from the Post Office Limited. Can you help us, what does that “optional review” mean?
Stephen Parker: When the document went out for optional review, the person may or may not return comments on it. If you were a reviewer, you had to return a no comments document.
Mr Beer: I see. Was that a mandatory review?
Stephen Parker: For a mandatory review of the document, yes, you had to return no comments.
Mr Beer: So an optional reviewer, here Mr Bruce, would be sent the document but it wasn’t mandatory for him to make a return?
Stephen Parker: Correct.
Mr Beer: The optional doesn’t apply to whether or not the document was sent to him?
Stephen Parker: That’s correct, yes.
Mr Beer: “Issued for information”, is that self-explanatory, ie you’re just getting this after we have written it?
Stephen Parker: Yes.
Mr Beer: Okay, thank you. Can we go, please, to FUJ00138355. This is a new species of document that we’re looking at with you, it’s called a WI. Can you recall what those are?
Stephen Parker: Those are work instructions which were entered and maintained on the SSC website.
Mr Beer: Can you briefly explain what the purpose and function of a work instruction is, please?
Stephen Parker: It was there to provide information to diagnosticians on how a particular task should be achieved or what the expectations were for standards of use.
Mr Beer: Was it an internal SSC document, then?
Stephen Parker: I think – they were only ever raised by SSC members. I don’t remember whether people outside the SSC could see them. I suspect they could.
Mr Beer: But the target audience were SSC diagnosticians?
Stephen Parker: Yes, indeed.
Mr Beer: If we just read it, the title is “Data correction”. It was authored, in its first version, by you. This is version 18 we’re looking at. The details are:
“GDPR regulations require that access to personal data remains within the European Union and PCI data security standards mandate physical security restrictions must be applied where update access is allowed to user data.”
Presumably you wouldn’t have been writing that, is that right, in 2011?
Stephen Parker: Yeah, don’t believe those are my words. They’re not my style. I probably – I may have lifted those from a security document.
Mr Beer: I was thinking more about whether, in 2011, you would have been referencing the GDPR at all?
Stephen Parker: Quite true, yes. I mean, that would have been too early for that, yes.
Mr Beer: So we can’t tell from this, the 18th edition of this document, what is your text, what is the text of those between versions 2 to 17, and that which is Mr Woodley’s text in version 18?
Stephen Parker: Yes.
Mr Beer: Is that right?
Stephen Parker: That’s correct, yes.
Mr Beer: Moving on a paragraph, just at the end of the first paragraph:
“The responsibility for data correction is vested with the SSC although ISD sometimes act under SSC authorisation.”
What was the ISD?
Stephen Parker: That was the Belfast Operations. That was another acronym used for them later on.
Mr Beer: “Corrections to live system data must be authorised via account change control and auditable. Any correction requiring APPSUP role is to be witnessed by a second member of the SSC. Both names must be recorded on the change control for audit purposes.”
Given the documents we’ve looked at to date, why was this work instruction necessary?
Stephen Parker: I think the idea was just to clarify for SSC members to make it clearer to them so that they didn’t have to look at various disparate documents.
Mr Beer: What would they have done between 2000, then, and September 2011 when this document was first created?
Stephen Parker: They would have had to refer to various documents to get the overall picture, as it pertained to the SSC.
Mr Beer: You see at the top it says that:
“This [work instruction] is waiting for approval by Mark Wright and should not be used.”
Stephen Parker: Mm-hm.
Mr Beer: Why was it, still in February 2021, waiting approval by Mark Wright and shouldn’t be used?
Stephen Parker: I don’t know.
Mr Beer: If you just read through it to yourself, just to refamiliarise yourself with it. (Pause)
Stephen Parker: Okay, yes, got that.
Mr Beer: If you scroll down to “Change Control”. Thank you. (Pause)
Stephen Parker: Yeah, okay.
Mr Beer: Is there anything in there that you can read that might explain or justify why the work instruction was “awaiting approval by Mark Wright”?
Stephen Parker: No. Nothing there is obvious to me, no.
Mr Beer: Going back to the top of the page in the second paragraph under “Details”:
“Corrections to live system data must be authorised via Account change control and auditable.”
Does that suggest that still at this date, when you wrote it in 2011 and when Mr Woodley last updated it in 2021, that there wasn’t any automated system of secure access and auditing?
Stephen Parker: No, I don’t remember whether I wrote that sentence or not. But I mean, any change of that type to the system we would want to be auditable in some way. I don’t think that says that changes were not actually auditable previously.
Mr Beer: It continues:
“Any correction requiring APPSUP role …”
What was the APPSUP role, please?
Stephen Parker: The APPSUP role was an elevated permission that members of the SSC could invoke in order to view or change certain information within a database. So it was more than our standard permissions.
Mr Beer: Was it up to them to determine whether they used that enhanced facility?
Stephen Parker: It was, yes.
Mr Beer: Was there any restriction on them using that enhanced facility?
Stephen Parker: No, there wasn’t, to my knowledge.
Mr Beer: It says that:
“Any correction requiring APPSUP is to be witnessed by a second member of the SSC.”
The four-eyes approach that we had seen in the earlier documents didn’t restrict that requirement to the used to of the APPSUP facility, did they?
Stephen Parker: No, they didn’t.
Mr Beer: Was it the four-eyes approach, restricted only to the APPSUP facility, or not?
Stephen Parker: The four-eyes approach would be expected for any financial change.
Mr Beer: Do you know why this puts a different requirement or restriction on it, namely it’s the use of the APPSUP –
Stephen Parker: Um –
Mr Beer: – that triggers the four eyes requirement?
Stephen Parker: I think that’s probably more bad writing than requirement because I hope further down in the financial data bit it does say – yes, it does – of the two-man rule is used.
Mr Beer: You’re looking under the heading “Financial data” –
Stephen Parker: I am indeed, yes.
Mr Beer: – two sentences in?
Stephen Parker: Yes, correct.
Mr Beer: Thank you. Can we move on still further, please, and look at FUJ00087154. This is a document which is described as a “Statement on Fujitsu remote support access to Post Office branch counters”, written by Dave Haywood, a security architect within Fujitsu. Do you recall Mr Haywood?
Stephen Parker: I do, yes.
Mr Beer: Where did he work within the company?
Stephen Parker: In terms of division or location?
Mr Beer: Both, please.
Stephen Parker: He was part of the architectural team. I think Dave was one of the exceptions who tended to work offsite. I don’t remember him being in the Bracknell building, apart from coming down for meetings.
Mr Beer: So he’s neither third or fourth line?
Stephen Parker: No.
Mr Beer: He’s architecture?
Stephen Parker: Architectural, yeah.
Mr Beer: You’ll see from the bottom half of the page the distribution list. It includes you and you’re described the “Strategic Support Lead”. What does that mean?
Stephen Parker: I think it’s just indicative of the fact that our titles meant that – meant very little and were sometimes interchangeable. I don’t know why Dave used that in that particular document.
Mr Beer: It should say “SSC Manager”?
Stephen Parker: It would be better defined that way, I think, yes.
Mr Beer: Anyway, if we go over the page, please. The document says that:
“In the event that this document is shared outside of [Fujitsu] it should be noted that whilst Fujitsu endeavours to ensure that the information contained in this document is accurate … it accepts no liability …”
It sets out the “Scope” as being remote support access to branch post office counters under both Horizon Online and Legacy Horizon; is that correct?
Stephen Parker: Yes.
Mr Beer: It starts with HNG-X. If we just scroll down, please.
Stephen Parker: Sorry, may I go back to where we were briefly?
Mr Beer: Yes, of course.
Stephen Parker: You said it referred to HNG-X and Legacy Horizon.
Mr Beer: HNG-X and HNG-A?
Stephen Parker: Ah, right, I thought I heard Legacy but, yes, HNG-X and HNG-A were later systems, yes.
Mr Beer: Can we just then scroll down and look at HNG-X. Do you see that it sets out a process that is used to access branch counters?
Stephen Parker: Indeed, yes.
Mr Beer: It says that the method is Secure Shell.
Stephen Parker: Yes.
Mr Beer: Can you describe, please, to a lay audience what Secure Shell was?
Stephen Parker: It enabled a technician to connect to and execute commands on a remote system over a secure encrypted connection.
Mr Beer: It says that:
“The server component resides on the branch counter and is provided by the Cygwin OpenSSH server package.”
What does that mean, please?
Stephen Parker: Cygwin was a package that could be used on Windows’ platforms to enable Unix-like commands to be executed so Windows and Unix being two different flavours of operating system. It then sets out requirements, if we skip on a couple of paragraphs to “To gain access to the branch counter”. It says:
“… using the remote support capability the member of staff must …”
Then there are a number of requirements set out:
“Be a Fujitsu employee
“Have been security and financially vetted …”
Was that a new requirement, to be financially vetted?
Stephen Parker: No, I think the financial vetting was the original level of vetting. No, I can’t help with that. I’m struggling there.
Mr Beer: Okay:
“Possess a 2 factor authentication token issued by the Security Operations team …”
Can you remember when that was introduced?
Stephen Parker: Two-factor authentication tokens were around from the very early days of Horizon. We used to use a token called a secure ID, right back – I can’t give you a date but it was early in Legacy Horizon and, in HNG-X terms, there was a separate secure – a different secure token that was connected to the PC in order to generate a security token number.
Mr Beer: Just to be clear, the two-factor authentication token, was that just to get access to the system generally or was a special token required to be issued by the security operations team, if you were going to make changes to branch counters?
Stephen Parker: Yeah, a token was required for any secure system access. So that would be anybody in the third line support group, anybody in Belfast or Operations, people in other units would also have had secure tokens if they needed to access the system in something other than a read-only fashion.
Mr Beer: But there wasn’t a special token issued –
Stephen Parker: Not for this purpose.
Mr Beer: – for the purposes of making alterations, I’m going to call it?
Stephen Parker: No.
Mr Beer: Okay.
Skipping a couple of paragraphs:
“Have access to a branch support access private key.”
What does that mean?
Stephen Parker: I don’t know. I don’t know, sorry.
Mr Beer: Just going back to page 1, and looking back at the distribution list, the second person to whom the document is said to have been distributed was Chris Jay, who was described as “Defence Legal”. Can you remember who that was and what Defence Legal was?
Stephen Parker: I remember there was a period when there was some sort of legal oversight going on. I mean, Chris Jay was part of the Fujitsu legal department, as I remember it. I can’t remember when his involvement started or why his involvement was on there.
Mr Beer: You said that you remember a period when there was some sort of legal oversight going on.
Stephen Parker: Mm-hm.
Mr Beer: Legal oversight of what?
Stephen Parker: I’m not sure. I just remember occasionally having to pass documents past Chris Jay.
Mr Beer: Documents about the Horizon System?
Stephen Parker: Yes, indeed, yeah.
Mr Beer: What was the purpose of having to pass them past Chris Jay?
Stephen Parker: Some kind of review. I unfortunately just don’t remember precisely why he was, in the loop for something.
Mr Beer: You said that you remember that being at some period?
Stephen Parker: Yes.
Mr Beer: Can you remember when that was?
Stephen Parker: Unfortunately, no.
Mr Beer: Can we move on, please, to FUJ00087187. We were previously looking at a document dated August 2015, we’re now moving, if we look at the foot of this page, to 12 August 2016. Yes?
Stephen Parker: Indeed.
Mr Beer: If we go to the top of the page, the heading is “Transaction Corrections within Riposte based Horizon”:
“The ‘Old’ Horizon System (pre-HNG-X) was based upon a product called Riposte. The basic architecture was that each counter had a local database known as the Message store. The data centre had a number of servers known as correspondence servers, each instance of which managed a subset of the live branch estate.”
All accurate?
Stephen Parker: Yes.
Mr Beer: “Correspondence servers contained large Message stores which replicated to and from the set of counters that correspondence server managed. Thus collectively the central Message stores would contain detail of all branch transactions.”
Correct.
Stephen Parker: All correct, yes.
Mr Beer: “The old audit system harvested branch transaction data from the correspondence servers giving it an audit trail of all branch transactions.”
Is that accurate?
Stephen Parker: I was never supporting the audit part of the service, so I can’t say for sure that it gave an audit trail of all branch transactions but I know that was its purpose.
Mr Beer: “The replication process between the correspondence server message stores and counter message stores was two way. So it was possible to inject messages into the central message stores and these would be transmitted to the relevant counter message store. This was the process that was used to effect the equivalent of transaction corrections in old Horizon.”
Does that match your understanding?
Stephen Parker: It does, yes.
Mr Beer: “Any such correction entered this would be recorded with a node ID of the central correspondence server ([greater than] 32) …”
Can you explain what that means, please?
Stephen Parker: Yes. As we saw earlier, where the IDs and nodes within the branches would be 1 upwards, correspondence servers were 32 upwards just to separate them from the branch estate – or, sorry, make it clear that it was a correspondence server rather than a branch counter.
Mr Beer: “… and would be included in the standard branch audit trail. Thus they were readily identifiable. The same technique was used to transmit other data … from the centre to the branch.
“Any such correction would have been subject to an … (Operational change process pre-dating MSCs). Need to find some examples of some old OCPs and some view on how often it happened – Steve Parker?”
Now, presumably you won’t have seen this document, other than for preparing for today?
Stephen Parker: That is correct, yeah.
Mr Beer: Can you remember the context, why in August 2016 you would have been being asked for examples of OCPs, old ones, and a view on how often the process described there happened?
Stephen Parker: I have to suspect in my mind that this was all to do with legal/litigation issues, but I don’t remember the exact – exact context of this document.
Mr Beer: The sentence “All such corrections would be recorded with a node ID of the central correspondence server [of greater than 32]”, didn’t we establish earlier that some corrections would have to be made using the branch counter ID?
Stephen Parker: That’s correct, yes, a limited, very limited number had to be entered as if they had originated at the branch. Most would be able to be executed at the correspondence server but I can’t remember or give you examples of which ones were which.
Mr Beer: So this is inaccurate to say that any such correction would be recorded with a node ID that would leave a footprint to make it readily identifiable as coming from the SSC?
Stephen Parker: If it – I think that depends on your reading. My reading of it was that, as it said, it was possible to inject messages into the central message stores. That sentence was referring to messages injected into the central message stores, but I agree it could be read either way.
Mr Beer: Can we move on, please, to FUJ00087220. We were previously in August 2016, we’re now in October 2016 and this is an email chain in which you were involved. It’s in relation to a Deloitte audit report, an audit, I think, in which you were also involved?
Stephen Parker: I believe I took part in it, yes.
Mr Beer: Yes. I think I’ve got a record of you being interviewed before it.
Stephen Parker: Yes.
Mr Beer: Can we go to page 5, please. We can see that this is an email from Stuart Honey to Russell Norman, Dave Haywood and you?
Stephen Parker: Yes.
Mr Beer: Can you help us with who Mr Honey was?
Stephen Parker: Stuart was involved in the security of the system as well. I can’t remember, I think Stuart was more on the development side than – as opposed to Dave Haywood being on the architectural side.
Mr Beer: In any event, the email that’s sent to you and others says:
“Hi Russell,
“I sent some information to Stuart Honey regarding this …”
Then that’s repeated.
“… and I was not sure of the outcome after that point. Was this linked to the info Paul has collated for data flows – Paul/Dave/Stuart APPSUP – Steve raised the point about whether the process should be changed to match the designs or the designs changed to match the process as in the attached?”
Doing the best we can of reading this email, you’re reported – I think you’re the Steve here – as saying, “Should we” – is this right – “write documents that match the process that we currently operate or should we change our processes to match designs in documents that we are to write?” Is that right?
Stephen Parker: Yes, except the documents are already written, I believe.
Mr Beer: Ah, so some documents had already been written –
Stephen Parker: I believe so, yes.
Mr Beer: – that didn’t match the process?
Stephen Parker: Yes, I believe so.
Mr Beer: Can you recall in what respect they didn’t match the process?
Stephen Parker: I mean, I looked at the information in my bundles on this whole APPSUP issue. I don’t remember exactly how they didn’t correspond to the actual process but I know that the way that the SSC used APPSUP at this time allowed any member of the SSC to escalate privilege, in order to make – in order to work on the system in a privileged fashion.
I believe the documentation said that any such changes in HNG-X would only be done via a development provided script. It was around that area. I mean, the whole thing got extremely complicated and went backwards and forwards for sometime.
Mr Beer: So there’s a debate really here whether the SSC should do what’s in a written policy or whether the written policy should, in effect, be a piece of reverse engineering –
Stephen Parker: Sure.
Mr Beer: – to reflect what it does in practice?
Stephen Parker: Indeed.
Mr Beer: What was the outcome?
Stephen Parker: As I remember, the outcome was that, in order to – in order for the development group to provide scripted – the ability for scripted changes for everything the SSC did, it became too difficult to implement for reasons of the logistics of people being available out of hours to approve SSC access and then make changes to the system in order to allow a member of the SSC to elevate access or use scripts. It was – there was – it was more to do with “We can’t get the right people on call to do this”, and a pragmatic view was taken that, since all SSC access via APPSUP in HNG-X was audited anyway, the existing methods would continue to be used.
Mr Beer: I think we can see your reply on page 4, if we scroll down. We can see that is from you to Stuart Honey and others?
Stephen Parker: Yes. This was an earlier stage in that process, yes.
Mr Beer: You say:
“In principle … I would prefer that we have this removed …”
That was the– the “this” here was essentially the APPSUP access –
Stephen Parker: The ability to raise our privilege to APPSUP level without any –
Mr Beer: Auditable oversight?
Stephen Parker: Thank you, yes.
Mr Beer: You said in principle you would prefer that you had that privileged access removed so that you could go back to the security model as documented. You wanted to do what the policy said ought to be done, rather than what was in fact being done?
Stephen Parker: Correct, yes.
Mr Beer: But for pragmatic reasons that was not possible?
Stephen Parker: I do outline some of those, the issues that were going to be experienced further on there.
Mr Beer: How significant an issue was this?
Stephen Parker: It went backwards and forwards for sometime. But it was – it’s a reasonable example of the pure security view which says “You just don’t do this” and the pragmatic view which says that was the only way we could logistically manage the process.
Mr Beer: Can we go forwards, please, to a little later in October 2016. Sorry, this is August 2016 to October 2016, to FUJ00089535. You’ll see that this is a formal policy document setting out the high level design for the remote access secure access server, written by Mr John Bradley. If we turn to page 4, at the foot of the page, I think we can see that you’re a reviewer?
Stephen Parker: Yes. Whether I reviewed or not is debatable. That form of entry with my name and the name of a member of the SSC afterwards, I was sent every document for review and I would farm those out to individual members of the SSC who would respond for me.
Mr Beer: I see. We can see that the mark in brackets afterwards takes us to – underneath “0.3 Review Details”, it shows that it was somebody that actually returned a comment?
Stephen Parker: Yes.
Mr Beer: Does that mean it was Mr Breakspear that did so –
Stephen Parker: Yes.
Mr Beer: – or does it mean that either of you and Mr Breakspear did?
Stephen Parker: I would expect that to mean Phil did. By that time, I was getting less and less technically proficient, having been in a management role for longer, and I didn’t feel competent to actually comment on this kind of a document.
Mr Beer: Can we look at what it says is the formal policy by October 2016, at page 13, please. Scroll down to 4.1.2 “Audit”, it states:
“Although no active command logging or keystroke logging is done, we are keeping a record of people logged on to SAS Server through double authentication and OS security policies for state servers.”
Firstly, the things that aren’t being done, active command logging, what’s that?
Stephen Parker: Believe that refers to logging the commands being executed. Why that’s been distinguished from keystroke logging, I’m not clear, really.
Mr Beer: Are they essentially the same thing?
Stephen Parker: Actually, probably not, thinking about it. Keystroke logging, if you were entering data into a field in a form on a screen, then keystroke logging would detect as you enter keys 5, 4, 3, 2, et cetera. Whereas command logging would log the whole string that you put in after any corrections have been done.
Mr Beer: So on that example –
Stephen Parker: So, thinking about it, I can see why there is a difference there, yes.
Mr Beer: So, in your example, command logging would just record that you had committed to whatever process you were undertaking, the digits 5, 4, 3, 2, 1. It wouldn’t record that you initially typed 7, 8, 9, 10, deleted them and then wrote 5, 4, 3, 2, 1 and then committed them to the process?
Stephen Parker: That’s correct, yes.
Mr Beer: Why would command logging or keystroke logging be contemplated for secure access to the live estate?
Stephen Parker: It gives an irrefutable record of precisely what was being – was being executed.
Mr Beer: In that way, it is entirely auditable after the event?
Stephen Parker: It would be, yes.
Mr Beer: In what sense is that a normal standard for the kind of remote access to financial data that we are speaking about here, or to what extent is it a gold standard that’s never achieved?
Stephen Parker: I don’t know what the documented standards are, industry standards are, in this area. So I can’t be sure.
Mr Beer: Can you recall discussion across the ages as to whether or not active command logging and/or keystroke logging ought to have been the standard that should be achieved?
Stephen Parker: I don’t remember discussions. It would be my preference, for the reasons we have stated previously, that it gives an irrefutable record of what’s been done.
Mr Beer: So it was that, even by 2016, despite the documents we’ve previously seen as to what had been proposed, that this still that not been introduced?
Stephen Parker: Yes, that would have been my reading.
Mr Beer: Had that been the subject of discussion and debate?
Stephen Parker: No. But if I may, I will rewind slightly. There was keystroke logging introduced as part of the SSH implementation that we’ve been looking at here, and I know for a period keystroke logging did take place because I remember there being servers that contained the log data.
At some stage, and I don’t remember when, it must have come out of the system again for some reason. I have no recollection of when it came out or why.
Mr Beer: Who would have put it in and who would have taken it out?
Stephen Parker: It was put in as part of the version of Horizon that we saw earlier when we were talking about this was about the time of network banking. That’s when it would have gone in. I believe, the more I think about it, it probably came out at HNG-X but I’m not positive of that.
Mr Beer: Your best memory is between about 2006 and 2010?
Stephen Parker: Correct.
Mr Beer: Can you recall, in general terms, the reason why, despite it being so obviously desirable that it was not done?
Stephen Parker: I can’t remember why now, no.
Mr Beer: Thank you.
Can we go to FUJ00138382. This is exceptionally difficult to read, so I’ll take it slowly. It’s another work instruction; can you see that?
Stephen Parker: Yes, I can.
Mr Beer: Its title is the “APPSUP role”.
Stephen Parker: Yes.
Mr Beer: Why was it described as a role?
Stephen Parker: That was the term used within the Oracle software that ran the database services. You literally called a command “set role APPSUP”.
Mr Beer: Okay, so it’s not speaking but person’s role; it’s speaking about a role in terms of a function that a system performs?
Stephen Parker: It is, yes.
Mr Beer: Okay. You’ll see that you created this on 31 October. Again, it had a later update, last by Mr Gelder, and we’re looking by version 21?
Stephen Parker: Yes.
Mr Beer: So, again, we should bear in mind that not every word will be yours and maybe none of them are yours. Can we see under heading “Below is the Historic Process”, it says:
“The Horizon security design has two main groups with privileged access to the system. Belfast Operations for operational purposes and SSC for data correction and support.”
Is that accurate, that there were two main groups within Fujitsu who had privileged access to the system?
Stephen Parker: Yes.
Mr Beer: “This privilege was deliberately split between the two units to separate the roles for security purposes and prevent a single point of failure.”
Can you explain how splitting, as it’s described, operational purposes and data correction and support, prevents a single point of failure?
Stephen Parker: If for some reason there was a disaster which rendered the SSC inoperable or there are network connections in to the service that make it inoperable, then Belfast Operations could carry out commands on our behalf or vice versa.
Mr Beer: It continues:
“In each case the requirement is for a distinct privileged role that would only be used when suitable change control has been raised for audit trail, not authorisation purposes.”
Can you explain what that means? It tends to suggest, does it, that the audit trail is the desired focus for the change control process, rather than actually being for authorising the change? Sorry, that’s a terrible question.
Stephen Parker: No, I understand what you’re saying. I think you’re right. Because the SSC were capable of doing a set role APPSUP without authorisation, then that sentence, in some ways, makes sense. The statement is being made that you should raise the change control to make sure a record is being kept.
Mr Beer: Does it follow that the Operational Change Process was all about creating an audit trail and not about actually seeking authorisation in each case?
Stephen Parker: No. No. I mean, the change control process was as much – for most purposes, was as much about the approval as about ensuring whatever was being affected wasn’t documented.
Mr Beer: Can you help us, this is within seven days, this work instruction was raised, of the formal policy setting out high-level design for remote access to the secure access server. Remember, that one was dated 24 October 2016 and we’re now on the 31 October 2016.
Stephen Parker: Right, yes.
Mr Beer: Why was it necessary, in October 2016, to set out in a work instruction the historic process that had been followed years before but was now no longer followed?
Stephen Parker: I don’t know. I have no recollection of it.
Mr Beer: At this stage, can you remember, were complaints being made and litigation contemplated?
Stephen Parker: Timing wise, I would say that’s possible but I don’t remember that being the case here, or a motivation here. I don’t remember enough about it to tie that in.
Mr Beer: Can you think of a reason why a work instruction would be written in October 2016 that set out, not a work instruction, but an historic process in the past?
Stephen Parker: Not really, no, because, I mean, I would have expected that kind of thing to have already existed. So I’m not clear why this is here in this form.
Mr Beer: You wrote the document?
Stephen Parker: Yeah, and I just – unfortunately just don’t remember what I was trying to achieve at that time.
Mr Beer: You think it was “We’ve got a new document dated 24 October setting out what we’re going to do in the future, we need to reduce to writing” –
Stephen Parker: What we did in the past.
Mr Beer: – “what we did in the past, so that it’s accurately recorded because we now know it’s going to be the subject of questions”?
Stephen Parker: It’s the sort of thing I can see myself doing I just don’t remember it.
Mr Beer: Can we go to your witness statement, please, at paragraph 72, which is on page 23. If we scroll down, thank you. You say:
“The SSC was hugely reluctant to change transaction data as that was not our job and we recognised the seriousness of doing so.”
Why were you being requiring to change transaction data when it wasn’t your job?
Stephen Parker: If there was a situation where it was impossible for a change to be effected by the Post Office, in order – via a transaction correction or whatever other mechanisms they used, then, in rare circumstances, it may be necessary for us to effect a financial change. I mean, the comment that it is not our job was – you know, we would much prefer in all cases that financial information was rectified by the Post Office and not us.
Mr Beer: Did you say you would much prefer in “court cases”?
Stephen Parker: No, in all cases.
Mr Beer: In all cases, thank you.
Stephen Parker: Yes, yes.
Mr Beer: Why would you much prefer that?
Stephen Parker: Because I don’t believe that people who were supporting a system should be responsible for making financial changes. That is a business position.
Mr Beer: So whose job was it?
Stephen Parker: I would argue that POL should be issuing some form of transaction correction for a postmaster’s account.
Mr Beer: Why weren’t they doing it?
Stephen Parker: I believe there were some circumstances where it just couldn’t be effected with the tools they had.
Mr Beer: Is that because you controlled access to the dominion that required changing and that they simply physically could not do it?
Stephen Parker: I believe so, yes. Yes.
Mr Beer: At the time, did you express your concern that you were being required to change transaction data that wasn’t your job?
Stephen Parker: That comment would be made with the caveat that sometimes we just had to do it. There was no choice. But the circumstances were rare.
Mr Beer: You say in paragraph 72.4 over the page that – the lead-up to this paragraph is:
“In the rare circumstances where it was necessary to correct financial information on the system we would …
“72.4. Ensure POL and/or the subpostmasters were informed (… via the Service Delivery Team).”
Stephen Parker: Yes.
Mr Beer: How would you ensure that POL and/or the subpostmasters were informed?
Stephen Parker: By giving the necessary information to the Service Delivery Team for onward routing to the Post Office or onward discussion with the Post Office.
Mr Beer: Where you’re referring here to the Service Delivery Team, who are you referring to within Fujitsu?
Stephen Parker: People’s names or roles?
Mr Beer: Roles, please.
Stephen Parker: It’s the team I was referring to earlier in our discussion, who had various service managers who would be responsible for different parts of the system and that could collectively be termed the Service Delivery Team.
Mr Beer: Did you expect subpostmasters therefore to be informed on each occasion that changes were made to financial data concerning their counters and their branches to be informed that that had happened?
Stephen Parker: Oh, yes.
Mr Beer: Sir, I wonder whether we could take the break now, please, until, say, 3.15.
Sir Wyn Williams: Yes, and how do you predict the remaining afternoon going?
Mr Beer: Sir, I’ve got another topic, which is about 20 minutes, to cover. Then I think –
Sir Wyn Williams: Are there many CP questions?
Mr Beer: Five minutes and two minutes, I’ve been told, sir.
Sir Wyn Williams: Right. So we’re well on track to finish Mr Parker this afternoon, that’s what it boils down to?
Mr Beer: Yes, sir.
Sir Wyn Williams: Fine. What time again, sorry?
Mr Beer: 3.15, please.
Sir Wyn Williams: Fine.
(3.02 pm)
(A short break)
(3.15 pm)
Mr Beer: Good afternoon again, sir. Can you see and hear me?
Sir Wyn Williams: Yes, I can.
Mr Beer: Before we move to the topic that I said I was going to move to, can I just ask you some supplemental questions on the issue we were just addressing and go back to paragraph 85 of your witness statement on page 31, please. So it’s paragraph 85.
You’ll remember the “One would have to concede” sentence, and then you set out some controls that give protection against the errors or similar that you have identified as a possible consequence of remote access. I just want to ask you about the one you identify in 85.2 and so you say:
“Controls offered some protection here …”
Then 85.2:
“Any such intervention would be with the subpostmaster’s consent and the subpostmaster would use system reporting to check that the results of SSC work were as expected.”
Dealing with the first part of the sentence first, any such intervention would be with the subpostmaster’s consent. Are you saying that before the SSC made any changes to data, any alterations or inserted messages, that was always done with the subpostmaster’s consent?
Stephen Parker: I would probably have to amend that to say where the incident to originated from the subpostmaster, then clearly we would be in contact with him or her and would be discussing and telling them we are effecting something for them. I think that I should probably caveat it in just that way.
Mr Beer: Just dealing with that caveatted way first, being in contact with a subpostmaster doesn’t necessarily mean that you have their consent to make alterations to their financial data, agreed?
Stephen Parker: Yes, yes.
Mr Beer: So, even in the cases where you were in contact in the SSC with a subpostmaster, it was not the case that you always obtained their consent before alterations to financial data were made; is that right?
Stephen Parker: I want to say that it’s not right and that we would always discuss with the subpostmaster but there was no controls to ensure that was the case.
Mr Beer: Why were there no controls to ensure that that was the case?
Stephen Parker: Again, change control would always be used, but that was effectively the only control in that process.
Mr Beer: Change control was focused on the Post Office as an institution, rather than the individual subpostmaster knowing, less still consenting, to the change?
Stephen Parker: That is true. That is true. But I would expect that, whenever a member of the SSC was working on a subpostmaster call, they would be talking to them as necessary and helpful to them.
Mr Beer: Let’s deal with the sentence without the caveat. In a case where SSC was talking with one subpostmaster but on examination it was found that the problem affected the financial data of 100 subpostmasters, those other 100 subpostmasters were not contacted, and –
Stephen Parker: Well –
Mr Beer: – said that there will be a correction made to their data?
Stephen Parker: They wouldn’t be by the SSC, no.
Mr Beer: Were they contacted by anyone, to your knowledge?
Stephen Parker: In the case of a change to that scale, ie 100 subpostmasters, I mean, that would have gone – been part of the problem management process, it would have gone through service managers it would have gone through POL.
Mr Beer: Yes. Were you personally involved in carrying out any of the communications back down to the subpostmaster –
Stephen Parker: I very rarely –
Mr Beer: – in that kind of incidence?
Stephen Parker: In that kind of incident I was not personally.
Mr Beer: Were any of your staff in the SSC involved, “We’re talking with one subpostmaster, we’ve discovered that the bug affects 100 others, let’s, in the SSC, contact the other 100”?
Stephen Parker: No. No.
Mr Beer: That wasn’t part of the SSC’s function?
Stephen Parker: No, it wasn’t.
Mr Beer: What do you know about the process by which those other 100 would be contacted?
Stephen Parker: Very little. I would have expected it to have gone through the Post Office in – I think, in all cases. We wouldn’t phone up a large number of subpostmasters ourselves.
Mr Beer: Do you know anything about a process by which such subpostmasters would be contacted by the Post Office –
Stephen Parker: No.
Mr Beer: – to say “A bug has been discovered, it’s affected your data without your knowledge. A correction has been made without your knowledge”?
Stephen Parker: No, I don’t know about that sort of process, no.
Mr Beer: Thank you, that can come down.
Can we turn to the topic I wanted to ask about which is the process by which Anne Chambers came to give evidence in the Lee Castleton case.
Stephen Parker: Right, yes.
Mr Beer: You know that Mrs Chambers gave evidence in the Lee Castleton trial in 2006?
Stephen Parker: I do, yes.
Mr Beer: What was your involvement in the process that led to her giving evidence?
Stephen Parker: I don’t remember being involved in the process that led to her giving evidence in any substantive way. I may have helped in the provision of some information.
Mr Beer: Information to who?
Stephen Parker: To either Anne or the Post Office. But –
Mr Beer: Information about what?
Stephen Parker: About the issue.
Mr Beer: What was the issue?
Stephen Parker: I don’t remember exactly the history of that particular incident.
Mr Beer: So when you say you may have been involved in giving information about the issue concerning the incident, do you mean information about the subpostmaster, Lee Castleton, and the Marine Drive branch?
Stephen Parker: Yes, I recollect vaguely being asked a few questions about it and filtering those – some of Anne’s answers back.
Mr Beer: Why was Anne Chambers selected to give evidence?
Stephen Parker: Because she was the person who had worked on the problem.
Mr Beer: Was she content to give evidence?
Stephen Parker: No. I mean, she – as I remember, she wasn’t particularly happy about the idea of giving evidence and the situation was somewhat forced on her.
Mr Beer: Who forced it on her?
Stephen Parker: It was internal Fujitsu politics.
Mr Beer: Who were the internal Fujitsu politicians?
Stephen Parker: I would have to refer you to Mik Peach for that. He was manager then and, like, would have been the person who was directly involved in it.
Mr Beer: Why did she not want to give evidence or why was she not content that she should give evidence?
Stephen Parker: My impression, when I had the opportunity to talk to her, was that it was the environment and the stressful nature of the questioning process.
Mr Beer: So was it after the event that you learned that she was unhappy –
Stephen Parker: Yes.
Mr Beer: – rather than beforehand?
Stephen Parker: Fairly sure it was, yes.
Mr Beer: Can we look at a couple of documents, please. POL00070133. Can we look at the foot of the page, please. There’s an email from Mandy Talbot in Royal Mail to Gary Blackburn and others in Royal Mail, and a copy to Stephen Dilley:
“Lynne, further to our chat can you advise what are the names of the postmasters and addresses of the branches if possible of the following FAD codes …
“In February of this year you wrote to Gary Blackburn and he wrote to Shaun Turner and then Sandra MacKay about these branches which had apparently registered complaints about the Horizon System. Fujitsu have told us that in respect of Callendar Square that there was a problem when stock was transferred from one stock unit to another but this would only apply when there was more than one stock unit, ie more than one position at the counter.
“Did any of you find out what the problems were at the other branches and what did POL and Fujitsu do to correct them?”
Can you recall your involvement in the Callendar Square bug?
Stephen Parker: I don’t recall. It was very little.
Mr Beer: Can you recall whether that suggestion there, that the bug would only apply where there was more than one stock unit, ie more than one position at the counter, is accurate or not?
Stephen Parker: No, but I watched Anne’s testimony so I saw what she said about it but that’s why I can recall something now, but only what she said then.
Mr Beer: Okay, and so if I ask you questions about that you’d be replaying to us what you saw Anne say last week?
Stephen Parker: I would, yeah.
Mr Beer: Okay. Can we go to the top of the page, please. It is sent on to you, can you see –
Stephen Parker: I do.
Mr Beer: – by Mandy Talbot on 6 December:
“Steve I have copied you into this email to POL because it may be that you might have to do a repeat performance tomorrow once the FAD codes have been identified and the name of the branches revealed. Incidentally can you identify branches from FAD codes? As, if so, this might give you a head start?”
Can you recall what the repeat performance she was talking about was?
Stephen Parker: I don’t, no.
Mr Beer: Can you recall the context of this, namely Mr Castleton raising the existence of the Callendar Square bug and you and Fujitsu being asked to investigate its extent and the branch that it was said to have affected?
Stephen Parker: Not really, no. No.
Mr Beer: “Stephen and Richard our legal team at the Court will be doing their best to persuade the Court not to allow Castleton [I think that’s Mr Castleton] to call this evidence because it is filed late and does not relate to the problems at his branch office. If they are successful there will be no need to progress any further with these investigations but as Castleton is a litigant in person it is common for Judges to be sympathetic and may allow him to rely on his evidence. If so you will have to pull out all the stops to investigate what, if anything, went wrong at these branches and why we can distinguish them from Mr Castleton at Marine Drive.”
Can you recall what work you did, in fact, do to seek to distinguish what had gone wrong at these other branches and why those problems had not afflicted Mr Castleton at Marine Drive?
Stephen Parker: No, I mean, I suspect that from the date while this was going on, I was acting in some reason as sort of deputy manager while Mik may not have been there and I would have farmed that job out to somebody else to actually do, so I don’t remember what was done.
Mr Beer: Can we see what I think is your reply at POL00070135. If we just look at the foot of the first page and then a bit of the second page, we can see that this is your email, yes?
Stephen Parker: Yes.
Mr Beer: So this is a reply on 6 December. You say:
“Mandy,
“As discussed on the phone today:
“Callendar Square demonstrated a software problem within Horizon. The problem has been present prior to 2004. For an unidentified reason Callendar Square was badly hit by it from September ‘05. Problem was fixed during release S90 of the Horizon software.
“The incidents at Marine Drive show no symptoms of this problem. In particular:
“1) Problem occurred when transferring stock between stock opportunities. Marine Drive had any one stock unit so couldn’t do transfers.”
That’s the point that Mrs Chambers corrected last week.
Stephen Parker: Yes.
Mr Beer: “2) Problem caused an event storm … with specific details. There were none of these at Marine Drive.
“3) Problem caused a receipts and payments mismatch which showed on the cash account. This didn’t happen on Marine Drive.”
For these, did you conduct the investigation to highlight those three points?
Stephen Parker: No.
Mr Beer: Where did you get the information from?
Stephen Parker: I don’t remember who I asked to do it. I would have expected, if Anne was about, I would have probably asked her because of her experience previously with that, with Callendar Square. But I can’t be sure.
Mr Beer: Can we go to the top of the page, please. You’re not copied in on this but Mandy Talbot forwards your email to Stephen Dilley, the Bond Dickinson solicitor; Richard Morgan, Post Office counsel; Dave Hulbert, who I don’t know; and then two others within the Post Office. She says:
“Anne Chambers conducted the analysis for Fujitsu.”
Does that help you recall what the content of your telephone conversation may have been with Mandy Talbot or might she have been talking directly to Anne Chambers?
Stephen Parker: It’s quite possible she was talking directly, but I’m not sure.
Mr Beer: Ms Talbot continues:
“She can give evidence on this. She will not say that no problem has arisen with the Horizon System since Castleton was sacked but will say that no serious problem have been elevated to their team to deal with.”
Dealing with those, was it the case that no serious problems had been elevated to the SSC?
Stephen Parker: I’m assuming that was what was meant there, yes.
Mr Beer: Was it true?
Stephen Parker: I don’t remember.
Mr Beer: “Fujitsu say that this particular software glitch was known about in 2004 and the initial response to a problem by the Helpdesk would usually be to suggest user error …”
Is that correct, the initial response of the Helpdesk was usually to suggest user error?
Stephen Parker: I don’t know what the Helpdesk was saying to the subpostmasters on this issue, unfortunately, sir.
Mr Beer: “… but that if it continued the problem had a pretty firm footprint which could be picked up by Fujitsu. Further that this glitch is limited to counters which have more than one stock unit and as Marine Drive had only one stock unit and the footprint did not appear it cannot explain Castleton’s problems. The glitch would also be observed as a mismatch in the receipts and payments records.
“This particular glitch was known to Fujitsu prior to 2004 and as such it is one of the things which would automatically have been checked for by Fujitsu when conducting their analysis.”
Is that right, when individuals were being either prosecuted or civil proceedings were being taken against them or civil proceedings were being defended, Fujitsu would conduct a series of checks as part of an analysis to see whether that branch was afflicted by known bugs.
Stephen Parker: I believe it was but I didn’t conduct – I didn’t request any of those such things myself.
Mr Beer: Why do you believe that it was?
Stephen Parker: Only because of my experience with what I’ve seen during the High Court cases and things.
Mr Beer: People in your department, would they be involved in conducting this analysis to see whether the branch or the subpostmaster, against whom action was being taken, whether they or their branch were afflicted by any of the known bugs in the system?
Stephen Parker: I believe the process was by then that it would be Gareth Jenkins who was actually presenting the information to court. So we would be in the SSC providing him with the information he required. It would be him who did the analysis, witness statement, et cetera.
Mr Beer: But people in your team would be providing him with the evidence that he would give?
Stephen Parker: We would be providing him with the raw data he asked for, yes.
Mr Beer: Was there a written process which said, “In the event of a criminal investigation, a prosecution or civil proceedings, these are the checks that the SSC must perform”?
Stephen Parker: I wasn’t aware – no, I wasn’t aware of any such documents. I also think it’s worth mentioning at this stage that the data as used in court would have actually come from the audit system via an ARQ request. When the SSC was providing data, this would be for initial analysis purposes.
Mr Beer: So the data that the SSC provided to Mr Jenkins, was that for information only and he wasn’t to use it as the basis to form conclusions – evidential conclusions?
Stephen Parker: Not for evidential conclusions. There was something around the fact that all data that was to be provided for court cases had to come via an ARQ request and audit because there was certain evidential change of evidence rules. I don’t remember the exact details.
Mr Beer: This email continues, skipping a paragraph:
“Steve Parker who conducted the investigation with Anne …”
Did you conduct the investigation with Anne?
Stephen Parker: No, I just think that was Mandy Talbot’s impression because I was involved in the phone calls and things.
Mr Beer: So that’s incorrect?
Stephen Parker: I would say so, yes.
Mr Beer: Was it only Anne Chambers that conducted the investigation?
Stephen Parker: I don’t remember any substantive input on my part, no. So, yes, it would have been Anne.
Mr Beer: To your knowledge, was anyone else involved in the investigation of Lee Castleton and the Marine Drive branch, within the SSC?
Stephen Parker: I don’t remember.
Mr Beer: Can we move forwards, please, to FUJ00138386. Thank you. We’ll see this is another work instruction.
Can I just check the reference, please?
That’s 8367. I’m looking for 8386.
Okay, that doesn’t appear to have been uploaded. I’ll have to skip over those questions.
Can we move, please, to POL00099397. POL00099397.
Sir, those two document are unavailable. I will therefore have to ask any questions of Mr Parker about them if and when he returns on the next occasion to give evidence.
Sir Wyn Williams: All right.
Mr Beer: Sir, those are the only questions I ask.
Thank you, Mr Parker.
I think it’s Mr Jacobs first.
Questioned by Mr Jacobs
Mr Jacobs: Hello, good afternoon, Mr Parker. I represent 156 subpostmasters who instruct Howe+Co and I have two questions for you. Firstly, this morning, Mr Beer asked you about Helpdesk scripts.
Stephen Parker: Mm-hm.
Mr Jacobs: You said they were written by senior technicians.
Stephen Parker: Correct, yes.
Mr Jacobs: What we’re interested to know is are you able to provide the names of those technicians who wrote the scripts?
Stephen Parker: Unfortunately, no. I mean there was number of people within the HSD who were considered more senior that but I very rarely met them so I don’t remember those names, sorry.
Mr Jacobs: Are you able to tell us perhaps someone who might know, so we can ask someone else?
Stephen Parker: The only suggestion I would have on that is the current – well, current – when I was last working for Fujitsu, the service manager for that area at the time was Sandie Bothick.
Mr Jacobs: Sandie?
Stephen Parker: Bothick.
Mr Jacobs: Bothick. Okay, thank you.
Stephen Parker: So she would have been around the HSD at that time.
Mr Jacobs: That’s very helpful, thank you.
The second question is a question you may already have heard because it was a question that Mr Stein put to Mrs Chambers last week –
Stephen Parker: Okay.
Mr Jacobs: – at the end of her evidence and I want to ask you the same question. So the question is: during the evidence of this Inquiry, many of our clients, subpostmasters and subpostmistresses, said that their accounts, their branch accounts never seemed to balance.
Examples are Janice Adams said that her branch accounts didn’t balance and shortfalls occurred on a weekly basis, and the weekly deficit was usually about £50 but higher on occasions, and she said she used to put these accounts routinely into the system in cash in order to continue to trade the next day.
Mujahid Faisal Aziz says similarly that there were many small shortfalls. He would estimate on average £50 to £80 shortfalls per week, which they always made good straightaway, again by paying cash. Edward Brown said that similar matters occurred to him and it wasn’t always a large shortfall but sometimes it could be in the thousands. Gary Brown reported that the shortfalls happened so often that it was hard to keep track.
Now a question for you is: can you help us understand how it was that the subpostmasters and mistresses experienced so many shortfalls?
Stephen Parker: No, I’m afraid I can’t, without an investigation of each of their issues, because there were a number of different possibilities there. So no, I mean, I can’t explain why a large number of your clients have those issues.
Mr Jacobs: Again, looking at the same point, would there be anybody else who you worked with who might be able to throw some light on this, if you can’t answer the question?
Stephen Parker: I can’t think of anybody relevant for that particular thing, sorry.
Mr Jacobs: That’s fine. Thank you very much. I haven’t any more questions.
Questioned by Ms Page
Ms Page: Hello, I’d like to ask some questions about the overnight processes for checking for system errors.
Stephen Parker: Okay, yes.
Ms Page: I understand that the program Tiscali was involved in that, is that right?
Stephen Parker: Not aware of that name.
Ms Page: No? Is it right that there were automated processes that checked across the estate for system problems?
Stephen Parker: Yes.
Ms Page: Would some of the system events appear on what’s called the NT Event Log?
Stephen Parker: Yes, that would be one place where problems or notable events would be written, yes.
Ms Page: Is it right that some of them were particularly on the radar, as it were? At any given time, there might be a reason why you’d be looking out for particular system events that might have come up overnight?
Stephen Parker: Yes, that would be true, yes.
Ms Page: Is it right that you’d look on the event logs for that, perhaps the NT Event Log, but perhaps there were other ones as well?
Stephen Parker: That wouldn’t be a function the SSC would have performed, but yes. I mean, probably the name we were trying to get to earlier was Tivoli, and that would have been a function performed by the estate management team. So they would have been looking out for events of a certain nature and, if necessary, then raising incidents.
Ms Page: So if they raised an incident that meant it would come through to SSC; is that right?
Stephen Parker: Potentially, but it may have been an event which indicated something which a different team needed to see. So it wouldn’t necessarily always be SSC.
Ms Page: If it was one that they knew was on the SSC radar –
Stephen Parker: Yes.
Ms Page: – then it would come through to you; is that right?
Stephen Parker: It would do, yeah.
Ms Page: This may or may not still ring a bell – but does an event which said the hard disk has a bad block, does that ring a bell?
Stephen Parker: It does. That would be in the Legacy days generally because that was when incidents of hard disk error actually caused problems with the Riposte messaging software.
Ms Page: Right. So if you got that, it might mean that there was problems with the messages?
Stephen Parker: It might do, yes. I mean, it wouldn’t always do but it’s one of those –
Ms Page: Would that mean that would be a reason to flag it for the SSC?
Stephen Parker: It would, yes.
Ms Page: Yes, I see. If we see that and we then see the SSC doing a remote reboot, would that be to try to fix that?
Stephen Parker: I would have thought a remote reboot would have been done by the event management team rather than us but that would be an attempt to fix that, yes.
Ms Page: How did SSC go about doing a remote reboot, if I can just try to understand that?
Stephen Parker: This is why I said it would be the event management team. I believe a remote reboot was effected by a Tivoli script being fired at the counter. So the SSC didn’t use Tivoli scripts. This was departments like VSMC who would have effected that.
Ms Page: So a Tivoli script can be used to do that and, in the case of a bad block, that would be an attempt to restore messages on the hard drive?
Stephen Parker: It wouldn’t be an attempt to restore messages. Generally, if I remember correctly, if you – to reboot – if you rebooted after a bad block, it would trigger part of the Windows NT operating system to actually try to repair the disk and I believe that was why it was done but we are out of my technical expertise, there, really.
Ms Page: Well, that’s very helpful. Is that likely, then, it might well tie in to SMC doing something with replacing hardware if it failed?
Stephen Parker: Yes, it would, yeah.
Ms Page: Thank you, those are my questions.
Mr Beer: Sir, just before you release Mr Parker, I wonder whether I could ask for your indulgence. The error in the two documents not being available to display is entirely my fault, and nothing to do with the hardworking team that sits behind me. Could I ask you just to rise for five minutes, please. We might be able to sort it out.
The questions that I have to ask are less than ten minutes and, just in case we don’t call Mr Parker back in Phase 5, it would be an advantage to him and to us if we got the questions out of the way now.
Sir Brian Langstaff: Yes, by all means. Certainly.
Mr Beer: We’ll let you know when we’re ready, but I imagine it’ll be five minutes.
Sir Wyn Williams: What I’ll do is I’ll stay close to my monitor. I’ll actually switch the video off but I won’t leave the room, so that you can just speak to me and I’ll come back to life immediately.
Mr Beer: Thank you, sir.
Sir Wyn Williams: Fine.
(3.52 pm)
(A short break)
(3.55 pm)
Mr Beer: Can you see and hear us?
Sir Wyn Williams: Yes, I can.
Mr Beer: Thank you very much. Apologies for that once more, and apologies to you, Mr Parker.
Further Questioned by Mr Beer
Mr Beer: Can we look at FUJ0013186, which is on the screen.
You’ll see that it’s a work instruction written by you on 8 September 2011. The title of it is “Providing evidence for police or litigation enquiries”. It’s version 11, and was last updated by Mr Woodley in August 2021. Details:
“Any request for evidence supporting any form of litigation must be made via a defined route. That route is from the security department in POL to the Fraud and Litigation service within the CSPOA Security team. This is the only route that can be used for evidential purposes because the data handling conforms to the required legal rules for evidence.
“CSPOA Security will make contact with the police and if necessary with POL lawyers. CSPOA Security team may request that SSC staff provide some technical input to the process. CSPOA Security do not notify POL as to who provides input into their general processes. They have confirmed that no member of SSC will be required to raise and sign any statements of witness as to their activity in such matters and nor will any pressure be brought to bear on SSC staff to do so. If a request is made for a statement of witness you should immediately inform the SSC duty manager.”
Then there’s something about physical hardware that I’m not going to read.
Why were you writing a work instruction in September 2011 about the provision of evidence to the police, or to POL?
Stephen Parker: It must have been because it became clear to me that requests of this sort were being made without coming from the CS security team and, as I say there, that was the approved route and the only one which should be used for those purposes.
Mr Beer: Can you recall what had happened, what event justified the writing of this work instruction?
Stephen Parker: No. Only that some sort of event of that type must have happened to trigger me to make things hopefully crystal clear.
Mr Beer: You see it refers in its body to the CSPOA Security team, and CSPOA Security, yes?
Stephen Parker: Yes, indeed.
Mr Beer: And that it refers to the Fraud and Litigation service within the CSPOA Security team. For how long had the Fraud and Litigation service within the CSPOA existed at the time that you wrote this, or is that a later author’s work?
Stephen Parker: I think the Fraud and Litigation service responsibility that the CSPOA Security team had always been there. I don’t remember it being something new. It was the means by which evidence could be obtained and that was going on while I was both the SSC manager and previously.
Mr Beer: You see it’s got a capital “F” and capital “L” –
Stephen Parker: Yes, indeed.
Mr Beer: – on “Fraud and Litigation”, which might suggest a title to a suborganisation within CSPOA Security team. Am I right to draw that from it or is that just a function that’s being described, namely Fraud and Litigation service provision?
Stephen Parker: I can’t be sure if somebody has changed it afterwards. During my time, it was a function rather than a separate service.
Mr Beer: We’ve heard from somebody called Andy Dunks. Did he work in that team?
Stephen Parker: He did, yes.
Mr Beer: The work instruction says:
“This is the only route that can be used for evidential purposes because the data handling conforms to the required legal rules for evidence.”
Can you explain what that sentence is meant to mean?
Stephen Parker: Only the face value that it gives you there. I mean, I’m not – I wasn’t in any way involved with that process from – for the CSPOA Security team. I was just aware that it had to be done that way.
Mr Beer: What had the requirement that there be a single route got to do with what are described as the “legal rules of evidence”?
Stephen Parker: That was a – those words would have – or that requirement would have been given to me, rather than me understanding it and making it up.
Mr Beer: Was the concern about exhibit or physical security of evidence being passed from one person to another to ensure continuity, for example?
Stephen Parker: I remember brief discussions about continuity of evidence and evidential requirements and just being told, “Look, this is the way it has to happen”.
Mr Beer: Or was it because the maker of the request from within the security team would know what those legal rules of evidence were?
Stephen Parker: I would expect them to, yes.
Mr Beer: But I’m trying to discover what the requirement that this single route had as its raison d’etre; would it be because you needed to secure continuity or was it because the person making the request is in the know on legal rules of evidence and therefore any requests should come from them?
Stephen Parker: It was the former in that we were – I was trying to ensure that the correct evidential rules were followed by the team who actually knew what those rules were.
Mr Beer: Was there any document that you were aware of in your time in the SSC that set out the legal rules for evidence to guide the SSC in the provision of evidence?
Stephen Parker: No.
Mr Beer: The document continues:
“They [that’s Security] have confirmed that no member of SSC will be required to raise and sign any statement as to their activity in such matters, and nor will any pressure be brought to bear on SSC staff to do so.”
In the past, had the security team required SSC staff to provide a witness statement?
Stephen Parker: That was – this was a reflection on the situation for Anne Chambers, where she was required to provide a witness statement, and that resulted in a court appearance which she found stressful, and this was a way of trying to alleviate the fears of other SSC staff that they would be put into the same position.
Mr Beer: But five years had elapsed –
Stephen Parker: Mm.
Mr Beer: – between the Castleton case and this work instruction. What prompted, after that five-year period passing, you to return to this issue?
Stephen Parker: There must have been a litigation query or something which came in via the wrong route.
Mr Beer: I mean, presumably the security team had required SSC staff to provide a witness statement, otherwise the record of a guarantee that they wouldn’t would be unnecessary?
Stephen Parker: That may have been the case. All I can remember is something definitely happened to trigger me actually writing it, to attempt to (a) define the route clearly and (b) put SSC staff’s mind at rest that they wouldn’t find themselves in a courtroom for just helping the security team with a few bits of advice and guidance.
Mr Beer: I’m trying to discover what the trigger was, given the only one we’ve identified happened five years before this document was written.
Stephen Parker: Sorry, I don’t know.
Mr Beer: In the past, had the security team brought pressure to bear on SSC staff to provide a witness statement?
Stephen Parker: Not during my tenure. I don’t remember that going on. I do remember the situation with Anne Chambers and Mik but that’s the only one I clearly remember.
Mr Beer: Thank you. Can we move to the second document, please. POL00099397. This is an email exchange involving you in 2013. Can we pick it up at the bottom of page 3, please.
If we look at the bottom of this page, please, we can see an email from Andrew Winn to you of 16 July 2013 at 16.01:
“Hi Steve
“Would you be able to assist with this one? I’ve been trying for months to get the referral info from the raw logs as per Gareth’s advice without success.
“Ironically I have had a subsequent challenge from [some details are given]. Is this something that can be relatively easily pulled within the 6 month window when detailed data moves into archive?
“Appreciate any help.”
Then you reply at the bottom of page 2, please:
“Andy,
“Initial information on Gilmerton … shows that the transaction was a referral. Still working.”
Then you put a note.
“NOTE: not trying to teach you to suck eggs but thought I’d remind you that none of the information we dig out for you like this can be used in litigation. Anything required for evidential purposes MUST come from the litigation support team.”
So does that reflect the work instruction that you had raised a couple of years earlier?
Stephen Parker: It does, yes.
Mr Beer: Why were you including that warning to Mr Winn?
Stephen Parker: Reminder only. I mean, I wasn’t sure how Andy intended to use the information he was asking me for.
Mr Beer: Then if we scroll up, please.
“I think that is all I need. It is all I would pull if it was within 3 months.
“Good point about litigation. I am aware that any evidence we put in front of a court must come through the right channel. I am dealing well before this point but have to be aware that any case may end up in court. I will typically say something like ‘I’ve asked Fujitsu to investigate and they have confirmed that a referral was made to your Horizon System …’ So something like that might get waved around in court but the transactional data presented would need to come through approved channels.”
Then if we look at your reply at the foot of page 1. It’s at the foot of the page now, “The litigation bit”, thank you:
“The litigation bit is all to do with chain of evidence for prosecutions and delivery in court. I’m sensitive about it because in the distant past one of my [colleagues] was ‘persuaded’ (by our side, not yours) to write an evidence statement without fully understanding the implications. As you know, our ‘professional witness’ for these types of cases is Gareth Jenkins but in this case, because process was not followed, Gareth couldn’t do it and preparation for court became very difficult.”
Is that paragraph a reference to Anne Chambers and the Lee Castleton case?
Stephen Parker: It is, yes.
Mr Beer: You say:
“In the distant past one of my team was ‘persuaded’ (by our side, not yours) …”
You’re here corresponding with Andy Winn of the Post Office?
Stephen Parker: Correct.
Mr Beer: So “our side” means Fujitsu, “your side” means Post Office?
Stephen Parker: It does, yes.
Mr Beer: Who in your side had persuaded Anne Chambers to give evidence?
Stephen Parker: I don’t remember the name. It was the – somebody in the security team but, again, you’d have to ask Mik Peach. I mean, he was privy to that. I wasn’t.
Mr Beer: You say that:
“[She was persuaded] to write an evidence statement without fully understanding the implications.”
What were the implications that she didn’t fully understand, to your knowledge?
Stephen Parker: That was the implication of having to actually stand up in court and face some questioning.
Mr Beer: So your understanding was she didn’t know that if you provided a witness statement, you might have to come along in court and speak to it?
Stephen Parker: I don’t think that was made clear. That was my understanding but my knowledge of this is coming secondhand from Mik in majority, apart from the odd time that I talked to Anne about it at the time.
Mr Beer: You continue:
“As you know our ‘professional witness’ for these types of cases is Gareth Jenkins but in this case, because process was not followed, Gareth couldn’t do it and preparation for court became very difficult.”
What was the process that ought to have been followed but which was not followed?
Stephen Parker: I don’t remember and I find that sentence strange because my recollection is that Gareth Jenkins started fulfilling that role after Anne Chambers found herself having to give a witness statement. So I can’t think now why I made that statement.
Mr Beer: That’s what I’m exploring with you. Why was it that in the Lee Castleton case Mr Jenkins couldn’t do it because process wasn’t followed?
Stephen Parker: I don’t remember, and that would have been, as I say, Mik, I should think, doing that at that time.
Mr Beer: In what way did preparation for court become very difficult?
Stephen Parker: I don’t remember.
Mr Beer: Can you think back and try to assist us?
Stephen Parker: Yeah, I’d like to but most of my knowledge about what happened in that situation came either from Mik or Anne, in conversations I had with them. I didn’t actually – I wasn’t actually there, taking part. So sorry, I just don’t remember.
Mr Beer: Thank you very much, Mr Parker.
Sir, those are all the questions that I ask.
Sir Wyn Williams: Right.
Well, thank you, Mr Parker, for coming to give evidence and thank you for making a witness statement. It’s possible, as you’ve heard, that you’ll be asked to return, probably in some months’ time, if you are asked to return and, if you are asked to return, a request for information, a Rule 9 Request, will be sent to you so that you know what it is that you have to address your mind to. All right?
The Witness: Understood, yes.
Sir Wyn Williams: So thank you again.
Mr Beer: 10.00 am tomorrow for Mr Ismay.
Sir Wyn Williams: Fine. 10.00 tomorrow.
(4.14 pm)
(The hearing adjourned until 10.00 am the following day)