PlusMagi's Blog By Pitt Phunsanit Technology Soft Delete กับมาตรฐาน ISO — ทำไมระบบระดับองค์กรถึงห้ามกดลบแล้วหายไปเลย?

Soft Delete กับมาตรฐาน ISO — ทำไมระบบระดับองค์กรถึงห้ามกดลบแล้วหายไปเลย?

ในการพัฒนาระบบซอฟต์แวร์ หลายคนมักเคยได้ยินคำสั่งจาก System Analyst หรือทีม Compliance ว่า “ระบบนี้ต้องเป็นไปตามมาตรฐาน ISO ห้ามทำ Hard Delete เด็ดขาด ให้ทำเป็น Soft Delete เท่านั้น”

คำถามที่ตามมาคือ ในตัวบทมาตรฐาน ISO มีข้อกำหนดที่เขียนคำว่า “Soft Delete” ไว้ตรงๆ หรือไม่? แล้วมาตรฐาน ISO ตัวไหนที่บังคับเรื่องนี้? บทความนี้จะพาไปเจาะลึกความเชื่อมโยงระหว่างการออกแบบฐานข้อมูลกับข้อกำหนดมาตรฐานสากล


ในมาตรฐาน ISO มีคำว่า “Soft Delete” จริงหรือไม่?

ไม่มีคำนี้ระบุอยู่ในตัวบทมาตรฐานแม้แต่บรรทัดเดียว

มาตรฐาน ISO เป็นข้อกำหนดเชิงหลักการและการจัดการ (Management & Governance Standards) ไม่ใช่คู่มือการเขียนโค้ด จึงไม่เคยระบุเทคนิคการลงโปรแกรม เช่น is_deleted = true หรือ deleted_at

ทว่า สิ่งที่ ISO ระบุไว้อย่างเข้มงวดคือ Data Integrity (ความครบถ้วนสมบูรณ์ของข้อมูล), Audit Trail (ร่องรอยการตรวจสอบ), และ Protection of Records (การปกป้องเอกสารหลักฐาน) ซึ่งคุณสมบัติเหล่านี้ในเชิงสถาปัตยกรรมระบบ (System Architecture) แทบจะเป็นไปไม่ได้เลยหากอนุญาตให้คำสั่ง DELETE FROM ... ทำงานโดยไม่มีการเก็บประวัติ


มาตรฐาน ISO ฉบับใดบ้างที่ผลักดันให้ต้องใช้ Soft Delete?


ISO/IEC 27001 (Information Security Management System)

เวอร์ชัน ISO/IEC 27001:2022 มี Control สำคัญที่เกี่ยวข้องกับการลบข้อมูลโดยตรง

  • Control A.5.33 (Protection of Records)
    บันทึกธุรกรรมและประวัติการทำงานต้องได้รับการปกป้องจากการสูญหาย การปลอมแปลง และการทำลายก่อนครบกำหนดเวลาจัดเก็บ (Retention Period)
  • Control A.8.15 (Logging)
    บันทึกเหตุการณ์ของผู้ใช้งานและข้อผิดพลาดเพื่อนำไปใช้ตรวจสอบย้อนหลัง หากพนักงานกดลบใบสั่งซื้อแล้วข้อมูลแถวนั้นหายไปจากตารางทันที Log ที่อ้างอิงถึง Foreign Key นั้นจะกลายเป็นกำพร้า (Orphan Reference) หรือสูญเสียบริบททางธุรกิจ

ISO 15489-1 (Information and Documentation — Records Management)

มาตรฐานสากลด้านการบริหารจัดการเอกสารและบันทึกหลักฐานขององค์กรโดยเฉพาะ ระบุว่าบันทึกหลักฐานที่ดีต้องมี 4 เสาหลัก

  • Authenticity
    พิสูจน์ได้ว่าเป็นข้อมูลจริง
  • Integrity
    ข้อมูลครบถ้วน ไม่ถูกดัดแปลงหรือลบทำลายโดยพลการ
  • Reliability
    เชื่อถือได้ในฐานะหลักฐาน
  • Usability
    สามารถค้นหาและนำกลับมาใช้งานได้

การทำ Soft Delete คือหัวใจสำคัญที่ทำให้ระบบยังคงสืบค้นสถานะเดิมของเอกสารได้ แม้ว่าในมุมมองหน้าบ้าน (UI) ผู้ใช้จะ “สั่งลบ” ไปแล้วก็ตาม


