ICL Pathway
FUJ00119343
FUJ00119343
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
Document Title:
Document Type:
Abstract:
Distribution:
Document Status:
Document Predecessor:
Associated Documents:
Author:
Approval Authority:
Signature/Date:
Comments To:
Audit Trail Functional Specification
Functional requirements specification
This document provides a specification of the Audit Trail in
accordance with R699.
Pathway Requirements
Pathway Audit
Pathway Design
Horizon Library
Pathway Library
Issued
Version 3.0
See below
JCC Dicks/ Jan Holmes
JCC Dicks
10/11/99
Author, Jan Holmes
Comments By: ASAP
0.1 CONTENT
0.1.1 DOCUMENT HISTORY
Printed: [ DATE \I]
CATEMP\atfs3-1.doc
COMMERCIAL-IN-CONFIDENCE
Page I of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
1.0 17/9/96 Externally published
Ll 8/10/96 Revised for BA Audit and Pathway comments
12 31/1/97 Revised for POCL comments and for review towards a
definitive version 2.0.
2.0 19/2/97 Revised for further comments. Definitive
2.1 19/5/97 Revised for further comments from DSS, alignment with Access
Control Policy Version 1.0, and for review towards a further
definitive version 3.0
22 8/9/97 Revised in response to implementation questions and further
comments from DSS/POCL. Further review towards a further
definitive version 3.0
2.3 20/10/97 Revised for comments received during Acceptance Specification
discussions and implementation progress
24 5/2/99 Revised to extend definition to Commercial Audit Trail and to
address Horizon comments dated 1/12/98.
2.5 9/3/99 Further comments received 23/2/99
2.6 9/4/99 Changes agreed at Acceptance Review 30/3/99
2.7 26/4/99 Changes agreed at post Acceptance Review Audit Panel meeting
22/4/99
2.8 09/06/99 Removing references to DSS/BA following their withdrawal
from the contract
2.9 24/06/99 Following comments received from POIA.
3.0 01/07/99 Raised to definitive. CCN423
3.1 10/11/99 Insertion of previously missing commercial audit trail details
following DSS/BA withdrawal from contract
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 2 of 32
ICL Pathway
Ref:
Audit Trail Functional Specification Version:
Date:
FUJ00119343
FUJ00119343
CR/FSP/006
3.1
10/11/99
0.1.2 ASSOCIATED DOCUMENTS
Si
2.0 24/2/98 Access Control Policy Pathway
04 09/02/98 Host Application Database Design and Pathway
Interface Standards
3.0 3/12/97 Security Functional Specification Pathway
40 30/9/97 Service Architecture Design Document Pathway
tba Horizon System Audit Manual Pathway
5.0 Schedules A03 POCL
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
Rnon Requirement number
SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung AG, German
software manufacturer
SIS Strategic Infrastructure Service
TIP Transaction Information Processing
Printed: [ DATE \I]
CATEMP\atfs3-1.doc
COMMERCIAL-IN-CONFIDENCE
Page 3 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
TMS Transaction Management Service
CHANGES HISTORY
0.1.4.1
CHANGES AS BETWEEN 3.0 AND 3.1
Revised schematic for Invoicing procedure.
0.1.4.2, CHANGES AS BETWEEN 2.9 AND 3.0
No changes made. Version number increased.
0.1.4.3 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.4 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.5 CHANGES AS BETWEEN 2.6 AND 2.7
Minor addition around caveats section to Commercial Audit Trail.
0.1.4.6 CHANGES AS BETWEEN 2.5 AND 2.6
Changes agreed at the Acceptance Review of 30/3/99 have been incorporated.
0.1.4.7 CHANGES AS BETWEEN 2.4 AND 2.5
Horizon comments dated 23/2/99 have been factored in.
0.1.4.8 CHANGES AS BETWEEN 2.3 AND 2.4
Horizon comments dated 1/12/98 have been factored in.
0.1.4.9 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 4 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
0.1.4.10 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.14.11 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.12 CHANGES AS BETWEEN VERSION 1.2 AND 2.0
A further consolidated set of DSS and POCL comments have been addressed.
0.1.4.13 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.14 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 5 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
0.1.6 CONTENTS
0.1 CONTENT
0.1.1 DOCUMENT HISTORY
0.1.2 ASSOCIATED DOCUMENTS
0.1.3 TERMS & ABBREVIATIONS
0.1.4 CHANGES HISTORY
0.1.5 CHANGES FORECAST
0.1.6 CONTENTS
1. FUNCTIONAL SPECIFICATION
1.1. AUDITOR'S EYE VIEW
1.1.4
1.1.2 THE TOTAL MAINSTREAM PATHWAY SOLUTION ..........04+
1.1.3. THE STRATEGIC INFRASTRUCTURE SERVICE
1.1.4 THE DSS POCL CLIENT...
RRR OR
a
a
rs
1.1.5 OTHER POCL CLIENTS «oe. eseecssseeeeeees 4
1.2 AUDIT TRAIL RESPONSIBILITIES AND USAGE. 4
1.2.1 RESPONSIBILITIES ............. 4
1.2.2 PRINCIPALS, AGENTS, MIXED DATA AND RIGHTS OF ACCESS wd
1.2.3. ACCESS CONTROLS. 4
1.2.4 POCL USAGE... 4
1.2.5 POCL CLIENT USAGE 4
1.2.6 AUDIT TRAIL FORMATS .........0245 4
1.2.7 AUDIT TRAIL RETENTION PERIODS 4
2. THE AUDIT TRACKS. 4
2.1 POCL SIS AUDIT TRACK.. 4
2.1.1 POCL SIS TRACK CONTENT AND MAINTENANCE 4
2.1.2 AUDIT ACCESS To THE POCL SIS TRACK 4
2.2 SYSTEMS MANAGEMENT TRACK . 4
2.2.1 SYSTEMS MANAGEMENT TRACK CONTENT AND MAINTENANCE 4
2.2.2 AupbiT ACCEss TO THE SYSTEMS MANAGEMENT TRACK we
3. THE COMMERCIAL AUDIT TRAIL...... we 4
3.1 MAGNETIC RECORDS............0:06
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 6 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
3.4.4 COMMERCIAL SUPPORT RECORDS. we
3.1.2 SLCA 4
3.2 MANUAL RECORDS 4
3.2.1 INCLUDED ITEMs. w4
3.2.2 EXCLUDED ITEMs . 4
3.2.3 CAVEATS 4
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
CATEMP\atfs3-1.doc Page 7 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
1.1
1.1.1
FUNCTIONAL SPECIFICATION
AUDITOR’S EYE VIEW
SCOPE
This functional specification defines the operational and commercial audit trails.
These are, respectively, the audit trail associated with the operation of the services
which make up the Pathway solution and the audit trail associated with that part of
Pathway’s internal commercial records to which POCL’s Internal Auditors or
Agents as set out in Schedule A03 may have access.
The operational audit trail includes that generated by the mainstream operational
services and the 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 8 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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).
POCL Client (s POCL Client
(DSS) p (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)
e Automated Payment Service (APS)
e Order Book Control Service (OBCS)
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 9 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
running on an “invisible” middleware messaging transport system:
e 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
NY
fe
structure Service
Getter applica
s 4 s
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.
1.1.4 THE POCL <DSS> CLIENT
The distributed POCL Client representing the DSS back-end system is shown at the
component level in Figure C.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 10 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
ESNCS
Ft
Vv
POCL Strategic Infrastructure Service
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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 11 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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
e Transaction Information Processing (TIP)
e SAP Advanced Distribution System (ADS) for inventory management (IM)
« Farnborough Host for AP
The TIP system is batch-oriented, receiving large-scale files of the outlets’
transactions. These comprise daily transactions, weekly (normally) stock holdings
and a cash account, daily AP Client summaries and daily BA transaction
reconciliation reports.
The stock and cash account files are also produced within each office on paper.
These signed paper records will, foreseeably, represent the fiduciary record of the
outlet’s business.
The Reference Data system is responsible for supplying transaction steering data to
Pathway. This data describes the relationships and properties of the data to be
processed (typing of regions, POCL organisations, outlets, Clients, items for sale,
methods of payment, and transaction tokens); and the processing methods
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 12 of 32
ICL Pathway
FUJ00119343
FUJ00119343
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
1.1.5.2
1.2
1.2.1
1.2.11
1.2.1.2
(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.
POCL CLIENT SYSTEMS
This level of specification does not define the audit facilities to be made available to
the audit departments of POCL’s Automated Payment commercial Clients. These
facilities will be negotiated between POCL and the Client as part of the AP
Migration Plan Interface specification for each Client. Pathway expects that these
Clients will use the same methods as are used for the Farnborough host. It has been
decided by POCL that such Client systems will NOT access the Pathway SIS directly
to provide customer and payment scheme reference data (transaction steering data).
Such data will be passed through the POCL Reference Data system.
AUDIT TRAIL RESPONSIBILITIES AND USAGE
RESPONSIBILITIES
TRACKS AND TRAILS
In the description below use is made of the terms audit track and audit trail. An
audit track is a record of activities made within a Pathway subsystem for one or more
of its interfaces. An audit trail is one or more such tracks. The data recorded in a
trail’s several tracks may represent the treatment of related transfers and processing.
In general it is possible to produce an audit track for an interface on either side of
that interface, or, if the interface is itself problematic, on both sides.
It is of course a matter for POCL and POCL Clients to produce their own audit
tracks on their sides of the interfaces to Pathway.
TWO TRACKS
The Pathway audit trail is based upon files representing the single main audit track
representing the traffic running through the Pathway solution, the POCL SIS. This
Printed: [ DATE
CATEMP\atfs3-1
\I] COMMERCIAL-IN-CONFIDENCE
doc Page 13 of 32
ICL Pathway
FUJ00119343
FUJ00119343
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
1.2.2
1.2.3
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.
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.
ACCESS CONTROLS
Access controls are effected through the use of roles.
There are THREE auditor roles: POCL Emergency Manager/auditor, POCL auditor
and POCL Client <C> auditor. It may not be necessary to represent the POCL
Emergency Manager/auditor and POCL auditor separately.
The POCL auditor roles are further defined in the HSAM.
The POCL Emergency Manager/auditor has the same access rights as that of the
Manager or Postmaster. In addition, he may delete and create a Manager/Postmaster
Role, and produce a cash account. Access as POCL Emergency Manager/auditor is
via initial access as POCL auditor then, if required, as in the case of the Manager or
Postmaster being unavailable, a further exchange via the Horizon Help Desk to
obtain a one-shot password which enables the additional Emergency Manager/auditor
operations and a key reference which turns on the filestore encryption/decryption.
POCL Emergency Manager/auditor and POCL auditor have access to all TMS
journal records.
The POCL auditor has no rights to modify the TMS journal. The POCL Emergency
Manager/auditor is not able to modify the TMS journal, except as the auditable result
of permitted operations in connection with his role as an Emergency Manager. In
common with all journal updates, such permitted modifications are always in the
form of appends.
The POCL Client <C> auditor role when implemented will have access only to that
part of the TMS journal which deals with transactions pertaining to that Client and in
accordance with the Client organisation’s contract with POCL. The POCL Client
<C> auditors have no rights to modify the TMS journal.
The POCL Emergency Manager/auditor has access only at the outlet. The POCL
auditor has access at both the outlet and the centre. All access at the centre is via the
Pathway audit function.
Printed: [ DATE
\] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 14 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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:
¢ 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 sofiware 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.
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.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 15 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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.
THE AUDIT TRACKS
2.1 POCL SIS AUDIT TRACK
Strategic Infrastructure
Service
Figure E: The POCL SIS track
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 16 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
2.1.1
2411
2.1.1.2
2.1.1.3
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:
¢ the POCL Horizon Help Desk files
¢ POCL’s own systems’ files
e AP Client files
Any other intermediate file or table constructs do not form part of the track.
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.
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.
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
' This represents an improved implementation. By this method the audit trail is always up to
date and in one place.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
CATEMP\atfs3-1.doc Page 17 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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 :
¢ that at OAS with ESNCS
and within the boundary :
e 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
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 18 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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 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.
? Improved implementation.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 19 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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
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
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 20 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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.
POCL Auditor
Outlet asset verification
Stock unit asset verification
Role verification
Collateral verification
POCL Emergency
Manager/auditor
Role management
Restatement on unexpected loss
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
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
Printed: [ DATE \I]
CATEMP\atfs3-1.doc
COMMERCIAL-IN-CONFIDENCE
Page 21 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
cl transactions Any transaction normally available to the Postmaster
2.1.2.6.2 Bulk access using keys
Bulk access is provided in the correspondence server centres only. A utility is
provided to produce bulk selections according to the role of the auditor and in the
custom magnetic format specified by the audit authority to which he belongs. POCL
Client audit authorities may require different formats from those used by POCL but
Pathway proposes that they be required to use the Pathway native flat format directly.
Clearly, subject to the terms of POCL’s contract with a POCL Client, the data
accessed will be limited to that pertaining to that Client.
The bulk selection utilises the same keyed access methods as for interactive access.
Additional key fields to represent one or more post offices will be available. The
selections are, in principle, of unlimited length. Long selections, where the audit
function expects greater than I 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 22 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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
¢ Network Devices, such as routers, whose events are mediated by HP OpenView
Audit events comprise:
e 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 23 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
CATEMP\atfs3-1.doc Page 24 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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:
¢ 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 REQUIRE
NTS
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 system against a
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
CATEMP\atfs3-1.doc Page 25 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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 oncs APs ROMC Uta Manual Input
Transfetion File File Ret Data Helpbesk Rollout, Fraining,
Timing Data Delivery Times Delivery Times Delivery Times Timing Data of.
Data
. = Sevice Level
Contract
eeies ‘Standing Administration
Data
SLA Monitor
Sande
Data
Changes
I
iaman-i8 ins
Figure H: SLCA Schematic
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 26 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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.
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
e 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
e Data output from the various calculations are passed to Service Level Agreement
Monitor (SLAM) where they are converted into graphs and histograms for
presentation to interested groups among them the POCL/Pathway Service
Management Group. SLAM is a passive system insofar that it does not carry out
any processing other than to transform tables of numbers into graphical
representations.
¢ Remedy Calculations are generated by SLCA for subsequent application during
the quarterly invoicing cycle within the Common Charging System. These values
are held as Oracle tables within the DW.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
CATEMP\atfs3-1.doc Page 27 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
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
3.2
3.2.1
3.2.11
Access is obtained via the procedures contained within the Horizon Audit Manual.
MANUAL RECORDS
These comprise Pathway records that are held definitively on paper to which the
Authorities have access.
INCLUDED ITEMS
The scope of this list is restricted to items of significance to POCL.
INVOICING
System Overview
Although the generation of an Invoice is a manual activity, and the core Invoice
values and frequencies are determined by the Contract between POCL and ICL
Pathway, there are a number of variable elements that are applied to each Invoice :
e Transaction volumes where the actual transaction count is compared to a
benchmark value and an adjustment factor calculated.
¢ Outlet availability during the Invoice period.
¢ Numbers of outlets actually rolled-out during NRO compared to original target.
e 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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 28 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
Schematic
The following diagram shows the main data flows within the Invoicing process.
Fananaon
[sal
tabbes
me
Report ace RODE Instructions
1
cohen
aE
payment» [Getta vlan
contact sepa Py te ne
aa
w
Invoices
laman-17.ins
Data Input Streams
Transaction Data
Transaction volume data taken by the TPS Harvester.
Outlet Data
Outlet availability data. (NB Source of this data not yet finalised).
Count of Outlets rolled-out taken from Roll-out database.
Contractual Data
Capital sum payments during National Roll-out. Based on the later of a pre-defined
date or cummulative number of Post Offices rolled out.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 29 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
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.
Qutput Stream
The invoicing suite of documents consists of the following :
a. Capital Payment Invoice
b. Operating Fee Invoice
c. Advice Note for OFT.
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.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 30 of 32
ICL Pathway
FUJ00119343
FUJ00119343
Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
e Change Control Note: used by Pathway to request approval for a change from
the sponsors.
e¢ 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.
3.2.1.3 SPECIAL ASSISTANCE INVOICES
Schedule A03 of the Codified Agreements enable Pathway to charge for costs
incurred in assisting POCL with audit activity following contract termination.
Records relating to time spent and expenses will be maintained on a case by case
basis.
Retention: Contract life or seven years whichever is the greater.
3.2.1.4 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.
3.2.1.5 CONTRACTS WITH SUB-CONTRACTORS
Access is limited to contractual and service related arrangements.
Retention: Contract life or seven years whichever is the greater.
3.2.2 EXCLUDED ITEMS
The following items are outside the scope of ‘Records’ as defined in R697:
¢ Financial arrangements with Pathway sub-contractors.
e Financial and employment arrangements with Pathway employees, both direct
and contract.
e The ICL Pathway Business Case.
¢ General accounting information including funding.
¢ Reports from and to ICL Group or Fujitsu.
Printed: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 31 of 32
FUJ00119343
FUJ00119343
ICL Pathway Ref: CR/FSP/006
Audit Trail Functional Specification Version: 3.1
Date: 10/11/99
There may be other documents or records that are subsequently added to this list.
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: [ DATE \I] COMMERCIAL-IN-CONFIDENCE
C:ATEMP\atfs3-1.doc Page 32 of 32