Você está na página 1de 122

Summary of Audit Issues

Number of Issues Per Department


Department

0
0
23
1
60
16
1
0
63
1
1

FY11 IA
Issues
0
0
10
11
12
2
0
0
9
1
1

FY12 IA
Issues
0
0
0
0
0
0
0
0
0
0
0

166

46

EA Issues

1 Business Risk Management


2 Corporate Services
3 Finance
4 Human Resources
5 Information Systems
6 IS/NWG
7 Marketing
8 Mobile Money
9 Networks
10 Sales and Distribution
11 All Departments
Total

CBS Report Total Issues


Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504

Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504

Err:504

Err:504

%
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504
Err:504

Number of Issues Per Quarter


Quarter

25
0
134
4
1
2

FY11 IA
Issues
17
11
18
1
0
0

FY12 IA
Issues
0
0
0
0
0
0

166

47

EA Issues

1 Not Applicable
2 FY11
3 FY12Q1
4 FY12Q2
5 FY12Q3
6 FY12Q4
Total

CBS Report Total Issues


Err:504
0
Err:504
0
0
0

Err:504
11

Err:504

Err:504

5
1
2

%
Err:504
Err:504
#VALUE!
Err:504
Err:504
Err:504
Err:504

Number of Issues Per Status


Status

EA Issues

1 Not Resolved
2 Resolved Pending IA Follow-up
3 Resolved Pending EA Follow-up
4 Resolved and Closed
Total

69
41
17
39
166

FY11 IA
Issues
13
5
6
22
46

FY12 IA
Issues
0
0
0
0
0

CBS Report Total Issues


Err:504
Err:504
Err:504
Err:504
Err:504

Err:504

Err:504

%
Err:504
#VALUE!
#VALUE!
#VALUE!
Err:504

1200.00%

1000.00%

800.00%

600.00%

400.00%

200.00%

0.00%

RESOLUTION PER STATUS (YEAR TO DATE)


1200.00%

1000.00%

800.00%

600.00%

Column I

400.00%

200.00%

0.00%
Not Resolved

Resolved Pending IA Follow-up

Resolved Pending EA Follow-up

Resolved and Closed

2011 External Audit Issues' Re


Process Area
5 Program Changes

Risk Rating
Medium

Title
Lack of test environment

12 Computer Operations

High

Lack of back up testing

14 Computer Operations

High

There is no succession plan in place for


key IS staf

18 Access to Programs

High

Lack of periodic review of user access

19 Access to Programs

High

Terminated users have not been removed


from the system

26 Operating System Review

High

Audit logs not formally reviewed

27 Operating System Review

Medium

Excessive access granted to "World"


group

28 Operating System Review

Low

Unsecure FTP service running

29 Operating System Review

High

Users are allowed to log in directly with


the root account

30 Operating System Review

Low

No legal banner displayed at login

31 Operating System Review

High

Operating system accounts were shared

32 Operating System Review

High

Password controls were weak

33 Database Review

High

Auditing has not been enabled

34 Database Review

Medium

DBA granted access to logs at OS level

35 Database Review

Medium

Only one control file configured for the


database

36 Database Review

Medium

Excessive access granted to "World"


group at OS level

37 Database Review

High

38 Database Review

Medium

Privileged user have access to more than


one technology stack

Weak database profile settings

39 Database Review

Low

Listener file not adequately protected

42 Operating System Review

Medium

Users are allowed to log in directly with


the root account

43 Operating System Review

High

Operating system accounts were shared

46 Database Review

High

47 Database Review

Medium

48 Database Review

High

Auditing has not been enabled on the


database

Excessive access granted to "World"


group at OS level

Privileged user have access to more than


one technology stack

49 Database Review

High

Database accounts were shared

50 Database Review

High

Generic user ID's were identified

52 Database Review

54 Operating System Review

High

Medium

Weak database profile settings

No formal review of log files

56 Operating System Review

Medium

Users are allowed to log in directly with


the root account

57 Operating System Review

Low

No legal banner displayed at login

58 Operating System Review

High

Operating system accounts were shared

59 Operating System Review

Medium

Dormant and inactive accounts identified

60 Operating System Review

Medium

Excessive privileges granted to users

62 Operating System Review

High

Operating system accounts were shared

63 Operating System Review

High

Generic user ID's were identified

65 Operating System Review

Medium

No formal review of log files

67 Operating System Review

Medium

Users are allowed to log in directly with


the root account

68 Operating System Review

Low

No legal banner displayed at login

69 Operating System Review

High

Operating system accounts were shared

82 Operating System Review

High

No formal review of log files

85 Operating System Review

High

Operating system accounts were shared

Medium

Users are allowed to log in directly with


the root account

103 Operating System Review

105 Operating System Review

High

Operating system accounts were shared

109 Operating System Review

High

Auditing was not enabled

110 Operating System Review

Low

The default administrator account has not


been renamed

111 Operating System Review

High

Unauthorised users could have access to


the system

112 Operating System Review

Medium

Lockout duration is not appropriately set

113 Database Review

Medium

Inappropriate login attepms audited

114 Database Review

Medium

DBA granted excessive access at OS level

115 Database Review

Medium

Weak password controls inherent from the


OS level

116 Database Review

High

Non system administrators granted


excessive privileges

117 Database Review

130 TT File Reconcliations

Low

Medium

Database management system not


updated

TT Files not processed

131 CDR Level End-to-End


Reconciliation

High

Inability to retain post rated pre-paid


CDRs

134 Network Integrity

High

Diferences identified between re-rated


test calls and calls rated by the billing
system

139 Key Reports

High

Diferences between system data and


billing system reports

140 Error Management

141 Granting of Credit to Prepaid


subscribers

Medium

High

Volume of CDRs in error

Reconciliations not performed consistently

143 General

High

Data transformation rules are not


formalised

144 General

High

Lack of data to support testing

Revenue Receivables

Important

Post paid customer credit limits must be


monitored to avoid any excesses which
increase the Companys credit risk
exposure.

Issues' Resolution Progress Tracker


Reference
2.1.1.5

