Bukti manajemen perubahan yang diterima auditor

Dalam audit SOC 2 Type II, manajemen perubahan (CC8.1) adalah salah satu kontrol yang paling sering diambil sampelnya: auditor memilih perubahan dari seluruh periode dan meminta Anda membuktikan bahwa setiap perubahan telah disetujui, diuji, dan disahkan sebelum masuk ke produksi. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2), dan Regulasi Pelaksana NIS2 (poin 6.4) meminta hal yang sama dengan redaksi berbeda. Tim engineering biasanya sudah mengerjakan pekerjaannya; yang sering hilang adalah buktinya.

Yang diuji auditor

Untuk sampel perubahan, mereka ingin melihat:

1. Perubahan diminta dan dijelaskan: tiket atau pull request yang menyatakan apa dan mengapa.
2. Perubahan ditinjau oleh orang selain penulisnya: pemisahan tugas.
3. Perubahan diuji sebelum masuk ke produksi, dengan hasilnya.
4. Perubahan disetujui sebelum diterapkan.
5. Yang diterapkan sama dengan yang disetujui: tidak ada kode yang belum ditinjau masuk ke produksi.
6. Populasinya lengkap: setiap perubahan produksi melalui proses ini, termasuk infrastruktur dan konfigurasi.

Bukti yang lolos

• Proteksi branch: branch utama mensyaratkan minimal satu tinjauan persetujuan dari orang selain penulisnya, dan pemeriksaan yang lolos, sebelum merge. Ekspor pengaturannya dan tunjukkan bahwa pengaturan itu tidak berubah selama periode audit.
• Deployment hanya melalui pipeline: deployment produksi hanya berasal dari branch yang diproteksi melalui CI/CD; engineer tidak dapat melakukan push langsung.
• Catatan yang saling terhubung: setiap deployment terhubung ke pull request yang di-merge, yang kemudian terhubung ke tiketnya.
• Infrastructure as code dengan aturan yang sama, sehingga perubahan infrastruktur meninggalkan jejak yang sama.
• Daftar perubahan lengkap dari alat deployment untuk periode tersebut, yang dapat diambil sampelnya oleh auditor.

Perubahan darurat

Setiap proses memerlukan jalur cepat untuk insiden, dan auditor mengharapkannya. Definisikan jalur tersebut: siapa yang dapat menyetujui, seberapa cepat tinjauan retrospektif dilakukan (dalam satu atau dua hari kerja adalah hal yang umum), dan bagaimana perubahan dikaitkan dengan insiden. Kemudian pastikan perubahan darurat benar-benar jarang terjadi.

Yang menggagalkan audit

• Admin dengan akses langsung ke produksi yang kadang melewati pipeline.
• Pull request yang disetujui sendiri, atau tinjauan hanya oleh bot.
• Perubahan konfigurasi yang dilakukan di konsol tanpa catatan.
• Proteksi branch dimatikan "sementara" selama periode audit.
• Tidak ada bukti pengujian selain "CI berhasil", padahal perubahan tersebut membutuhkan pengujian lebih.

Pengambilan sampel: apa yang sebenarnya dilakukan auditor

Dalam SOC 2 Type II, auditor biasanya meminta seluruh populasi perubahan produksi dalam periode tersebut, memilih sampel (ukurannya bergantung pada populasi dan metodologi auditor), dan meminta Anda menunjukkan untuk setiap perubahan yang diambil sampelnya: permintaannya, tinjauan oleh orang selain penulis, hasil pengujian, persetujuan, dan bahwa yang diterapkan sesuai dengan yang disetujui.

Ada dua konsekuensi praktis. Pertama, populasi harus lengkap dan dapat diekspor: jika perubahan dapat masuk ke produksi melalui lebih dari satu jalur, setiap jalur memerlukan catatan. Kedua, satu perubahan yang diambil sampelnya tanpa bukti akan menjadi pengecualian dalam laporan. Lebih murah memperbaiki proses agar bukti dihasilkan otomatis daripada menyusunnya ulang saat audit.

Halaman SOC 2 CC8.1 menunjukkan bagaimana kriteria ini dipetakan ke ISO 27001, PCI DSS, dan NIS2.

Satu proses, semua kerangka kerja

Dalam data kami, persyaratan manajemen perubahan saling terhubung lintas kerangka kerja:

Arah	Dipetakan	Terkait secara longgar	Tidak ada pemetaan
Miliki SOC 2 → butuhkan NIS2	47 dari 49 (96%)	1	1	laporan →
Miliki NIS2 → butuhkan SOC 2	37 dari 61 (61%)	0	24	laporan →

Proses berbasis pull request dengan branch yang diproteksi dan deployment hanya melalui pipeline memenuhi SOC 2, ISO 27001, PCI DSS, dan NIS2 sekaligus. PCI DSS menambahkan beberapa hal tambahan: memisahkan pra-produksi dari produksi (6.5.3), menjaga data akun aktif agar tidak masuk ke pengujian (6.5.5), dan memastikan persyaratan keamanan setelah perubahan signifikan (6.5.2).

Lihat topik Secure Development untuk persyaratan terkait dan tulisan kami tentang penggunaan ulang bukti lintas SOC 2, ISO 27001, dan PCI DSS.

Pertanyaan

Apakah pull request dihitung sebagai persetujuan perubahan untuk SOC 2?

Biasanya ya, jika repository memberlakukan tinjauan oleh orang selain penulis sebelum merge, deployment dibatasi pada kode yang disetujui, dan Anda dapat menunjukkannya untuk sampel perubahan selama periode tersebut.

Bagaimana perubahan darurat seharusnya ditangani untuk audit?

Dengan proses darurat yang terdefinisi: perbaiki dulu jika diperlukan, lalu tinjauan dan persetujuan retrospektif dalam batas waktu yang ditetapkan, serta catatan yang menghubungkan perubahan dengan insiden yang membenarkannya.