ส่วนที่ยากที่สุดของเหตุการณ์ด้านความปลอดภัยมักเกิดขึ้นหลังจากเหตุการณ์จบลงแล้ว : เมื่อธุรกิจต้องอธิบายว่าเกิดอะไรขึ้น ค้นพบเมื่อใด ข้อมูลใดเกี่ยวข้อง ใครได้รับผลกระทบ และเหตุใดจึงมีการตัดสินใจบางอย่าง
สำหรับ SMB หลายแห่ง บันทึกเหล่านี้ไม่ได้มีอยู่ในรูปแบบที่สมบูรณ์ รายละเอียดอาจกระจัดกระจายอยู่ในข้อความแชท กล่องขาเข้า ทิกเก็ตฝ่ายสนับสนุน ภาพหน้าจอ และความทรงจำของสมาชิกในทีม ธุรกิจยังดำเนินต่อไปได้ระหว่างเกิดเหตุการณ์ด้วยบันทึกที่ปะติดปะต่อเหล่านี้ แต่จะกลายเป็นปัญหาเมื่อหน่วยงานกำกับดูแล บริษัทประกัน ลูกค้า หรือกรรมการบริษัทขอไทม์ไลน์ที่ชัดเจน
ธุรกิจทุกขนาดจำเป็นต้องมีบันทึกเหตุการณ์ด้านความปลอดภัยที่ละเอียดครบถ้วน ควรเป็นแหล่งข้อมูลอ้างอิงเดียวที่เชื่อถือได้สำหรับบันทึกว่าเกิดอะไรขึ้น เหตุการณ์ได้รับการจัดการอย่างไร และมีหลักฐานใดสนับสนุนการตัดสินใจที่เกิดขึ้นตลอดกระบวนการ
บันทึกนี้มีคุณค่าแม้ในยามที่คุณไม่จำเป็นต้องรายงานเหตุการณ์ บทความนี้จะอธิบายว่าทำไมบันทึกเหตุการณ์ด้านความปลอดภัยจึงมีประโยชน์ต่อธุรกิจของคุณ และวิธีสร้างบันทึกของคุณเอง
เหตุใดบันทึกเหตุการณ์ด้านความปลอดภัยจึงสำคัญ
บันทึกเหตุการณ์เทียบกับแผนตอบสนองเหตุการณ์
บันทึกเหตุการณ์ด้านความปลอดภัยควรมีอะไรบ้าง
เทมเพลตบันทึกเหตุการณ์อย่างง่ายสำหรับ SMB
วิธีบันทึกการตัดสินใจเกี่ยวกับการแจ้งเตือน
สิ่งที่หน่วยงานกำกับดูแลคาดหวังจากบันทึกเหตุการณ์ด้านความปลอดภัย
บันทึกการเข้าถึงข้อมูลยืนยันตัวตน
เหตุใดบันทึกเหตุการณ์ด้านความปลอดภัยจึงสำคัญ
บันทึกเหตุการณ์ด้านความปลอดภัยสร้างความรับผิดชอบในช่วงเวลาที่ธุรกิจมีแนวโน้มจะหลงลืมรายละเอียดมากที่สุด ระหว่างเกิดเหตุการณ์ การดำเนินการต่าง ๆ เกิดขึ้นอย่างรวดเร็ว : รหัสผ่านถูกรีเซ็ต บัญชีถูกปิดใช้งาน ผู้ให้บริการไอทีถูกติดต่อ ข้อมูลลูกค้าถูกตรวจสอบ และผู้บริหารได้รับข้อมูลสรุป ขั้นตอนเหล่านี้อาจเป็นสิ่งที่ธุรกิจต้องการในขณะนั้น แต่จะอธิบายได้ยากขึ้นมากในภายหลัง หากไม่มีใครบันทึกว่าแต่ละการดำเนินการเกิดขึ้นเมื่อใด ใครอนุมัติ และมีหลักฐานใดสนับสนุนการตัดสินใจ
สำหรับธุรกิจที่ตั้งอยู่ในยุโรป นี่ไม่ใช่แค่แนวปฏิบัติที่ดี ภายใต้กฎระเบียบการคุ้มครองข้อมูลทั่วไป (GDPR) ทั้งในสหราชอาณาจักรและสหภาพยุโรป การละเมิดข้อมูลส่วนบุคคลจำเป็นต้องได้รับการประเมิน และบางกรณีต้องรายงานต่อหน่วยงานกำกับดูแลที่เกี่ยวข้อง
ในสหราชอาณาจักร คำแนะนำ รายงานการละเมิด(หน้าต่างใหม่) ของ ICO อธิบายว่าองค์กรต้องประเมินความเสี่ยงที่อาจเกิดขึ้นต่อสิทธิและเสรีภาพของผู้คน และแจ้ง ICO เมื่อความเสี่ยงนั้นมีแนวโน้มว่าจะเกิดขึ้น มาตรา 33 ยังกำหนดให้ผู้ควบคุมข้อมูลต้องบันทึกการละเมิดข้อมูลส่วนบุคคล รวมถึงข้อเท็จจริงของการละเมิด ผลกระทบ และมาตรการแก้ไขที่ดำเนินการ ข้อกำหนดเดียวกันนี้ใช้บังคับภายใต้ GDPR ของสหภาพยุโรป
ตัวอย่างเช่น ICO ไม่ได้คาดหวังว่า SMB ทุกแห่งจะมีระบบระดับองค์กร แต่คาดหวังให้มีบันทึกที่เหมาะสม กรอบการตอบสนองและติดตามการละเมิดข้อมูลของ ICO ระบุว่าองค์กรควรมีขั้นตอนเพื่อให้แน่ใจว่าเหตุการณ์และการละเมิดข้อมูลส่วนบุคคลถูกตรวจพบ จัดการ และบันทึกอย่างเหมาะสม นั่นหมายความว่าไม่ควรสร้างบันทึกเหตุการณ์เฉพาะเมื่อเกิดการละเมิดร้ายแรงขึ้นแล้วเท่านั้น แต่ควรเป็นส่วนหนึ่งของกระบวนการตอบสนองตามปกติ
บันทึกที่ดียังช่วยสนับสนุนการเรียกร้องค่าสินไหมทดแทนด้วย บริษัทประกันไซเบอร์อาจขอหลักฐานว่าเหตุการณ์ถูกค้นพบเมื่อใด มีการดำเนินการควบคุมความเสียหายขั้นใด บัญชีใดได้รับผลกระทบ และธุรกิจปฏิบัติตามกระบวนการตอบสนองเหตุการณ์หรือไม่ บันทึกที่จัดเก็บอย่างดีสามารถแสดงให้เห็นว่าธุรกิจดำเนินการอย่างรวดเร็วและสม่ำเสมอ
ยังช่วยให้บริษัทเรียนรู้ด้วย ความทรงจำและบันทึกด้วยวาจาไม่น่าเชื่อถือ แต่บันทึกที่แสดงว่าเหตุการณ์เริ่มจากรหัสผ่านที่ใช้ซ้ำ การไม่มี การยืนยันตัวตนหลายปัจจัย (MFA) การเข้าถึงของผู้ขาย หรือการปิดบัญชีผู้ใช้ออกจากระบบที่ล่าช้า ช่วยให้ธุรกิจมีสิ่งที่ต้องแก้ไขอย่างเป็นรูปธรรมและมีทิศทางที่ชัดเจนขึ้นในการเสริมสร้างความปลอดภัยในระยะยาว
บันทึกเหตุการณ์กับแผนตอบสนองเหตุการณ์
บันทึกเหตุการณ์ด้านความปลอดภัยและแผนตอบสนองเหตุการณ์เชื่อมโยงกัน แต่ไม่ใช่เอกสารเดียวกัน
แผนตอบสนองเหตุการณ์อธิบายว่าธุรกิจควรทำอะไรเมื่อเกิดปัญหา โดยกำหนดบทบาท ช่องทางส่งต่อ ขั้นตอนควบคุมความเสียหาย ความรับผิดชอบด้านการสื่อสาร และกระบวนการกู้คืน บันทึกเหตุการณ์จะบันทึกว่าเกิดอะไรขึ้นจริง เป็นไทม์ไลน์ เส้นทางหลักฐาน บันทึกการตัดสินใจ และไฟล์ติดตามผลสำหรับเหตุการณ์เฉพาะ
ความแตกต่างนี้สำคัญ เพราะแม้แผนที่ดีก็ล้มเหลวได้หากไม่มีเอกสารประกอบ ธุรกิจอาจทำตามขั้นตอนที่ถูกต้อง แต่ภายหลังยังคงพิสูจน์ได้ยาก บันทึกควรทำให้สามารถตอบคำถามเชิงปฏิบัติได้ว่า รู้เรื่องเมื่อใด ใครลงมือทำ อะไรถูกควบคุมไว้ ข้อมูลใดเสี่ยง ตัดสินใจอะไร และอะไรเปลี่ยนไปหลังจากนั้น
| แผนตอบสนองเหตุการณ์ : สิ่งที่ธุรกิจของคุณควรทำ | บันทึกเหตุการณ์ด้านความปลอดภัย : สิ่งที่เกิดขึ้นจริง |
| ใครเป็นผู้นำการตอบสนอง ใครติดต่อไอที ฝ่ายกฎหมาย บริษัทประกัน หรือหน่วยงานกำกับดูแล วิธีควบคุมความเสียหาย กู้คืน และสื่อสาร | เหตุการณ์ถูกค้นพบเมื่อใด ระบบและข้อมูลใดได้รับผลกระทบ มีการดำเนินการอะไร โดยใคร และเมื่อใด |
บันทึกเหตุการณ์ด้านความปลอดภัยควรมีอะไรบ้าง
บันทึกเหตุการณ์ที่มีประโยชน์ต้องมีความสม่ำเสมอเพียงพอให้ธุรกิจสามารถย้อนรอยเหตุการณ์ในภายหลังและอธิบายการตัดสินใจที่เกิดขึ้นระหว่างการตอบสนองได้
วันที่และเวลาที่ค้นพบ
บันทึกว่าธุรกิจเริ่มทราบเรื่องเหตุการณ์เมื่อใด ใครเป็นผู้สังเกตเห็น และค้นพบได้อย่างไร หากเวลาเป็นเพียงการประมาณ ให้ทำเครื่องหมายว่าเป็นเวลาประมาณ เวลาที่ค้นพบมีความสำคัญ เพราะกำหนดเวลาการรายงานตาม GDPR และข้อกำหนดของบริษัทประกันมักขึ้นอยู่กับว่าธุรกิจทราบปัญหาเมื่อใด
ลักษณะของเหตุการณ์
อธิบายสิ่งที่เกิดขึ้นด้วยภาษาที่เข้าใจง่าย หลีกเลี่ยงป้ายกำกับที่คลุมเครือ เช่น “ปัญหาด้านความปลอดภัย” หรือ “อาจมีการละเมิดข้อมูล” โดยไม่มีบริบท บันทึกควรอธิบายว่าระบบใดได้รับผลกระทบ และเหตุการณ์เกี่ยวข้องกับข้อมูลยืนยันตัวตน อีเมล ไฟล์ ข้อมูลลูกค้า ระบบชำระเงิน เอนด์พอยต์ หรือการเข้าถึงของบุคคลที่สามหรือไม่
ข้อมูลที่เกี่ยวข้อง
หากข้อมูลส่วนบุคคลอาจได้รับผลกระทบ ให้บันทึกว่าข้อมูลประเภทใดเกี่ยวข้อง : ชื่อ ที่อยู่อีเมล หมายเลขโทรศัพท์ ที่อยู่ รายละเอียดบัญชี ข้อมูลทางการเงิน บันทึกพนักงาน การสื่อสารกับลูกค้า ข้อมูลยืนยันตัวตนสำหรับเข้าสู่ระบบ หรือหมวดหมู่ที่เกี่ยวข้องอื่น ๆ ประเมินว่ามีบุคคลจำนวนเท่าใดที่อาจได้รับผลกระทบ และระบุให้ชัดเจนว่าจำนวนนั้นได้รับการยืนยันแล้วหรือยังอยู่ระหว่างการสอบสวน
สาเหตุที่เป็นไปได้
บันทึกสาเหตุที่ทราบหรือสงสัยไว้ แม้การสอบสวนยังดำเนินอยู่ เมื่อมีรายละเอียดใหม่ ๆ บันทึกสามารถอัปเดตจาก “ไม่ทราบสาเหตุ” เป็น “อีเมลฟิชชิ่งนำไปสู่การโจมตีข้อมูลยืนยันตัวตน” หรือ “บัญชีผู้รับเหมาเดิมยังคงใช้งานอยู่” บันทึกควรแสดงให้เห็นว่าความเข้าใจของธุรกิจเปลี่ยนแปลงไปอย่างไรเมื่อเวลาผ่านไป
การดำเนินการควบคุมความเสียหายทันที
บันทึกสิ่งที่ดำเนินการเพื่อจำกัดความเสียหาย ซึ่งอาจรวมถึงการรีเซ็ตรหัสผ่าน การเพิกถอนเซสชัน การบังคับใช้ MFA การระงับบัญชี การลบกฎในกล่องจดหมาย การแยกอุปกรณ์ออกจากระบบ การลบการเข้าถึงของผู้ขาย การเปลี่ยนแปลงไฟร์วอลล์ หรือการปิดบริการชั่วคราว เท่าที่ทำได้ ให้ระบุผู้รับผิดชอบและประทับเวลาสำหรับแต่ละการดำเนินการ
การตัดสินใจเกี่ยวกับการแจ้งเตือน
บันทึกว่าธุรกิจได้แจ้งหน่วยงานกำกับดูแลที่เกี่ยวข้อง (ICO ในสหราชอาณาจักร หรือหน่วยงานคุ้มครองข้อมูลส่วนบุคคลระดับชาติในสหภาพยุโรป) บุคคลที่ได้รับผลกระทบ ลูกค้า ซัพพลายเออร์ บริษัทประกัน ที่ปรึกษากฎหมาย หรือหน่วยงานบังคับใช้กฎหมายหรือไม่ หากตัดสินใจไม่แจ้ง ให้บันทึกเหตุผล คำอธิบายนั้นมักสำคัญพอ ๆ กับการแจ้งเตือนเอง
ขั้นตอนการแก้ไขและไทม์ไลน์
การควบคุมความเสียหายจัดการกับเหตุการณ์เฉพาะหน้า การแก้ไขช่วยลดโอกาสที่ปัญหาเดิมจะเกิดขึ้นซ้ำ บันทึกการดำเนินการติดตามผล เช่น การบังคับใช้ MFA การลบข้อมูลยืนยันตัวตนที่ใช้ร่วมกัน การอัปเดตนโยบายการเข้าถึง การปรับปรุงกระบวนการนำผู้ใช้ออกจากระบบ การแก้ไขการกำหนดค่าที่ผิดพลาด หรือการเปลี่ยนวิธีปกป้องข้อมูลสำรอง
บทเรียนที่ได้รับ
ปิดท้ายด้วยสิ่งที่ธุรกิจได้เรียนรู้และสิ่งที่จะเปลี่ยนแปลง ไม่ควรเขียนในเชิงตำหนิ แต่ควรระบุจุดอ่อน การปรับปรุงที่จำเป็น และผู้รับผิดชอบการติดตามผล
เทมเพลตบันทึกเหตุการณ์อย่างง่ายสำหรับ SMB
ไม่จำเป็นต้องใช้ซอฟต์แวร์เฉพาะทางในการบันทึกเหตุการณ์ ตารางคำนวณ แบบฟอร์มภายในที่ปลอดภัย ระบบทิกเก็ต หรือทะเบียนที่แชร์ร่วมกันสามารถใช้ได้ หากควบคุมการเข้าถึงและรักษารายการให้สม่ำเสมอ
บันทึกเหตุการณ์ที่มีประสิทธิผลควรมีช่องข้อมูลต่อไปนี้ :
- รหัสเหตุการณ์ : หมายเลขอ้างอิงที่ไม่ซ้ำกัน
- วันที่และเวลาที่ค้นพบ : เวลาที่ธุรกิจเริ่มทราบเรื่องเหตุการณ์
- รายงานโดย : พนักงาน ผู้ให้บริการ ลูกค้า ผู้ขาย การแจ้งเตือนจากการตรวจสอบ หรือบุคคลภายนอก
- ประเภทเหตุการณ์ : ฟิชชิ่ง มัลแวร์ การโจมตีข้อมูลยืนยันตัวตน ข้อมูลสูญหาย การเข้าถึงโดยไม่ได้รับอนุญาต แรนซัมแวร์ เหตุการณ์จากซัพพลายเออร์ อุปกรณ์สูญหาย อีเมลส่งผิดพลาด หรืออื่น ๆ
- สรุป : เกิดอะไรขึ้น เขียนด้วยภาษาที่เข้าใจง่าย
- ระบบที่ได้รับผลกระทบ : แอปพลิเคชั่น บัญชี อุปกรณ์ ฐานข้อมูล กล่องขาเข้า หรือบริการของบุคคลที่สามที่เกี่ยวข้อง
- ข้อมูลที่เกี่ยวข้อง : ข้อมูลส่วนบุคคลได้รับผลกระทบหรือไม่ เป็นข้อมูลประเภทใด และอาจมีผู้ได้รับผลกระทบจำนวนเท่าใด
- สาเหตุที่เป็นไปได้ : ทราบแล้ว สงสัย หรืออยู่ระหว่างการสอบสวน
- มาตรการควบคุม : สิ่งที่ดำเนินการทันที
- การตัดสินใจแจ้งเตือน : หน่วยงานกำกับดูแล บุคคล ลูกค้า บริษัทประกัน หรือไม่แจ้งเตือนพร้อมเหตุผล
- ลิงก์หลักฐาน : ภาพหน้าจอ ตั๋วสนับสนุน บันทึก อีเมล บันทึกการเข้าถึง ไฟล์ส่งออก หรือรายงานจากผู้ให้บริการ
- มาตรการแก้ไข : ขั้นตอนที่ดำเนินการหลังการควบคุมสถานการณ์
- ผู้รับผิดชอบ : บุคคลที่รับผิดชอบการติดตามผล
- สถานะ : เปิด การตรวจสอบ ควบคุมได้แล้ว แก้ไขแล้ว ปิด
- บทเรียนที่ได้รับ : สิ่งที่ควรเปลี่ยนแปลง
วิธีบันทึกการตัดสินใจแจ้งเตือน
การตัดสินใจเกี่ยวกับการแจ้งเตือนควรมีพื้นที่ของตัวเองในบันทึกเหตุการณ์ด้านความปลอดภัย เนื่องจากมักได้รับการทบทวนหลังเกิดเหตุการณ์
ภายใต้ GDPR ของสหราชอาณาจักรและสหภาพยุโรป องค์กรต้องประเมินความเสี่ยงที่อาจเกิดขึ้นต่อสิทธิและเสรีภาพของผู้คนเมื่อเกิดการละเมิดข้อมูลส่วนบุคคล หากมีความเสี่ยงที่อาจเกิดขึ้น ต้องแจ้งหน่วยงานกำกับดูแลโดยเร็วที่สุด และภายใน 72 ชั่วโมงหากเป็นไปได้ โดยในสหราชอาณาจักรคือ ICO(หน้าต่างใหม่) และในแต่ละประเทศสมาชิกสหภาพยุโรปคือหน่วยงานคุ้มครองข้อมูลส่วนบุคคลของประเทศนั้น หากความเสี่ยงอยู่ในระดับสูง ต้องแจ้งบุคคลที่ได้รับผลกระทบโดยไม่ล่าช้าโดยไม่มีเหตุอันควร เกณฑ์และกรอบเวลาของทั้งสองฝ่ายเหมือนกัน ต่างกันเพียงหน่วยงานที่ต้องแจ้ง
บันทึกเหตุการณ์ที่ดีควรแสดงว่าธุรกิจได้ทำการประเมินนี้ ควรบันทึกว่ามีข้อมูลส่วนบุคคลเกี่ยวข้องหรือไม่ อาจเกิดความเสียหายประเภทใด มีมาตรการป้องกันอะไรอยู่ และเหตุใดธุรกิจจึงตัดสินใจรายงานหรือไม่รายงาน
ตัวอย่างเช่น เหตุการณ์ที่เกี่ยวข้องกับรหัสผ่านผู้ดูแลระบบที่ถูกเปิดเผยอาจไม่แสดงให้เห็นทันทีว่ามีการเข้าถึงข้อมูลส่วนบุคคลหรือไม่ บันทึกควรสะท้อนความไม่แน่นอนนั้น โดยบันทึกข้อกังวลเริ่มต้น ขั้นตอนการสอบสวน การตรวจสอบกิจกรรมในบัญชี และข้อสรุปสุดท้ายเมื่อมีหลักฐาน
ในขั้นตอนนี้ของกระบวนการ ธุรกิจจำนวนมากมุ่งเน้นการจัดการแก้ไขทางเทคนิคและลืมบันทึกเหตุผลด้านการปฏิบัติตามข้อกำหนด มีการรีเซ็ตรหัสผ่าน ปกป้องบัญชี และดำเนินงานต่อ หลายสัปดาห์ต่อมา ธุรกิจไม่สามารถอธิบายได้ว่าทำไมจึงตัดสินใจว่าเหตุการณ์นี้ไม่ต้องรายงาน
สิ่งที่หน่วยงานกำกับดูแลคาดหวังจากบันทึก
หน่วยงานกำกับดูแลไม่ได้ดูเพียงว่าได้รายงานการละเมิดข้อมูลหรือไม่ แต่ยังอาจถามด้วยว่าธุรกิจ :
- ระบุเหตุการณ์
- ประเมินความเสี่ยง
- ตัดสินใจว่าจำเป็นต้องแจ้งเตือนหรือไม่
- บันทึกการดำเนินการที่ได้ทำ
บันทึกที่ดีควรทำให้เรื่องราวของเหตุการณ์ชัดเจนตั้งแต่ต้นจนจบ ควรแสดงว่าเกิดอะไรขึ้น มีข้อมูลส่วนบุคคลใดเกี่ยวข้อง อาจเกิดความเสียหายอะไร ธุรกิจทำอะไรเพื่อควบคุมปัญหา และเหตุใดจึงรายงานหรือไม่รายงานการละเมิดข้อมูล
ระดับรายละเอียดควรสอดคล้องกับความรุนแรงของเหตุการณ์ อีเมลที่ส่งผิดพลาดไม่จำเป็นต้องมีบันทึกเหมือนกับเหตุการณ์โจมตีด้วยแรนซัมแวร์ แต่ยังคงต้องบันทึกไว้เพื่อแสดงว่าธุรกิจได้ประเมินอย่างเหมาะสม
บันทึกเหล่านี้ควรถูกจัดเก็บอย่างปลอดภัยด้วย บันทึกเหตุการณ์อาจมีรายละเอียดที่ละเอียดอ่อนเกี่ยวกับบุคคลที่ได้รับผลกระทบ ระบบที่ถูกเปิดเผย การกระทำของพนักงาน ภาพหน้าจอ บันทึกการเข้าถึง หรือขั้นตอนการแก้ไข การเข้าถึงควรจำกัดเฉพาะผู้ที่จำเป็นต้องใช้ และการเก็บรักษาควรสอดคล้องกับนโยบายการเก็บรักษาข้อมูลโดยรวมของบริษัท
บันทึกการเข้าถึงข้อมูลยืนยันตัวตน
เหตุการณ์หลายอย่างเกี่ยวข้องกับข้อมูลยืนยันตัวตน : โดยอาจเกิดจากรหัสผ่านที่ใช้ซ้ำ บัญชีที่แชร์ กล่องขาเข้าที่ถูกโจมตี การเข้าสู่ระบบของผู้ดูแลระบบที่ถูกเปิดเผย การแจ้งเตือน MFA ที่น่าสงสัย หรือพนักงานที่ไม่ได้ถูก ปลดออกจากระบบ อย่างเหมาะสม
ด้วยเหตุนี้ บันทึกการเข้าถึงข้อมูลยืนยันตัวตนจึงกลายเป็นข้อมูลนำเข้าโดยตรงสำหรับเอกสารเหตุการณ์ด้านความปลอดภัยไซเบอร์ เมื่อเหตุการณ์เกี่ยวข้องกับการเข้าสู่ระบบที่แชร์หรือบัญชีที่ละเอียดอ่อน ธุรกิจจำเป็นต้องรู้ว่าใครมีการเข้าถึง มีการแชร์การเข้าถึงอย่างไร สิทธิ์เปลี่ยนแปลงหรือไม่ และข้อมูลยืนยันตัวตนถูกหมุนเวียนเปลี่ยนใหม่หลังเหตุการณ์หรือไม่
โปรแกรมจัดการรหัสผ่านสำหรับธุรกิจ อย่าง Proton Pass for Business ช่วยให้ทีมจัดการข้อมูลยืนยันตัวตนในห้องนิรภัยที่เข้ารหัส สร้างรหัสผ่านที่ไม่ซ้ำกัน ใช้การป้อนอัตโนมัติ แชร์ข้อมูลยืนยันตัวตนอย่างปลอดภัย จัดการพาสคีย์ และใช้การยืนยันตัวตนผ่านสองขั้นตอนที่มีในตัว สำหรับเอกสารเหตุการณ์ คุณค่าที่สำคัญที่สุดคือร่องรอยการเข้าถึงที่เกี่ยวข้องกับข้อมูลยืนยันตัวตน : ใครมีการเข้าถึงห้องนิรภัย/บัญชีที่แชร์ การเข้าถึงได้รับการจัดการอย่างไรและใครใช้งาน และอะไรเปลี่ยนแปลงไปหลังเหตุการณ์
โปรแกรมจัดการรหัสผ่านสำหรับทีมไอที เพิ่มคุณสมบัติสำหรับผู้ดูแลระบบ เช่น นโยบาย การรายงาน บันทึก การควบคุมการเข้าถึงตามบทบาท การจัดเตรียมผู้ใช้ผ่าน SCIM และการผสานรวม SSO คุณสมบัติเหล่านี้ช่วยให้ธุรกิจแสดงให้เห็นว่าการเข้าถึงข้อมูลยืนยันตัวตนได้รับการควบคุมอย่างไร และให้หลักฐานเมื่อเกิดการสอบสวนเหตุการณ์ที่เกี่ยวข้องกับข้อมูลยืนยันตัวตน
โปรแกรมจัดการรหัสผ่านไม่สามารถแทนที่บันทึกเหตุการณ์ การประเมินทางกฎหมาย กระบวนการแจ้งเตือนตามกฎระเบียบ หรือแผนตอบสนองเหตุการณ์ได้ แต่โปรแกรมให้หลักฐานด้านข้อมูลยืนยันตัวตนที่สามารถนำไปใช้ในกระบวนการเหล่านี้ได้
เก็บร่องรอยการตรวจสอบที่ครบถ้วนของการเข้าถึงข้อมูลยืนยันตัวตนด้วย โปรแกรมจัดการรหัสผ่านสำหรับธุรกิจ
