Risiko dan Pengendalian Proses Program Change/Perubahan Program ITGC ICOFR

Berikut ini adalah proses bisnis Perubahan Program ITGC ICOFR secara umum:

• Permintaan Perubahan (Change Request) – Permintaan perubahan diajukan, tiket perubahan dibuat, dan perubahan didokumentasikan secara menyeluruh. Permintaan perubahan dapat berasal dari pemangku kepentingan internal maupun eksternal.
• Evaluasi – Permintaan perubahan dinilai berdasarkan risiko, prioritas, dan dampaknya terhadap pengguna.
• Otorisasi – Pekerjaan pada perubahan diotorisasi oleh manajemen atau suatu komite IT. Dalam beberapa kasus, permintaan dapat ditolak atau ditunda. Perubahan ditugaskan kepada teknisi dan dimasukkan dalam sprint dan/atau rilis.
• Perencanaan – Perencanaan atas perubahan didokumentasikan, seperti kebutuhan, strategi implementasi, rencana pengujian, dan sebagainya.
• Peer Review – Perubahan kode ditinjau dan disetujui oleh rekan kerja untuk memastikan desain dan fungsionalitas.
• Pengujian – Pengujian manual dan/atau otomatis dilakukan untuk memvalidasi bahwa perubahan berfungsi sesuai rancangan, atau jika tidak memungkinkan, rencana rollback didokumentasikan.
• Persetujuan untuk Implementasi – Persetujuan akhir diberikan untuk menerapkan perubahan ke lingkungan produksi.
• Implementasi – Perubahan diterapkan ke lingkungan produksi.
• Pasca Implementasi – Tinjauan pasca implementasi dilakukan untuk memastikan perubahan berfungsi sebagaimana mestinya di produksi.
• Komunikasi – Informasi tentang perubahan disampaikan kepada pemangku kepentingan internal dan eksternal yang terdampak. Catatan rilis didokumentasikan dan dibagikan.
• Penutupan – Setelah semua dokumentasi perubahan selesai, tiket perubahan ditutup.

Risiko Umum dalam Proses Perubahan Program IT untuk Aplikasi Perangkat Lunak, Sistem Basis Data, dan Infrastruktur terkait meliputi:

• Perubahan tidak diotorisasi sebelum pekerjaan dimulai.
• Perubahan tidak dilacak dan/atau tidak didokumentasikan dengan tepat selama siklus hidupnya.
• Spesifikasi perubahan tidak memenuhi kebutuhan atau harapan manajemen.
• Perubahan tidak menangani tujuan, komitmen layanan, persyaratan sistem, atau dampak sistem lainnya dengan baik.
• Pelanggaran, insiden, dan gangguan sistem yang teridentifikasi tidak dipertimbangkan dalam siklus manajemen perubahan IT.
• Perubahan tidak berfungsi sebagaimana mestinya atau menimbulkan dampak tak terduga, seperti kerentanan keamanan.
• Perubahan yang tidak sah diterapkan ke produksi.
• Perubahan, termasuk perubahan konfigurasi, tidak disetujui dengan benar.
• Perubahan konfigurasi yang sah tidak dimasukkan dengan akurat.
• Pengujian unit, integrasi, atau regresi tidak memadai untuk mendeteksi masalah sebelum implementasi.
• Perubahan diterapkan tidak tepat waktu atau mengganggu jadwal penerapan lainnya.
• Tugas manajemen perubahan IT tidak dipisahkan dengan baik.
• Perubahan memperkenalkan kode berbahaya atau kerentanan baru yang tidak terdeteksi.
• Perubahan untuk mengatasi kerentanan yang diketahui tidak diterapkan tepat waktu.
• Perubahan gagal memenuhi tujuan, komitmen layanan, dan persyaratan sistem.
• Perubahan darurat tidak disetujui atau tidak tepat.
• Perubahan yang tidak sah tidak terdeteksi.
• Lingkungan non-produksi dan produksi tidak dipisahkan.
• Perubahan yang diterapkan ke produksi tidak didokumentasikan atau tidak dicatat.
• Akses untuk melakukan perubahan pada produksi tidak dibatasi secara tepat.
• Perubahan tidak dapat ditelusuri ke individu yang melakukan perubahan.
• Kontrol versi tidak dipelihara dengan tepat.