Recommendation
MTN Swaziland should
explore the possibility of
deploying a test
environment for all
systems within scope.

Agreed Management
Action

Agreed Action Date

Primary
Department

The risk posed by the


lack of stand-alone test
environments for the
critical network nodes
has been presented to
OPCO management for
acceptance. There are
risks posed by the lack
of the test environment
in the critical nodes of
the telecommunication
network (HLR, SDP,
MSC, etc), but tests are
performed in an
environment that is
expertnal of the
operational
environment. Changes
are implemented on the
standby nodes and
tested before being
loaded into the primary
nodes.

N/A

Information
Systems

MINSAT is a none
critical system as it is a
reporting tool that
extracts data from
source systems. if
MINSAT could be
compromised, the data
will not be afected as it
is not produced by
MINSAT, but by other
systems from which
MINSAT extracts for
reporting.
This rating should be

2.1.2.3

Periodic restoration of the Testing of backup media


backup tapes should be for the network systems
performed. Evidence of
is performed and
the restoration
logged on remedy.
procedures and testing
Beginning from August,
performed to ensure the these test are
completeness and
performed on a monthly
accuracy of the restored basis. Systems covered
data should be retained. include the MSC, which
includes the HLR.
While restoration tests
are performed for IS
systems, no evidence
can be produced.
restoration tests will be
logged on Remedy to
provide as evidence
going forward.
MINSAT is a none
critical reporting
system. It reads data
from other systems,
and that data can be
readily available if
required.

31-Mar-2012

Information
Systems

2.1.2.5

Swazi MTN should


A plan will be
identify backup resources developed to address
for key IS staf, especially the critical process
the database
areas and it will be
administrator. In addition, incorporated into the
IS management should
BCP. However, for all
ensure that the job
systems there is a
activity of key staf,
designated primary and
especially the database secondary system
administrator is
administrator. The
adequately documented efectiveness of the
to enable replacement
primary and secondary
staf to conduct the
roles will take sometime
required roles.
as it requires
investment in training
and development. the
2012 training plan
begins this process.

31-Dec-2012

Information
Systems

2.1.3.3

Management should
institute a process to
review user access rights
on a periodic basis to
ensure that these rights
are commensurate with
job responsibilities. This
should be applied to all
critical systems, at
minimum.

31-Mar-2012

Information
Systems

The finding is accepted


and should be rated
medium. To send access
reports to system
owners for review on a
quarterly basis. The
business systems
owners will be
responsible for the
review.

2.1.3.4

Management should
institute a process to
delete user access rights
on termination.

Users are not removed


from our systems, but
deactivated. This is
meant to retain their
transaction history
attached to their user
accounts. These
accounts are not active
within the diferent
systems.

31-Mar-2012

Information
Systems

30-Jun-2012

Information
Systems

N/A

Information
Systems

We therefore
recommend that this
finding should be
removed from the
report.

2.2.1.1

Logs should be reviewed Audit logs are being


regularly and the
reviewed informally, by
evidence ratined to
system administrators.
ensure that a process is A formal process of
in place to detect
reviewing audit logs will
unauthorised activities on be established, with the
the operating system.
purchase of a tool that
will allow for efective
review of logs.

2.2.1.2

The database files should


be appropriately
protected at operating
system level to ensure
that only the appropriate
and authorised users
have access to them.

System access is
restricted to
administrators.
Permissions can be
removed but presently
the people with the
view access are
privileged.

2.2.1.3

Disable unnecessary
Business needs to
services if not needed. If accept risk for this
these services must be
service.
used, ensure that the
latest version is being
used and that their use is
restricted, with only
properly authorised
individuals being able to
use them. Alternatively
explore the possibility of
using alternative more
secure services that
integrate with existing
controls.

N/A

Information
Systems

we recommend that
should FTP be required,
management should
explore other more
secure protocols such as
secure FTP.

2.2.1.4

Direct log in with the root


account should be
disabled. Users should
-su to root so that a
record of root usage is
kept.

There are no warmbodied users that have


access on the server.
The root account is the
only way to access the
system. Users login
using individual IDs and
-su to root will be
monitored.

N/A

Information
Systems

2.2.1.5

An appropriate legal
notice approved by the
MTN legal department
should be displayed upon
direct authentication to
this environment.

Standardised banner
could be included and
applied throughout all
systems. Enticement
information can be
removed.

N/A

Information
Systems

2.2.1.6

System administrators
should be allocated to
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

We will investigate
granting access to
warm-bodied users for
usage of the root
account.

2.2.1.7

A manual process should


be implemented which
ensures that system
account passwords are
changed at least
annually. The minimum
password age should be
set to 2 days. User
accounts should be
forced to be locked after
3-5 invalid password
attempts.

We will investigate
password control
parameters and
password management
processes and apply
them as necessary.

2.2.2.1

Auditing should be
Refer to attached
appropriately enabled
collective response.
and configured as
defined by the business.
Emphasis should be
placed on the auditing of
users who authenticate
directly to the database.
The audit logs should be
reviewd in a regular basis
by a security officer and
any unauthorised
activities conducted on
the database should be
reported to management.

N/A

Information
Systems

N/A

Information
Systems

31-Mar-2012

Information
Systems

The department will


motivate the business
to accept the risk for
the Oracle account

2.2.2.2

Management should
Refer to attached
ensure that audit logs are collective response.
protected from access by
privileged users.
Furthermore, a security
administrator (not a DBA)
should oversee the setup
of auditing on the
database environment.

31-Mar-2012

Information
Systems

2.2.2.3

Management should
Refer to attached
ensure that at least more collective response.
than 3 control files exist
for the database.

31-Mar-2012

Information
Systems

2.2.2.4

The database files should Refer to attached


be appropriately
collective response.
protected at operating
system level to ensure
that only the appropriate
and authorised users
have access to them.

31-Mar-2012

Information
Systems

2.2.2.5

Users with privileged


Refer to attached
access to the operating collective response.
system and database
should be separated. If
this is not practical, then
a formal process should
be implemented to
ensure that appropriate
logging of usage should
be implemented and
reviewed on a regular
basis for these accounts.

