Cybersecurity สำหรับ FA SIer — คู่มือ RFP และหลักฐานรับมอบในไทย ปี 2026

เมื่อต้องใส่ cybersecurity ลงในการจัดซื้อ FA SIer การถามเพียงว่า “รองรับ IEC 62443 หรือไม่” หรือ “remote maintenance ปลอดภัยหรือไม่” ยังไม่พอ เจ้าของโรงงาน วิศวกรรมการผลิต ฝ่ายจัดซื้อ และทีม OT security ต้องซื้อบริการที่ระบุว่าใครทำอะไร เมื่อไร ส่งหลักฐานใด และแก้ไขอย่างไรเมื่อไม่ผ่าน บทความนี้แปลงข้อกำหนดให้ใช้ได้จริงใน RFP สัญญา FAT, SAT การรับมอบงานบำรุงรักษา และชุดส่งมอบเมื่อสิ้นสุดสัญญาของโครงการระบบอัตโนมัติในไทย

แนวทางนี้ใช้ได้ทั้งเครื่องจักรใหม่และ brownfield เช่น PLC, HMI, robot cell, machine vision, SCADA การเก็บข้อมูลเครื่องจักร และการซ่อมบำรุงจากต่างประเทศ อย่างไรก็ตาม ข้อกำหนดต่อไปนี้ไม่ใช่คำแนะนำทางกฎหมายหรือ template ที่ใช้เหมือนกันทุกโครงการ ต้องปรับตามผลกระทบด้านความปลอดภัย เวลาหยุดที่ยอมรับได้ จุดเชื่อมต่อ ตลาดปลายทาง และบทบาทตามกฎหมายของคู่สัญญา

สรุป: จัดซื้อ “หลักฐานที่ทำซ้ำได้” ไม่ใช่เพียงคำยืนยัน

RFP ที่ดีไม่เพียงขอให้ SIer “ดูแล cybersecurity” แต่กำหนด asset inventory, configuration baseline, remote access ที่ควบคุมได้, บัญชีรายบุคคล, การตัดสินใจเรื่อง patch, การทดสอบ restore, incident escalation, change log, การควบคุมผู้รับเหมาช่วง และ exit package เป็น deliverable พร้อมให้สาธิตใน FAT/SAT และเชื่อมกับเกณฑ์รับมอบและการชำระเงิน

หลักสำคัญมีสามข้อ:

1. ระบุกระบวนการที่ใช้และเหตุผลของข้อยกเว้น ไม่ใช่ระบุเพียงชื่อมาตรฐาน
2. ยืนยันด้วยค่า configuration, log และผลทดสอบ ไม่ใช่ self-declaration
3. เชื่อมความรับผิดชอบถึงช่วงใช้งานและสิ้นสุดสัญญา รวมถึงการแจ้งเหตุและการตัด access ฉุกเฉิน

คู่มือนี้เสริม แนวทางเลือก FA system integrator ญี่ปุ่นในไทย และ คู่มือขอบเขตความรับผิดชอบของ FA system integration โดยเน้นการเปลี่ยนขอบเขตความรับผิดชอบให้เป็นหลักฐานและการทดสอบรับมอบ

1. เหตุผลที่ต้องทบทวนข้อกำหนดในปี 2026

TIS 62443 Part 2(4)-2568 มีผลใช้ในไทยแล้ว

สำนักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรมระบุ TIS 62443 Part 2(4)-2568 เรื่องข้อกำหนดโปรแกรมความมั่นคงปลอดภัยสำหรับผู้ให้บริการ IACS โดยมีผลวันที่ 9 พฤษภาคม 2026 และแทนที่ TIS 62443 Part 2(4)-2561 ข้อมูล TISI ระบุว่าฉบับเดิมเหมือนกับ IEC 62443-2-4:2015 แต่ไม่ควรกล่าวว่าฉบับ 2568 เหมือนกับ IEC 62443-2-4:2023 ทั้งหมด หากไม่มีแหล่งทางการยืนยันชัดเจน

ฝ่ายจัดซื้อจึงไม่ควรเขียนเพียง “ต้องสอดคล้อง TIS” แต่ให้ผู้เสนอระบุ edition, scope, กระบวนการที่ส่งมอบ, หลักฐาน และข้อยกเว้น ใบรับรองเพียงอย่างเดียวไม่ได้รับรอง configuration และการปฏิบัติงานของโครงการนี้โดยอัตโนมัติ