Contoh Pengendalian dalam Perubahan Program IT antara lain:

• Manajemen telah menetapkan kebijakan dan prosedur manajemen perubahan IT yang terdefinisi dan ditinjau setidaknya setiap tahun.
• Proses manajemen perubahan IT memiliki peran dan tanggung jawab yang terdefinisi dengan pemisahan tugas yang tepat.
• Alat bantu manajemen perubahan IT digunakan, termasuk sistem tiket, alat repositori kode untuk kontrol versi, dan alat pengujian.
• Permintaan perubahan yang didasarkan pada kebutuhan yang teridentifikasi dievaluasi, didokumentasikan, dan disetujui oleh pemilik bisnis dan manajemen IT sebelum pengembangan perbaikan bug atau fitur baru dimulai.
• Rencana dan data pengujian dibuat dan digunakan dalam pengujian sistem dan regresi.
• Perubahan ditinjau, diuji, dan disetujui oleh programmer rekan atau anggota tim QA IT independen untuk memastikan fungsionalitas dan spesifikasi yang dimaksud. Masalah yang ditemukan dikembalikan ke pengembang untuk diperbaiki.
• Perubahan diuji dan diterima oleh pengguna untuk memastikan berfungsi sesuai harapan dan meminimalkan risiko dampak tak terduga. Masalah yang ditemukan dikembalikan ke pengembang untuk diperbaiki.
• Setelah pengujian disetujui, komite IT menyetujui dan menjadwalkan perubahan untuk diterapkan di lingkungan produksi.
• Manajemen menyetujui perubahan sebelum penerapan ke produksi.
• Semua perubahan disetujui sebelum diterapkan ke lingkungan produksi.
• Terdapat lingkungan yang terpisah untuk pengembangan, pengujian, staging, dan produksi.
• Perubahan dicatat untuk mempertahankan kontrol versi yang mengidentifikasi siapa yang melakukan perubahan pada produksi.
• Alat repositori kode mempertahankan aturan perlindungan cabang (branch protection) yang mengharuskan semua perubahan ditinjau sebelum digabungkan ke cabang utama.
• Pemberitahuan otomatis dihasilkan saat perubahan telah digabung ke basis kode untuk mencegah perubahan tidak terdeteksi.
• Akses ke lingkungan produksi dan perangkat lunak repositori kode dibatasi hanya untuk personel yang berwenang.
• Pengembang tidak memiliki akses langsung untuk melakukan perubahan pada produksi tanpa pengawasan yang tepat.
• Semua perubahan dicatat untuk jejak audit dan log perubahan ditinjau untuk memastikan tidak ada perubahan yang tidak sah.
• Alat analisis pemindaian kode digunakan pada setiap kandidat rilis untuk mengidentifikasi dan memperbaiki kerentanan perangkat lunak sebelum diterapkan ke produksi.
• Perubahan darurat disetujui secara retrospektif dalam waktu yang tepat untuk memastikan kelayakan.
• Rencana rollback didokumentasikan untuk perubahan yang tidak dapat diuji sebelum implementasi ke produksi.
• Tinjauan pasca implementasi dilakukan untuk memverifikasi bahwa perubahan berfungsi sebagaimana mestinya di lingkungan produksi.

Satu-satunya hal yang pasti adalah perubahan. Perubahan sistem IT tidak dapat dihindari dan terus berlangsung agar perbaikan berkelanjutan dapat terwujud. Pengendalian manajemen perubahan IT melindungi perusahaan dalam mengelola perubahan sistem, baik yang direncanakan maupun tidak, serta membantu meminimalkan gangguan, permasalahan sistem, dan penghentian layanan produksi jika pengendalian tersebut tidak dijalankan dengan baik.

Sumber: Linford & Co. (2021)