องค์กรแบบไหนบ้างที่เกี่ยวข้องกับ PCI DSS โดยไม่รู้ตัว
.
ในหลายองค์กร คำว่า PCI DSS มักถูกมองว่าเป็นมาตรฐานที่เกี่ยวข้องเฉพาะกับธนาคาร ผู้ให้บริการชำระเงิน หรือธุรกิจขนาดใหญ่เท่านั้น แต่ในความเป็นจริง องค์กรจำนวนมากอาจมีความเกี่ยวข้องกับ PCI DSS โดยไม่รู้ตัว โดยเฉพาะธุรกิจที่มีการรับชำระเงินผ่านบัตรเครดิตหรือบัตรเดบิต ไม่ว่าจะเป็นหน้าร้าน เว็บไซต์ แอปพลิเคชัน ระบบคอลเซ็นเตอร์ หรือแม้แต่การเชื่อมต่อกับผู้ให้บริการภายนอก
ตามข้อมูลของ PCI Security Standards Council, PCI DSS มีผลกับหน่วยงานที่ เก็บ ประมวลผล หรือส่งข้อมูลผู้ถือบัตร รวมถึงองค์กรที่ อาจมีผลต่อความปลอดภัยของ Cardholder Data Environment (CDE) ด้วย ไม่ได้จำกัดเฉพาะผู้รับบัตรโดยตรงเท่านั้น
คำถามสำคัญจึงไม่ใช่แค่ “องค์กรของเรารับบัตรหรือไม่” แต่คือ “องค์กรของเรามีส่วนเกี่ยวข้องกับข้อมูลบัตรหรือสภาพแวดล้อมที่รองรับการชำระเงินหรือเปล่า”
PCI DSS คืออะไร และเกี่ยวข้องกับใครบ้าง
PCI DSS หรือ Payment Card Industry Data Security Standard เป็นมาตรฐานความมั่นคงปลอดภัยสำหรับองค์กรที่เกี่ยวข้องกับข้อมูลบัตรชำระเงิน โดยกลุ่มที่ PCI SSC ระบุไว้อย่างชัดเจน ได้แก่ merchants, processors, acquirers, issuers และ service providers รวมถึงหน่วยงานใดก็ตามที่อาจส่งผลต่อความปลอดภัยของ CDE
นั่นหมายความว่า แม้องค์กรจะไม่ได้เป็นผู้ประมวลผลธุรกรรมโดยตรง แต่หากมีระบบ บุคลากร ซอฟต์แวร์ หรือโครงสร้างพื้นฐานที่เชื่อมโยงกับข้อมูลบัตร ก็อาจอยู่ในขอบเขตของ PCI DSS ได้
1) ธุรกิจที่รับชำระเงินผ่านบัตร ไม่ว่าจะออนไลน์หรือออฟไลน์
กลุ่มแรกที่ชัดเจนที่สุดคือ merchant หรือองค์กรที่รับชำระเงินผ่านบัตร เช่น
- ธุรกิจ e-Commerce
- โรงแรม
- โรงพยาบาล
- ร้านค้าปลีก
- โรงเรียนหรือสถาบันการศึกษา
- ผู้ให้บริการ subscription
- ธุรกิจท่องเที่ยวและสายการบิน
หลายองค์กรเข้าใจว่าถ้าใช้ Payment Gateway ภายนอกแล้วจะ “ไม่เกี่ยวกับ PCI DSS” แต่ในความจริง หากองค์กรยังมีระบบหรือกระบวนการที่เกี่ยวข้องกับการรับข้อมูลบัตรไม่ทางใดก็ทางหนึ่ง ก็ยังอาจมีภาระตาม PCI DSS อยู่ โดยแม้แต่กรณีที่ outsource การประมวลผลทั้งหมด องค์กรก็ยังต้องตรวจสอบความสอดคล้องของผู้ให้บริการภายนอกที่ใช้งานด้วย
2) องค์กรที่ไม่ได้เก็บข้อมูลบัตรเอง แต่มีระบบที่ “แตะ” ข้อมูลบัตร
หลายองค์กรไม่ได้ตั้งใจเก็บเลขบัตร แต่กลับมีข้อมูลเหล่านี้เล็ดลอดเข้าไปอยู่ในระบบโดยไม่รู้ตัว เช่น
- บันทึกข้อมูลลง Excel หรือระบบ back office
- แนบข้อมูลบัตรในอีเมล
- รับข้อมูลผ่านแชตหรือคอลเซ็นเตอร์
- บันทึกเสียงสนทนาที่มีเลขบัตร
- เก็บภาพหน้าจอหรือเอกสารยืนยันการชำระเงินที่มีข้อมูลอ่อนไหว
สถานการณ์เหล่านี้ทำให้องค์กรอาจเข้าสู่ขอบเขต PCI DSS ทันที เพราะมาตรฐานนี้ครอบคลุมทั้งการเก็บ ประมวลผล ส่งต่อข้อมูลบัตร และข้อมูลยืนยันตัวตนที่มีความอ่อนไหว (SAD)
3) องค์กรที่ใช้ระบบของบุคคลที่สาม แต่ยังมีผลต่อความปลอดภัยของ CDE
นี่คือจุดที่หลายบริษัทมองข้ามมากที่สุด
PCI SSC ระบุชัดว่ามาตรฐานนี้ไม่ได้ใช้เฉพาะกับผู้ที่ถือข้อมูลบัตรโดยตรงเท่านั้น แต่ยังรวมถึงองค์กรที่ could impact the security of the cardholder data environment หรือองค์กรที่สามารถส่งผลต่อความปลอดภัยของ CDE ได้ด้วย
ตัวอย่างเช่น
- บริษัทที่ดูแลระบบเครือข่าย
- ผู้ให้บริการ Managed Service
- ผู้ดูแล Firewall / WAF / IDS / SIEM
- ผู้ให้บริการ Hosting หรือ Cloud ที่เกี่ยวข้องกับระบบรับชำระเงิน
- ทีมพัฒนาแอปหรือเว็บไซต์รับชำระเงิน
- ผู้ดูแลฐานข้อมูลหรือเซิร์ฟเวอร์
- ผู้ให้บริการ remote support เข้าสู่ระบบที่เกี่ยวข้องกับ CDE
แม้องค์กรเหล่านี้จะไม่ถือข้อมูลบัตรเอง แต่หากสามารถเข้าถึง เปลี่ยนแปลง สนับสนุน หรือมีผลต่อระบบที่เกี่ยวข้องกับการชำระเงิน ก็อาจถูกพิจารณาว่าอยู่ใน scope ได้
4) ธุรกิจที่มีหลายแผนก แต่คิดว่าเรื่อง PCI DSS เป็นหน้าที่ของ IT เท่านั้น
PCI DSS ไม่ใช่มาตรฐานที่จบในฝ่าย IT เพียงฝ่ายเดียว เพราะหลายส่วนงานในองค์กรมีโอกาสเกี่ยวข้อง เช่น
- ฝ่ายการเงินที่รับข้อมูลจากลูกค้า
- ฝ่ายขายที่ปิดการขายผ่านโทรศัพท์
- ฝ่าย Customer Service ที่รับข้อมูลบัตรเพื่อยืนยันการชำระ
- ฝ่าย Operations ที่เข้าถึงระบบหลังบ้าน
- ฝ่าย Procurement ที่ดูแลผู้ให้บริการภายนอก
- ฝ่ายบริหารความเสี่ยงและกำกับดูแล
ถ้าองค์กรยังมอง PCI DSS เป็นเรื่องเฉพาะของระบบเทคนิค โครงการมักจะเจอปัญหาเรื่อง scope บานปลาย หลักฐานไม่ครบ และควบคุมกระบวนการไม่รอบด้าน
5) องค์กรที่เชื่อว่า “เราใช้ผู้ให้บริการภายนอกทั้งหมดแล้ว จึงไม่ต้องทำอะไรเพิ่ม”
นี่คือความเข้าใจผิดที่พบบ่อยมาก
แม้บางโมเดลการให้บริการจะช่วยลดภาระขององค์กรลงได้ แต่ไม่ได้หมายความว่าองค์กรจะหลุดจากความรับผิดชอบทั้งหมด ตัวอย่างจากเอกสาร SAQ A ระบุว่า merchant ที่ outsource การประมวลผลทั้งหมด ยังต้องพึ่งพาผู้ให้บริการที่สอดคล้องกับ PCI DSS และต้องมีการทบทวนเอกสารยืนยันความสอดคล้องของผู้ให้บริการนั้นด้วย
กล่าวอีกอย่างคือ การจ้าง third-party ไม่ได้แปลว่า “หมด scope” เสมอไป แต่เป็นการเปลี่ยนรูปแบบความรับผิดชอบ และทำให้ต้องประเมินบทบาทขององค์กรใหม่อย่างเหมาะสม
6) องค์กรที่กำลังทำ Digital Transformation ด้าน Payment
ยิ่งองค์กรขยายช่องทางชำระเงินมากขึ้น ความเสี่ยงเรื่อง PCI DSS ก็ยิ่งซับซ้อนขึ้น เช่น
- เพิ่มระบบชำระเงินผ่านเว็บไซต์
- เปิดรับบัตรผ่านมือถือหรือแอป
- เชื่อมระบบกับหลาย Payment Gateway
- ใช้ SaaS หรือ cloud service สำหรับงานขายและบริการลูกค้า
- มีการทำ recurring payment หรือ card-on-file
- เชื่อมระบบหน้าร้านกับระบบกลาง
ทุกการเปลี่ยนแปลงเหล่านี้อาจกระทบต่อ scope ของ PCI DSS ได้ หากไม่มีการออกแบบ architecture และ controls อย่างเหมาะสมตั้งแต่ต้น
สัญญาณเตือนว่าองค์กรของคุณอาจเกี่ยวข้องกับ PCI DSS โดยไม่รู้ตัว
ลองเช็กเบื้องต้นว่าองค์กรของคุณมีลักษณะเหล่านี้หรือไม่
- รับชำระเงินผ่านบัตรเครดิตหรือเดบิต
- มีหน้าเว็บหรือแอปที่เชื่อมกับระบบชำระเงิน
- มีการรับข้อมูลบัตรผ่านโทรศัพท์ อีเมล หรือเอกสาร
- ใช้ third-party ที่เกี่ยวข้องกับระบบรับชำระเงิน
- มีพนักงานหรือผู้ดูแลระบบที่เข้าถึงระบบชำระเงินได้
- มีการเก็บ log, recording หรือไฟล์แนบที่อาจมีข้อมูลบัตร
- เคยคิดว่า “เราไม่ได้เก็บเลขบัตรหรอก” แต่ยังไม่เคยทำ scope assessment อย่างจริงจัง
หากตอบว่า “ใช่” แม้เพียงบางข้อ องค์กรของคุณก็ควรเริ่มประเมินความเกี่ยวข้องกับ PCI DSS อย่างเป็นระบบ
องค์กรควรเริ่มต้นอย่างไร หากไม่แน่ใจว่าเข้าข่ายหรือไม่
จุดเริ่มต้นที่ดีที่สุดไม่ใช่การรีบทำเอกสารทั้งหมด แต่คือการทำความเข้าใจว่า
- องค์กรรับข้อมูลบัตรผ่านช่องทางใด
- ข้อมูลนั้นไหลผ่านระบบไหนบ้าง
- ใครเข้าถึงข้อมูลหรือระบบเหล่านั้นได้
- มี third-party รายใดเกี่ยวข้อง
- ระบบไหนอยู่ใน CDE และระบบไหนมีผลกระทบต่อ CDE
เมื่อเห็นภาพเหล่านี้ชัด องค์กรจะสามารถกำหนด scope ได้แม่นขึ้น ลดการทำงานเกินจำเป็น และวางแผน compliance ได้อย่างคุ้มค่ากว่าเดิม
ACIS ช่วยองค์กรของคุณเรื่อง PCI DSS ได้อย่างไร
สำหรับองค์กรที่ยังไม่แน่ใจว่าตัวเองเกี่ยวข้องกับ PCI DSS หรือไม่ สิ่งที่สำคัญที่สุดคือการมีผู้เชี่ยวชาญช่วยมองภาพรวมทั้งในมุมธุรกิจ กระบวนการ และเทคนิค เพื่อไม่ให้ตีความ scope ผิดตั้งแต่ต้น
ACIS Professional Center มีหลักสูตร Introduction to PCI DSS Implementation Training ซึ่งครอบคลุมหัวข้อสำคัญ เช่น การทำ scoping, การลด scope, การเจาะลึก 12 ข้อกำหนด, เอกสารและหลักฐาน, การบริหารโครงการ PCI DSS และแนวคิด Business as Usual (BAU)
ในมุมของการให้บริการ องค์กรสามารถใช้แนวทางของ ACIS เพื่อสนับสนุนงานด้าน PCI DSS ได้ในลักษณะต่อไปนี้
- ช่วยประเมินว่าองค์กรเกี่ยวข้องกับ PCI DSS หรือไม่
- ช่วยวิเคราะห์ระบบและกระบวนการที่อาจอยู่ใน scope
- ช่วยวาง roadmap การเตรียมความพร้อม
- ช่วยให้ทีมงานเข้าใจ requirement ของ PCI DSS อย่างเป็นระบบ
- ช่วยลดความเสี่ยงจากการตีความมาตรฐานผิด
- ช่วยให้การเตรียมหลักฐานและการดำเนินโครงการมีทิศทางชัดเจน
สำหรับหลายองค์กร ความท้าทายไม่ได้อยู่ที่ “จะทำ PCI DSS หรือไม่” แต่อยู่ที่ “จะเริ่มต้นอย่างไรให้ถูกทาง” และนั่นคือจุดที่การมีพาร์ตเนอร์ที่เข้าใจทั้งมาตรฐานและบริบทธุรกิจเข้ามาช่วย จะทำให้โครงการเดินได้เร็วขึ้นและลดต้นทุนจากการแก้งานซ้ำ