IEC 62443-2-4:2023 เน้นกระบวนการของผู้ให้บริการ

IEC 62443-2-4:2023 Edition 2.0 เผยแพร่วันที่ 15 ธันวาคม 2023 และกำหนดกระบวนการด้าน security ที่ผู้ให้บริการ IACS สามารถเสนอในช่วง integration และ maintenance ของ Automation Solution มาตรฐานเปิดให้ใช้ profile หรือ subset ตามสภาพแวดล้อม จึงไม่ควรตีความว่าทุก clause ต้องใช้ระดับเดียวกันในทุกโครงการ

แทนคำถาม Yes/No ให้ผู้เสนอกรอกตารางว่าใช้กระบวนการใด ข้อใดไม่ใช้ compensating control คืออะไร หลักฐานชื่อใด และส่งเมื่อไร จะเปรียบเทียบข้อเสนอได้จริง

สินค้าสู่ตลาด EU ต้องมีหลักฐานจาก supplier เพื่อรองรับ CRA

หน้าที่รายงานตาม Article 14 ของ EU Cyber Resilience Act เริ่มวันที่ 11 กันยายน 2026 ผู้ผลิต products with digital elements ต้องรายงาน actively exploited vulnerability และ severe incident ผ่าน ENISA Single Reporting Platform โดย early warning ภายใน 24 ชั่วโมงนับจากรับรู้ และ fuller notification ภายใน 72 ชั่วโมง รายงานสุดท้ายของ actively exploited vulnerability ต้องส่งภายใน 14 วันหลังมีมาตรการแก้ไขหรือบรรเทาพร้อมใช้งาน ส่วน severe incident ต้องส่งภายในหนึ่งเดือนนับจาก notification ที่ 72 ชั่วโมง

ไม่ได้หมายความว่า FA SIer ในไทยทุกรายเป็น “manufacturer” ตาม CRA ต้องให้ฝ่ายกฎหมายพิจารณาจากสัญญา ผลิตภัณฑ์ และบทบาทในตลาด EU ประเด็นเชิงปฏิบัติคือผู้ผลิตเครื่องจักรที่ส่ง EU ต้องได้รับเวลาตรวจพบ asset/version ที่กระทบ วิธีบรรเทา และผู้รับผิดชอบจาก SIer และ supplier อย่างรวดเร็ว แพลตฟอร์ม ENISA เป็นช่องทางรายงาน ไม่ใช่ portal รับรองมาตรฐาน

VPN เพียงอย่างเดียวไม่ทำให้ remote maintenance สมบูรณ์

CISA เตือนว่าไม่อาจสมมติว่าความไว้วางใจเดิมระหว่าง vendor กับ operator ปลอดภัย หาก vendor ถูกโจมตี ผู้โจมตีอาจอาศัย trusted connection เข้าโรงงาน VPN ปกป้องช่องทางสื่อสารได้ แต่ไม่ได้ยืนยันว่าใครอนุมัติ ใช้ endpoint ใด เข้าได้นานเท่าไร เข้าถึง asset ใด หรือเปลี่ยนอะไร

จึงควรใช้ named approval, MFA, jump host, time-bounded enablement, least privilege, session logging และ emergency disable ตามความเสี่ยง พร้อมสาธิตใน SAT เอกสาร procurement language ของ CISA เป็น toolkit ให้ข้อมูล ไม่ใช่มาตรฐานหรือนโยบายบังคับ และต้องปรับใช้ตามโครงการ

2. สิ่งที่เจ้าของระบบต้องตัดสินใจก่อนออก RFP

คำตอบของ SIer จะชัดเจนได้ไม่เกินขอบเขตที่เจ้าของกำหนด ก่อน tender ให้สรุปอย่างน้อยดังนี้:

• อุปกรณ์ใน scope: PLC, HMI, industrial PC, robot, vision, SCADA, server, switch, gateway
• กระบวนการและผลกระทบ: ผลของ downtime ต่อ safety, quality และ delivery
• interface: OT โรงงาน, enterprise IT, cloud, OEM และไซต์ต่างประเทศ
• ข้อมูล: recipe, program, ภาพคุณภาพ, personal data, credential และ log
• lifecycle: design, build, installation, warranty, maintenance, modification และ exit
• ผู้ตัดสินใจ: owner, production engineering, IT/OT, safety, quality, procurement และ legal
• เป้าหมายการกู้คืน: ต้องกู้อะไร ตามลำดับใด และย้อนกลับถึง baseline ใด
• ตลาด: ใช้ในไทยเท่านั้นหรือเกี่ยวข้องกับสินค้า/เครื่องจักรสู่ EU

