WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
Document Title: Audit Trail Functional Specification
Document Type: Functional Requirements Specification
Release: BI3 (Network Banking)
Abstract: This document provides a specification of the Audit Trail in
accordance with R699.
Document Status: APPROVED
Originator & Dept: J. Holmes (Quality & Audit)
Contributors: J.C. C. Dicks (Customer Requirements)
B. Mooney (QRM)
Reviewed By: R. Laking (IPDU) (*) G. Hooper (CS Security)
G.V. ASD R. Dhesi (Consignia IA) (*
(*) Comments made ane ( ) esi (Consignia IA) (*)
Comments By:
Comments To: Originator (& Pathway Document Controller)
Distribution: ICL Pathway Document Management
G. Vane (ASD) R. Laking (IPDU)
G. Hooper (CS Security) R. Dhesi (Consignia IA)
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: I of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
0.0 Document Control
0.1. Document History
Version Date Reason for Issue Associated
No. CP/PinICL
1.0 17/9/96 Externally published N/A
1.1 8/10/96 Revised for BA Audit and Pathway comments N/A
12 31/1/97 Revised for POCL comments and for review towards a definitive N/A
version 2.0.
2.0 19/2/97 Revised for further comments. Definitive N/A
21 19/5/97 Revised for further comments from DSS, alignment with Access N/A
definitive version 3.0
Control Policy Version 1.0, and for review towards a further
2.2 8/9/97 Revised in response to implementation questions and further N/A
nts from DSS/POCL. Further review towards a further
comm
definitive version 3.0
23 20/10/97 I Revised for comments received during Acceptance Specification I N/A
discussions and implementation progress
24 5/2/99 Revised to extend definition to Commercial Audit Trail and to N/A
address Horizon comments dated 1/12/98.
2.5 9/3/99 Further comments received 23/2/99 N/A
26 9/4/99 Changes agreed at Acceptance Review 30/3/99 N/A
27 26/4/99 Changes agreed at post Acceptance Review Audit Panel meeting N/A
22/4/99
28 09/06/99 I Removing references to DSS/BA following their withdrawal from N/A
the contract
2.9 24/06/99 I Following comments received from POTA. N/A
3.0 01/07/99 Raised to definitive. CCN423 N/A
3.1 10/11/99 Insertion of previously missing commercial audit trail details N/A
following DSS/BA withdrawal from contract
4.0 Raised to definitive. CCN. No CCN submitted; overtaken by CSR+ I N/A
definition.
4.1 10/04/00 Introduction of Logistics Feeder Service (LFS), Change ofname— I N/A
RED :> BIMS.
42 21/07/00 I Reviewed by Brian Mooney. Document references updated. N/A
5.0 15/01/01 I Raised to Approved NIA
3.1 25/01/02 Changes to reflect Network Banking, EFTPOS and N/A
decommissioning of HAPS
5.2 12/02/02 Following internal review cycle N/A
53 25/02/02 Following review comments from POL N/A
6.0 25/02/02 Raised to Approved. CCN 929 N/A
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE
Page: 2 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
0.2 Approval Authorities
Name Position Signature Date
P. Jeram Programme Director
R. Dhesi Consignia Internal Audit
0.3 Associated Documents
Reference Version Date Title Source
RS/POL/003 Access Control Policy Pathway
TD/STD/001 Host Application Database Pathway
Design and Interface Standards
RS/FSP/001 Security Functional Specification I Pathway
CR/FSP/004 Service Architecture Design Pathway
Document
TA/MAN/005 Horizon System Audit Manual for I Pathway
CSR+
Schedules A03 POCL
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 Abbreviations/Definitions
Abbreviation I Definition
ACD Automated Call Distribution
ADS Advanced Distribution Systems
AP Automated Payment
APS AP Service
BIMS Business Incident Management System
DLT Digital Linear Tape
EFTPOS Electronic Fund Transfer at Point of Sales
EPOS Electronic Point of Sale
EPOSS EPOSS Service
ESNCS Electronic Stop Notice Control Service
LFS Logistics Feeder Service
HSAM Horizon System Audit Manual
IM Inventory Management
ISDN Integrated Services Digital Network
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE
Page: 3 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
NBS Network Banking System
OAS OBCS Access Service
OBCS. Order Book Control Service
OPS Office Platform Service
POL Post Office Limited
RD Reference Data
Rnnn 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
0.5 Changes in this Version
Version I Changes
6.0 No changes made.
53 POL reviewer’s comments.
52 Pathway reviewer’s comments
5.1 Major additions; Network Banking and EFTPOS. Further changes to reflect the decommissioning
of HAPS and directly linked AP Clients. Change name from POCL to POL.
5.0 Approvers changed
4.2 Approvers changed
41 Introduction of Logistics Feeder Service details
40 No changes made. Version number increased
31 Revised schematic for Invoicing procedure
3.0 No changes made. Version number increased.
2.9 Minor amendments following feedback from POIA including a revised Commercial Audit Trail
section on Invoicing
28 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
2.7 Minor addition around caveats section to Commercial Audit Trail
2.6 Changes agreed at the Acceptance Review of 30/3/99 have been incorporated
2.5 Horizon comments dated 23/2/99 have been factored in
24 Horizon comments dated 1/12/98 have been factored in
2.3 A general overhaul to reflect agreements made in the course of Acceptance Specification
negotiations and during design and development
2.2 PDA comments dated 19 June have been factored in: defining the mainstream operational Services;
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 4 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
extending the list of keys
21 A further set of comments from POCL and DSS have been addressed. A number of clarifications
and corrections have been made
2.0 A further consolidated set of DSS and POCL comments have been addressed
12 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)
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.6 Changes Expected
Changes _
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 5 of 29
WITN04600103
WITNO04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
0.7. Table of Contents
10 INTRODUCTION...
1.1 AUDITOR’S EYE VIEW
1 Scope...
2 The Total Mainstream PATHWAY Solution
3 The Strategic Infrastructure Service ..
4
5
The POL <DSS> Client
Other POL Clients ..
L151 POL In-house
5 POL Client Systems...........
1.2 “AU DIT TRAIL RESPONSIBILI TIES AND USAGE.
Responsibilities ..
Tracks and Trails ...
TWO Tracks
Principals, Agents And Rights Of Access
Access controls
POL usage..
POL Client Usage
Audit trail formats.
Native Formats.
1 Custom Formats .
1.2.7 Audit trail retention periods
2.0 THE AUDIT TRACKS...
2.1 POL SIS AUDIT TRACK ..
2.1.1 POL SIS Track Content And Maintenance...
TMS Journal
Horizon Help Desk ...sscccsscsssssesssissssisnssnssssenenssnstnnetsnseneee
POL Systems
AP Client
5 POL <DSS> Client .
Audit Access to the POL SIS Trac
TMS Journal Access at the Outh
TMS Journal Access at the Correspondence
Horizon Help Desk Log File Access.
RNRNNK
POL Systems Files Access.
POL Client Files Access
2. Auditor Utilities ..
Interactive Access
Bulk Access Using Keys...
" Sys’ TEMS MANAGEMENT TRACK...
Systems Management Track Content and Maintenance .
Audit Access to the Systems Management Track..
Interactive Access... coereseeensnsnnneneeeene
Bulk Access
3.0 © THE COMMERCIAL AUDIT TRAIL
3.1 MAGNETIC RECORDS
Business Incident Management System (BIMS) ...
Data Retention Requirements ...
: Audit Access to Operational Support Records
Service Level Contract Administration (SLCA)
SLCA Content and Maintenance .... —
Input Streams...
Changes to Standing Data.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 6 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE Date: 25/02/02
3.1.24 Output Streams . . 25
3.1.25 Data Retention Requirements... seevtnnnttnninnntennineieenreesse 25
3.1.2.6 Audit Access to SLCA 25
3.2. MANUAL RECORDS
3.2. Included Items
Invoicing...
Change Control Documentation.
Special Assistance Invoices ...
Development Activity Invoices.
Contracts with Sub-Contractors
Excluded Items ..
Caveats.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 7 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
1.0 Introduction
1.1 Auditor’s Eye View
1.1.1 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 POL’s Internal Auditors or Agents may have access as set
out in Schedule A03.
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 POL Steady State
Services :
> Automated Payment Service (APS)
» EPOS Service (EPOSS)
> Order Book Control Service (OBCS)
» Logistics Feeder Service (LFS)
» Transaction Information Processing (TIP)
» Network Banking (NWB)
» Electronic Fund Transfer at Point of Sale (EFTPOS)
» POL 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 POL’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 introduction of Network Banking and EFTPOS means that those parts of the
operational audit trail to do with Network Banking and EFTPOS are retained for 7 years.
The remainder of the operational audit trail, specifically data relating to APS, OBCS, TIP
and LFS is retained for 18 months. The commercial audit trail is also 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 8 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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).
Bae
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 sofiware and telecommunications platforms
themselves.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 9 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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:
vy
Vv
Vv WV
>
EPOS Service (EPOSS)
Automated Payment Service (APS)
Order Book Control Service (OBCS)
Logistics Feeder Service (LFS)
Network Banking (NWB)
Electronic Fund Transfer at Point of Sale (EFTPOS)
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
POL Client Systems
3
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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 10 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
1.1.4 The POL <DSS> Client
The distributed POL Client representing the DSS back-end system is shown at the
component level in Figure C.
I POL Strategie Infrastructure Service
Figure C: Components of the POL <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).
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 11 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
1.1.5 Other POL Clients
Figure D shows the relationship between the SIS and other POL Client systems. These
client systems comprise both those that belong to the POL organisation itself and those,
which belong to POL’s commercial Clients, such as utilities and high street banks.
POL Client
4 (POL)
Y
Figure D: Other POL Clients
1.1.5.1 POL In-house Systems
The POL in-house systems that interface to the Pathway SIS are:
» Reference Data
» Transaction Information Processing (TIP)
>» SAP Advanced Distribution System (ADS) for inventory management (IM)
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, POL 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).
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)
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 12 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
AP Clients will have direct interfaces to the Pathway SIS for receiving files of payment
records.
1.1.5.2 POL Client Systems
This level of specification does not define the audit facilities to be made available to the
audit departments of POL’s Automated Payment commercial Clients. These facilities
will be negotiated between POL and the Client as part of the AP Migration Plan Interface
specification for each Client. It has been decided by POL 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 POL Reference
Data system.
1.2 Audit Trail Responsibilities and Usage
1.2.1 Responsibilities
1.2.11 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 POL and POL Clients to produce their own audit tracks on
their sides of the interfaces to Pathway.
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 POL 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 13 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
1.2.2 Principals, Agents And Rights Of Access
An Agent may carry out a particular audit for POL or by POL 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: POL Emergency Manager/auditor, POL auditor and POL.
Client <C> auditor. It may not be necessary to represent the POL Emergency
Manager/auditor and POL auditor separately.
The POL auditor roles are further defined in the HSAM.
The POL 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 POL Emergency Manager/auditor is via initial access
as POL 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
that enables the additional Emergency Manager/auditor operations and a key reference
that turns on the filestore encryption/decryption.
POL Emergency Manager/auditor and POL auditor have access to all TMS journal
records.
The POL auditor has no rights to modify the TMS journal. The POL 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 POL Client <C> auditor role when implemented will have access only to that part of
the TMS journal that deals with transactions pertaining to that Client and in accordance
with the Client organisation’s contract with POL. The POL Client <C> auditors have no
rights to modify the TMS journal.
The POL Emergency Manager/auditor has access only at the outlet. The POL auditor has
access at both the outlet and the centre. All access at the centre is via the Pathway audit
function.
1.2.4 POL usage
POL Audit functions has access to the POL SIS audit track and the Systems Management
track
1.2.5 POL Client Usage
POL Client Audit functions will have access to those parts of the POL SIS track relating
to that Client and subject to the Client’s contract with POL (subject to paragraph 1.2.3
above)
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 14 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
1.2.6 Audit trail formats
1.2.6.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 that 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, ADS and POL Clients,
and from RD, ADS, possibly POL 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.6.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 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.
1.2.7 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 that
correspond to the commercial audit trail. A general retention period of 18 months is
required for the operational audit trail although those elements to do with Network
Banking and EFTPOS will be retained for 7 years. 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 15 of 29
WITN04600103
WITNO04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
2.0 The Audit Tracks
2.1 POL SIS Audit Track
Strategic Infrastructure
Service
Figure E: The POL SIS track
2.1.1 POL SIS Track Content And Maintenance
The POL SIS audit track comprises:
» the TMS journal
and those POL files exchanged between the Pathway data centres:
» the POL Horizon Help Desk files
> POL’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
that 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.
‘ This represents an improved implementation. By this method the audit trail is always
up to date and in one place.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 16 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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 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 POL Systems
These comprise:
» Those at the TIP, RD 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 and ADS transfers are selective extracts of it.
2.1.1.4 AP Client Systems
This comprises the various AP Client interfaces holding control records describing files
being transferred.
21.15 POL <DSS> Client
The specific DSS element of the POL 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.
2.1.2 Audit Access to the POL SIS Track
Logical audit access will be provided as follows:
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 17 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
2.1.2.1 TMS Journal Access at the Outlet
Views of the transactions that 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 POL 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”.
2.1.2.2. TMS Journal Access at the Correspondence Servers
Equivalent TMS journal data is maintained at each of the two Pathway Data Centres.
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, the retrieval time being in proportion to the
volume requested.
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 POL 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.
? Improved implementation.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 18 of 29
WITN04600103
WITNO04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
2.1.2.4
2.1.2.5
2.1.3
2.1.3.1
POL Systems Files Access
This comprises simple access to the control files, potentially followed by access to other
files transferred to the TMS journal.
POL 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. POL Region
> stock unit
Clerk id
Vv
interval of time
> POL Client identity
Vv
> 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 that 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 POL auditor
and POL Emergency Manager/auditor use of EPOSS facilities, taken from notes of
17/12/96. Auditor access to such operations is a function of POL auditor or POL
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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 19 of 29
ICL Pathway Ltd
COMMERCIAL-IN-CONFIDENCE.
Audit Trail Functional Specification
Ref: CR/FSP/006
Version: 6.0
Date: 25/02/02
POL Auditor
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
POL
EmergencyMana
ger/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
© 2001 ICL Pathway Ltd
COMMERCIAL-IN-CONFIDENCE
Page: 20 of 29
WITN04600103
WITN04600103
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
2.1.3.2 Bulk Access Using Keys
Bulk access is provided in the Data 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. POL Client audit authorities may require
different formats from those used by POL but Pathway proposes that they be required to
use the Pathway native flat format directly. Clearly, subject to the terms of POL’s
contract with a POL 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 I million records from direct access or 100,000 records from archive
media, or numbers of selections that would disrupt operational schedules are ordered or
scheduled by mutual agreement. Selections confined to the data that 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.
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:
> 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
» Sofiware Distributions
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 21 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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 that 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.
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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 22 of 29
WITN04600103
WITNO04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
3.0
3.1
3.11
3.1.11
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 cither 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 freestanding from the mainstream Pathway Solution. It is a record of the
activities undertaken by the Pathway Customer Service Management Support Unit to
make necessary adjustments to transactions, typically to effect accurate reconciliation.
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 B03. 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/POL committee.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 23 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
Schematic
The following diagram shows the main data flows within SLCA.
TPS Harvester ones 4P8 RDMC once Nerval input
Transfetion Filo Fife Ret bata HelpDesk Rollout raining,
Timing Data Deliver} Times ——_—Dativer} Times Deliver} Times Timing Data a
=r
aman ins
“A 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 24 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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 POL/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.
3.1.2.5 Data Retention Requirements
Requirement 697 calls for this data to be retained, in effect, for 7 years.
3.1.2.6 Audit Access to SLCA
Access is obtained via the procedures contained within the Horizon Audit Manual.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 25 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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 POL.
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 POL 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.
> 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 26 of 29
WITN04600103
WITNO04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
Schematic
The following diagram shows the main data flows within the Invoicing process.
Data
Warehouse
Transaction >
Volume Manual Debit
Report sLca ‘& credit
Instuctions
SLALiquidated RPI
tanewe Adjustments
aes
Payment Generate Invoice
Contact J Schedules (Manual)
lamana7.ins
Data Input Streams
Transaction Data
Transaction volume data taken by the TPS Harvester.
Outlet Data
Outlet availability data.
Contractual Data
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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 27 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
> 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 is, 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.
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:
> 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.
>» 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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 28 of 29
WITN04600103
WITN04600103
ICL Pathway Ltd Audit Trail Functional Specification Ref: CR/FSP/006
Version: 6.0
COMMERCIAL-IN-CONFIDENCE. Date: 25/02/02
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 POL 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.
Vv WV
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.
© 2001 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Page: 29 of 29