FUJ00155523 - ICL Pathway Audit Trail Functional Specification version 4.0.

Evidence on official site

FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

Document Title:

Document Type:

Abstract:

Distribution:

Document Status:

Document Predecessor:

Associated Documents:

Author:

Approval Authority:

Signature/Date:

Comments To:

Comments By:

Audit Trail Functional Specification

Functional requirements specification

This document provides a specification of the Audit Trail in
accordance with R699.

Pathway Requirements
Pathway Audit
Pathway Design
Horizon Library
Pathway Library

Issued

Version 4.0

See below

JC C Dicks/ Jan Holmes

JCC Dicks

Author, Jan Holmes

ASAP

© 2000 ICL Pathway Ltd

COMMERCIAL IN CONFIDENCE Page 1 of 29
FUJ00155523

FUJ00155523
ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00
0 Document control
0.1 Document history

Version [Date [Reason

1.0 17/9/96 [Externally published

1.4 8/10/96 [Revised for BA Audit and Pathway comments

4.2 31/1/97 Revised for POCL comments and for review towards a definitive version
2.0.

2.0 19/2/97 Revised for further comments. Definitive

2.1 19/5/97 [Revised for further comments from DSS, alignment with Access Control
Policy Version 1.0, and for review towards a further definitive version 3.0

2.2 8/9/97 Revised in response to implementation questions and further comments
from DSS/POCL. Further review towards a further definitive version 3.0

2.3 20/10/97 Revised for comments received during Acceptance Specification
\discussions and implementation progress

2.4 5/2/99 Revised to extend definition to Commercial Audit Trail and to address
[Horizon comments dated 1/12/98.

2.5 9/3/99 Further comments received 23/2/99

2.6 9/4/99 (Changes agreed at Acceptance Review 30/3/99

2.7 26/4/99 (Changes agreed at post Acceptance Review Audit Panel meeting 22/4/99

2.8 (09/06/99 Removing references to DSS/BA following their withdrawal from the
contract

2.9 24/06/99 [Following comments received from POIA.

3.0 (01/07/99 _ Raised to definitive. CCN423

3.1 10/11/99 Insertion of previously missing commercial audit trail details following
IDSS/BA withdrawal from contract

4.0 Raised to definitive. CCN

4.1 110/04/00 _IIntroduction of Logitics Feeder Service (LFS), Change of name - RED :>
BIMS

0.2 Approval authorities

Name Position Signature Date

IM. Bennett Director Quality & Risk

0.3 Associated documents

COMMERCIAL IN CONFIDENCE Page 2 of 29
FUJ00155523

FUJ00155523
ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00
Version [Date [Title jSource
2.0 24/2/98 (Access Control Policy Pathway
0.4 (09/02/98 [Host Application Database Design and Interface Standards Pathway
3.0 [3/12/97 ‘Security Functional Specification [Pathway
4.0 }30/9/97 Service Architecture Design Document Pathway
tba [Horizon System Audit Manual [Pathway
5.0 Schedules AO3 IPOCL
0.4 Terms and Abbreviations

Acronym leaning

(ACD (Automated Call Distribution

(ADS \Advanced Distribution Systems

AP IAutomated Payment

APS JAP Service

BIMS Business Incident Management System

IDLT Digital Linear Tape

IEPOS Electronic Point of Sale

IEPOSS IEPOSS Service

IESNCS Electronic Stop Notice Control Service

LFS Logistics Feeder Service

IHSAM [Horizon System Audit Manual

IM Inventory Management

ISDN integrated Services Digital Network

OAS IOBCS Access Service

(OBCS \Order Book Control Service

(OPS. \Office Platform Service

IRD Reference Data

Rann Requirement number

SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung AG, German softwareI

manufacturer

ISIS Strategic Infrastructure Service
\TIP ITransaction Information Processing
[TMS ITransaction Management Service

COMMERCIAL IN CONFIDENCE Page 3 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

0.5
0.5.1

0.5.2

0.5.3

0.5.4

0.5.5

0.5.6

0.5.7

0.5.8

0.5.9

0.5.10

0.5.11

0.5.12

0.5.13

0.5.14

Change History
Changes Between 4.0 And 4.1

Introduction of Logistics Feeder Service details.
Changes Between 3.1 And 4.0

No changes made. Version number increased.
Changes Between 3.0 And 3.1

Revised schematic for Invoicing procedure.
Changes Between 2.9 And 3.0

No changes made. Version number increased.
Changes Between 2.8 And 2.9

Minor amendments following feedback from POIA including a_ revised
Commercial Audit Trail section on Invoicing.

Changes Between 2.7 And 2.8

Major Surgery to remove all references to DSS and/or BA and their associated
requirements following the withdrawal of the Benefit Payment Card from
Horizon.

Changes Between 2.6 And 2.7

Minor addition around caveats section to Commercial Audit Trail.

Changes Between 2.5 And 2.6

Changes agreed at the Acceptance Review of 30/3/99 have been incorporated.
Changes Between 2.4 And 2.5

Horizon comments dated 23/2/99 have been factored in.

Changes Between 2.3 And 2.4

Horizon comments dated 1/12/98 have been factored in.

Changes Between Version 2.2 And 2.3

A general overhaul to reflect agreements made in the course of Acceptance
Specification negotiations and during design and development.

Changes Between Version 2.1 And 2.2

PDA comments dated 19 June have been factored in: defining the mainstream
operational Services; extending the list of keys.

Minor clarifications.

Changes Between Version 2.0 And 2.1

A further set of comments from POCL and DSS have been addressed.

A number of clarifications and corrections have been made.

Changes Between Version 1.2 And 2.0

A further consolidated set of DSS and POCL comments have been addressed.

COMMERCIAL IN CONFIDENCE Page 4 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

0.5.15

0.5.16

Changes Between Version 1.1 And 1.2
Two sets of comments from POCL have been addressed.
OBCS has been added following the ordering of the service.

Inclusion of raw data from CMS/PAS Help Desk ACDs and the CMS Card
Production Interface.

Inclusion of raw data from Horizon Help Desk ACDs.

The requirement texts have been removed pending availability of Version 6 of
the agreements (in preparation).

Changes Between Version 1.0 And 1.1

Clarification of meaning of Pathway native flat formats and removal of
immediate dependencies on particular audit authority flat file formats.

Correction to process of record deletions.

COMMERCIAL IN CONFIDENCE Page 5 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

0.4 Table of content

Introduction
1.1Auditor’s Eye View.
1.1.1Scope..
1.1.2The Total Mainstream PATHWAY Solution.
1.1.3The Strategic Infrastructure Service...
1.1.4The POCL <DSS> Client
1.1.50ther POCL Clients.
1.2Audit Trail Responsibilities and Usage.............
1.2.1Responsibilities.
1.2.2Principals, Agents And Rights Of Access.
1.2.3Access controls.
1.2.4POCL usage..
1.2.5POCL Client Usage
1.2.6Audit trail formats.
1.2.7Audit trail retention periods.
2The Audit Tracks...
2.1POCL SIS Audit Track.
2.1.1POCL SIS Track Content And Maintenanc
2.1.2Audit Access to the POCL SIS Track.
2.1.3Auditor Utilities..............
2.2Systems Management Track.

2.2.1Systems Management Track Content and Maintenance.

2.2.2Audit Access to the Systems Management Track.
3The Commercial Audit Trail

3.1Magnetic Records.
3.1.1Business Incident Management system (BIMS:
3.1.2Service Level Contract Administration (SLCA).
3.2Manual Records
3.2.1Included Items
3.2.2Excluded Items
3.2. 3CAVEAS..... eee eeeeeeeeeeteeeee

COMMERCIAL IN CONFIDENCE Page 6 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

Introduction

Auditor’s Eye View

Scope

This functional specification defines the operational and commercial audit trails.
These are, respectively, the audit trail associated with the operation of the
services which make up the Pathway solution and the audit trail associated with
that part of Pathway’s internal commercial records to which POCL’s Internal
Auditors or Agents as set out in Schedule A03 may have access.

The operational audit trail includes that generated by the mainstream
operational services and the Business Incident Management System (BIMS).

The mainstream operational services are the services making up the POCL
Steady State Services :

>» Automated Payment Service (APS)
>» EPOS Service (EPOSS)

> Order Book Control Service (OBCS)
» Logistics Feeder Service (LFS)

» POCL Infrastructure Services

The BIMS provides an auxiliary audit trail which separately covers the treatment
of exceptions encountered within the mainstream operational services. The
audit trail associated with the mainstream services is never modified for the
purposes of correction as such.

This specification also addresses in Section 3 certain requirements, particularly
R697, which relate to access by POCL’s commercial auditors to parts of
Pathway’s own internal records and systems. These latter requirements are
met through the definition and use of a commercial audit trial and associated
audit procedure providing for access from within Pathway.

The operational audit trail is retained for 18 months. The commercial audit trail
is retained for seven years although some records are held for the life of the
contract, which may be longer than seven years.

If the technology used to hold elements of the audit trail becomes obsolete then
they will be copied to the new technology to maintain continuity of access.

COMMERCIAL IN CONFIDENCE Page 7 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

The Total Mainstream PATHWAY Solution

From the standpoint of the auditor, the total mainstream solution, including both
the Pathway sub-systems and the source and sink subsystems, is shown in
Figure A. The arrows represent the subsystem interfaces at which key
auditable events occur. Pathway’s responsibilities extend to the subsystems
coloured green (darker) and the interfaces coloured blue (darker).

(POCL)

Figure A: Subsystems and principal interfaces

In addition, but not shown, are the Systems Management facilities that Pathway
employs in the course of operating the hardware and software and
telecommunications platforms themselves.

COMMERCIAL IN CONFIDENCE Page 8 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

1.1.3 The Strategic Infrastructure Service
The Strategic Infrastructure Service (SIS) can be analysed as a number of
“visible” counter applications to which the post office clerks interface:
>» EPOS Service (EPOSS)
>» Automated Payment Service (APS)
>» Order Book Control Service (OBCS)
» Logistics Feeder Service (LFS)
running on an “invisible” middleware messaging transport system:
>» Transaction Management Service (TMS)

in turn supported by an operating platform distributed across a Wide Area
Network containing:

» Instance of the Office Platform Service (OPS) in each outlet
> Central servers

Figure B: Principal components of the Strategic Infrastructure Service

The SIS also contains a telephony interface to callers and interfaces to Systems
Management functions (not illustrated).

Figure B shows the SIS components with the same interfaces remapped
appropriately.

COMMERCIAL IN CONFIDENCE Page 9 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

1.1.4 The POCL <DSS> Client

The distributed POCL Client representing the DSS back-end system is shown at
the component level in Figure C.

ESNCS
Ae
s

Figure C: Components of the POCL <DSS> Client

It comprises a single, large-scale database Order Book Control Service (OBCS)
interfacing across a Wide Area Network through the OBCS Access Service
(OAS) to the DSS Electronic Stop Notice Control System (ESNCS).

COMMERCIAL IN CONFIDENCE Page 10 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

1.1.5.1

Other POCL Clients

Figure D shows the relationship between the SIS and other POCL Client
systems. These client systems comprise both those which belong to the POCL
organisation itself and those which belong to POCL’s commercial Clients, such
as utilities.

Figure D: Other POCL Clients
POCL In-house Systems

The POCL in-house systems which interface to the Pathway SIS are:

> Reference Data

> Transaction Information Processing (TIP)

>» SAP Advanced Distribution System (ADS) for inventory management (IM)
> Farnborough Host for AP

The TIP system is batch-oriented, receiving large-scale files of the outlets’
transactions. These comprise daily transactions, weekly (normally) stock
holdings and a cash account, daily AP Client summaries and daily BA
transaction reconciliation reports.

The stock and cash account files are also produced within each office on paper.
These signed paper records will, foreseeably, represent the fiduciary record of
the outlet’s business.

The Reference Data system is responsible for supplying transaction steering
data to Pathway. This data describes the relationships and properties of the
data to be processed (typing of regions, POCL organisations, outlets, Clients,
items for sale, methods of payment, and transaction tokens); and the
processing methods (processing and validation rules, check digits, calendars,
accounting collation sequences, tax tables).

COMMERCIAL IN CONFIDENCE Page 11 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

1.1.5.2

1.2

1.2.1
1.2.1.1

1.2.1.2

ADS is an on-line system but with a same-day level of response time. It
handles orders, secure stock returns, transfers and secure stock inventories,
providing for central control interfacing with Pathway’s Logistics Feeder Service
(LFS)

Initially traffic associated with POCL’s Automated Payment Clients is
consolidated to a single interface with an in-house POCL system, the
Farnborough AP Host. Later these Clients will have direct interfaces to the
Pathway SIS for receiving files of payment records.

POCL Client Systems

This level of specification does not define the audit facilities to be made
available to the audit departments of POCL’s Automated Payment commercial
Clients. These facilities will be negotiated between POCL and the Client as part
of the AP Migration Plan Interface specification for each Client. Pathway
expects that these Clients will use the same methods as are used for the
Farnborough host. It has been decided by POCL that such Client systems will
NOT access the Pathway SIS directly to provide customer and payment scheme
reference data (transaction steering data). Such data will be passed through
the POCL Reference Data system.

Audit Trail Responsibilities and Usage

Responsibilities
Tracks and Trails

In the description below use is made of the terms audit track and audit trail. An
audit track is a record of activities made within a Pathway subsystem for one or
more of its interfaces. An audit trail is one or more such tracks. The data
recorded in a trail’s several tracks may represent the treatment of related
transfers and processing.

In general it is possible to produce an audit track for an interface on either side
of that interface, or, if the interface is itself problematic, on both sides.

It is of course a matter for POCL and POCL Clients to produce their own audit
tracks on their sides of the interfaces to Pathway.

TWO Tracks

The Pathway audit trail is based upon files representing the single main audit
track representing the traffic running through the Pathway solution, the POCL
SIS. This system is Pathway’s operational responsibility and its operating
interfaces are also under Pathway control.

As discussed above, a second audit track represents the systems management
operation of the Pathway system itself.

COMMERCIAL IN CONFIDENCE Page 12 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

1.2.2

1.2.3

1.2.4

1.2.5

Principals, Agents And Rights Of Access

A particular audit may be carried out by an Agent for POCL or by POCL
themselves. The Agents that are permitted are defined in Schedule A03.

Pathway provides for rights of access for individual roles and enforces these
tights of access. Changes to these rights is via Change Control.

Access controls

Access controls are effected through the use of roles.

There are THREE auditor roles: POCL Emergency Manager/auditor, POCL
auditor and POCL Client <C> auditor. It may not be necessary to represent the
POCL Emergency Manager/auditor and POCL auditor separately.

The POCL auditor roles are further defined in the HSAM.

The POCL Emergency Manager/auditor has the same access rights as that of
the Manager or Postmaster. In addition, he may delete and create a
Manager/Postmaster Role, and produce a cash account. Access as POCL
Emergency Manager/auditor is via initial access as POCL auditor then, if
required, as in the case of the Manager or Postmaster being unavailable, a
further exchange via the Horizon Help Desk to obtain a one-shot password
which enables the additional Emergency Manager/auditor operations and a key
reference which turns on the filestore encryption/decryption.

POCL Emergency Manager/auditor and POCL auditor have access to all TMS
journal records.

The POCL auditor has no rights to modify the TMS journal. The POCL
Emergency Manager/auditor is not able to modify the TMS journal, except as
the auditable result of permitted operations in connection with his role as an
Emergency Manager. In common with all journal updates, such permitted
modifications are always in the form of appends.

The POCL Client <C> auditor role when implemented will have access only to
that part of the TMS journal which deals with transactions pertaining to that
Client and in accordance with the Client organisation’s contract with POCL. The
POCL Client <C> auditors have no rights to modify the TMS journal.

The POCL Emergency Manager/auditor has access only at the outlet. The
POCL auditor has access at both the outlet and the centre. All access at the
centre is via the Pathway audit function.

POCL usage

POCL Audit functions has access to the POCL SIS audit track and the Systems
Management track
POCL Client Usage

POCL Client Audit functions will have access to the POCL SIS track (subject to
paragraph 1.2.2 above)

COMMERCIAL IN CONFIDENCE Page 13 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

1.2.6

1.2.6.1

1.2.6.2

1.2.7

2.1

Audit trail formats
Native Formats

The principle followed is that Pathway originates the audit track source data in
self-describing flat files.

The format in which the TMS journal is written by Pathway operational software
is that used as input to the utilities which prepare the bulk extracts for the audit
authorities. That is, the Pathway native flat format is the operational format.
This format is attribute grammar (keyword and value) format and is therefore
self-describing at the field level. Subsets of the TMS journal represent the data
transferred to TIP, Farnborough AP, Andover AP, ADS and POCL Clients, and
from RD, ADS, possibly POCL Clients.

The native format of the flat files containing the data transferred between
subsystems is described in file headers. They are therefore self-describing at
the file level. See Host Application Database Design and Interface Standards.

The logs of file transfers (control files) are in one simple format.
Custom Formats

The TMS journal native flat format is not to be further transformed.

Custom formats for other audit files may be specified at a later level of
specification.

Transfer is either downloaded from disk or by CDROM.

As a principle, the less transformation the better, since this preserves more of
the original raw data and removes the need to qualify and maintain transforming
software.

Audit trail retention periods

R699 states : “Subject to Clause 801 of the Related Agreements, audit trail
records shall be retained for a period consistent with Companies Act
requirements, or for a period of eighteen (18) months, whichever is longer.”
The records described in this document are not subject to the provisions of the
Companies Act. Clause 801 refers to Records which correspond to the
commercial audit trail. A general retention period of 18 months is required for
the operational audit trail. See also R816 and R914.

R829, which deals with Prosecution Support, requires Audit Trail and other
information may be retained for potentially longer periods.

Of course, certain archived data such as EPOSS administration functions,
which contain dated internal references, will itself have an implied longevity of
more than 18 months.

The Audit Tracks

POCL SIS Audit Track

COMMERCIAL IN CONFIDENCE Page 14 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

U

Figure E: The POCL SIS track

2.1.1 POCL SIS Track Content And Maintenance

The POCL SIS audit track comprises:

> the TMS journal

and those POCL files exchanged between the Pathway data centres:

>» the POCL Horizon Help Desk files

>» POCL’s own systems’ files

> AP Client files

Any other intermediate file or table constructs do not form part of the track.
2.1.1.1 TMS Journal

The audit archive of the TMS journal is taken daily at the correspondence

server level by copying all new messages that day to Digital Linear Tape (DLT)
audit archive media."

The TMS journal comprises records appended to the journal of each outlet
within a messaging group usually in time sequence. Each group includes
correspondence servers which hold a replica of the outlet. The outlet replica(s)
of the journal are housekept from the front periodically to maintain a recent
history to cover at least three cash account periods. The correspondence
servers’ replicas are similarly housekept.

The TMS journal contains the original transaction details, including its origin,
when it happened, who caused it to happen, and the outcome.

2.1.1.2 Horizon Help Desk

The POCL Horizon Help Desk files contain the call records from the Automated
Call Distribution (ACD) system. These are written during operation and

' This represents an improved implementation. By this method the audit trail is
always up to date and in one place.

COMMERCIAL IN CONFIDENCE Page 15 of 29

FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

2.1.1.3

2.1.1.4

2.1.1.5

harvested daily into a flat file. A control file will be written for each such daily
file.

POCL Systems

These comprise:

> Those at the TIP, RD, Andover AP and ADS interfaces holding control
records describing files being transferred

>» There is no systematic value in holding separate audit copies of the raw data
transferred across these interfaces with TMS because this is what the TMS
journal itself represents and because the TIP, Farnborough AP and ADS
transfers are selective extracts of it.

AP Client Systems

These are to be defined at later levels of specification. The expectation is that
these will correspond to those for POCL Systems.

POCL <DSS> Client

The specific DSS element of the POCL Audit Track comprises the following
files outside the Pathway boundary :

> that at OAS with ESNCS

and within the boundary :

» that at OBCS

> with TMS

Any other intermediate file and table constructs do not form part of the track.
OBCS

This comprises:

» the Control Notice updates table for access by the OBCS TMS Loader
Agent, and:

> OBCS transactions, comprising encashment transactions and totals table
received from the OBCS TMS Harvester Agent

The data used to represent these are the serial files transferred to and from
OAS.

An audit control file provides as a permanent record of all files received and
transferred by OAS.

This file is kept permanently on-line within OAS(VME). It is also transferred in its
entirety to the ICL Pathway Sequent as part of the daily housekeeping process.

Audit Access to the POCL SIS Track

Logical audit access will be provided as follows:

COMMERCIAL IN CONFIDENCE Page 16 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

2.1.2.1

2.1.2.2

2.1.2.3

TMS Journal Access at the Outlet

Views of the transactions which have taken place within a whole post office
during the recent past are available from any counter or back office position
within a post office, subject to the auditor himself having appropriate access
rights. This recent past period for which transaction records will remain at any
workstation in the post office varies inversely with the traffic conducted by that
office as a whole, but is not less than the current and two previous cash
account periods, such periods being typically a week. The term “transactions”
here embraces both the serving of customers and EPOSS administration
events. The journal is also used to carry certain Pathway control sequences.
These are of no intrinsic interest to auditors but their retention within the
message numbering means that auditors can be sure there are no missing
records?.

TMS Journal Access at the Correspondence Servers

Equivalent TMS journal data is maintained at each of the two Pathway central
services sites. These are not copies one of the other but are independently
derived from the same original data by the same systems. They will therefore
provide a natural point of systematic reconciliation: for example, on a sample
basis it is possible to compare the audit track record of the same transaction
recorded in two places to verify that systems were operating consistently.

Audit records are written to DLT audit archive media. They are presented in
exactly the same way as recent records when retrieved although will be subject
to filters appropriate to the selection and the audit authority for which the
selection is being made. Archive records will take a longer time to retrieve,
typically up to 30 minutes.

If and when the TMS service provider changes, then the TMS journal will be
transferred to the new provider as part of the transfer agreement. Apart from the
longevity of data retention and the associations of data with post offices, these
views are equivalent to those taken in the post office. It is understood that the
vast majority of POCL audits will be conducted within the post offices, with
resort to the Correspondence Server views only where the outlet views are not
available (denial, destruction) or, of course, where the historical record is
required.

Access from one outlet to the data of another or to the back-history data on the
correspondence servers is not provided.

Although the bulk of the TMS journal data is transferred to TIP, R699 specifies
that the audit trail shall be maintained and retained by Pathway and protected
by security measures.

Horizon Help Desk Log File Access

This comprises simple access to serial flat file. File selection will be by date or
dates. Search of the selected file will be by ordinary text search.

2 Improved implementation.

COMMERCIAL IN CONFIDENCE Page 17 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

2.1.2.4

2.1.2.5

2.1.3
2.1.3.1

POCL Systems Files Access

This comprises simple access to the control files, potentially followed by access
to other files transferred to the TMS journal.

POCL Client Files Access
This will be defined at a later level of specification.
Auditor Utilities

Interactive Access

Access Using Keys

In both the post office and correspondence server cases audit facilities are
provided to retrieve, store locally, display and/or print one or more transaction
records, with the selection being based on simple keys. Key elements may be
drawn from certain selected keys in the transaction records.

These key elements will be:

> one or more outlets as defined by reference data, e.g. POCL Region
> stock unit

> clerk id

> interval of time

>» POCL Client identity

> one or more product codes

Other specific key elements may be defined at a later level of specification in
the light of experience.

The keys which an auditor may use will be in accordance with the auditor role.

Controls will be available to limit the selection to practical length. Initially this
control will be set at 256 records.

Disk serial files thus produced may be saved for later local search.
Access using Standard Reports

The following table categorises and lists the operations to be supported by
POCL auditor and POCL Emergency Manager/auditor use of EPOSS facilities,
taken from notes of 17/12/96. Auditor access to such operations is a function of
POCL auditor or POCL Emergency Manager/auditor role management. It is
believed that there are no auditor-specific actions required. In all meaningful
cases print or print-preview is provided.

Where access to the outlet itself is not possible, as for example when an outlet
has been destroyed by fire, equivalent access might be effected by visit to a
correspondence server centre or by restarting the outlet at an auditor centre or
a replacement centre.

COMMERCIAL IN CONFIDENCE Page 18 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date: 10/04/00
Category Report
POCL Auditor

2.1.3.2

Outlet asset verification

Cash account for selected week

Interrogate Transactions

Daily summaries

Cash on hand

Stock on hand

Rems in and out

Suspense account

History of losses and gains

Stock unit asset verification

Counter balances

Internal transfers

Role verification

Statement of users

Collateral verification

Order books on hand

POCL Emergency
Manager/auditor

Role management

Delete/create users

Statement of users

Restatement on unexpected
loss

Cash and stock declaration

Rem out

Current cash account transactions

Daily summaries

Cash account

Effect transactions

Any transaction normally available to the Postmaster

Bulk Access Using Keys

Bulk access is provided in the correspondence server centres only. A utility is
provided to produce bulk selections according to the role of the auditor and in

COMMERCIAL IN CONFIDENCE

Page 19 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

2.2

2.2.1

the custom magnetic format specified by the audit authority to which he
belongs. POCL Client audit authorities may require different formats from those
used by POCL but Pathway proposes that they be required to use the Pathway
native flat format directly. Clearly, subject to the terms of POCL’s contract with
a POCL Client, the data accessed will be limited to that pertaining to that Client.

The bulk selection utilises the same keyed access methods as for interactive
access. Additional key fields to represent one or more post offices will be
available. The selections are, in principle, of unlimited length. Long selections,
where the audit function expects greater than 1 million records from direct
access or 100,000 records from archive media, or numbers of selections which
would disrupt operational schedules are ordered or scheduled by mutual
agreement. Selections confined to the data which is on direct access may be
undertaken in emergencies.

Such bulk files are delivered to one location using media and transport methods
to be agreed. Bulk selections except the very largest may be file-transferred
over the same communications as are used for TIP and eventually Client AP. It
is essential that the security of any such path used be no less than that of these
paths. Very large selections are transferred only in CD-ROM form and are
either collected from Pathway or couriered by Post Office Special Delivery to
one location.

Regular use of bulk selections allows audit functions to build up a history for
own use.

In the event that the audit function requires direct, personal and extempore
access to the actual TMS operational journal then this access will be by
attendance at a Pathway centre and will be supervised by Pathway.

Systems Management Track

Systems Management Track Content and Maintenance

The track is made up of audit events for the particular domain in question. In
the Pathway solution all events are generated within domains and eventually
transferred to the Tivoli Event Management Server.

Within these domains events are collected by Tivoli Agents and transformed
into Tivoli Events. On non-NT platforms the Tivoli Agent role is performed by an
equivalent agent function within the local systems management facility
appropriate to the platform.

These non-NT platforms are:
>» the Sequent Servers, whose events are relayed by BMC Patrol
>» SUN Servers, whose events are notified directly

>» Network Devices, such as routers, whose events are mediated by HP
OpenView

Audit events comprise:

>» System Events, which include Security Events
> Status Reports

> Software Distributions

COMMERCIAL IN CONFIDENCE Page 20 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

2.2.2
2.2.2.1

2.2.2.2

System Events are gathered from all domains, and Status Reports and
Software Distributions from all Windows NT domains.

Tivoli provides extensive event management facilities including central display,
sorting and filtering before viewing, for example, all operations initiated by a
particular operator. These facilities are accessed via a PC-based Tivoli Desktop
available to the Pathway Systems Management functions located in Stevenage
and Lytham St Annes and connected via the Pathway WAN to the master Tivoli
Management Region, or hierarchic level which is at Bootle.

These Tivoli Events are extracted from the Tivoli Event Management Server
and archived using the standard Archive Service. Filters are used to remove
unusable operational events before archiving. Archiving is in Comma
Separated Variable (CSV) format.

Audit Access to the Systems Management Track
Interactive Access

Archived data may be restored from CSV format and viewed using native Tivoli
facilities.

Bulk Access

This will be facilitated as follows:
» the Tivoli events will be archived daily

> analysis can be either by Notepad-type browsing the archive file or by
importing from CSV format into a database or editor of choice.

COMMERCIAL IN CONFIDENCE Page 21 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

3.1

3.1.1.1

3.1.1.2

3.1.2

3.1.2.1

The Commercial Audit Trail

The commercial audit trail is defined to comprise material, held in either
magnetic forms or definitively on paper, to which the Authorities have access.

Magnetic Records

These comprise copies of certain Operational Support records that the
Authorities receive as part of the Steady State and other Services, and those
parts of ICL Pathway’s internal commercial records to which the Authorities
have automated access.

The tracks making up the magnetic commercial audit trail are:
> Business Incident Management System (BIMS)

> Service Level Contract Administration (SLCA)

Business Incident Management System (BIMS)

BIMS is free-standing from the mainstream Pathway Solution. It is a record of
the activities undertaken by the Pathway Customer Service Business Support
Unit to make necessary adjustments to transactions, typically to effect accurate
reconciliations.

Data Retention Requirements
Requirement 697 calls for this data to be retained, in effect, for 7 years.

Audit Access to Operational Support Records
Access is obtained via the procedures contained within the HSAM.

Service Level Contract Administration (SLCA)
SLCA Content and Maintenance

SLCA, and its associated reporting system Service Level Agreement Monitoring
(SLAM) are used to compare the performance of the Horizon system against a
number of measures established in the contract Schedule BO3. It does this by
taking information feeds from the Data Warehouse (DW) and running these
against special formulae, again established in the contract. SLAM is used to
report the outcome of these calculations to the Horizon Service Management
Group, a Pathway/POCL committee.

COMMERCIAL IN CONFIDENCE Page 22 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

Schematic
The following diagram shows the main data flows within SLCA.

Horizon
TPS Harvester ones APS RDM HebDesk

Manual Input

Transeetion File File Rot Data Holpbesk Rollout, Training,
Timing Data Dolvery Times Delivery Times Delivery Times Timing Data te

Dae
Warehouse

= ee

= Saeng Administration
Osta

ry

SUA Monitor

Saag
Data
changes

==

laman-t8.ins

Figure H: SLCA Schematic
3.1.2.2 Input Streams

Automatic Transaction Data held as Oracle tables within the DW.

Manual Transaction Data (Achievement of Rollout, achievement of Training
etc).

Standing Data - SLA parameters and formulae used to calculate achievement
are held as Oracle tables within the DW.

3.1.2.3. Changes to Standing Data
Changes to the SLA Parameters and mathematical formulae are allowed via an

Administration Facility within the SLCA system. Physical access to this facility is
strictly controlled and password controls are used to control logical access.

COMMERCIAL IN CONFIDENCE Page 23 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

3.1.2.4

3.1.2.5

3.1.2.6

Changes to the parameters and/or formulae require pre-authorisation through
the Change Control process before they can be applied. A CCN number must
exist for each change.

Records of changes to Standing Data, including Contract, Contract SLA,
Performance Measure and Liquidated Damages are maintained:

» For each field in the Contract table created, amended or deleted a record of
the change

> For each field in the Contract SLA table created, amended or deleted a
record of the change

» For each field in the Performance Measures table created, amended or
deleted a record of the change

> For each field in the Liquidated Damages table created, amended or deleted
a record of the change

Output Streams

Data output from the various calculations are passed to Service Level
Agreement Monitor (SLAM) where they are converted into graphs and
histograms for presentation to interested groups among them the
POCL/Pathway Service Management Group. SLAM is a passive system insofar
that it does not carry out any processing other than to transform tables of
numbers into graphical representations.

Remedy Calculations are generated by SLCA for subsequent application during
the quarterly invoicing cycle. These values are held as Oracle tables within the
DW.

Data Retention Requirements
Requirement 697 calls for this data to be retained, in effect, for 7 years.
Audit Access to SLCA

Access is obtained via the procedures contained within the Horizon Audit
Manual.

COMMERCIAL IN CONFIDENCE Page 24 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

3.2

3.2.1

3.2.1.1

Manual Records

These comprise Pathway records that are held definitively on paper to which
the Authorities have access.

Included Items

The scope of this list is restricted to items of significance to POCL.

Invoicing

System Overview

Although the generation of an Invoice is a manual activity, and the core Invoice
values and frequencies are determined by the Contract between POCL and ICL
Pathway, there are a number of variable elements that are applied to each
Invoice :

> Transaction volumes where the actual transaction count is compared to a
benchmark value and an adjustment factor calculated.

> Outlet availability during the Invoice period.

>» Numbers of outlets actually rolled-out during NRO compared to original
target.

> Liquidated damages arising from failures to achieve SLA commitments.
The Contract also allows for RPI adjustments.

Interim, or ad-hoc, invoices can be generated at any time although these do not
become committed and are used for internal reporting purposes only.

COMMERCIAL IN CONFIDENCE Page 25 of 29
FUJ00155523
FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006
Version:4.1
Date:10/04/00

Schematic
The following diagram shows the main data flows within the Invoicing process.

Reconeliation

Transaction Manual Debit
Volume & Credit
Report ioe ay Instructions

RPI Rollout
SLA Liqhidated oldimes
Damdges Adjustments Vol
I Payment Generate Invoice
Contract Schedules] (Manual)

oh

faman-17 ins

Data Input Streams
Transaction Data

Transaction volume data taken by the TPS Harvester.

Outlet Data

Outlet availability data. (NB Source of this data not yet finalised).
Count of Outlets rolled-out taken from Roll-out database.
Contractual Data

Capital sum payments during National Roll-out. Based on the later of a pre-
defined date or cummulative number of Post Offices rolled out.

Operating fees during operating period. Monthly fee subject to Transaction and
Availability factors.

COMMERCIAL IN CONFIDENCE Page 26 of 29

FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

3.2.1.2

>» Transaction Component factor. A 7% factor based on actual transactions
made compared to an agreed benchmark value.

> Outlet Cost Component factor. A 32% factor based on the availability of
outlets during the Invoicing period.

Manual Data
Debit Instructions from BIMS.
Credit Instructions from BIMS.

These are manual notifications that are applied to the Invoice during its
production cycle. (There are, currently, no identified occurrence that might
cause a BIMS Instruction to be raised but it is included for completeness.)

Changes to Contractual Data

Changes to any element of the Contractual data can only be achieved through
formal negotiation between the two parties.

Output Stream

The invoicing suite of documents consists of the following :

> Capital Payment Invoice

> Operating Fee Invoice

» Advice Note for Operating Fee Invoice.

» Credit Note for service credits.

> General Invoice for ad-hoc supply of goods and services.

> RPI Adjustment Tracking Schedule.

Data Retention Requirements

Requirement 697 calls for these records and data to be retained for 7 years.
Change Control Documentation

Change Control is an agreed process through which changes to the Horizon are
defined, notified, impacted and costed, authorised and controlled.

Documents that are output from the process and which represent the audit trail
of proposed changes and their outcome are:

> Change Request: used by sponsors to request changes of
Pathway.

>» Change Proposals: used by Pathway to progress the change
through the Change Control process.

>» Change Control Note: used by Pathway to request approval for a

change from the sponsors.

Vv

Supplier Change Request: used by Suppliers to request changes to their
services to Pathway.

> CCB Meeting minutes: used to record the outcome of Change Control
Boards where individual Change Proposals are
reviewed.

Retention: Contract life or seven years whichever is the greater.

COMMERCIAL IN CONFIDENCE Page 27 of 29
FUJ00155523

FUJ00155523

ICL Pathway AUDIT TRAIL FUNCTIONAL SPECIFICATION Ref:CR/FSP/006

Version:4.1
Date:10/04/00

3.2.1.3

3.2.1.4

3.2.1.5

3.2.2

3.2.3

Special Assistance Invoices

Schedule A03 of the Codified Agreements enable Pathway to charge for costs
incurred in assisting POCL with audit activity following contract termination.
Records relating to time spent and expenses will be maintained on a case by
case basis.

Retention: Contract life or seven years whichever is the greater.

Development Activity Invoices

Where Fixed Price contracts are entered into on the basis of estimates
documented in Change Control Notes (CCN) or elsewhere then the CCN under
which the work is authorised forms the commercial record. Where work is
conducted on a Time and Material basis records relating to time spent on that

work will be maintained. Note that that this element includes studies undertaken
as part of the Change Control process.

Retention: Contract life or seven years whichever is the greater.
Contracts with Sub-Contractors

Access is limited to contractual and service related arrangements.
Retention: Contract life or seven years whichever is the greater.
Excluded Items

The following items are outside the scope of ‘Records’ as defined in R697:
» Financial arrangements with Pathway sub-contractors.

> Financial and employment arrangements with Pathway employees, both
direct and contract.

> The ICL Pathway Business Case.
>» General accounting information including funding.
» Reports from and to ICL Group or Fujitsu.

There may be other documents or records that are subsequently added to this
list.

Caveats

There are two caveats that apply to the above lists:

» Special access to records not identified as ‘included’ may be granted on a
case by case basis, subject to request and approval at the appropriate level.

> The scope of access to records identified as ‘included’ must be agreed as
part of agreeing Terms of Reference for an audit as described in the Joint
Working Framework.

It is possible that records and/or documents will be identified during an audit
that were not included in the original Terms of Reference. Pathway Internal
Audit will facilitate the release of these records and/or documents through the
appropriate channels subject to the records not being on the ‘Excluded’ list.

COMMERCIAL IN CONFIDENCE Page 28 of 29