วาดขอบเขต Automation Solution ไม่ใช่เพียงรายการอุปกรณ์

หาก scope มีเพียง PLC และ VPN appliance อาจตกหล่น engineering laptop, สื่อ backup, licence server และเครื่อง relay ของ OEM นอกจาก network diagram ต้องวาด data flow ว่า program สร้างที่ไหน ใครอนุมัติ ขนส่งอย่างไร เก็บที่ไหน และใคร restore

ทบทวน safety และ security change ร่วมกัน

hardening อาจทำให้การซ่อมช้าลง patch อาจเปลี่ยน PLC communication และ logging อาจเพิ่มโหลด industrial PC ให้ใส่ security impact, safety impact, production impact และ rollback criteria ใน change record เดียวกัน การอนุมัติแยกทางอีเมลทำให้ไม่มีใครเป็นเจ้าของ configuration สุดท้าย

3. Evidence matrix สำหรับ RFP ด้าน FA SIer cybersecurity

ตารางต่อไปนี้เป็นขั้นต่ำเชิงปฏิบัติ ปรับตาม criticality และ architecture แต่ทุกข้อที่เลือกต้องมีรูปแบบหลักฐานและวันส่ง

ให้น้ำหนักหลักฐานเฉพาะโครงการมากกว่า policy ทั่วไป

SIer อาจมี corporate policy ที่ดีแต่ไม่เชื่อมกับ PLC หรือ OEM account ของโครงการ ให้แยกคะแนน process description, ตัวอย่าง deliverable เฉพาะโครงการ, ความสามารถในการสาธิต, ความโปร่งใสของ exception และความต่อเนื่องช่วง maintenance ตั้ง minimum pass ก่อนรวมคะแนน security กับราคา

ห้าช่องที่ต้องมีในการตอบเรื่องมาตรฐาน

1. มาตรฐาน edition และ profile
2. บริการที่อยู่ในและนอก scope
3. กระบวนการภายในที่ใช้ตอบ requirement
4. หลักฐานที่จะส่งในโครงการนี้
5. deviation, compensating control และ approver

คำตอบว่า “มีแผน comply” หรือ “ทำตาม best practice” ยังไม่ใช่ข้อผูกพันที่ทำสัญญาได้

4. ลดความกำกวมในสัญญา

ผูก security deliverable กับ milestone และ payment

หากเกณฑ์รับมอบมีเพียงเครื่องเดินได้ inventory, backup, log และการจัดการ account จะถูกเลื่อน ให้กำหนด deliverable ใน design approval, FAT, SAT และ final handover พร้อมเงื่อนไข conditional acceptance ระยะเวลาแก้ไข และผู้รับผิดชอบค่า retest

Notification SLA ต้องมีจุดเริ่ม ช่องทาง และข้อมูลขั้นต่ำ

คำว่า “แจ้งโดยเร็ว” วัดไม่ได้ ต้องระบุว่านับจากเวลาที่ SIer พบเหตุหรือเมื่อมี confidence ตามเกณฑ์ใด แยกช่องทางปกติกับฉุกเฉิน Initial notice อย่างน้อยต้องมีเวลาพบ ขอบเขตที่อาจกระทบ version การ containment ปัจจุบัน และเวลารายงานครั้งถัดไป หากสัญญารองรับ manufacturer ที่อยู่ใต้ CRA ต้องออกแบบ supplier notification ให้ manufacturer ประเมินภายใน 24 และ 72 ชั่วโมงได้ โดยไม่เขียนเหมือน SIer รับบทกฎหมายของ manufacturer โดยอัตโนมัติ

แยกสิทธิในการรู้กับสิทธิในการเปลี่ยน

สิทธิรับ vulnerability notice, ดู component information, อ่าน log และอนุมัติการเปลี่ยน device เป็นคนละสิทธิ สัญญาที่ให้ SIer patch ฉุกเฉินโดยไม่ขออนุมัติก็เสี่ยง และสัญญาที่ทำอะไรไม่ได้เมื่อ owner ติดต่อไม่ได้ก็เสี่ยงเช่นกัน ให้กำหนดเส้นทาง urgent containment, permanent remediation และ normal change แยกกัน

ทำให้ subcontractor และ OEM access มองเห็นได้