31-Mar-2012

Information
Systems

2.2.2.6

We recommend that all


Refer to attached
user accounts be
collective response.
allocated to profiles
which are in line with
their job responsibilities.
Furthermore, profiles
should be created for
each class of user who
authenticates directly to
the database (e.g.,
database administrators,
security officers, etc) and
applicable profiles
assigned to each user ID.
the following is a
guideline of parameter
settings for the profiles
allocated to users who
authenticate directly to
the database:
- Sessions_per_user = 1
- Idle_time = 30
- Failed_Login_Attempts =
3
- Password_Life_time =
30
- Password_Reuse_Time =
360
- Password_Reuse_Max =
12
Password_Verify_Function
= "Link to SQL function"
- Password_Lock_Time =
24
- Password_Grace_Time =
5

31-Mar-2012

Information
Systems

The RESOURCE_LIMIT

2.2.2.7

Management should
ensure tha the listener
file is securely
configured.

Refer to attached
collective response.

31-Mar-2012

Information
Systems

2.3.1.3

Direct log in with the root Refer to attached


account should be
collective response.
disabled. Users should
-su to root so that a
record of root usage is
kept.

31-Mar-2012

Information
Systems

2.3.1.4

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.3.2.1

Auditing should be
Refer to attached
appropriately enabled
collective response.
and configured as
defined by the business.
Emphasis should be
placed on the auditing of
users who authenticate
directly to the database.
The audit logs should be
reviewd in a regular basis
by a security officer and
any unauthorised
activities conducted on
the database should be
reported to management.

31-Mar-2012

Information
Systems

2.3.2.2

The database files should refer to attached


be appropriately
collective response.
protected at operating
system level to ensure
that only the appropriate
and authorised users
have access to them.

31-Mar-2012

Information
Systems

2.3.2.3

Users with privileged


Refer to attached
access to the operating collective response.
system and database
should be separated. If
this is not practical, then
a formal process should
be implemented to
ensure that appropriate
logging of usage should
be implemented and
reviewed on a regular
basis for these accounts.

31-Mar-2012

Information
Systems

2.3.2.4

Each user should be


assigned his/her own
account and a formal
password procedure
should be implemented
for the password to
ensure accountability.

Refer to attached
collective response.

31-Mar-2012

Information
Systems

2.3.2.5

The use of generic user Refer to attached


ID's should generally be collective response.
restricted. If usage
cannot be avoidable, the
use thereof should be
reviewed on a regular
basis and any security or
unlawful activities that
have taken place should
be highlighted,
investigated and reported
to management.

31-Mar-2012

Information
Systems

Additionally, a system
auditing policy should be
formalised and published.

2.3.2.7

2.4.1.1

We recommend that all


Refer to attached
user accounts be
collective response.
allocated to profiles
which are in line with
their job responsibilities.
Furthermore, profiles
should be created for
each class of user who
authenticates directly to
the database (e.g.,
database administrators,
security officers, etc) and
applicable profiles
assigned to each user ID.
the following is a
guideline of parameter
settings for the profiles
allocated to users who
authenticate directly to
the database:
- Sessions_per_user = 1
- Idle_time = 30
- Failed_Login_Attempts =
3
- Password_Life_time =
30
- Password_Reuse_Time =
360
- Password_Reuse_Max =
12
Password_Verify_Function
= "Link to SQL function"
- Password_Lock_Time =
24
- Password_Grace_Time =
5
The RESOURCE_LIMIT
Logs should be reviewed Refer to attached
regularly and the
collective response.
evidence ratined to
ensure that a process is
in place to detect
unauthorised activities on
the operating system.

31-Mar-2012

Information
Systems

31-Mar-2012

Information
Systems

2.4.1.3

Direct log in with the root Refer to attached


account should be
collective response.
disabled. Users should
-su to root so that a
record of root usage is
kept.

31-Mar-2012

Information
Systems

2.4.1.4

An appropriate legal
Refer to attached
notice approved by the
collective response.
MTN legal department
should be displayed upon
direct authentication to
this environment.

31-Mar-2012

Information
Systems

2.4.1.5

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.4.1.6

Dormant and inactive


Refer to attached
accounts should be
collective response.
investigated and disabled
accordingly.

31-Mar-2012

Information
Systems

2.4.1.7

Management should
Refer to attached
ensure that an
collective response.
accountable person has
been appoited for all
administrator logins, and
the users that use the
login are authorised to
have adminstrator
access.

31-Mar-2012

Information
Systems

2.5.1.1

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.5.1.2

We recommend tha these Refer to attached


accounts be investigated collective response.
to determine their origin
and ownership.

31-Mar-2012

Network

We also recommend that


any unused accounts
then be removed from
the server.

2.6.1.1

Logs should be reviewed Refer to attached


regularly and the
collective response.
evidence ratined to
ensure that a process is
in place to detect
unauthorised activities on
the operating system.

31-Mar-2012

Information
Systems

2.6.1.3

Direct log in with the root Refer to attached


account should be
collective response.
disabled. Users should
-su to root so that a
record of root usage is
kept.

31-Mar-2012

Information
Systems

2.6.1.4

An appropriate legal
Refer to attached
notice approved by the
collective response.
MTN legal department
should be displayed upon
direct authentication to
this environment.

31-Mar-2012

Information
Systems

2.6.1.5

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.7.1.1

Logs should be reviewed Refer to attached


regularly and the
collective response.
evidence ratined to
ensure that a process is
in place to detect
unauthorised activities on
the operating system.

31-Mar-2012

Information
Systems

2.7.1.4

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.9.1.3

Direct log in with the root Refer to attached


account should be
collective response.
disabled. Users should
-su to root so that a
record of root usage is
kept.

31-Mar-2012

Information
Systems

2.9.1.5

System administrators
Refer to attached
should be allocated to
collective response.
the own user accounts
and granted appropriate
access. The system
password should be kept
in a safe and the account
used only when there is
an emergency.

31-Mar-2012

