ซื้อกล้องวงจรปิดให้องค์กร สัญญาและการตรวจรับต้องมีอะไร

กล้องวงจรปิดที่ติดแล้วภาพขึ้นจอ ยังไม่ได้แปลว่าผู้ขายส่งมอบงานเสร็จ รหัสผ่านโรงงานอาจยังไม่ถูกเปลี่ยน บัญชีของช่างติดตั้งอาจยังเปิดอยู่ และแอปของผู้ผลิตอาจส่งภาพออกไปยังเซิร์ฟเวอร์ที่ไม่มีใครถามว่าอยู่ที่ไหน แนวปฏิบัติ สกมช. เล่มทั่วไปจึงใช้ทั้งบทที่ 4 พูดเรื่องการซื้อและการตรวจรับโดยเฉพาะ

บทความนี้อ่านข้อ 4.1 (ข้อกำหนดในการจัดซื้อ) และข้อ 4.2 (การส่งมอบและตรวจรับ) แล้วจัดเป็นของที่ผู้ซื้อหยิบไปใช้ได้เลย คือตารางข้อกำหนดคู่กับหลักฐาน รายการตรวจวันรับมอบ และจุดที่ต้องเขียนในสัญญา ส่วนเรื่อง PDPA ของตัวกล้อง เช่น ป้าย ฐานกฎหมาย และระยะเก็บภาพ อยู่ใน บทความกล้องวงจรปิดในออฟฟิศ ร้าน คอนโด ที่นี่จะไม่เล่าซ้ำ

แนวปฏิบัติ สกมช. เล่มนี้เป็นกฎหมายหรือไม่ และใช้กับใคร?

ไม่ใช่กฎหมาย ตัวแนวปฏิบัติเขียนไว้เองในคำนำว่าเป็นข้อเสนอแนะเบื้องต้น ไม่มีสภาพบังคับใช้ และใช้แทนกฎหมาย ประกาศ หรือสัญญาที่มีผลบังคับอยู่ไม่ได้ ในบทความนี้ทุกครั้งที่เขียนว่า "ควร" ให้อ่านว่าแนวปฏิบัติแนะนำ ไม่ใช่กฎหมายสั่ง

เอกสารที่ใช้คือแนวปฏิบัติการรักษาความมั่นคงปลอดภัยระบบกล้องโทรทัศน์วงจรปิดสำหรับประเทศไทย ฉบับ 1.0.0 ฉบับประกาศใช้ ลงวันที่ 29 กันยายน 2569 เผยแพร่โดย สกมช. ส่วนฉบับที่ว่าด้วยกล้องที่ใช้ AI เป็นอีกเล่มหนึ่ง ไม่ได้อยู่ในบทความนี้

ข้อ 4.1 แบ่งหน้าที่ไว้ชัด เจ้าของระบบหรือผู้จัดซื้อเป็นฝ่ายกำหนดความต้องการและเกณฑ์ใน TOR ส่วนผู้เสนอราคา ผู้ติดตั้ง และผู้รวมระบบเป็นฝ่ายแสดงความสามารถและหลักฐานให้ตรงกับข้อกำหนด นั่นแปลว่าถ้า TOR เขียนหลวม ผู้ขายไม่มีอะไรต้องพิสูจน์

แนวปฏิบัติแบ่งระบบเป็นระดับ B, E และ H ตามความสำคัญและผลกระทบ ระดับของข้อกำหนดที่ขอควรสัมพันธ์กับระดับนี้ จุดที่ต้องระวังคือ ตัวอักษรสามตัวนี้เป็นวิธีใช้แนวปฏิบัติของเล่มนี้เอง ตัวเอกสารเขียนว่าไม่ใช่การจัดประเภทองค์กรตามกฎหมาย และไม่ใช่การจำแนกโครงสร้างพื้นฐานสำคัญทางสารสนเทศ จึงอย่านำไปอ้างว่าองค์กรเป็น CII หรือไม่เป็น CII

TOR แบบไหนที่ตรวจรับไม่ได้ และแบบไหนที่ตรวจได้?