ผู้เชื่อมต่อจริงอาจเป็น OEM ต่างประเทศ panel builder หรือ software company ให้ลงทะเบียนองค์กร ประเทศ วิธีเชื่อม ข้อมูล privilege และวันสิ้นสุดสัญญา การเพิ่มรายใหม่ต้องขออนุมัติก่อน และ prime SIer ต้องส่งผ่านหน้าที่เทียบเท่าและจัดหาหลักฐานได้

5. การออกแบบรับมอบ OT remote maintenance security

ให้ถือ remote maintenance เป็น work session ที่ได้รับอนุมัติ ไม่ใช่เพียง network connection

ก่อนเชื่อมต่อ

• ใช้ identity รายบุคคล และห้าม shared ID เป็นค่าเริ่มต้น
• บันทึก work order, target asset, purpose, เวลาเริ่ม/จบ และ approver
• ใช้ MFA และ managed endpoint ตามความเสี่ยง
• จำกัด destination และป้องกัน lateral movement
• เปิด access เฉพาะช่วงอนุมัติ ไม่เปิดถาวร
• กำหนดขั้นต่ำของ vendor endpoint และการแจ้งเมื่อ vendor ถูก compromise

ระหว่างเชื่อมต่อ

• รวมเส้นทางผ่าน jump host เมื่อเหมาะสม
• เก็บ login, target, เวลาเริ่ม/จบ และ command หรือ session record
• ควบคุม file transfer, clipboard และ removable media
• privilege elevation ต้องอนุมัติแยก
• โรงงานต้องมองเห็น session และตัดได้ทันที

หลังเชื่อมต่อ

• คืนรายละเอียดงาน ไฟล์ที่เปลี่ยน configuration delta การ restart และ test result เข้าสู่ work order
• expire temporary ID, rule และ file
• อัปเดต baseline, inventory และ backup
• review failed action และ anomalous traffic
• ยืนยันว่าครั้งถัดไปไม่ได้รับอนุญาตอัตโนมัติ

SAT ต้องทดสอบกรณีปฏิเสธด้วย

การเชื่อมสำเร็จไม่พอ ต้องพิสูจน์ว่า unapproved ID, approval หมดอายุ, destination ผิด และ MFA fail ถูกปฏิเสธ หลัง emergency shutdown ต้อง reconnect ไม่ได้ และ owner export log ได้ หากห้าม video recording ให้ตกลงหลักฐานอื่น เช่น command audit, screenshot ที่ปิดข้อมูล และการทดสอบต่อหน้าพยาน

6. รับมอบคุณภาพการตัดสินใจ ไม่ใช่เพียง patch rate

OT อาจ patch ทันทีไม่ได้เพราะ compatibility, outage window, safety approval หรือ vendor support แต่ “เครื่องจักรจึงไม่ patch” ไม่ใช่การบริหาร ให้บันทึก:

• product/component ที่ติดตาม
• advisory source และความถี่การ review
• impact: product, version, exposure, exploitation และ process impact
• decision: deploy, defer, not applicable หรือ compensating control
• compatibility test และ rollback
• วันหมดอายุการ defer, วัน reassess และ approver
• เวลาและเนื้อหาที่แจ้ง owner

ใน FAT ให้ใช้ vulnerability ticket จำลอง เพื่อตรวจว่าใครเทียบ inventory ใครตัดสินใจ และเก็บหลักฐานใด ใน SAT ให้ตรวจ compensating control และ expiry ในสภาพจริง

7. วัด backup ด้วยความสามารถในการ restore

folder โปรแกรม PLC ไม่ช่วยกู้คืนหากขาด engineering software, licence, library, firmware, communication setting และ recipe Golden copy ควรมี:

• project และ deployed version ของ PLC/HMI/robot/vision/SCADA
• engineering software/version และวิธีกู้ licence
• network, user, time sync และ certificate setting
• recipe, calibration และ parameter ที่เกี่ยวกับ safety
• configuration hash, วันอนุมัติ, approver และ change number
• restore sequence, dependency และ functional verification

ให้ restore จากสภาพว่างใน isolated environment, spare device หรือ virtual environment โดยไม่เสี่ยง production ตรวจ startup, communication, I/O หรือ simulation, recipe และ login หน้าจอ “backup job succeeded” ไม่เท่ากับ recovery และ recovery time เป็นค่าที่ตกลงตาม process/safety ไม่ใช่ค่ากฎหมายเดียวสำหรับทุกโรงงาน