Information
Systems

2.10.1.1

Auditing should be
Refer to attached
appropriately enabled
collective response.
and configured as
defined by the business.
Emphasis should be
placed on the auditing of
users who authenticate
directly to the database.
The audit logs should be
reviewd in a regular basis
by a security officer and
any unauthorised
activities conducted on
the database should
reported to management.

31-Mar-2012

Information
Systems

2.10.1.2

The administrator
account should be
renamed as it is a prime
target for unauthorised
users to abuse.

31-Mar-2012

Information
Systems

Refer to attached
collective response.

2.10.1.3

Controls over the use of Refer to attached


shared accounts should collective response.
be implemented with
only one person able to
use these accounts at
any point in time. Any
usage of the privileged
account by vendors and
administrators should be
formally monitored and
the usage justified. At a
minimum, the activities
of the privileged account
should be logged and
regularly reviewed.

31-Mar-2012

Information
Systems

2.10.1.4

The lockout duration


should be set to
"forever". The accounts
should remain locked
until the administrator
unlocks it.

Refer to attached
collective response.

31-Mar-2012

Information
Systems

2.10.2.1

All key login attempts


should be logged and
reviewed on a regular
basis to identify any
patterns out of the
ordinary logon attempts.

Refer to attached
collective response.

31-Mar-2012

Information
Systems

The implementation of
appropriate login will be
set up in conjunction
with the SEA HUB.

2.10.2.2

Management should
ensure that audit logs are
protected from access by
privileged users.
Furthermore, a security
administrator (not a DBA)
should oversee the setup
of auditing on the
database environment.

Refer to attached
collective response.

31-Mar-2012

Information
Systems

31-Mar-2012

Information
Systems

31-Mar-2012

Information
Systems

The implementation of
appropriate login will be
set up in conjunction
with the SEA HUB.

Furthermore, access to
program and data
directories shoulc be
secured and accessible
only by authorised
personnel.

2.10.2.3

Management should
ensure that secure
password controls are
configured for all
technology stacks across
the system and applied
appropriately to the
users.

Refer to attached
collective response.
Complex passwords will
be set.\

The lockout duration


should be set to
"forever". The user
account should remain
locked until the
Administrator unlocks it.

2.10.2.4

All privileges provided to


PUBLIC should be
investigated and
removed if possible. If
this is not practical, then
a formalised process
should be implemented
to monitor and review
the usage thereof.

Refer to attached
collective response.
Vendor will be engaged
to see necessity of the
use of PUBLIC. If
required, monitoring
processes will be
implemented.

2.10.2.5

5.2

We recommend that the


latest security patches
should be installed and
properly configured.

Refer to attached
collective response.

We recommend that
management investigate
the root cause of these
missing TT-files. A
process should be put in
place to ensure that
adequate provision is
made to safeguard the
switch files. We
recommend that TT-files
are backed up on a daily
basis, and that the
backups be regularly
tested to ensure that
they can be restored.
We further recommend
that MTN takes legal
advice regarding the loss
of data to determine
whether the law or
telecommunications
regulations have been
violated as a result of the
data not being available.
MTN should also confirm
what data should be
retained, and for what
period.

As from September
2011 RA is monitoring
billing TT file sequences
and reporting missing
files to the billing team
on a weekly basis. As
this is dynamic data
and billing has a
specific cut of date,
there bound to be a few
files not processed in
the same period but RA
ensures that these are
resolved within the
required 90 days.
Therefore RA will
continue to monitor
these on a weekly
basis.

31-Mar-2012

Information
Systems

N/A

Information
Systems

We will test and apply


the latest service pack.

6.1

The lack of system


resources to retain billed
prepaid events is a high
risk. One of the most
critical revenue
assurance activities is to
reconcile switch CDRs to
billing CDRs on a daily
basis. RA is restricted in
performing its function
without the supply of
accurate and complete
data. Management
should therefore address
this high risk issue and
resolve with a solution
that is adequate.

This will be resolve


once Ericsson resolves
the CRS problem and
the implementation of
the RA tool later in the
year.

31-Jan-2012

Information
Systems

7.1

We recommend that
management further
investigate these
diferences. Management
is urged to review tarif
configurations to ensure
that the correct tarif
rules are being applied.
Furthermore,
billing/rating systems
should be corrected for
errors identified. Regular
reviews of the billing
system logic should be
conducted by the
Revenue Assurance
department.
Management should
consider the regulatory
impact of this issue
including the possible
need to provide
compensation to
subscribers.

RA is monitoring
diferences in charging
on a weekly basis and
exceptions forwarded to
networks for further
investigation. Networks
is still in the process of
testing the root cause
of the various
diferences and has
requested Ericssons
assistance in this
matter.

N/A

Information
Systems

To resolve this issue the


business has identified
the need to have a
single source of data
warehouse which will
then be used as the
reporting source for all
key reports. This will be
addressed by the
implementation of the
Business Intelligence
tool.

31-Jan-2012

Information
Systems

We also recommend that


RA re-rate the test calls,
compare the re-rated
calls to the actual charge
and then follow up on
diferences.

10.1

We recommend that
management investigate
the reporting diference
and document and
approved the method
and rules that produce
the usage reports.

11.1

The error management


process should be
formalised and
documented. We
recommend that old
errors be archived or
purged and the live error
log should only contain
the current error CDRs.
We also recommend that
an ageing of CDRs be
performed by billing
administrator taking into
account all of the data in
the error bucket and then
filtering for various
dates/types.

The Technology
department is working
on motivating for data
that is older than 3months in the error
bucket to be archived
and removed from the
systems environment.
Once this has been
achieved, the data will
be archived on a
quarterly basis to
ensure that errors
within the error bucket
are still relevant for
processing. Technology
will also document a
formal process of
managing error
buckets.

31-Jan-2012

Information
Systems

11.2

A formalised process
should be put in place for
the preparation and
review of the
reconciliations by a
person independent of
the preparation of the
spreadsheets as well as
independent of making
the actual adjustments
on MINSAT as well as
VTU.