TOR ที่ตรวจรับได้คือ TOR ที่บอกว่าจะดูอะไร ดูด้วยวิธีใด และเห็นอะไรถึงนับว่าผ่าน ข้อ 4.1.1.15 ให้เหตุผลว่า ถ้าไม่เขียนไว้ก่อน พอถึงวันรับมอบผู้ซื้อจะบอกไม่ได้ว่าคุณสมบัติข้อไหนผ่านหรือไม่ผ่านจากหลักฐานอะไร

ตัวอย่างที่แนวปฏิบัติยกเองคือ TOR ที่เขียนแค่ความละเอียดของกล้อง เอกสารถือว่าไม่เหมาะสม เพราะยืนยันไม่ได้ว่าภาพของแต่ละจุดตอบวัตถุประสงค์หรือไม่

เริ่มจากความต้องการรายจุด ไม่ใช่จากสเปกกล้อง

ข้อ 4.1.1.7 ให้เริ่มจากความต้องการเชิงปฏิบัติการรายจุด คือเขียนก่อนว่าภาพจากจุดนี้ต้องใช้ทำอะไร ตรวจพบคนผ่าน สังเกตพฤติกรรม จดจำคนที่เคยเห็น หรือระบุตัวบุคคล แล้วค่อยกำหนดสเปกและเกณฑ์ตรวจรับที่พิสูจน์ได้

ปัจจัยที่ทำให้กล้องความละเอียดสูงให้ภาพใช้ไม่ได้ ตามที่ข้อนี้ระบุ คือตำแหน่งติดตั้ง ระยะ มุมมอง เลนส์ สภาพแสง การเคลื่อนไหว และการบีบอัดข้อมูล ผู้ซื้อจึงควรขอให้ทดสอบทั้งกลางวันและกลางคืนในช่วงที่ระบบต้องใช้จริง ไม่ใช่เฉพาะตอนแสงดี

ควรขออะไรจากผู้ขาย และขอหลักฐานอะไรคู่กัน?

ตารางต่อไปนี้ย่อหัวข้อ 4.1.1.1 ถึง 4.1.1.13 ของแนวปฏิบัติเป็นรายการสำหรับใส่ใน TOR ผู้เขียนเรียบเรียงเอง ไม่ได้คัดตารางของแนวปฏิบัติมาตรง ๆ คอลัมน์ท้ายสุดอิงตัวอย่างวิธีตรวจในข้อ 4.1.1.15 ถ้าเป็นระบบเล็ก เลือกใช้เท่าที่เข้ากับความเสี่ยงได้ แนวปฏิบัติเองก็ให้ปรับตามสัดส่วน

ถ้าองค์กรอยากเก็บระยะเก็บภาพให้ตรงกับนโยบายและมีบันทึกการลบไว้เป็นหลักฐาน ฟีเจอร์กฎการเก็บรักษาและบันทึกการทำลายใน AIPDPA รองรับเรื่องนี้ ดูตัวอย่างได้ที่ บัญชีตัวอย่าง

หลักฐานมีหลายระดับ ไม่ต้องเป็นใบรับรองเสมอไป

ข้อ 4.1.1.14 บอกให้กำหนดตั้งแต่ต้นว่าผู้เสนอราคาต้องแสดงหลักฐานชนิดใด หลักฐานมีตั้งแต่เอกสารคุณลักษณะ คู่มือการตั้งค่า นโยบายของผู้ผลิต ประกาศแจ้งเตือนด้านความปลอดภัย การสาธิต ผลทดสอบ การประเมินโดยหน่วยอิสระ ใบรับรอง ไปจนถึงเอกสารที่เปิดเผยเฉพาะผู้ประเมินภายใต้ข้อตกลงรักษาความลับ ระดับที่ขอควรสัมพันธ์กับความเสี่ยง

ใบรับรองไม่ใช่คำตอบเดียว ข้อ 4.1.2 ให้ดูว่าใบรับรองครอบคลุมขอบเขตใด ตรงกับรุ่นและเวอร์ชันที่ซื้อจริงหรือไม่ ยังมีผลอยู่หรือหมดอายุ ใครเป็นผู้ออก และเป็นการประเมินตนเองหรือโดยบุคคลที่สาม แนวปฏิบัติบอกว่าการมีใบรับรองไม่ได้แปลว่าผลิตภัณฑ์ปลอดภัยพอสำหรับทุกบริบท และการไม่มีใบรับรองก็ไม่ควรเป็นเหตุผลเดียวที่ใช้สรุปว่าผลิตภัณฑ์ไม่เหมาะสม

