Siapa yang Perlu Patuh PCI DSS 4.0.1 di Thailand?

Daftar isi

Pertanyaan PCI DSS yang paling sering saya dengar bukan “bagaimana cara patuh?” melainkan “apakah saya perlu patuh sama sekali?” Jawabannya lebih luas daripada yang diasumsikan kebanyakan organisasi, dan konsekuensi menebak salah tidaklah teoretis: denda, interchange fee yang lebih tinggi, dan saat terjadi breach, biaya forensik serta kerusakan merek yang dihitung dengan uang sungguhan.

Jawaban singkat #

PCI Data Security Standard berlaku bagi entitas mana pun yang menyimpan, memproses, atau mengirimkan data pemegang kartu, dan bagi entitas mana pun yang dapat mempengaruhi keamanan data tersebut. Definisinya memang sengaja luas, dan menelan tiga kelompok yang rutin dianggap dikecualikan.

1. Siapa pun yang menyimpan, memproses, atau mengirimkan data kartu #

Ini kasus yang jelas, tetapi mencakup jauh lebih banyak daripada merchant yang men-swipe kartu. Cakupannya:

Situs e-commerce yang mengambil nomor kartu pada formulir checkout.
ERP yang menyimpan PAN “hanya untuk rekonsiliasi”.
Call center yang mengetik nomor kartu ke CRM lewat salinan telepon terekam.
Payment gateway, PSP, acquirer, dan issuer yang menyentuh data itu setiap hari.

Jika data kartu mendarat di sistem Anda, sesaat pun, di memori saja, Anda masuk scope. “Kami hanya menyimpannya sebentar” bukan pengecualian; itu adalah scope.

2. Bahkan ketika Anda memakai pemroses pihak ketiga #

Miskonsepsi terbesar adalah “kami pakai Stripe / 2C2P / PayPal, jadi PCI DSS bukan urusan kami.” Menggunakan pihak ketiga mengecilkan scope Anda; tidak menghapusnya.

Bagi organisasi kecil, ini biasanya berarti Anda memenuhi syarat formulir validasi yang diperkecil: SAQ A atau SAQ A-EP alih-alih SAQ D lengkap, karena data kartu tak pernah menyentuh sistem Anda. Namun Anda tetap punya kewajiban: merawat integrasi skrip dengan benar, menjaga halaman checkout bebas dari skimming, dan mengelola pihak ketiga sesuai Requirement 12.8 standar tersebut. Anda tetap memvalidasi; hanya lebih sedikit.

Perangkapnya adalah scope creep. Tambahkan satu field kustom yang menangkap nomor kartu di sisi server, atau alihkan pembayaran melalui endpoint milik sendiri, dan tanpa suara Anda pindah dari SAQ A ke SAQ D: kewajiban yang berbeda jauh. Tidak ada yang memberi tahu Anda saat itu terjadi.

3. Bank dan semua pihak di hulu pemegang kartu #

Bank, acquirer, issuer, dan payment facilitator bukan sekadar “masuk scope”: mereka entitas yang divalidasi paling intensif dalam ekosistem ini. Di Thailand, lembaga keuangan juga bertanggung jawab kepada pedoman Bank of Thailand tentang risiko IT dan kanal digital di atas PCI DSS. Dua rezim itu tumpang-tindih tetapi tidak identik, dan audit BOT tidak menggantikan validasi PCI DSS.

Mengapa scope adalah segalanya #

Biaya PCI DSS berskala mengikuti scope. Setiap sistem, jaringan, dan orang di dalam Cardholder Data Environment (CDE) Anda tunduk pada set kontrol penuh. Memperkecil CDE karena itu aktivitas kepatuhan berdaya ungkit tertinggi yang bisa Anda lakukan:

Tokenisasi data kartu agar Anda menyimpan referensi tak berguna alih-alih PAN.
Isolasi sistem pembayaran di balik segmentasi sehingga bagian bisnis lainnya keluar dari scope.
Outsource secara sadar kepada penyedia layanan tervalidasi untuk bagian yang tidak perlu Anda sentuh.

Lingkungan yang scope-nya ditata baik bisa mengubah asesmen enam bulan bernilai enam digit menjadi latihan yang terkendali dan berulang. Lingkungan yang ditata buruk mengaudit seluruh perusahaan tanpa manfaat keamanan tambahan.

flowchart TD A[Data kartu diterima] --> B{Menyentuh sistem Anda?} B -- Tidak --> C[SAQ A / A-EP: scope diperkecil] B -- Ya --> D[CDE penuh: SAQ D / ROC] D --> E{Tokenisasi dan segmentasi?} E -- Ya --> F[Perkecil CDE sebelum audit] E -- Tidak --> G[Asesmen penuh, setiap sistem] style F stroke:#10B981,stroke-width:2px style G stroke:#F43F5E,stroke-width:2px

4.0.1 mengubah aturan main #

PCI DSS 4.0.1 memformalkan banyak hal yang sudah lama dilakukan tim engineering yang baik: memperlakukan kepatuhan sebagai kondisi berkelanjutan alih-alih acara tahunan, dengan persyaratan seputar targeted risk analysis, pendekatan kontrol yang dikustomisasi, dan menjaga keamanan melalui perubahan. Pesannya: sertifikat titik-waktu tidak lagi cukup; standar kini mengharapkan kontrol tetap benar di antara dua asesmen.

Belum yakin Anda termasuk SAQ A, SAQ A-EP, atau butuh ROC penuh? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com).

Mulai dari mana #

Mulailah dengan PCI DSS Gap Assessment & Scope Reduction sebelum berkomitmen pada audit: perkecil CDE, uji segmentasi Anda, baru kemudian validasi. Saat siap, audit kami yang dipimpin QSA akan mendampingi Anda melewati ROC/AOC penuh dengan asesor aktif di Bangkok.