As part of Continuous
Monitoring, all credit
granting and
adjustments processed
afecting customer
balances or outstanding
balance are reconciled
and reported on a
weekly basis. With the
upgrading of the VTU
system, RA is also able
to monitor adjustments
and reconcile these to
the manual
spreadsheets and
source documents, a
process to be reviewed
on a monthly basis
starting January 2012.

31-Jan-2012

Information
Systems

13.1

A data transformation
rule document should be
created and maintained
which includes all data
transformation rules for
all major income streams
and processes.

Technology to review,
amend and modify the
data process provided
by Ericsson for the
Swazi MTN
environment.

12.2

We recommend that
management formalize
the process for:
Assigning audit liaisons
to be the gatekeepers to
resources and
information within each
part of the business.
Extracting data to
support the various tests.
This will include:
Incorporating the data
extraction into the
operational procedures of
the relevant IS and
Network Group staf
members
Linking the data
extraction to key
performance indicators of
the relevant staf
Communicating the
importance of the data in
support of assurance
functions
Follow up on data
extractions that were
either not provided or not
provided timeously. This
will include a reschedule
of the missed data
extraction as well as an
understanding of why the
data could not be
extracted.
We requested the
remote server to have 8
TB of space but we have
only been allocated 1 TB.

This has been greatly


addressed by the
Continuous Monitoring
Project implemented in
September 2011,
whereby RA has a
server that collects all
data required for
testing purposes. The
challenge with CRS will
be resolved by Ericsson
in Q1. Furthermore, RA
will be implementing an
RA Tool in 2012 which is
a holistic approach to
obtaining data from
source, decoding the
data and storing large
amounts sufficient for
analysis. Technology
will further implement
Business Intelligence
which is a complete
data warehouse and
therefore another
source of data.

31-Jan-2012

Information
Systems

N/A

Information
Systems

1.2

Customer credit limits


must be monitored to
avoid any excesses which
increase the companys
credit risk exposure.

The billing systems


automatically suspends
the customers account
when it reaches the
credit limit, however,
this functionality is
depended on call rating
occurring almost real
time to update the
customer accounts and
therefore enable the
credit management
function check actual
usage against credit
limit and suspend
accordingly.
Discussions with IT
were held and it was
agreed that call rating
will be done frequently
to enable the credit
management to
function properly.

N/A

Information
Systems

er
Status

Management Comment
(FY12 Q1 Status)
The issue of motivating for some risks to
be accepted by the business has been
escalated to the Board of Directors for
consideration and review.

Not Resolved

No change in status

Resolved
Pending IA
Follow-Up

Resolved and
Closed
No change in status

Not Resolved

Resolved
Pending IA
Follow-Up

Resolved and
Closed
The issue of motivating for some risks to
be accepted by the business has been
escalated to the Board of Directors for
consideration and review.

Resolved and
Closed

The issue of motivating for some risks to


be accepted by the business has been
escalated to the Board of Directors for
consideration and review.

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

An MTN approved legal banner has been


placed on all the UNIX servers of MTN
Swaziland.

Not Resolved

Resolved and
Closed

Resolved and
Closed

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

No change in status

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Resolved and
Closed

Resolved and
Closed

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending IA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Not Resolved
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Not Resolved
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
Login directly using the root account has
been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending IA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending IA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

An MTN approved legal banner has been


placed on all the UNIX servers of MTN
Swaziland.

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

Resolved and
Closed

Resolved and
Closed

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

Resolved and
Closed

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending IA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

An MTN approved legal banner has been


placed on all the UNIX servers of MTN
Swaziland.

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

Resolved and
Closed

Resolved and
Closed

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

Resolved and
Closed

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed

Login directly using the root account has


been disabled. System Administrators are
now required to logon using their
personal user credentials, and then - su to
the root account

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Resolved and
Closed

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending IA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved and
Closed
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up
The baseline standard document for the
configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.
Once finalised, it will be submitted to the
appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

The baseline standard document for the


configuration of all servers of Swazi MTN
is still under development. This baseline
standard will take into consideration all
the audit issues related to it.

Once finalised, it will be submitted to the


appropriate structures for adoption and
approval.
Thereafter, an efort to bring all servers to
conformance with this baseline will be
made.

Resolved
Pending EA
Follow-Up

Resolved
Pending IA
Follow-Up

No movement in this issue

Resolved
Pending EA
Follow-Up

To obtain guidance from RA audit that is


currently underway.

Resolved
Pending IA
Follow-Up

Resolved
Pending EA
Follow-Up

No movement in this issue

To obtain guidance from RA audit that is


currently underway.

Resolved
Pending IA
Follow-Up

Resolved
Pending IA
Follow-Up

No movement in this issue

To obtain guidance from RA audit that is


currently underway.

Not Resolved

Resolved
Pending IA
Follow-Up

To obtain guidance from RA audit that is


currently underway.

Resolved
Pending IA
Follow-Up

Status at Follow-Up (05 Sep 2012)


Escalated to the board. Presented to the board on the
29th May 2012.

IS department will set specific dates at which file


restoration tests will be conducted. An independent
assurance resource (Internal Audit) will be invited to
observe the restoration process. As a start, the tests
will be for the VTU system.

The DBA responsibilities have been migrated to the


SEA HUB DB administration team.
The application support responsibilities will now be
shared between the local applications' team and the
SEA HUB application team.
The above will ensure that the there is a spread in the
ability to support these functions, which will then
allow for continuity of services for any eventualities.

IS to send a list of the system user access to the HoD


for feedback on the review. This will be done by the
30th September 2012.

Escalated to the board. Presented to the board on the


29th May 2012.

Confirmed with Ncamiso

This issue has not been resolved. Management should


motivate for the acceptance of the risk by the
relevant level of escalation level per the escalation
procedures.
(Tipho to advise on the escalation based on the
delegation of authority)

Check with Vijay

Resolved. Biswa to send evidence and only then can


the issue be closed.

The "root" account password has been changed and