แนวปฏิบัติยังเตือนว่า ฉลากหรือระบบรับรองของต่างประเทศใช้เป็นหลักฐานประกอบได้ แต่ไม่ควรเอากฎหมายหรือเกณฑ์บังคับของประเทศอื่นมาเป็นข้อบังคับของระบบในไทยโดยอัตโนมัติ

สัญญาควรเขียนเรื่องอายุผลิตภัณฑ์และวันที่ผู้ผลิตเลิกดูแลอย่างไร?

กล้องวงจรปิดมักใช้งานหลายปี แต่เฟิร์มแวร์ ซอฟต์แวร์ และบริการที่เกี่ยวข้องอาจได้รับการสนับสนุนสั้นกว่านั้น ข้อ 4.1.1.13 จึงให้มองไปตลอดอายุการใช้งาน ไม่ใช่ดูแค่ว่ารับประกันฮาร์ดแวร์กี่ปี

แนวปฏิบัติยังเตือนไม่ให้เขียนสั้น ๆ ว่า "ผู้ขายต้องแจ้ง EoL/EoS" แต่ให้เขียนให้ครบว่าต้องแจ้งสถานะสิ้นสุดอายุและสิ้นสุดการสนับสนุน พร้อมวันที่มีผล ขอบเขตที่ยุติลง และแนวทางปรับปรุงหรือทดแทน

ผู้ขายหรือผู้ติดตั้งดูแลระบบหรือเก็บภาพแทนเรา ต้องมีสัญญาตาม PDPA ไหม?

ถ้าผู้ขาย ผู้ติดตั้ง หรือผู้ให้บริการคลาวด์เข้าถึงหรือประมวลผลภาพที่เป็นข้อมูลส่วนบุคคลแทนองค์กร เขามีสถานะเป็นผู้ประมวลผลข้อมูลส่วนบุคคลได้ และ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล มาตรา 40 วรรคสาม ให้ผู้ควบคุมข้อมูลต้องจัดให้มีข้อตกลงระหว่างกัน

แนวปฏิบัติ สกมช. พูดไปในทางเดียวกัน แต่ใช้ภาษาของงานจัดซื้อ ข้อ 4.1.1.11 ให้กำหนดบทบาท หน้าที่ มาตรการความปลอดภัย การจัดการเหตุ การคืนหรือลบข้อมูล และการใช้ผู้ให้บริการช่วงไว้ในสัญญา

ข้อเดียวกันยังเตือนว่า ฟังก์ชันด้านความเป็นส่วนตัวในตัวผลิตภัณฑ์ เช่น มาสก์พื้นที่ในภาพ เป็นแค่เครื่องมือช่วยปฏิบัติตามข้อกำหนด ไม่ได้ทำให้การใช้ระบบถูกกฎหมายโดยอัตโนมัติ

ถ้าผู้ให้บริการหรือเซิร์ฟเวอร์อยู่ต่างประเทศ เรื่องส่งข้อมูลออกนอกไทยตามมาตรา 28 จะเข้ามาด้วย ลำดับตรวจดูได้ใน บทความมาตรา 28 และคำถามเฉพาะกล้องอยู่ใน บทความกล้องบนคลาวด์และ P2P

วันรับมอบต้องตรวจอะไรบ้างก่อนเซ็น?

แนวปฏิบัติเขียนวัตถุประสงค์ของข้อ 4.2 ไว้กว้างกว่าการดูว่าภาพขึ้น การส่งมอบที่สมบูรณ์ต้องทำให้เจ้าของระบบบริหาร ใช้งาน ดูแล ตรวจสอบ กู้คืน และปรับปรุงระบบต่อได้ โดยไม่ต้องพึ่งผู้ติดตั้งเกินความจำเป็น

1. ก่อนประกาศ TOR
   เขียนความต้องการรายจุด ระดับ B/E/H และเกณฑ์ตรวจรับของข้อกำหนดสำคัญข้อ 4.1.1.15
