ICL Pathway
Audit Trail Functional Specification
Ref:
Date:
Version:
FUJ00118196
FUJ00118196
CR/FSP/006
4.0
10/11/99
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
Version Complete
Version 3.0
See below
JC C Dicks/ Jan Holmes
JCC Dicks
10/11/99
Author, Jan Holmes
ASAP
0.1 CONTENT
0.1.1 DOCUMENT HISTORY
Version Date [Reason
1.0 17/9/96 Externally published
Printed: 1/15/01
COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc
Page 1 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
1.4 8/10/96 Revised for BA Audit and Pathway comments
1.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 al
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
la further definitive version 3.0
2.3 20/10/97 Revised for comments received during Acceptance
‘Specification discussions and implementation progress
2.4 9/2/99 Revised to extend definition to Commercial Audit Trail and
fo 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
Imeeting 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 DSS/BA withdrawal from contract
4.0 Raised to definitive. CCN (not raised)
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 2 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
0.1.2 ASSOCIATED DOCUMENTS
Version (Date [Title jSource
2.0 [24/2/98 \Access Control Policy [Pathway
0.4 [09/02/98 [Host Application Database Design and [Pathway
Interface Standards
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.1.3 TERMS & ABBREVIATIONS
ACD Automated Call Distribution
ADS Advanced Distribution Systems
AP Automated Payment
APS AP Service
DLT Digital Linear Tape
EPOS Electronic Point of Sale
EPOSS EPOSS Service
ESNCS Electronic Stop Notice Control Service
HSAM Horizon System Audit Manual
IM Inventory Management
ISDN Integrated Services Digital Network
OAS OBCS Access Service
OBCS Order Book Control Service
OPS Office Platform Service
RD Reference Data
Rann Requirement number
SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung AG,
German software manufacturer
sis Strategic Infrastructure Service
TIP. Transaction Information Processing
TMS Transaction Management Service
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 3 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
CHANGES HISTORY
0.1.4.1 CHANGES AS BETWEEN 3.1 AND 4.0
None — raised for CCN
0.1.4.2 CHANGES AS BETWEEN 3.0 AND 3.1
Revised schematic for Invoicing procedure.
0.1.4.3 CHANGES AS BETWEEN 2.9 AND 3.0
No changes made. Version number increased.
0.1.4.4 CHANGES AS BETWEEN 2.8 AND 2.9
Minor amendments following feedback from POIA including a revised
Commercial Audit Trail section on Invoicing.
0.1.4.5 CHANGES AS 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.
0.1.4.6 CHANGES AS BETWEEN 2.6 AND 2.7
Minor addition around caveats section to Commercial Audit Trail.
0.1.4.7 CHANGES AS BETWEEN 2.5 AND 2.6
Changes agreed at the Acceptance Review of 30/3/99 have been
incorporated.
0.1.4.8 CHANGES AS BETWEEN 2.4 AND 2.5
Horizon comments dated 23/2/99 have been factored in.
0.1.4.9 CHANGES AS BETWEEN 2.3 AND 2.4
Horizon comments dated 1/12/98 have been factored in.
0.1.4.10 CHANGES AS 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 4 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
0.1.4.11 CHANGES AS 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.
0.1.4.12 CHANGES AS 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.
0.1.4.13 CHANGES AS BETWEEN VERSION 1.2 AND 2.0
A further consolidated set of DSS and POCL comments have been
addressed.
0.1.4.14 CHANGES AS 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).
0.1.4.15 CHANGES AS 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.
0.1.5 CHANGES FORECAST
Addition of material for POCL commercial Clients.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 5 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
0.1.6 CONTENTS
0.1. CONTENT... 2
0.1.1 DOCUMENT HISTORY. 2
0.1.2 I ASSOCIATED DOCUMENTS 3
0.1.3. TERMS & ABBREVIATIONS... 3
0.1.4 CHANGES HISTORY.......... 4
0.1.5 CHANGES FORECAST. 5
0.1.6 CONTENTS. 6
1. FUNCTIONAL SPECIFICATION.
1.4 AUDITOR'S EYE VIEW....cscsscsecnnse
1.4.4
4.1.2 THE TOTAL MAINSTREAM PATHWAY SOLUTION 9
1.1.3. THE STRATEGIC INFRASTRUCTURE SERVICE.......c.csssssssssstssistninttintintnnetsnens
1.1.4 THE DSS POCL CLIENT. 10
1.1.5 OTHER POCL CLIENTS 11
1.2 AUDIT TRAIL RESPONSIBILITIES AND USAGE. ..........::scsnsnsnstmsnsnnnintnintniennnneneensenee 1B
4.2.4 RESPONSIBILITIES. 13
1.2.2 PRINCIPALS, AGENTS, MIXED DATA AND RIGHTS OF ACCESS..... 14
1.2.3. ACCESS CONTROLS. 14
1.2.4 POCL USAGE. 15
1.2.5 POCL CLIENT USAGE... ccscccccsssssesssssesnsssssetnsnsseennnssseennssseetnnsetenunsseetnnsettinnssseennsseeesee TS)
14.2.6 AUDIT TRAIL FORMATS. 15
1.2.7. AUDIT TRAIL RETENTION PERIODB.......... sossstntssiststnsiststistniseistniisisinetsisetntees 16
2. THE AUDIT TRACKG...........
2.1 POCL SIS AUDIT TRACK......c.csscsssssssinistinintsnintisnieistitisinnisnstienstnistenenstnetnen TT
2.1.1 POCL SIS TRACK CONTENT AND MAINTENANCE. 17
2.1.2 AUDIT ACCESS TO THE POCL SIS TRACK........:ccccccsscessssssessssssinnsetttnssetetnnseeenseeeeees 19
2.2 SYSTEMS MANAGEMENT TRACK.......c:cssssssssssestinsistnnistnnistntisistntistineiennninenntnensesnese 20
2.24 SYSTEMS MANAGEMENT TRACK CONTENT AND MAINTENANCE........c.:0cscssssssessien 20
2.2.2 AUDIT ACCESS TO THE SYSTEMS MANAGEMENT TRACK. 20
3. THE COMMERCIAL AUDIT TRAIL.
3.1. MAGNETIC RECORDS
3.1.1 COMMERCIAL SUPPORT RECORDS. .......cco:ssossessssnsstensssnnstinestnnsttnnsennsetenettnsetsnssennseenee 20
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 6 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
3.1.2 SLCA.
3.2 MANUAL RECORDS. 20
3.2.1. INCLUDED ITEMS 20
20
3.2.2 EXCLUDED ITEMS.
3.2.3 CAVEATS....cccscocssessseneeenneee
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc
Page 7 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
1. FUNCTIONAL SPECIFICATION
11 AUDITOR'S EYE VIEW
1.1.4 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 AO3 may have
access.
The operational audit trail includes that generated by the mainstream
operational services and the Reconciliation Exceptions Database (RED).
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)
¢ POCL Infrastructure Services
The RED 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 8 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
1.1.2 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).
a 2
POCL Client POCL Client
(DSS) (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.
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)
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 9 of 1
ICL Pathway
Ref:
Audit Trail Functional Specification —_Version:
Date:
FUJ00118196
FUJ00118196
CR/FSP/006
4.0
10/11/99
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 s of the Office Platform Service (OPS) in each outlet
* central servers
POCL Client Systems
iN
Central Servers
3
&
5
a
2
a
3
&
2
OP:
S.
Counter spies) ) >
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.
THE POCL <DSS> CLIENT
The distributed POCL Client representing the DSS back-end system is
shown at the component level in Figure C.
Printed: 1/15/01
COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc
Page 10 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
Pathway Network >
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).
1.1.5 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1 Audit Work\ATFS-FuncSpec\Release-CSR\atfs4_0.doc Page 11 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
POCL Client
(POCL)
Figure D: Other POCL Clients
1.1.5.1 POCL IN-HOUSE SYSTEMS
The POCL in-house systems which interface to the Pathway SIS are:
« Reference Data
« Transaction Information Processing (TIP)
. iM) Advanced Distribution System (ADS) for inventory management
« 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,
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 12 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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).
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)
[DN: ADS/LFS is not implemented at Core System Release.]
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.
1.1.5.2 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.
1.2 AUDIT TRAIL RESPONSIBILITIES AND USAGE
1.2.1 RESPONSIBILITIES
1.2.1.1 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 13 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
1.2.1.2 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.
1.2.2 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
rights of access. Changes to these rights is via Change Control.
1.2.3 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
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 14 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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.
1.2.5 POCL USAGE
POCL Audit functions has access toPOCL SIS audit trackand the Systems
Management track
1.2.6 POCL CLIENT USAGE
POCL Client Audit functions will have access to:
e POCL SIS track (subject to paragraph 1.2.2 above)
1.2.8 AUDIT TRAIL FORMATS
1.2.8.1 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, 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.
1.2.8.2 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 15 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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.
1.2.9 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 16 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
2. THE AUDIT TRACKS
2.1 POCL SIS AUDIT TRACK
Figure E: The POCL SIS track
2.1.1 POCL SIS TRACK CONTENT AND MAINTENANCE
The POCL SIS audit track comprises:
e the TMS journal
and those POCL files exchanged between the Pathway data centres:
e the POCL Horizon Help Desk files
e¢ POCL’s own systems’ files
¢ AP Client files
Any other intermediate file or table constructs do not form part of the track.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 17 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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 harvested daily into a flat file. A control file will be written for
each such daily file.
2.1.1.3 POCL SYSTEMS
These comprise:
those at the TIP, RD, Farnborough 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.
References to ADS/LFS are not definitive at this level of specification.
2.1.1.4 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.
2.1.1.5 POCL <DSS> CLIENT
The specific DSS element of the POCL Audit Track comprises the following
files outside the Pathway boundary :
' This represents an improved implementation. By this method the audit trail is
always up to date and in one place.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 18 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
¢ 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:
e 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.
2.1.2 AUDIT ACCESS TO THE POCL SIS TRACK
Logical audit access will be provided as follows:
2.1.2.1 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*.
? Improved implementation.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 19 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
2.1.2.2 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.
2.1.2.3 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.1.2.4 POCL SYSTEMS FILES ACCESS
This comprises simple access to the control files, potentially followed by
access to other files transferred to the TMS journal.
2.1.2.5 POCL CLIENT FILES ACCESS
This will be defined at a later level of specification.
2.1.2.6 AUDITOR UTILITIES
2.1.2.6.1 Interactive access
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 20 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
2.1.2.6.1.1_ 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.
2.1.2.6.1.2_ I 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.
Category Report
POCL Auditor
Outlet asset verification Cash account for selected week
Interrogate Transactions
Daily summaries
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 21 of 1
ICL Pathway
Audit Trail Functional Specification
Ref:
Date:
Version:
FUJ00118196
FUJ00118196
CR/FSP/006
4.0
10/11/99
2.1.2.6.2
Stock unit asset verification
Role verification
Collateral verification
POCL Emergency
Manager/auditor
Role management
Restatement on unexpected
loss
Effect transactions
Bulk access using keys
Cash on hand
Stock on hand
Rems in and out
Suspense account
History of losses and gains
Counter balances
Internal transfers
Statement of users
Order books on hand
Delete/create users
Statement of users
Cash and stock declaration
Rem out
Current cash account transactions
Daily summaries
Cash account
Any transaction normally available to the Postmaster
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 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.
Printed: 1/15/01
COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc
Page 22 of 1
ICL Pathway
FUJ00118196
FUJ00118196
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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 CDROM 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.
Printed: 1/15/01
P:\Audit\Brian Mi
COMMERCIAL-IN-CONFIDENCE
looney\1 Audit Work\ATFS-FuncSpec\Release-CSR\atfs4_0.doc Page 23 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
2.2 SYSTEMS MANAGEMENT TRACK
2.2.1 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:
e the Sequent Servers, whose events are relayed by BMC Patrol
e SUN Servers, whose events are notified directly
e Network Devices, such as routers, whose events are mediated by HP
OpenView
Audit events comprise:
¢ System Events, which include Security Events
e Status Reports
¢ Software Distributions
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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 24 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
2.2.2 AUDIT ACCESS TO THE SYSTEMS MANAGEMENT TRACK
2.2.2.1 INTERACTIVE ACCESS
Archived data may be restored from CSV format and viewed using native
Tivoli facilities.
2.2.2.2 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
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 25 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
3. 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.
3.1 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:
e Reconciliation Exceptions Database (RED)
e Service Level Contract Administration (SLCA)
3.1.1 RED
RED 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. It is implemented as a Microsoft Access
database. Usage is by import to Microsoft Access.
3.1.1.2 DATA RETENTION REQUIREMENTS
Requirement 697 calls for this data to be retained, in effect, for 7 years.
3.1.1.3 AUDIT ACCESS TO OPERATIONAL SUPPORT RECORDS
Access is obtained via the procedures contained within the HSAM.
3.1.2 SLCA
3.1.2.1 SLCA CONTENT AND MAINTENANCE
SLCA, and its associated reporting system Service Level Agreement
Monitoring (SLAM) are used to compare the performance of the Horizon
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 26 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
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.
The following diagram shows the main data flows within SLCA.
Horizon
TPS Harvester oBcs APS ROMC ance Manual input
Transaction File File Ref Data Helpdesk Rollout, Training,
Timing Data Delivery Times Delivery Times Delivery Times Timing Data e
= Sevice Level
Contract
Contract Standing Administration
Data
SLA Monitor
Sanaa —.,
Data TS
Changes
= SLAM
=
Reports
Senice
‘Management
Group
laman-t8.ins
Figure H: SLCA Schematic
3.1.2.2 INPUT STREAMS
e Automatic Transaction Data held as Oracle tables within the DW.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 27 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
¢ Manual Transaction Data (Achievement of Rollout, achievement of
Training etc).
e 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.
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
3.1.2.4 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.
e« Remedy Calculations are generated by SLCA for subsequent application
during the quarterly invoicing cycle within the Common Charging System.
These values are held as Oracle tables within the DW.
3.1.2.5 DATA RETENTION REQUIREMENTS
Requirement 697 calls for this data to be retained, in effect, for 7 years.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 28 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
3.1.2.6 AUDIT ACCESS TO SLCA
Access is obtained via the procedures contained within the Horizon Audit
Manual.
3.2 MANUAL RECORDS
These comprise Pathway records that are held definitively on paper to which
the Authorities have access.
3.2.1 INCLUDED ITEMS
The scope of this list is restricted to items of significance to POCL.
3.2.1.1 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 :
e Transaction volumes where the actual transaction count is compared to a
benchmark value and an adjustment factor calculated.
e Outlet availability during the Invoice period.
e 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 29 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
Schematic
The following diagram shows the main data flows within the Invoicing
process.
Reconelaton
Exception
Database
Data
Warehouse
A A
Transaction Manual Debit
Volume & Credit
rb Rollout
“a Adjustments -
y
Payment Generate invoice
Contract Schedules (Wana)
Y
Invoices
laman-17 ing
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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 30 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
Operating fees during operating period. Monthly fee subject to Transaction
and Availability factors.
¢ 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 RED.
Credit Instructions from RED.
These are manual notifications that are applied to the Invoice during its
production cycle. (There are, currently, no identified occurrence that might
cause a RED 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 :
a Capital Payment Invoice
b. Operating Fee Invoice
Cc. Advice Note for OFI.
d. Credit Note for service credits.
e General Invoice for ad-hoc supply of goods and services.
f. RPI Adjustment Tracking Schedule.
Data Retention Requirements
Requirement 697 calls for these records and data to be retained for 7 years.
3.2.1.2 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:
e Change Request: used by sponsors to request changes of Pathway.
e Change Proposals: used by Pathway to progress the change through
the Change Control process.
e Change Control Note: used by Pathway to request approval for a
change from the sponsors.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 31 of 1
ICL Pathway
FUJ00118196
FUJ00118196
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
3.2.1.3
3.2.1.4
3.2.1.5
3.2.2
¢ Supplier Change Request: used by Suppliers to request changes to
their services to Pathway.
e¢ 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.
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:
e Financial arrangements with Pathway sub-contractors.
e Financial and employment arrangements with Pathway employees, both
direct and contract.
« The ICL Pathway Business Case.
e General accounting information including funding.
e Reports from and to ICL Group or Fujitsu.
There may be other documents or records that are subsequently added to
this list.
Printed: 1/15/01
COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 32 of 1
FUJ00118196
FUJ00118196
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 4.0
Date: 10/11/99
3.2.3 CAVEATS
There are two caveats that apply to the above lists:
e 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.
e 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.
Printed: 1/15/01 COMMERCIAL-IN-CONFIDENCE
P:\Audit\Brian Mooney\1Audit Work\ATFS-FuncSpec\Release-CSRlatfs4_0.doc Page 33 of 1