access to it has been restricted. Policy has been
invoked to manage the control of the "root" account
password. Direct logon at the OS level using the
"root" account has been disabled. Instead, any user
that requires the use of the "root" account, e.g., DBA,
SAs, etc, is required to first logon using his/her
account and then switch to the "root" account.

Pending with MTN SEA IT HUB CAB and


implementation teams (CR 8578)

However, there are challenges with the


implementation of this issue due to the lack
of a proper environment to test the
solution. This requirement will be
incorporated into the new database
environment of Ability (Wave 1.2 project).

To be confirmed by the external auditors. According to


the System Administrator (Vijay), there is no "World"
group that exist at the operating system level of the
Ability database environment.

The "oracle" account password has been changed


and access to it is restricted to the Swaziland resident
DBA (Biswamaya) and the DB administration team at
the Hub. Ncamiso and Phephisa still have access at
the operating system and application/database levels
as they have responsibilities that require this access.
however, their level of access is restricted to the
levels that are required by their responsibilities.

The DEFAULT profile is used by application dependent


accounts. As a result, changing this profile will
severely impact the performance of the application.
The MONITORING profile is used by Uptime
Monitoring Tool, which is used to monitor the whole
system environment within the IS department. As a
result, these profiles cannot be changed to the
recommended settings.
The WDBA profile is used by the DB administration
team in Swaziland (Biswamaya) and at the SEA HUB.
This profile has all the confirguration settings that
ensure the necessary security of the DB environment.

CR has been submitted and approved by the local


change control team (NCCA). The NCCA has
forwarded it to the SEA HUB CAB, which is expected
to give a go ahead on the implementation of the CR.
All Oracle DBs within the environment will be
configured per the CR, on server at a time, per the
NCCA condition. An update will be available by th 16
July 2012.
CR8578.

Noting the challenges with the point


2.2.2.3,a new CR will be raised to address
this point.

Confirmed

Auditing has been enabled on all other Oracle


databases other than Ability. This was due to the
billing cycle being in progress. Feedback to be
provided on the th 16 July 2012.
===============
See comment on Ability database. The databases are
in a clustered environment.

To be confirmed by the external auditors. According to


the System Administrator (Vijay), there is no "World"
group that exist at the operating system level of the
CRS database environment.

The "oracle" account password has been changed


and access to it is restricted to the Swaziland resident
DBA (Biswamaya) and the DB administration team at
the Hub. Sabelo, Nkosingiphile and Ericsson Support
still have access at the operating system and
application/database levels as they have
responsibilities that require this access. However,
their level of access is restricted to the levels that are
required by their responsibilities.

Resolved.

All the generic accounts, except the Outln account


have been removed. The outln account has been
maintained, however, it has been expired from the
system.

Confirmed

Confirmed

Inactive accounts have been removed. Only a limited