2. ช่วงพิจารณาข้อเสนอ
   ขอหลักฐานตามที่กำหนด เช่น เอกสาร การสาธิต ผลทดสอบ และตรวจว่าใบรับรองตรงรุ่นและตรงขอบเขตข้อ 4.1.1.14 · 4.1.2
3. ก่อนเซ็นสัญญา
   ใส่อายุผลิตภัณฑ์ EoL/EoS ข้อตกลงผู้ประมวลผล เงื่อนไขคลาวด์ และการยุติบริการข้อ 4.1.1.10 · 4.1.1.12
4. ตอนติดตั้ง
   ของจริงต้องตรงแบบที่อนุมัติ ถ้าต่างอย่างมีนัยสำคัญให้ประเมินและขออนุมัติก่อนข้อ 4.2.1
5. วันตรวจรับ
   ตรวจภาพ การบันทึก ความปลอดภัย และเอกสารที่ส่งมอบข้อ 4.2.2–4.2.4
6. ก่อนเปิดใช้จริง
   ยกเลิกบัญชี รหัส ช่องทางรีโมต และกฎที่เปิดไว้ชั่วคราว แล้วเก็บผลตรวจเป็นค่าฐานข้อ 4.2.3 · 4.2.5
7. หลังตรวจรับ
   ติดตามประเด็นคงค้างจนปิด หรือให้ผู้มีอำนาจยอมรับความเสี่ยงอย่างเป็นทางการข้อ 4.2.8–4.2.9

รายการที่ 1 ของที่ติดตั้งตรงกับที่ซื้อหรือไม่ (ข้อ 4.2.1)

• กล้อง จำนวน รุ่น หมายเลขประจำเครื่อง และตำแหน่งตรงกับรายการที่อนุมัติ
• เครื่องบันทึกและระบบบริหารวิดีโอ รุ่น เวอร์ชัน และใบอนุญาตใช้งาน
• พื้นที่จัดเก็บ ประเภท ความจุ และการตั้งค่า
• อุปกรณ์เครือข่าย รุ่น การเชื่อมต่อ และการแบ่งเครือข่าย
• เวอร์ชันเฟิร์มแวร์และซอฟต์แวร์ที่ติดตั้งจริง รวมถึงค่าตั้งระบบ
• บริการคลาวด์ การเข้าจากระยะไกล และการเชื่อมต่อกับระบบอื่น ตรงกับขอบเขตที่อนุมัติ

ถ้าของจริงต่างจาก TOR แบบ หรือข้อเสนอแบบมีนัยสำคัญ แนวปฏิบัติให้ประเมินผลกระทบและขออนุมัติก่อนตรวจรับ ไม่ใช่รับไปก่อนแล้วค่อยคุย

รายการที่ 2 ภาพและการบันทึกใช้งานได้จริงหรือไม่ (ข้อ 4.2.2)

• ตรวจในสภาพใช้งานจริงหรือใกล้เคียง โดยยึดความต้องการรายจุดเป็นฐาน
• ดูพื้นที่ครอบคลุม ระดับ DORI การใช้งานกลางวันและกลางคืน การจัดการแสง และภาพเบลอจากการเคลื่อนไหว
• ทดสอบบันทึกต่อเนื่อง เรียกดูย้อนหลัง ส่งออก ระยะเก็บ ความจุ และการแจ้งเตือนเมื่อพื้นที่ใกล้เต็ม
• สำหรับระบบสำคัญ ทดสอบความต่อเนื่องและการกู้คืนตามที่กำหนด

ข้อนี้ปิดท้ายว่าไม่ควรตรวจรับคุณภาพภาพจากความละเอียดหรือแผ่นสเปกของกล้องเพียงอย่างเดียว

รายการที่ 3 ความปลอดภัยก่อนเปิดใช้ (ข้อ 4.2.3)

• รหัสผ่านและข้อมูลยืนยันตัวตนเริ่มต้นถูกเปลี่ยน ยกเลิก หรือจัดการแล้ว
• บัญชีสร้างตามผู้ใช้จริงและบทบาท บัญชีติดตั้ง บัญชีทดสอบ และบัญชีแขก ถูกลบ ปิด หรือจำกัด
• พอร์ตและบริการเปิดเฉพาะที่อนุมัติ ส่วนบริหารเข้าได้เฉพาะเครือข่ายและสิทธิที่กำหนด
• การเข้าจากระยะไกลใช้เฉพาะช่องทางที่อนุมัติ และ MFA ทำงานตามที่กำหนด
• เฟิร์มแวร์เป็นเวอร์ชันที่อนุมัติและยังได้รับการสนับสนุน
• บันทึกเหตุการณ์ เวลาของอุปกรณ์ ระยะเก็บ การสำรองและกู้คืน การเข้ารหัสและใบรับรอง และบริการ P2P หรือคลาวด์ ตรงตามที่กำหนด