8. Checklist รับมอบ cybersecurity ใน FAT/SAT

FAT ตรวจ design/function ในสภาพแวดล้อม SIer/OEM ส่วน SAT ตรวจซ้ำเรื่องที่ขึ้นกับ network และขั้นตอนจริงของโรงงาน

กำหนด pass, conditional pass และ fail

checkbox ไม่ใช่เกณฑ์ตัดสิน ข้อบกพร่องที่กระทบ safe shutdown, external connection ที่ไม่ได้อนุมัติ, shared administrator ที่ไม่ควบคุม หรือ restore ไม่ได้ อาจเป็น major nonconformity และเป็น gate ก่อน shipment/startup ส่วนเอกสารผิดเล็กน้อยอาจ conditional pass พร้อม deadline ต้องกำหนด classification, correction time, retest scope และผู้อนุมัติก่อน award

อย่าเปิดเผย secret มากเกินไปในหลักฐาน

กำหนดการ mask password, private key และ personal data ใน screenshot เก็บ configuration ในที่ปลอดภัยและอ้างอิงจาก acceptance record ใช้ hash และ version ช่วยตรวจ integrity ได้ แต่ hash ตรงเพียงอย่างเดียวไม่ได้พิสูจน์ว่า configuration เหมาะสม

9. ตัวอย่างแผน 90 วันหลัง startup

นี่เป็นตัวอย่าง implementation ไม่ใช่ statutory deadline หรือ SLA สากล หาก startup วันที่ 1 ตุลาคม 2026:

ตัวอย่างนี้กำหนดให้วันที่ 1 ตุลาคม 2026 เป็น Day 1 ดังนั้น Day 90 คือวันที่ 29 ธันวาคม อย่าแปลเป็น “สามเดือน” โดยไม่กำหนด และให้สัญญาระบุชัดว่าใช้ Day 1 เป็นฐานและนับเป็น calendar day

10. Red flag ในข้อเสนอ SIer

• อ้าง “IEC 62443 compliant ทั้งหมด” แต่ไม่มี edition, scope, evidence, exclusion
• บอกว่า VPN ทำให้ปลอดภัยแล้ว
• ใช้ OEM shared/admin ID โดยไม่มี exception ที่อนุมัติ
• inventory มีเพียงรุ่นและจำนวน ไม่มี version, IP, support date
• ส่ง backup แต่ปฏิเสธ restore test
• ไม่มี clock start และช่องทางของ vulnerability notice
• ไม่เปิดเผย subcontractor หรือ support location ต่างประเทศ
• log ดูได้เฉพาะ SIer และ export ให้ owner ไม่ได้
• สาธิตเฉพาะ FAT แต่ตัด SAT ออก
• ไม่มีการ disable ID คืน key ส่ง source/configuration เมื่อ exit

red flag หนึ่งข้อไม่จำเป็นต้องตัดสิทธิ์ทันที หากมีข้อจำกัดทางเทคนิค ต้องเขียน risk, time limit, compensating control และ approver ได้

11. Governance ระหว่างใช้งาน

ไม่ควรดูเพียงจำนวน ให้ review account หมดอายุ session ที่ไม่อนุมัติ baseline deviation การตัดสิน vulnerability เกินกำหนด restore test ที่ fail contact ที่ติดต่อไม่ได้ และการเปลี่ยน subcontractor ทุก metric ต้องมี denominator, scope และ exception

เพื่อไม่ให้ availability ขัดกับ security ให้ดูคุณภาพการตัดสิน เช่น compensating control เสร็จตรงเวลา change ที่มี rollback พร้อม และเวลาที่ใช้ reconcile ของจริงกับ register ส่วนการซ้อม response/recovery สามารถใช้ร่วมกับ คู่มือฝึกซ้อม OT cyber incident response สำหรับโรงงานไทย

สรุป: สร้าง evidence chain ตั้งแต่ RFP ถึง exit

ผลลัพธ์สำคัญของ FA SIer cybersecurity คือ chain ที่ trace ได้จาก requirement, design, configuration ไปสู่ test, operation, change และ exit TIS 62443 Part 2(4)-2568 และ IEC 62443-2-4:2023 ช่วยจัดโครงกระบวนการ แต่ต้องแปลงเป็น profile, scope, exception และ acceptance evidence เฉพาะโครงการ Remote access ต้องไม่จบที่ VPN แต่ต้องทดสอบ approval, identity, time, target, record และ emergency termination สำหรับสินค้าสู่ EU ให้พิจารณาบทบาท CRA แยกต่างหาก พร้อมทำสัญญาให้ supplier ส่งข้อมูลที่ช่วย manufacturer ประเมินได้ทันเวลา