number of accounts remain - admin (advised to
change to a more identifable name; vkhadmin (Vijay),
wepro - used by the Wipro consultants and 2 other
system accounts that are used by applications.

The identified user accounts are disabled at the


operating system level. They are only enabled when
testing the ftp configurations in readiness for the
EMM ftp sessions.
Being person-linked accounts, their use/abuse can be
identified through the existing logging processes.

Busi to confirm Left open.


Jabu to obtain Ericsson confirmation and update.

Part of uptime monitoring

Busi to confirm Left open.

Uptime Monitoring Tool is used to review the


operating systems in terms of which services and
which are not. Flags have been configured for specific
events to be raised so that attention can be taken to
resolve them.

Confirmed

Confirmed

TS to make follow-up with SphaD on Friday, 14 Sept


2012.

Confirmed

Confirmed

External Auditors will have to make a review of the


findings that relate to the VTU database environment.
The report indicates that the database environment is
SQL 2005 yet the environment is SQL 2008.

External Auditors will have to make a review of the


findings that relate to the VTU database environment.
The report indicates that the database environment is
SQL 2005 yet the environment is SQL 2008.

External Auditors will have to make a review of the


findings that relate to the VTU database environment.
The report indicates that the database environment is
SQL 2005 yet the environment is SQL 2008.

External Auditors will have to make a review of the


findings that relate to the VTU database environment.
The report indicates that the database environment is
SQL 2005 yet the environment is SQL 2008.

External Auditors will have to make a review of the


findings that relate to the VTU database environment.
The report indicates that the database environment is
SQL 2005 yet the environment is SQL 2008.

To obtain guidance from current RA audit being


performed.

Management would like to discuss with the external


auditors about the issue.

TS to confirm with Elgiva and Ntokozo on the agreed


process to manage the prepaid CDR (28th September
2012)

2011 Internal Audit Issues' R


Process Area

2011 IA
Plan

Risk Rating

Title or Recommendation

Disaster Recovery

Yes

High

Business departments have not


defined RTOs and RPO to guide
DR Plans for diferent systems.

Disaster Recovery

Yes

High

Lack of incident management


system.

Disaster Recovery

Yes

Medium

Storage and transportation of


backup media.

Disaster Recovery

Yes

High

Disaster Recovery

Yes

Medium

MSC' in pool weaknesses

Disaster Recovery

Yes

Medium

Lack of media gateway


redundancies

Disaster Recovery

Yes

Medium

Deficiencies to the Virtual Top-Up


Continuity Planning

Disaster Recovery

Yes

Medium

Inadequate EMM Disaster


Recovery and Service Continuity
Plan

Data Integrity

Yes

High

Maintenance of data
completeness and accuracy
(Error correction processes)

10 Data Integrity

Yes

High

Monitoring of production
environment (Backup power)

11 Data Integrity

Yes

High

Access to systems and data


(@bility)

12 Data Integrity

Yes

High

Access to systems and data


(CDRLive)

13 Data Integrity

Yes

Medium

Access to systems and data


(Sage Line 500)

14 Data Integrity

Yes

High

Access to systems and data


(VTU)

Lack of synchronisation between


HLRs.

15 Data Integrity

Yes

High

16 Data Integrity

Yes

Medium

17 Data Integrity

Yes

High

Network Security Settings

18 Data Integrity

Yes

High

Postpaid subscriber management

19 Data Integrity

Yes

Low

M2U

High

Lines that are part of the Finance


Department population but not
part of the Network Technology
Department population.

20 Leased Lines

No

Roaming partner management

SDP HLR reconciliations

21 Leased Lines

No

High

Lines that are part of both the


Finance Department and
Technology populations but have
been decommissioned.

22 Leased Lines

No

High

Commissioning dates of
communication lines

23 Rebates Report

No

High

Rebates report includes voucher


loadings

24 Revenue Assurance

No

Medium

25 Revenue Assurance

No

High

CDR Information

26 Revenue Assurance

No

High

Prepaid - HLR to SDP Recon

27 Revenue Assurance

No

High

Prepaid SDP to A4L Recon

28 Revenue Assurance

No

High

Prepaid EVD

Training

29 Revenue Assurance

No

Medium

Prepaid High Balances on IN

30 Revenue Assurance

No

Medium

Postpaid Error bucket

31 Revenue Assurance

No

High

32 Revenue Assurance

No

Medium

Interconnect

33 Revenue Assurance

No

Medium

Postpaid TAP IN

34 Revenue Assurance

No

Medium

Postpaid TAP OUT

35 Revenue Assurance

No

Medium

GPRS

36

37

Annual Leave Days


Management

Annual Leave Days


Management

No

No

Postpaid End to End Recon

Unsatisfactory

Amounts of leave taken should


be recorded to update leave
balances. Consulting leave
balances will determine whether
the applicant has sufficient leave
to cover the absences. If they do
not, then the leave will need to
be converted to another form
such as leave without pay.

Unsatisfactory

It is important that all types of


leave be accurately and
timeously documented in HRIS.
Accurate, complete leave data is
essential to ensure leave policies
are fully respected and to
provide a reliable database for
meaningful trend and exception
monitoring.

38

Annual Leave Days


Management

Annual Leave Days


39
Management

No

No

Unsatisfactory

Management must be consistent


when approving leave requests
and they must verify the leave
entitlement prior to approval.
Timely reconciliation and follow
up on descrepancies is
recommended. Appropriate
departmental monitoring process
should be put in place to monitor
leave administration so that
areas of risk can be identified
and mitigated.

Unsatisfactory

All leave requests must be acted


upon by immediate supervisors
and a sound sytsem of leave
approval delegation put in place.

40

Annual Leave Days


Management

No

Unsatisfactory

A more accountable approach is


for the department to specify
that approval of annual leave
after the event should be held by
either senior line manager or by
the Head of Human Resources.
Applicants should provide a
written explanation to the
appropriate officer detailing the
circumstances that justify the
late application.

41

Annual Leave Days


Management

No

Unsatisfactory

Management should implement a


formalized HRIS incident and
problem management process

42

Annual Leave Days


Management

No

Unsatisfactory

The company policy states that


at the beginning of the year each
department should prepared its
leave schedule. Due to inherent
process weakness, to ensure
accurate financial reporting, this
leave schedules should be
quartely reconciled to HRIS, any
descrepancies resolved timely. To
ensure the completeness of
leave days taken, in addition to
records on HRIS, manual leave
book and Out of Office e-mail
notification, individuals should be
asked to confirm their leave days
taken and balances. This
reconciliation should be
independently reviewed by a
senior personnel than the one
who prepares it.

43

Annual Leave Days


Management

No

Unsatisfactory

All employees must adhere to


the company policy.

Unsatisfactory

Departments should manage


their employees to deplete their
leave days to the acceptable
level.

Unsatisfactory

Employees should be provided


with their leave balances every
month and certify for their
correctness. If there is a
descrepancy due to interrupted
leave, an arrangement should be
made at departmental level for
rescheduling the leave.

Annual Leave Days


44
Management

45

Annual Leave Days


Management

No

No

46

Annual Leave Days


Management

48 VTU Process

To ensure that the company


always have complete and
accurate records on the system,
line managers' leave records
should be monthly reconciled to
HRIS. Any variances resolved.
No

Unsatisfactory
Line managers should ensure
that all leave of absence are
captured into HRIS and
approved/rejected and that the
leave records on HRIS are always
complete and accurate.

No

Unsatisfactory

The executive owners and


supporters of the system should
ensure that accountabilities,
roles and responsibilities are
clearly defined and formally
communicated to managers,
employees and key stakeholders
involved in the IFS and VTM
system.

dit Issues' Resolution Progress Tracker


Reference

Agreed Management
Action

This will be resolved through


the involvement of the SEA
Shared Services Helpdesk
system.

Agreed Action
Date

Primary
Department

Primary
Responsibility

31-Mar-2012

All Departments

Heads of
Departments

31-Mar-2012

Information
Systems

Sinaye Dlamini

29-Feb-2012

Information
Systems

Sinaye Dlamini

31-Jan-2012

Network

Busi Mamba

29-Feb-2012

Network

29-Feb-2012

Network

29-Feb-2012

Information
Systems

Ncamiso
Khumalo

29-Feb-2012

Information
Systems

Ncamiso
Khumalo

31-Mar-2012

Network

Busi Mamba

31-May-2012

Network

Anand Naidoo

N/A

Information
Systems

Sinaye Dlamini

31-Mar-2012

Information
Systems

Sinaye Dlamini

31-Mar-2012

Information
Systems

Sinaye Dlamini

31-Mar-2012

Information
Systems

Sinaye Dlamini

Mcebo
Shabangu
Mcebo
Shabangu

N/A

Network

Busi Mamba

N/A

Network

Busi Mamba

31-Mar-2012

Information
Systems

Mduduzi
Dlamini

31-Mar-2012

Information
Systems

Sinaye Dlamini

N/A

Network

Busi Mamba

N/A

Network

Anand Naidoo

N/A

IS/NWG

Anand Naidoo

N/A

IS/NWG

Anand Naidoo

N/A

Network

Sabelo Bhembe

31-Jan-2012

Finance

Elgiva Sibisi

N/A

Information
Systems

Ntokozo
Mngomezulu

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

31-Jan-2012

Finance

Elgiva Sibisi

31-Mar-2012

Information
Systems

Sinaye Dlamini

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

N/A

Finance

Elgiva Sibisi

2.1

All leave should be managed


in HRIS as leave days
outstanding can be viewed
from the system by
employees applying for leave
and managers/supervisors
who approve leave. We will
recall all leave books from
diferent departments to
ensure that leave books are
no longer used.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.2

The use of manual leave


books will be discountinued to
ensure that all leave is
recorded in the system. A
follow up will be made to
managers/supervisors once in
two weeks for leave applied
but left unapproved, to ensure
that the leave application
process is closed.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.3

Agree with recommendation;


however with the use of HRIS
such descrepancies will be
avoided.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.4

Agree with recommendation;


however with the use of HRIS
such descrepancies will be
avoided. HR to conduct
monthly checks on HRIS and
follow up line mangers with
pending actions.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.5

Agreed

01 October 2011

Human
Resources

Sibusiso Nhleko

2.6

All HRIS users are notified


that an e-mail has to be sent
to HR department should they
encounter any problems with
the system. If HR not able to
sort the problem a request is
logged to group via USD
(Unicentre Service Desk).

01 October 2011

Human
Resources

Sibusiso Nhleko

2.7

Noted. With the accurate use


of HRIS, leave days
outstanding will be reliable for
provision calculation. Agree
that we need to comply with
applicable IAS's in leave
provision calculation.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.8

Agreed.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.9

Agree. Managers must


encourage employees to go
on leave to minimise huge
leave balances at year end.
Leave days above maximum
days to be carried forward to
the following financial year as
per policy will be forfeited
unless there is written
explanation from HOD why
the leave days must not be
forfeited.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.10

The HRIS administrators


should be notified by the
supervisor/manager about the
recall to modify leave days.

01 October 2011

Human
Resources

Sibusiso Nhleko

2.11

1.1

Agreed.

Despite the absence of the


aforementioned document, a
control system has been put
in place to annihilate the risk
of issuing VTU and not
creating a corresponding
invoice on sage which was a
recurring challenge in the
past. Under this system, the
manager in charge checks the
web report for all VTU
transactions and reconciles
with SAGE on a daily basis.
The VTU web and SAGE
reports are then
systematically filed for future
reference. This procedure
ensures that any VTU sale
that is erroneously or
intentionally not invoiced is
realized within 24hrs.

01 October 2011

Human
Resources

Heads of
Departments

29-Feb-2012

Sales &
Distribution

Kholekile
Mlangeni Kudiabor

Tracker
Secondary
Department
IS/NWG

Secondary
Responsibility

Status

Anand Naidoo Not Resolved

Resolved and
Closed

Network
Network

Jabulile Dlamini Not Resolved


Mcebo
Shabangu

Not Resolved
Not Resolved
Not Resolved
Not Resolved

Not Resolved

Resolved and
Closed

Not Resolved

Human
Resources

Qhakazile
Dlamini

Resolved
Pending EA
Follow-Up

All Departments

Heads of
Departments

Resolved
Pending EA
Follow-Up

Business Risk
Management

Sales &
Distribution

Resolved
Tipho Shabalala Pending EA
Follow-Up

Chris Wasswa

Resolved
Pending EA
Follow-Up

Resolved
Pending EA
Follow-Up
Not Resolved
Not Resolved

Finance

Elgiva Sibisi

Resolved
Pending IA
Follow-Up

Marketing

Cebisa
Hlatshwayo

Resolved and
Closed

Resolved and
Closed

Resolved and
Closed

Resolved and
Closed
Not Resolved
Resolved and
Closed

Finance

Elgiva Sibisi

Resolved
Pending EA
Follow-Up
Resolved and
Closed
Resolved and
Closed

Decoding issue has been resolved.

The CM team audits and reconciles all


RA is not
subscriber balances against reloads and doing any
usage, regardless of the method of
work on EVD
loading. RA will be trained on VTU in April
2012 and will then audit VTU logs and
Not Resolved
Distributor balances against subscriber
loadings and SAGE payments.

Resolved
Pending IA
Follow-Up

MINSAT has been upgraded and


subscriber transactions can be viewed
using a date filter. A full subscriber
balance reconciliation is done by the CM
team on a monthly basis and no issues
are pending on this reconciliation.

Not Resolved
Information
Systems

Sinaye Dlamini

Resolved
Pending IA
Follow-Up

CM doing a MSC - Billing check.

Resolved and
Closed
Resolved
Pending IA
Follow-Up
Resolved
Pending IA
Follow-Up

No reconciling with the MARC. Have had


to change the status due to CM
discontinuing TAP IN tests.
CM doing a MSC - TAP OUT files. Missing a
leg to MARC

End-to-end not being done. CM doing


Resolved and some work on the GGSN.
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

All Departments

Heads of
Departments

Resolved and
Closed

Resolved
Pending IA
Follow-Up

Status by Department
Department
Information Systems
Networks
Finance
Marketing
Sales and Distribution
Mobile Money
Human Resources
TOTAL

# of Issues (EA)
# of Issues (IA)
# CBS
Not Resolved Resolved Not Resolved Resolved Not Resolved
86
41
5
7
0
8
4
5
7
0
4
19
1
9
0
0
1
0
0
0
1
0
1
0
0
0
0
0
0
0
1
0
0
11
0
100
65
12
34
0

Resolved by Department
Department
Information Systems
Networks
Finance
Marketing
Sales and Distribution
Mobile Money
Human Resources
TOTAL

# of Issues (EA)
41
4
19
1
0
0
0
65

# of Issues (IA)
7
7
9
0
0
0
11
34

External Audit
# CBS
Resolved
0
0
0
0
0
7
0
7

Total (Not
Resolved)
91
13
5
0
2
0
1
112

Total
(Resolved)
48
11
28
1
0
7
11
106

Total
48
11
28
1
0
0
11
99

Resolved
29
10

High
Not Resolved
34
4

Medium
Resolved
21
5

Audit
Medium
Not Resolved
30
3