ผลการตรวจชุดนี้แนวปฏิบัติให้เก็บเป็นค่าฐานที่ได้รับอนุมัติ (Approved Configuration Baseline) ใช้เทียบทุกครั้งที่มีการเปลี่ยนค่าตั้งภายหลัง ถ้าไม่มีค่าฐาน ก็ไม่มีอะไรให้เทียบว่าใครแก้อะไร

รายการที่ 4 เอกสารที่ต้องได้รับ (ข้อ 4.2.4)

เอกสารที่ส่งมอบควรพอให้เจ้าของระบบดูแลและกู้ระบบได้โดยไม่ต้องพึ่งความรู้ในหัวของช่างคนเดียว ไม่จำเป็นต้องทำเอกสารใหม่ทุกรายการ ถ้าข้อมูลนั้นมีอยู่แล้วในระบบหรือคู่มือที่เจ้าของระบบเข้าถึงและตรวจได้

• ทะเบียนอุปกรณ์ และรุ่นซอฟต์แวร์กับเฟิร์มแวร์ที่ติดตั้งจริง
• ผังตำแหน่งกล้อง ผังเครือข่าย แบบที่ติดตั้งจริง และข้อมูลเครือข่าย (IP, VLAN, พอร์ตและบริการ)
• โครงสร้างบทบาทและสิทธิ ค่าตั้งระยะเก็บและผลคำนวณความจุ
• ขั้นตอนและผลทดสอบการสำรองและกู้คืน แผนบำรุงรักษา ขั้นตอนอัปเดตเฟิร์มแวร์
• คู่มือตั้งค่าที่มั่นคงปลอดภัย ช่องทางรับ Security Advisory และแจ้งช่องโหว่ ข้อมูลช่วงสนับสนุนและ EoL/EoS
• ผลการทดสอบและตรวจรับ รวมถึงประเด็นคงค้าง ข้อยกเว้น และความเสี่ยงคงเหลือ

รายการที่ 5 ปิดทางเข้าหลังบ้านที่ใช้ตอนติดตั้ง (ข้อ 4.2.5)

ก่อนเปิดใช้จริง ควรยกเลิกสิทธิและช่องทางที่ใช้เฉพาะช่วงติดตั้งหรือส่งมอบ แนวปฏิบัติไล่ไว้ 8 รายการ

1. บัญชีสำหรับติดตั้งระบบ
2. บัญชีสำหรับทดสอบระบบ
3. บัญชีผู้ใช้ชั่วคราว
4. รหัสผ่านชั่วคราว
5. ช่องทางสนับสนุนจากระยะไกล
6. โทเคนหรือกุญแจพิสูจน์ตัวตนชั่วคราว
7. กฎไฟร์วอลล์ที่เปิดไว้ชั่วคราว
8. พอร์ตหรือบริการเครือข่ายที่เปิดเพื่อติดตั้งหรือทดสอบ

ถ้าช่างต้องการเก็บสิทธิไว้ซ่อมบำรุงจริง ให้ทำเป็นข้อตกลงที่ระบุตัวคน วัตถุประสงค์ ขอบเขต วิธีอนุมัติ ระยะเวลา และตรวจย้อนหลังได้ แล้วเก็บไว้ในเอกสารสัญญา ไม่ใช่ตกลงปากเปล่า

ถ้าสัญญาให้มีใบรับรอง รายงานทดสอบ หรือผลประเมินจากบุคคลที่สาม (ข้อ 4.2.6–4.2.7)