ISO 9001 (Quality Management System)

  • Clause 7.5.3 (Control of Documented Information)
    กำหนดให้องค์กรต้องมีการควบคุมข้อมูลเอกสารเพื่อป้องกันการสูญหายโดยไม่ตั้งใจ และสามารถทวนสอบกระบวนการทำงานย้อนหลังได้เมื่อเกิดข้อผิดพลาดในการบริการหรือการผลิต

ทำไม Hard Delete ถึงสร้างปัญหาให้กับงาน Audit?

มิติการเปรียบเทียบHard Delete (DELETE FROM)Soft Delete (is_deleted / Status Flag)
ความต่อเนื่องของข้อมูล (Referential Integrity)Foreign Key พัง หรือต้องตั้ง ON DELETE CASCADE จนลบข้อมูลที่เกี่ยวข้องกันลามไปหมดForeign Key คงเดิม เชื่อมโยงประวัติย้อนหลังได้ครบ
การตรวจสอบย้อนหลัง (Auditability)ไม่รู้ว่าก่อนถูกลบ ข้อมูลมีค่าอะไรบ้าง และใครเป็นผู้ลบ (ถ้าไม่มี Audit Log แยก)รู้ทันทีว่าใครเป็นคนปิดสถานะ ลบเมื่อไหร่ และข้อมูลเดิมคืออะไร
การกู้คืนข้อมูล (Recovery)ต้องกู้จาก Backup Database ซึ่งกระทบเวลาและ Downtimeอัปเดตสถานะกลับมาเป็น Active ได้ทันที
ผลกระทบต่อรายงาน (BI / Historical Reporting)ตัวเลขรายงานบัญชีย้อนหลังเพี้ยนทันที เพราะ Record หายไปรายงานในอดีตยังถูกต้อง โดยกรองเงื่อนไขตามช่วงเวลาได้

ข้อควรระวัง: Soft Delete ขัดแย้งกับกฎหมายความเป็นส่วนตัวหรือไม่?

การเก็บข้อมูลไว้ตลอดไปด้วย Soft Delete อาจสร้างปัญหากับข้อกำหนดเรื่อง Right to Erasure (สิทธิในการขอให้ลบข้อมูล) ตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล เช่น GDPR หรือ PDPA รวมถึง ISO/IEC 27001 Control A.8.10 (Information Deletion)

แนวทางปฏิบัติที่ดีในระดับ Enterprise Architecture จึงไม่ใช่การเลือกอย่างใดอย่างหนึ่ง แต่คือการออกแบบสถาปัตยกรรมแบบ Multi-tier Data Lifecycle:

Plain Text

Plain Text

[User Interface]  -- สั่งลบ (Delete) -->  [Application Layer]
                                                   │
                                                   ▼
[Active Storage]  <-- ทำ Soft Delete (Flag is_deleted / deleted_at)
  - ตอบโจทย์: ISO 27001 (A.5.33), ISO 15489, ISO 9001
  - ข้อมูลยังคงอยู่สำหรับ Audit Trail & Referential Integrity
                                                   │
                                     พ้นกำหนด Retention Period 
                                     หรือคำร้อง PDPA/GDPR อนุมัติ
                                                   │
                                                   ▼
[Batch Job / Purge] <-- ทำ Hard Delete / Anonymize / Crypto-shredding
  - ตอบโจทย์: ISO 27001 (A.8.10), PDPA, GDPR
  1. ระดับหน้าบ้าน (Operational Tier)
    ให้ใช้ Soft Delete เพื่อตอบโจทย์ความสมบูรณ์ของระบบ การทวนสอบ และการควบคุมข้อผิดพลาด
  2. ระดับนโยบายการจัดเก็บ (Retention & Disposal Tier)
    มีระบบตั้งเวลา (Purge Scheduler) เมื่อข้อมูลสิ้นสุดระยะเวลาจัดเก็บตามที่กฎหมายกำหนด (เช่น 5 ปี หรือ 10 ปี) ให้รัน Batch Job เพื่อทำ Hard Delete หรือ Anonymization (นิรนามข้อมูล) ออกไปจริง ๆ เพื่อตอบโจทย์ด้าน Data Privacy

บทสรุป

คำกล่าวที่ว่า “ISO บังคับให้ทำ Soft Delete” แม้จะไม่ตรงตามตัวอักษร 100% แต่เป็น ข้อสรุปเชิงเทคนิคที่ถูกต้องที่สุด สำหรับนักพัฒนาระบบ

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


Exit mobile version