Global Technology Audit Guide 14:
Mengelola User-Developed Application (UDA)
I. Pendahuluan
Dalam era perkonomian global saat ini, denyut nadi kehidupan organisasi perusahaan
dipengaruhi oleh bagaimana aktivitas IT mengelola availabilitas, integritas dan
konfidensialitas informasi serta sejauh mana sistem IT mengoperasikan prosedur-
prosedur bisnis inti.
Di sisi lain, UDA (User-Developed Applications) atau EUC (End-User Computing) dapat
melemahkan kemampuan aktivitas IT dalam meningkatkan perannya karena UDA ini
secara unik menyuguhkan tantangan tersendiri sebab secara tradisional berada di luar
proses-proses IT standar. Jika tidak dikelola secara tepat, UDA menyimpan potensi
melemahkan sistem kontrol walau berada di lingkungan organisasi perusahaan yang
tertata dengan baik.
1.1 Definisi User-Developed Applications
UDA adalah aplikasi-aplikasi yang dikembangkan oleh end user, biasanya dilakukan
secara tidak terkontrol. Sama seperti aplikasi-aplikasi IT tradisional, UDA
mengotomatisasi dan memfasilitasi proses-proses bisnis. Walaupun umumnya UDA itu
spreadsheet, namun dalam beberapa hal UDA dapat terdiri dari databases, queries,
scripts atau output dari pelbagai reporting tools. Secara umum, UDA adalah aplikasi apa
pun yang tidak dikelola dan dikembangkan dalam lingkungan yang mengindahkan IT
General Controls.
Dalam prakteknya, perusahaan yang telah memiliki lingkungan IT yang matang pun
banyak yang memanfaatkan UDA untuk kepentingan aktivitas manajemen harian mereka.
UDA digunakan mulai untuk perhitungan-perhitungan sederhana dan pelacakan
informasi sampai pemakaian macro yang kompleks untuk meng-compile laporan-laporan
keuangan. Studi-studi menunjukkan bahwa perusahaan besar dengan lingkungan IT yang
matang menggunakan ratusan bahkan ribuan spreadsheets dalam aktivitas bisnisnya.
1.2 Manfaat User-Developed Applications
Manfaat-manfaat UDA sebagai berikut:
Cepat dalam pembuatan dan penggunaanya. Untuk membuat UDA hanya butuh
waktu relatif cepat yang kalau dilakukan oleh personal IT akan tampak mahal karena
harus mengikuti prosedur siklus system development standar.
Ketersediaan tools dengan ongkos lebih rendah. Tool yang tersedia, seperti
spreadsheet, menawarkan kemudahan bagi user guna melakukan otomatisasi logika
bisnis tanpa perlu bersusah payah menunggu sistem software yang rumit dan mahal.
Dapat dikonfigurasi dan feksibel. Dibanding dengan aplikasi-aplikasi IT tradisional,
user memiliki fleksibilitas lebih besar untuk mengkonfigurasi UDA dalam memenuhi
kebutuhan bisnis. Sebagai contoh, informasi dalam spreadsheet secara mudah dapat
disortir dan diformat ulang untuk kepentingan analisa tambahan bagi user yang tidak
terlalu familiar dengan struktur data yang ada
1.3 Risiko-risiko Terkait UDA
Walaupun UDA memiliki sejumlah manfaat, namun bukan berarti tidak rentan terhadap
risiko. Risiko-risiko ini berkaitan dengan integritas, availabilitas, dan konfidensialitas.
Risiko paling signifikan adalah yang terkait dengan integritas data dan informasi yang
harus dikelola dan dilaporkan. Manajemen boleh beranggapan bahwa data yang
terkandung pada hasil proses UDA adalah handal sebagai informasi yang dikeluarkan
dari aplikasi yang dibangun IT. Namun sebagaimana sifat suatu UDA, anggapan tersebut
tentu saja tidak tepat karena UDA dikembangkan tidak melalui prosedur life cycle
pengembangan/ perubahan aplikasi terkontrol dan terstruktur.
Kontrol yang harus dilakukan sehubungan UDA berkisar pada hal-hal berikut:
Kontrol pada manajemen perubahan dan proses pengembangan yang terstruktur.
Kelemahan pada area ini dapat mengakibatkan perhitungan-perhitungan dan data
output tidak akurat. Faktor utama hal ini dapat dilacak dari pengendalian manajemen
perubahan/ proses pengembangan yang lemah pula.
Isu download data. Kelemahan kontrol seputar download data terdapat pada UDA
sebagaimana juga mungkin terdapat pada aplikasi-aplikasi tradisional IT yang dapat
membawa pada ketidakakuratan informasi.
Peningkatan kompleksitas. Risiko UDA menjadi lebih kompleks seiring berjalannya
waktu. Karena tanpa desain atau arsitektur yang memadai, error dapat terjadi dalam
manipulasi data atau output.
Kekurangan pengalaman pengembang. Pengembangan UDA yang tidak familiar
dengan fungsi-fungsi khusus aplikasi dapat menyebabkan praktek pengembanagn tak
efisien dan tak efektif. Sebagai contoh, dalam mendesain suatu formula pada
spreadsheet, pengembang UDA mungkin menggunakan ’hard code’ untuk
perhitungan ketimbang merujuk pada angka dari suatu field lain atau fungsionalitas
aplikasi yang sudah tersedia.
Kelemahan pengendalian versi. UDA boleh jadi dimodifikasi dan diperbaharui oleh
banyak individu, yang dapat membawa pada pelbagai error akibat perubahan-
perubahan tersebut.
Kelemahan dokumentasi. Ketiadaan dokumentasi formal UDA dapat menyebabkan
kesulitan pelacakan informasi seputar mekanisme input, proses dan reporting hasil
proses. Juga ketiadaan dokumentasi mengakibatkan kesulitan transfer pengetahuan
kepada pihak lain.
Kelemahan dukungan. UDA boleh jadi dibuat oleh seorang pegawai dengan
menggunakan teknologi yang tak terlalu dikenal orang banyak, maka tentu akan
memunculkan isu dukungan yang kurang.
Kontrol input dan output terbatas. Kekurangan kontrol pada input dan output yang
tepat, seperti pengecekan kelengkapan, edit validitas, dan balancing routine dapat
menyebabkan data error.
Ketiadaan pengujian formal. Kegagalan pengujian kelengkapan dan akurasi UDA
bisa menimbaulkan error yang tidak terdeteksi.
Worksheet atau kolom data tersembunyi. UDA dapat mengandung worksheet atau
kolom data yang tersembunyi yang mungkin tak terdeteksi dan teruji.
Dalam beberapa kasus, UDA tidak begitu memperhatikan konsep segregation of duties
terkait dengan siapa yang mendesain, yang mengembangkan, dan yang menguji UDA.
Bahkan end user yang membuat UDA adalah orang yang sama dengan yang
menggunakannya. Hal-hal ini akan mengantarkan pada error desain, programming dan
logikanya sendiri tanpa terdeteksi.
1.4 Perbedaan antara UDA dengan IT-developed and Supported Applications/ ITDSA
(Aplikasi yang didukung dan dikembangkan IT)
Pengembangan
Pengembangan UDA berbeda sama sekali dengan pengembangan ITDSA. ITDSA
memiliki siklus hidup standar yang terdiri dari suatu analisa kelayakan yang juga
dilengkapi dengan penilaian risiko, pendefinisian user requirement, tahap desain,
konstruksi, tahap pengujian dan post-implementation review guna meyakinkan bahwa
hasil akhir telah memenuhi kebutuhan user serta beroperasi sebagaimana desain. Melalui
tahapan-tahapan ini, perwakilan Risk Management, Internal Auditing, dan Information
Security harus menjadi bagian proses Manajemen Proyek guna meyakinkan bahwa
aplikasi dapat diimplemetasikan dengan pengendalian yang tepat.
Sebaliknya, UDA dikembangkan atas permintaan mereka yang berada di luar peran dan
tanggung jawab IT secara formal, dalam periode waktu pendek dan sering tidak
memanfaatkan internal control siklus hidup manajemen perubahan dan pengembangan
aplikasi secara terstruktur. UDA dibangun biasanya dengan pertimbangan seadanya dan
tanpa persetujuan resmi. Kontrol-kontrol aplikasi dipikirkan setelahnya, bahkan sering
kali tes-tes kecil dilakukan sekedar untuk memperlihatkan bahwa informasinya layak
dipandang. Testing aplikasi sering dilakukan oleh dia yang mendesain dan sekaligus
pemakai aplikasi tersebut. Hal lain yang membedakan dengan ITDSA, UDA tidak
disertai pendokumentasian yang memadai
Deployment
Saat ITDSA digelar pada tahap operasi, kode-kode pemrograman disimpan dalam sebuah
aplikasi manajemen source code, guna antisipasi aplikasi tersebut terkena masalah. Jika
kode tersebut berubah, audit trails biasanya ada yang mendetailkan perubahan tersebut.
Adapun UDA ditujukan untuk menanggulangi data corruption akibat kelemahan sekuriti
dan pengendalian versi. Biasanya UDA ditempatkan di lokasi umum yang mudah
diakses sehingga keamanannya rawan terhadap perubahan yang tidak terotorisasi. Begitu
pula, audit trails-nya kurang baik.
Operasi
UDA tidak dipertimbangkan sebagai proses-proses tata kelola IT karena UDA ditujukan
untuk user-user primer dan bukan bagian risk assessment IT biasa atau skema klasifikasi
data. Kontrol akses, jika ada, biasanya lemah dan jika tidak, disimpan pada drive yang
di-sharing, UDA boleh jadi tidak di-backup.
1.5 Permasalahan Compliance
Disebabkan terdapat kelemahan pengendalian terhadap UDA, maka penggunaannya akan
banyak menemui masalah yang terkait dengan kepatuhan (compliance), terutama dengan
sejumlah regulasi yang terbit di berbagai negara. Contoh regulasi ini misalnya Sarbanes-
Oxley Act USA, the Gramm-Leach-Billey Act, the Health Insurance Portability and
Accountability Act of 1996, Federal Financial Institution Examination Council Guidance,
the United Kingdom’s Data Protection Act of 1998, Japan’s Financial Instruments and
Exchange Law, Germany’s Law on Employee Confidenciality, European Privacy
Regulations, Basel II dan PCI-DSS.
Menurut Sarbanes-Oxley Act dan Japan’s Financial Instruments and Exchange Law,
perusahaan publik harus menyajikan pengendalian atas pelaporan keuangan didesain dan
beroperasi efektif. Oleh karena itu kelemahan pengendalian saat pengembangan dan
penggunaan UDA, menjadikannya harus dengan mempertimbangkan pelaporan keuangan
eksternal. Internal control harus didesain dan diimplementasikan untuk membatasi risiko
yang terkait pengembangan dan penggunaan UDA.
1.6 Peranan Internal Audit
Internal Audit berada pada posisi khusus untuk mengerti kebergantungan manajemen
terhadap UDA, mereview penggunaan UDA dan mengevaluasi risiko yang akan terjadi
pada perusahaan akibat pemakaian UDA. Untuk UDA berisiko tinggi, Internal Audit
harus merekomendasikan apakah pengembangan, proses manajemen perubahan dan
pengendalian diperlukan dan bagaimana semuanya itu dikemas kerangka pengendalian
UDA.
Internal Audit dapat merekomendasikan dan membantu perusahaan dalam
mengembangkan standar-standar berbasis risiko yang dapat digunakan untuk memacu
proses pengembangan UDA lebih tepat. Standar tersebut dapat pula digunakan untuk
mengevaluasi UDA eksisting secara periodik manakala perlu modifikasi. Walau
demikian, Internal Audit harus tetap memelihara independensinya sekalipun terlibat
dalam asistensi saat pengembangan standar, prosedur atau kontrol. Hal ini sesuai dengan
Standard Attribute 1130: Impairment to Independence or Objectivity for more
information.
Keterlibatan Internal Audit saat pengembangan UDA dapat membantu mengurangi risiko
masalah, sekuriti dan kelemahan kontrol yang tak teridentifikasi kecuali setelah
memasuki fase produksi. Perubahan yang dibuat belakangan dalam siklus hidup UDA
akan lebih mahal ketimbang dilakukan pada awal proses pengembangan, seperti saat fase
user requirement.
Namun sayangnya, pengembangan UDA bukan merupakan proyek formal sehingga
Internal Audit harus membantu manajemen meningkatkan kesadarannya terhadap standar
seputar pengembangan UDA dan aplikasi best pactice lainnya. Internal Audit dapat
membantu manajemen melalui pengembangan UDA yang efektif dan
mensosialisasikannya kepada para pengguna. Satu yang penting adalah menciptakan
definisi, misalnya bagi suatu spreadsheet yang menjadi kunci untuk pelaporan
operasional dan finansial.
Internal Audit harus mereview prosedur dan kebijakan perusahaan dalam kaitannya
dengan UDA. Apakah peraturan tersebut memadai untuk mengawal pengembangan UDA.
Internal Audit harus menguji kepatuhan prosedur dan kebijakan tersebut. Jika terdapat
defisiensi dalam peraturan tersebut, harus didokumentasikan dan dilaporkan kepada
manajemen.
Singkatnya Internal Audit harus melakukan penilaian terhadap UDA seputar hal-hal
berikut:
Menentukan apakah manjemen telah mengetahui hal-hal kritis pada UDA
Mereview risk assessment
Memilih UDA dengan signifikansi tertinggi dalam risiko
Mengevaluasi tingkat kontrol
Mereview dokumen
Menilai kontrol, jika perlu, dalam hal:
o Perubahan dan modifikasi
o Backup dan recovery
o Sekuriti
o Integritas data
II. Lingkup Pengelolaan UDA
2.1 Mendefinisikan Lingkup UDA
UDA digunakan untuk menginisiasi, mengakumulasi, merekam, membuat laporan,
atau memonitor laporan keuangan material terkait transaksi-transaksi dan laporan
manajemen.
Penggunaan UDA inheren dalam pengerjaan proses-proses kontrol operasional dan
keuangan (seperti rekonsiliasi akun dan laporan key performance indicator) sehingga
apabila spreadsheet atau data hilang/ corrupt, hal tersebut dapat mempengaruhi
efektivitas pengendalian.
2.2 Menentukan dan Mendefinisikan Populasi UDA
Teknik-teknik yang dapat digunakan untuk mengidentifikasi populasi UDA:
Mengidentifikasi dan menginventarisasi UDA dengan mengevaluasi dokumen proses
bisnis seperti narasi aliran dan prosedur proses bisnisnya.
Penggunaan kemampuan pencarian untuk mengidentifikasi file tags spreadsheet dan
database di dalam direktori file terkait proses bisnis.
Penggunaan software tools untuk mendeteksi populasi UDA (penjelasan lanjut di
bawah).
Mereview laporan-laporaan yang mengidentifikasi jurnal-jurnal manual yang
menggunakan UDA.
2.3 Mendefinisikan Faktor-faktor Risiko
Saat mengembangkan kerangka kendali UDA, proses biasanya diawali dengan
wawancara manajemen kunci dan staf terkait. Hal ini dilakukan guna memperkuat
pemahaman mengenai siapa yang akan menggunakan UDA dan bagaimana UDA
digunakan sebagai bagian proses bisnis, fungsi-fungsi laporan, program kepatuhan atau
pengendalian.
Penilaian risiko UDA yang relevan dengan objektif operasional, finansial dan kepatuhan
perusaahaan mendorong Internal Audit.pada tantangan tersendiri. Menggunakan
spreadsheet atau UDA lain dapat menyajikan risiko signifikan perusahaan, termasuk:
Isu integritas data
Error yang terjadi selama input, proses dan output temasuk interface dan pelaporan.
Error atau manipulasi yang disengaja akibat file yang tak aman atau perubahan yang
tidak terkelola.
Internal Audit dapat memandu manajemen dalam menggunakan teknik risk assessment
untuk mengidentifikasi kerentanan sehubungan dengan opersional, finansial, pelaporan
dan kepatuhan perusahaan sebagaimana dituntut oleh Performance Standard no. 2120:
Risk Management. Dua fator yang harus dinilai saat evaluasi risiko: dampak dan
probabilitas kegagalan/ risiko,
Dalam tingkat minimum, faktor risiko untuk mengidentifikasi dampak kegagalan UDA
harus mengandung hal berikut:
Materialitas kepatuhan aturan, operasional dan finansial UDA. Proses risk assessment
dimulai dengan mereview inventory UDA dan penentuan apakah kegagalan integritas
UDA menjadi ancaman terhadap kehandalan laporan keuangan, laporan manajemen
atau tuntutan kepatuhan terhadap aturan.
Umur dan frekuensi penggunaan aplikasi. Jika suatu spreadsheet atau database
dikembangkan untuk pemakaian berulang, itu akan memiliki dampak tinggi.
Jumlah user baik aplikasi maupun hasilnya. Jika spreadsheet atau database dapat
diakses untuk lebih dari satu user dan digunakan menyajikan data terhadap banyak
penerima, tentu hal itu akan memiliki dampak tinggi pula.
Pada tingkat minimum, faktor risiko untuk identifikasi probabilitas/ likelihood harus
mengandung hal berikut:
Kompleksitas dalam mendapatkan input dan menghasilkan output. Spreadsheet
dengan macro atau link terhadap database atau spreadsheet lain, jumlah data,
penggunaan data extract atau perhitungan rumit adalah beberapa hal kunci dalam
penentuan probabilitas kegagalan UDA.
Frekuensi modifikasi UDA. Semakin banyak perubahan yang terjadi pada spreadsheet
atau database, semakin tinggi risiko yang tak terkendali yang berdampak terjadinya
error pada laporan keuangan, laporan manajemen atau laporan kepatuhan pada aturan.
Kriteria tambahan untuk menentukan dampak dapat memasukan unsur berikut:
Jumlah proses bisnis yang bergantung pada UDA
Jumlah kontrol yang didukung UDA
Sumber data atau kontrol yang dapat mendeteksi kegagalan kontrol UDA
Kontrol alternatif atau sumber data yang dapat mendeteksi error UDA atau isu
integritas.
Informasi sensitif yang terkandung di dalam UDA
Kriteria tambahan untuk menentukan probabilitas/ likelihood adalah sebagai berikut:
Hubungan dengan sistem lain dan outputnya. Spreadsheet yang memproduksi output
yang diverifikasi dengan sumber data lain termasuk UDA yang tidak berisiko tinggi.
Namun spreadsheet yang bergantung pada link dari sumber data lain yang outputnya
tak mudah dikonfirmasi termasuk UDA berisiko tinggi.
Guideline yang digunakan selama desain kontrol-kontrol input dan output (seperti
area input data tidak mengandung formula atau data input dalam orde sama seperti
sumber data).
Guideline logik yang digunakan selama pengembangan UDA dan saat perubahan
dibuat untuk UDA eksisting (seperti penggunaan formula untuk foot dan cross-foot
data, me-lock dan memproteksi sel, penempatan nilai-nilai kritis dalam sel terpisah,
dll.).
Guideline yang digunakan untuk pengujian dan persetujuan UDA yang baru
dikembangkan dan modifikasi UDA eksisting.
Kegagalan kontrol sebelumnya diasosiasikan dengan kebergantungan pada UDA.
Guideline akses yang digunakan untuk kontrol akses ke dalam UDA (seperti storage).
Tanggung jawab staf dalam pembuatan dan pemeliharaan UDA.
Penggunaan kontrol versi.
Penggunaan kontrol monitoring.
Hasil penilaian faktor-faktor risiko yang dikaitkan dengan inventory UDA akan
menentukan kriteria dalam penentukan risk assessment.
Contoh Kriteria Memeringkat Dampak Risiko
1. Materialitas Finansial. Dampak laporan keuangan didefinisikan dengan
menjumlahkan transaksi keuangan yang didukung UDA dalam suatu triwulan.
Sebagai contoh:
Materialitas Finansial
Ranking Dampak pada Income
Statement
Dampak pada Balance
Sheet
High $3 juta atau lebih/ triwulan $3 juta atau lebih/ triwulan
Medium $1.5 juta - < S3 juta $1.5 juta - < S3 juta
Low <$ 1.5 juta <$ 1.5 juta
Tak Berdampak 0 0
2. Materialitas Operasional. Dampak operasional didefinisikan sebagai kumpulan
dari manajemen keputusan yang didukung oleh UDA.
Materialitas Operasional
Rangking Dampak pada Manajemen Keputusan
High Bergantung penuh pada UDA
Medium Bergantung sebagian pada UDA
Low Bergantung sedikit pada UDA
Tak Berdampak Tak bergantung pada UDA
3. Materialitas Kepatuhan. Dampak kepatuhan didefinisikan sebagai potensi penalty
yang signifikan atau disclosure yang merusak yang terjadi akibat error oleh UDA
karena digunakan mendukung program kepatuhan.
Materialitas Kepatuhan
Rangking Dampak pada Objek Kepatuhan
High Bergantung penuh pada UDA dan penalty material untuk
ketidakpatuhan
Medium Bergantung sebagian pada UDA dan penalty moderat
untuk ketidakpatuhan
Low Bergantung sedikit pada UDA dan penalty rendah
Tak Berdampak Tak bergantung pada UDA
Peringkat Risiko (Risk Ranking)
Langkah lanjutan dalam risk assessment adalah mereview peringkat risiko berdasarkan
dampak dan likelihood untuk masing-masing UDA dengan menggunakan kriteria risiko
yang telah dibicarakan sebelumnya. Oleh karenanya rating risiko dapat dibuat
berdasarkan skala tabel dampak dan likelihood berikut:
Dampak
Ranking Skala Dampak*)
High 3
Terdapat kemungkinan bahwa error pada UDA dapat mengakibatkan
dampak material pada laporan keuangan perusahaan, kemampuan
pembuatan keputusan manajemen, atau kepatuhan pada tuntunan
peraturan yang relevan
Medium 2 Dampak potensial boleh jadi signifikan terhadap unit bisnis namun
moderat terhadap keseluruhan perusahaan
Low 1 Dampak potensial terhadap perusahaan dalam skala minor dan
lingkup terbatas
*) Didasarkan pada kriteria risiko yang teridentifikasi
Penilaian kriteria likelihood menentukan rating risiko keseluruhan untuk masing-masing
UDA
Likelihood
Ranking Skala Likelihood*)
High 3 Risiko akan terjadi dengan probabilitas tinggi
Medium 2 Risiko akan terjadi dengan probabilitas medium
Low 1 Risiko akan terjadi dengan probabilitas rendah
Rating risiko keseluruhan UDA harus dikembangkan berdasarkan pada dampak dan
likelihood yang memiliki error bedampak tinggi. Skor gabungan (composite score) boleh
digunakan sebagai hasil perkalian antara dampak dan likelihood. Berikut adalah beberapa
contoh yang direkomendasikan:
Composite Scores
Composite Score Tindakan yang direkomendasikan
7-9 Masuk ke dalam sampel audit tahunan
4-6 Masuk ke dalam sampel audit per dua tahun
1-3 Tidak masuk ke dalam sampel audit
Contoh berikut memperlihatkan hasil suatu risk assessment menggunakan faktor risiko
minimum seperti yang dideskripsikan sebelumnya. Template ini dapat dipilih bergantung
pada faktor risiko yang relevan untuk suatu perusahaan.
Konsiderasi Dampak
Konsiderasi
Likelihood
Pro
ses
Des
kri
psi
Tu
juan
Nam
a F
ile
Ex
ist
as a
20
09
UD
A (
Y/N
)
Ex
ist
as a
20
10
UD
A (
Y/N
)
Ses
uai
Def
inis
i O
rgan
isas
i d
ari
UD
A K
un
ci
Mat
eria
lita
s F
inan
sial
, O
per
asio
nal
dan
Kep
atu
han
p
ada
Atu
ran
(H
, M
, L
)
Ran
gk
ing
(1
,2,3
)
Um
ur
yan
g d
ihar
apk
an d
an F
rek
uen
si
Pem
akai
an (
H,M
,L)
Ran
gk
ing
(1
,2,3
)
Jum
lah
Use
r (H
, M
, L
)
Ran
gk
ing
(1
,2,3
)
Dam
pak
Rat
a-ra
ta
Ko
mp
lek
sita
s (H
, M
, L
)
Ran
gk
ing
(1
,2,3
)
Fre
ku
ensi
Per
ub
ahan
(In
freq
uen
t =
I,
Occ
asio
nn
al =
O,
Fre
qu
ent
= F
)
Ran
gk
ing
(1
,2,3
)
Lik
elih
oo
d R
ata-
rata
Co
mp
osi
te R
ank
ing
Dim
asu
kan
ke
dal
am p
op
ula
si
Divisi Perusahaan
1.0 Proses Bisnis
1.1
bil
ling
Acc
ess
Qu
aery
XX
X.m
db
N Y Y H 3 H 3 H 3 3
H 3 O 2 3 8 Y
Acc
ess
Qu
aery
XX
X2
.md
b
N Y Y H 3 L 1 H 3 2 H 3 O 2 3 6 Y
Ex
cel
YY
Y.x
ls
N Y N M 2 M 2 M 2 2 M 2 F 3 3 5 Y
Ex
cel
YY
Y2
.xls
N Y N M 2 L 1 M 2 2 M 2 1 1 2 3 N
Ex
cel
YY
Y3
.xls
N Y Y L 1 H 3 L 1 2 L 1 F 3 2 3 N
Ex
cel
YY
Y4
.xls
N Y Y L 1 M 2 L 1 1 L 1 F 3 2 3 N
2.0 Proses Bisnis
Pendekatan lain untuk mengevaluasi risiko pada level lebih tinggi. Sebagaimana
pendekatan sebelumnya, populasi UDA diidentifikasi dengan proses bisnis. Pendekatan
ini mengidentifikasi risiko, kontrol dan residual risk dengan inklusi atau ekslusi yang
direkomendasikan dari populasi.
Kategori UDA
Jum
lah
UD
A
Inherent
Risk Impact/
Prob
Risiko
Kontrol
Mitigasi
selain UDA
Residual
Risk
Interface:
Revenue/
Billing/ AR
Mass Additions
Cash Receipts
93
Tinggi:
Perubahan
substansial
Ketidaklengkapan
atau ketidakakuratan
integrasi dari sistem
sumber ke general
ledger berakibat
financial
misstatement
Rekonsiliasi
dan review
sub-ledger ke
general ledger
dan
rekonsiliasi
dan analisis
revenue. Good
change
controls
Low: Exclude
Revenue jangka
pendek Accrual
dan Deferrals:
Month in
Advance
Pemakaian
9
Moderat:
Triwulan and
Annual Activity
High
Salah klasifikasi
revenue antara
beberapa periode
Mereview
analisis
revenue dan
menyesuaikan
invoice actual
lewat waktu.
Material
accrual
reviews
occurring.
Low: Exclude
Revenue jangka 18 Tinggi: Ketidaklengkapan Rekonsiliasi High: Include
panjang Deferrals
and Reserves:
General Reserve
Bad debt
reserve
Substantial Bad
Debt, Manual
Calculations
atau ketidakakuratan
data, asumsi gagal
atau error logik
berakibat
unsupported reserve
and deferred revenue
balances and
misstated revenue
akun, entry
jurnal, review
kecukupan
reserve
Expense Accruals 28 Moderat:
Minor Activity
Kelebihan atau
kekurangan accrual
disebabkan
ketidaklengkapan
atau ketidaakuratan
data
Analisa dan
review biaya,
reveiew
balance sheet,
dan adjust
invoice paid
Low: Exclude
Expense-related:
Capital
Expenditure
Tax and
Contingencies
Noncash
Compensation
27
Tinggi:
Substantial
Capital
Expenditures and
Tax Liabilities
Ketidaklengkapan
atau ketidakakuratan
data, asumsi gagal
atau error logik
berakibat
unsupported
balances and
misstated expenses
Review
rekonsiliasi
akun, review
entry jurnal,
review laporan
isu-isu laporan
dan akunting.
Existence of
heavy tax
contingency
analysis.
Low: Exclude
Revenue
Assurance 5
Moderat:
Automated,
Low-dollar,
High-transaction
Volumes
Gagal mendeteksi
error revenue sebab
ketidaklengkapan
data, queries dan
laporan
Review dan
anlisa revenue
menggunakan
data general
ledger dalam
laporan
performansi
interim dan
laporan
lainnya.
Deteksi dan
koreksi error
dalam proses-
proses koleksi
dan disputes.
Low: Exclude
Financial
Reporting:
Interim
Performance
Detailed
Financials
Cash Flow
Statement
Footnotes/
Other
14
Tinggi:
Critical to
Decision Making
and Regulatory
Processes
Ketidakuratan
laporan dan
disclosure keuangan
Review
laporan
keuangan.
Review
tambahan oleh
senior
manajemen,
komite
disclosure dan
komite audit
High: Include
III. Pertimbangan-pertimbangan Dalam Melakukan Audit UDA
Hal-hal yang perlu diperhatikan saat melakukan audit UDA sebagai berikut:
Evaluasi semua kebijakan perusahaan yang relevan. Evaluasi kebijakan seputar
pengembangan dan pemakaian UDA, begitu pula kebijakan klasifikasi dan
kepemilikan data dan bagaimana semua itu boleh atau tidak boleh dipengaruhi oleh
penggunaan UDA.
Evaluasi perhatian manajemen (management’s concern) dan hasil review sebelumnya.
Hal ini perlu dilakukan dalam rangka auditor mengerti seputar lingkungan
manajemen, perhatian mereka, dan masalah-masalah yang diketahui mereka sehingga
dapat menjadi pintu masuk auditor mendalami lebih jauh.
Evaluasi dan buat rekomendasi untuk UDA otomatis. UDA spreadsheet atau
database dapat diotomatisasi atau ditempelkan ke dalam sistem lain yang bisa
menjadi bagian dari kontrol-kontrol IT formal.
Identifikasi peran dan tanggung jawab di dalam proses sedini mungkin. Peran dan
tanggung jawab standar di dalam organisasi perusahaan termasuk:
o Klien adalah penghubung kunci untuk identifikasi kebijakan perusahaan yang
dapat diterapkan, user, langkah-langkah proses dan kontrol serta mereka
bertanggung jawab untuk review dan validasi temuan.
o Pemilik proses/ user melapor kepada klien, individu-individu ini menggunakan
UDA dan melengkapi tugas-tugas dalam proses dikaitkan dengan UDA yang
direview.
o Auditor berjumpa user dan process owner untuk mereview UDA termasuk input,
output dan fungsionalitasnya.
Pengujian UDA. Auditor harus menguji fungsionalitas UDA berdasarkan perspektif
user akhir didasarkan pada pemahaman terhadap proses, risiko, kontrol dan fungsi-
fungsi UDA.
Pengujian IT general controls. Seperti pengujian aplikasi formal, pengujian UDA
menghendaki pula review rinci akses sistem, kontrol-kontrol sistem yang diterapkan,
manajemen perubahan, sekuriti jaringan, dan backup. Pertimbangan khusus dapat
diambil jika UDA disimpan di komputer stand alone dan bukan pada network.
Tools yang diotomatiskan. Auditor dapat menggunakan tools otomatis untuk
mereview komponen-komponen UDA lebih dalam.
Implikasi kelemahan dan pengecualian pengujian. Hal tersebut harus dievaluasi
sesuai konteks lingkungan, rating risiko, dan sistem terkait serta kontrol manual.
Saat membuat program pengujian, coba telusuri guideline UDA. Guideline dibuat
untuk menggambarkan best practice dalam pengembangan, pemeliharaan dan
penggunaan oleh user akhir.
3.1 Atribut dan Kemampuan Tool
Kerangka kontrol UDA diterapkan oleh perusahaan namun kemudian harus direview oleh
Internal Audit sesuai proses berikut:
Inventory UDA adalah dasar untuk memeringkat risiko dan kontrol yang tepat. Hal ini
mengharuskan adanya proses discovery guna meyakinkan bahwa inventory lengkap dan
akurat. Teknologi dapat meningkatkan kemampuan perusahaan untuk membuat
inventory lebih baik lagi sehingga memudahkan modifikasi UDA. Dalam lingkungan
bisnis yang kompleks, UDA boleh jadi terdiri dari ratusan bahkan ribuan buah yang
membutuhkan perubahan secara harian. Proses inventory manual secara ekstrim dapat
mengintensifkan waktu, butuh dua atau tiga bulan untuk melengkapi sejumlah kasus.
Selama waktu tersebut, UDA tambahan dapat ditambahkan atau dihapus.
Penggunaan teknologi akan membantu menghasilkan inventory yang lengkap, akurat, dan
relevan terhadap user. Tools automatis tidak saja memiliki kemampuan membantu
perusahaan untuk discovery UDA namun pula dapat memeringkat risiko berdasarkan
pada kompleksitas dan materialitas yang telah didefinisikan sebelumnya. Begitu pula,
tools ini dapat secara berkelanjutan memonitor program dukungan terhadap kerangka
pengendalian UDA perusahaan. Pada gilirannya, auditor dapat fokus hanya pada risiko
yang telah disajikan melalui penggunaan UDA.
Selain membantu dalam discovery, inventory dan risk ranking, tools di atas masih dapat
menyajikan hal-hal berikut:
Melakukan diagnosa guna mengidentifikasi error mekanik atau logik UDA, termasuk
error penghilangan, dan laporan tentang error tersebut untuk tujuan remediasi.
Menyajikan kapabilitas manajemen UDA yang sedang berjalan untuk meyakinkan
integritas dari pembuatan ke storage dan destruksi.
Menyajikan workflow lengkap dengan tanda tangan elektronik.
Meningkatkan kemampuan untuk mengelola spreadsheet yang saling terkait.
Menyajikan kemampuan manajemen dokumentasi untuk input kunci UDA, kalkulasi
dan outputnya.
Menyajikan proses terstruktur untuk manajemen perubahan, integritas data, kontrol
akses dan versi.
Menyajikan visibilitas untuk monitoring guna mendukung pemeliharaan lingkungan
kontrol.
Discovery Inventory Risk Rank
3.2 Best Practice untuk Kontrol-kontrol pada UDA
Berikut guideline best practice untuk pengembangan, pemeliharaan dan penggunaan
UDA.
Guideline Akses
Batasi akses ke dalam spreadsheet dan end-user system lainnya yang disimpan
pada jaringan server.
Guideline Data Sumber
Umumnya area input data tidak boleh mengandung formula. Harus terjadi
pemisahan antara data dengan algoritma dan asumsi yang diaplikasikan pada data
tersebut.
Jika mungkin, input data harus dalam order yang sama dengan sumber data guna
memfasilitasi review dan meminimalkan error input.
Lock formulas
Guideline Output Sumber
Jangan gunakan worksheet yang sama dan hanya mengubah asumsi dan variabel
saat tak ada baseline atau trail dari perubahan selama analisa ’what if’. ”Cara
terbaik membandingkan dan review hasil dari kombinasi variabel berbeda adalah
(a) mencopy set data asli dan kalkulasi ke dalam tab spreadsheet terpisah, dan (b)
membangun tab spreadsheet perbandingan, yang mewakili dan kontras terhadap
yang asli”.
Pertimbangkan apakah format presentasi final perlu nampak serupa. Hindarkan
mengetik ulang manual output ke dalam tools dan format lain, yang menyebabkan
error.
Identifikasi user-user terotorisasi untuk masing-masing laporan yang outputnya
sebagaimana data storage dan guideline retensi.
Guideline Pengujian
Yakinkan bahwa perubahan menjadi UDA kompleks atau kritis diminta secara
formal, didokumentasikan dan diuji.
Tugaskan seseorang selain daripada user atau developer spreadsheet untuk
melakukan pengujian komplek atau kalkulasi kritis.
Gunakan review analisis dan tingkat alasan untuk mendeteksi error dalam
kalkulasi dan logik.
Guideline Logik
Tempatkan nilai-nilai kritis dalam sel berbeda, jadikan sel ini sebagai acuan
untuk formula.
Gabungkan total batch dan total kontrol.
Gunakan formula yang memakai foot dan data cross-foot.
Yakinkan integritas data dengan proteksi sel untuk antisipasi perubahan
disengaja ke data atau formula statik.
Masukan hasil yang diharapkan saat mungkin untuk membandingkan dan
memonitor tingkat alasan output UDA.
Guideline Versi, Backup dan Arsip
Gunakan folder unik dan konvensi penamaan file yang memuat bulan, triwulan
dan tahun untuk meyakini bahwa versi UDA terbaru yang digunakan. Pakai
software check-in dan check-out untuk mengatur kontrol versi.
Yakinkan backup data dengan storing UDA di server network yang dilakukan
harian.
Simpan file historis dan database yang tak dipakai dalam folder terpisah dan read-
only untuk pengamanan.
Guideline Dokumentasi
Dokumenkan UDA yang memuat objektif bisnis, input, output dan urutan
eksekusi.
Buat layout (input, kalkulasi dan output) UDA secara konsisten untuk
memudahkan penggunaan dan pengujian.
Beri label file, set data, worksheet, field kunci, baris, kolom dan data untuk
kemudahan identifikasi.
Inventorikan semua spreadsheet kunci dan UDA lainnya yang berpengaruh pada
penyaiapan pelaporan keuangan.
IV. Membuat Program Pengujian
4.1 Contoh Program Audit
Tools Evaluasi UDA
Area Audit:
Nomor Audit
Audit:
Deskripsi:
Overview UDA dan Risk Assessment Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Objektif:
Tujuan workpaper ini untuk mengidentifikasi UDA kritis yang masih di dalam lingkup
guna mempertimbangkan kontrol aplikasi standar tertentu untuk review.
Pengujian:
1. Evaluasi aplikasi dilakukan untuk menentukan aplikasi mana yang perlu masuk
inklusi pada audit. Diminta bahwa manajemen menyajikan risiko terkait daftar UDA
per departemen termasuk penggunaan masing-masingnya dan pemilik aplikasi.
2. Berdasarkan evaluasi di atas, ada sejumlah X UDA kritis. Kita memilih aplikasi
dengan skor lebih dari X.0, menghasilkan X aplikasi sesuai lingkup kita. Komentar
dan disposisi kita yang dikaitkan terhadap aplikasi-aplikasi ini, dimasukkan ke dalam
risk assessment.
3. Untuk masing-masing UDA diidentifikasi untuk inklusi dalam lingkup audit tahun
sekarang, narasi internal audit, walkthrough atau prosedur lain guna menentukan
kontrol aplikasi standar mana yang akan diuji (seperti akses dan interface). Kontrol-
kontrol aplikasi yang diidentifikasi untuk pengujian atau evaluasi lanjutan harus
didokumentasikan.
A. Sekuriti Sistem dan Akses
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Sekuriti Sistem dan Akses
1. Identifikasi UDA dan data terkait. Tentukan nama-
nama file, direktori, dataset, database UDA.
Pertimbangkan:
Sumber UDA dan file yang dapat dieksekusi
File data terkait pada input dan output
Log Audit trail
PII yang terkandung di data
2. Dapatkan hak akses pada UDA dan data terkait,
evaluasi kesesuaian akses tersebut. Pertimbangkan:
Adminitrator system
Administrator sekuriti
User account default/ shared
Akses view ke PII
3. Verifikasi kontrol autentikasi user ke sistem yang
memuat UDA dan data yang membatasi akses tak
berotoritas. Timbang:
Setting parameter password (panjang, kompleksitas,
history, periode ekspirasi)
Penguncian akun paska jumlah tertentu gagal akses
Sesi terminasi paska suatu periode tak aktif
Dua faktor autentikasi yang dipakai selama akses
jauh
4. Tentukan apakah ada cara lain untuk akses ke UDA
atau datanya dan evaluasi kontrol-kontrol terhadap
akses tersebut.
5. Verifikasi apakah akases secara periodik direview.
Timbang:
Review tahunan
Review dan persetujuan yang terdokumentasi
Tindakan korektif yang diambil sesuai waktunya
B. Audit Trails
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Audit Trails
1. Identifikasi apakah audit trail ada dan berada dimana
2. Tentukan kesesuaian audit trail. Timbang:
Audit trail yang diproduksi otomatis oleh aplikasi
Audit trail yang tak dapat dihentikan
Informasi yang ditangkap audit trail sudah benar
3. Verifikasi bahwa user yang mampu mengubah,
menghapus audit trail dan lognya adalah mereka
yang bukan user UDA dan datanya
4. Verifikasi bahwa audit trail direview secara periodik
dan ditahan sampai periode waktu yang pas
C. Input, Edit dan Interface
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Input, Edit dan Interface
1. Identifikasi sumber dan tipe data input
2. Verifikasi bahwa kontrol-kontrol untuk input file kritis
telah tepat. Timbang:
Aturan validasi data
Edit konsisten tanpa melihat sumber
Record/ item counts and balances ensure
completeness
3. Verifikasi apakah notifikasi error atau laporan
dihasilkan dan tindakan koreksi telah diambil.
Timbang:
Total kontrol direkonsiliasi untuk kelengkapan
File input error dikembalikan dan dijalankan ulang
D. Pemrosesan Data dan Integritas Data
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Pemrosesan Data dan Integritas Data
1. Tentukan apakah rekod-rekod yang diproduksi sistem
ditimpa manual secara rutin untuk perbaikan error
proses. Pertimbangkan:
Perbaikan berulang akibat kasus yang sama
Tindakan koreksi untuk perbaikan cacat kode
aplikasi
2. Tentukan apakah tools manipulasi data digunakan
guna koreksi error proses. Timbang:
Utilitas yang dapat menimpa rekod.
Statemen SQL untuk menimpa rekod database
Record/ item counts and balances ensure
completeness
3. Verifikasi bahwa audit trail rinci dipelihara. Timbang:
Kontrol monitoring manual mengidentifikasi entry
tak terotorisasi
User ID dikumpulkan untuk transaksi-transaksi
override
Sesi terminasi paska suatu periode tak aktif
Log kekecualian dan aktiviti ada
4. Verifikasi error proses digambarkan jelas, dideteksi
tepat dan ditandai untuk koreksi. Timbang:
Pemrosesan rekod berhenti begitu sekali error
terjadi
Laporan kekecualian tersedia untuk tindakan
koreksi
Laporan tindakan koreksi direview
Item-item dibersihkan sesuai objektif service level
bisnis
5. Tentukan apakah suatu proses ada untuk mengulang
transaksi, koreksi error, dan proses ulang transaksi
secara manual handling. Timbang:
Aturan dan prosedur bisnis khusus didefinisikan
oleh perusahaan
Aplikasi membolehkan penanganan khusus
Rekod-rekod yang ditolak, diproses ulang dalam
time frame yang dapat diterima
6. Verifikasi keberadaan kontrol proses untuk
spreadsheet. Timbang:
Formula dan komputasi didukung dokumen
memadai
Formula dan sel dikunci
Referensi sel atau perubahan nama digunakan
dalam formula sebagai pengganti konstanta
Total cross check digunakan
Fungsi kalkulasi otomatis dihidupkan dalam
spreadsheet.
Komputasi yang disisipkan didukung dokumentasi
yang memadai sehingga menggambarkan
mekanikme dan logik komputasi.
E. Output dan Pelaporan
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Output dan Pelaporan
1. Verifikasi bahwa total kontrol output yang
dibandingkan dengan total kontrol input dan errornya
telah disolusikan
2. Verifikasi bahwa logika aplikasi dan formula kritis
UDA secara periodik divalidasi
3. Tentukan apakah kontrol bisnis mitigasi ada untuk
mendeteksi error output (seperti rekonsiliasi
downstream atau proses kontrol)
F. Retensi
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Retensi
1. Verifikasi bahwa data telah secara tepat diretensi.
Pertimbangkan:
Tipe data dan program
Dipertahankan untuk waktu tertentu
Disimpan di tempat aman
Terdapat dokumen-dokumen fisik
Arsip data dapat dibaca dan dapat direproduksi jika
diperlukan
2. Yakinkan bahwa informasi tepat atau catatan-catatan
bisa dipelihara sebagai dokumen
G. Backup dan Recovery
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Backup dan Recovery
1. Verifikasi bahwa daftar UDA kritis dipelihara baik
2. Verifikasi aakah UDA kritis dan data terkaitnya secara
periodik dibackup. Timbang:
Tipe beckup (full atau incremental)
Frekuensi backup
3. Tentukan apakah backup diretensi dis auatu lokasi
aman. Timbang:
Lokasi on/ off site
Akses bagi personal terotorisasi
4. Tentukan apakah recovery UDA secara periodik diuji.
Timbang:
Recovery telah sukses
Recovery dimasukkan pada Disaster Recovery
Exercise
Kerja recovery dirangkum dan dipelajari
H. Manajemen Perubahan
Disiapkan oleh: Tanggal:
Direview oleh: Tanggal:
Aplikasi yang Direview Aplikasi(n) Aplikasi(n+1)
Item-item Evaluasi Manajemen Perubahan
1. Verifikasi bahwa prosedur manajeemn perubahan
telah tepat dan dipedomani. Timbang:
Perubahan diuji, direview dan disetujui
Pengujian meliputi uji formula, logik dan
downstream feed
Hasil test diretensi sampai waktu tertentu
Pengujian dilakukan oleh orang independen
Pengujian dilakukan bukan pada mesin produksi
2. Verifikasi bahwa salinan sumber terpisah dipelihara.
Timbang:
Sumber secara tepat diproteksi
3. Verifikasi bahwa versi aplikasi yang disetujui
dialihkan ke mesin produksi. Timbang:
Kode sumber dan kode eksekusi (executable code)
Terdapat segregation of duty yang benar
antar ’developer’, orang yang memindahkan kode
dan usernya.
V. Penerapan UDA di Telkom
Sebagai perusahaan yang berskala nasional bahkan internasional – karena listing di Bursa
Saham New York Stock Exchange – Telkom tidak mungkin terhindarkan dari penerapan
konsep UDA. Selama ini istilah UDA lebih dikenal dengan sebutan EUC (End User
Computing). Aplikasi EUC ini merupakan aplikasi perantara dari aplikasi-aplikasi besar
yang memiliki output standar. Sementara itu guna pengolahan yang lebih applicable lagi
di tingkat teknis, maka dibuatlah aplikasi-aplikasi hasil kreasi user yang dikelompokkan
sebagai Aplikasi EUC.
Contoh aplikasi-aplikasi ini sebagai aplikasi pelaporan keuangan – yang dibuat melalui
aplikasi spreadsheet – misalnya adalah:
Untuk Financial Accounting di Kantor Perusahaan adalah Aplikasi Rekonsiliasi
Indo GAAP-US GAAP dan Laporan Cash Flow.
Untuk Finance Center Kantor Perusahaan adalah Perhitungan PPh Badan &
Deferred Tax dan PSAK 30R.
Untuk Management Accounting Kantor Perusahaan adalah FINAMO.
Supaya pembuatan aplikasi-aplikasi tersebut tidak terlalu menyimpang dari kaidah-
kaidah Manajemen Proyek Perangkat Lunak, maka tulisan ini dapat dipedomani dalam
pelaksanaan pengembangan aplikasi EUC ini.
Selain itu kegunaan tulisan ini adalah sebagai pedoman bagi para auditor EUC guna
menguji sejauh mana aplikasi EUC ini masih di dalam koridor Manajamen Perangkat
Lunak. Oleh karena itu tulisan ini juga ditujukan untuk pedoman audit guna:
Meyakini bahwa proses pengendalian atas pengelolaan EUC telah sesuai dengan
kebijakan Perusahaan khususnya yang bertalian dengan ketersediaan policy dan
prosedur, dokumentasi dan review reguler atas integritas dan akurasi
pemrosesan, penyediaan dan pengendalian back up EUC beserta datanya,
pengendalian akses user ke EUC, serta verifikasi independen atas input,
pemrosesan dan output.
Meyakini bahwa aplikasi spreadsheet (computation) atau spreadsheet yang
dibuat telah memenuhi kaidah keamanan informasi yaitu confidentiality,
integrity & availabiliy sesuai kebijakan Perusahaan.
Untuk memperoleh keyakinan yang memadai mengenai kelayakan pengendalian
atas EUC, khususnya atas penggunaan aplikasi spreadsheet (computation) yang
bertalian dengan pengelolaan data aplikasi besar seperti SAP dll.
Untuk menemukenali permasalahan yang timbul dalam implementasi EUC
beserta resiko-resikonya yang berpotensi menimbulkan salah saji laporan
keuangan dan fraud.
VI. Rangkuman
Penggunaan UDA dapat berkontribusi terhadap atau mengurangi dari lingkungan kontrol
perusahaan. Profesional judgment harus digunakan saat mengaudit UDA. Secara ideal,
perusahaan harus mempunyai definisi pasti yang dapat menjadi acuan. Jika pun definisi
tersebut belum ada, pendekatan sistematis harus digunakan guna menentukan risiko-
risiko perusahaan dan level risko tersebut yang dapat diterima.
Begitu perluasan program audit dilakukan, akan banyak hal yang harus dipertimbangkan
terkait dengan kompleksitas sistem. UDA dapat mengganggu proses downstream dan
melalui review hal ini dapat diketahui. Demikian pula, jika kontrol-kontrol upstream
lemah, maka kontrol UDA tidak boleh membuat banyak perbedaan.