อย่าตรวจแค่ว่า "มีเอกสาร" ให้ดูว่าหลักฐานมีจริง ยังมีผล ขอบเขตตรงกับที่ซื้อ รุ่นและเวอร์ชันตรงกัน และเชื่อมกับของที่ส่งมอบได้ ถ้าใช้กับคนละรุ่นหรือครอบคลุมบางส่วน ข้อ 4.2.6 ไม่ให้ถือว่าครอบคลุมทั้งระบบ ส่วนระบบที่ใช้คลาวด์ ข้อ 4.2.7 ให้ตรวจว่าที่ตั้งข้อมูล ที่ประมวลผล ผู้ให้บริการช่วง ผู้เข้าถึงเพื่อบริหาร กุญแจ การสำรอง การแจ้งเหตุ การคืนและการลบข้อมูล ตรงกับ TOR และสัญญา

ตรวจรับแล้วยังมีข้อบกพร่อง จะรับแบบมีเงื่อนไขได้อย่างไร?

รับได้ แต่ต้องเขียนให้ติดตามได้ ข้อ 4.2.8 ไม่ให้บันทึกแค่ว่า "แก้ไขภายหลัง" และข้อ 4.2.9 ให้ผู้ตรวจรับระบุผลพร้อมเหตุผลตามเกณฑ์ที่กำหนด

• ประเด็น คือข้อบกพร่องหรือช่องว่างที่พบ
• ผลกระทบต่อข้อมูล ระบบ หรือภารกิจ และระดับความเสี่ยง
• มาตรการชั่วคราวระหว่างรอแก้
• สิ่งที่ต้องแก้ ผู้รับผิดชอบ และกำหนดเวลา
• สถานะ คือเปิด อยู่ระหว่างดำเนินการ หรือปิดแล้ว

แนวปฏิบัติยกตัวอย่างผลการตรวจรับไว้สามแบบ ซึ่งเอามาใช้เป็นแบบฟอร์มได้เลย

อีกจุดที่ผู้ซื้อมักพลาดคือคิดว่าเซ็นรับงานแล้ว ความเสี่ยงก็ถูกยอมรับแล้ว แนวปฏิบัติบอกตรง ๆ ว่าไม่ควรตีความอย่างนั้น

ความเสี่ยงคงเหลือที่มีนัยสำคัญ ควรให้ผู้มีอำนาจตามกระบวนการบริหารความเสี่ยงขององค์กรพิจารณาและยอมรับเป็นลายลักษณ์อักษร ไม่ใช่ให้ช่างหรือคณะกรรมการตรวจรับทางเทคนิคเซ็นแทน

สรุปเป็นลำดับลงมือ สำหรับผู้ซื้อ

1. เขียนความต้องการรายจุดก่อนเลือกรุ่น และกำหนดว่าภาพแต่ละจุดต้องใช้ทำอะไร
2. ใส่ข้อกำหนดที่ตรวจได้ใน TOR พร้อมบอกว่าจะตรวจด้วยวิธีใดและเกณฑ์ผ่านคืออะไร
3. ขอหลักฐานตามระดับความเสี่ยง และเช็กขอบเขต รุ่น เวอร์ชันของใบรับรองทุกครั้ง
4. ถามเรื่อง Security Update, EoL และ EoS เป็นลายลักษณ์อักษรก่อนเซ็น
5. ถ้าใครเข้าถึงภาพแทนเรา ทำข้อตกลงผู้ประมวลผลตามมาตรา 40 วรรคสาม
6. วันรับมอบ ตรวจ 5 รายการข้างต้น แล้วเก็บผลเป็นค่าฐานที่อนุมัติ
7. ปิดบัญชีและช่องทางชั่วคราวก่อนเปิดใช้ แล้วค่อยลงนามรับ
8. ถ้ารับแบบมีเงื่อนไข ให้มีผู้รับผิดชอบและวันครบกำหนดเป็นลายลักษณ์อักษร

ใครรับผิดชอบเนื้อหานี้?

เรียบเรียงโดยทีมกฎหมาย AIPDPA · ผู้รับผิดชอบเนื้อหา ภูวรา ครอบตะคุ ทนายความ · เนติบัณฑิตไทย · ที่ปรึกษากฎหมายเทคโนโลยีและทรัพย์สินทางปัญญา

ใบอนุญาตทนายความ 477/2558 · เนติบัณฑิตไทย · นิติศาสตรมหาบัณฑิต กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ (เหรียญทอง)