หากกำลังจัดทำ RFP ระบบอัตโนมัติ ต่ออายุสัญญา SIer หรือกำหนดหลักฐาน FAT/SAT สำหรับโรงงานในไทย สามารถติดต่อ TOMAS TECHได้ตั้งแต่ขั้น concept เราช่วยจัด deliverable ขอบเขตความรับผิดชอบ และ acceptance test ให้สอดคล้องกับ installed base และข้อจำกัด downtime

FAQ

มีใบรับรอง IEC 62443 แล้วเพียงพอหรือไม่?

ไม่เสมอ ต้องตรวจองค์กร edition และ scope ที่รับรอง แล้วระบุกระบวนการ หลักฐานโครงการ exclusion และ compensating control ในสัญญา หากไม่มีใบรับรองก็ไม่ควรถูกตัดสิทธิ์โดยอัตโนมัติ แต่สามารถประเมินกระบวนการและหลักฐานที่เทียบเท่าได้

ใน RFP ควรระบุ IEC 62443-2-4 หรือ TIS 62443-2-4?

เลือกตามสัญญาไทย requirement ลูกค้า และตลาดปลายทาง แต่ต้องระบุ edition และขอ mapping table อย่าอ้างว่า TIS 2568 เท่ากับ IEC 2023 หากไม่มีหลักฐานทางการ

VPN และ MFA เพียงพอสำหรับ OT remote maintenance หรือไม่?

ไม่พอ ต้องมี named approval, time-bounded access, destination restriction, controlled jump path, least privilege, session record, emergency disable และ post-work expiry พร้อม denial test ใน SAT

FAT และ SAT ต้องทดสอบซ้ำเหมือนกันหรือไม่?

จุดประสงค์ต่างกัน FAT ตรวจ design/function ใน supplier environment ส่วน SAT ตรวจ factory network, identity, time source, operator และ kill switch หลักฐาน static ที่ความเสี่ยงต่ำอาจ reuse ได้ แต่ข้อที่ขึ้นกับ environment ต้องทดสอบซ้ำ

ควรคัดลอก deadline ของ CRA ลงสัญญา SIer โดยตรงหรือไม่?

ไม่ควรทำโดยอัตโนมัติ ต้องพิจารณาก่อนว่าใครเป็น manufacturer และมีบทบาทกฎหมายใด แล้วค่อยย้อนจากความต้องการประเมิน 24/72 ชั่วโมงของ manufacturer มากำหนดเวลาและเนื้อหาที่ supplier ต้องแจ้ง

การรับมอบ backup ขั้นต่ำต้องทดสอบอะไร?

ต้อง restore ใน isolation และตรวจ software, licence, communication, I/O หรือ simulation, recipe และ account ไม่ใช่ตรวจเพียงว่ามีไฟล์ พร้อมบันทึกเวลาและ dependency ที่ยังไม่แก้

ถ้าเครื่องเก่าไม่รองรับ named account หรือ logging ควรทำอย่างไร?

ลงทะเบียน asset เหตุผล risk วันหมดอายุ compensating control และ approver อาจเสริมด้วย jump host ที่ระบุตัวบุคคล กุญแจทางกายภาพที่ควบคุม งานต่อหน้าพยาน และ work order ตามระดับความเสี่ยง

ควรรวมราคาและ security ในคะแนน RFP อย่างไร?

ตั้ง minimum pass สำหรับหัวข้อสำคัญก่อน แล้วจึงประเมิน total cost ข้อเสนอราคาต่ำที่ทิ้ง external access ไร้การควบคุมหรือ restore ไม่ได้ อาจมี lifecycle cost สูงกว่ามาก

แหล่งอ้างอิง

• TISI: TIS 62443 Part 2(4)-2568
• TISI: TIS 62443 Part 2(4)-2561
• IEC 62443-2-4:2023
• European Commission: CRA reporting
• ENISA: Single Reporting Platform
• EU Regulation 2024/2847
• CISA: ICS Recommended Practices
• CISA: Cybersecurity Procurement Language
• CISA: Managing Remote Access
• NIST SP 1800-10
• Siemens at AMB Stuttgart 2026