MO（Mobile Originated）是手機使用者主動回覆到企業指定接收端的訊息，內容由使用者自行輸入，具有不可預測性，可能包含企業原本未預期收到的個人資訊。DLR（Delivery Receipt）是電信網路回傳的投遞狀態或結果，屬於傳送中繼資料，不包含使用者輸入的內容。

兩者性質不同，若套用同一套保存與查詢權限政策，容易造成資料治理失焦。EVERY8D 依訊息方向、用途與系統功能區分資料型態，MO 因內容不可預測，在用途限制、資料最小化與保存期限上需要更明確的政策。企業在設計雙向互動流程時，建議於導入階段即確認 MO 的用途範圍與後續保存方式。

EVERY8D 依訊息方向與用途區分為五類資料：MT（企業由平台送往使用者手機的訊息）、MO（使用者主動回覆的訊息）、OTP／驗證碼（一次性驗證訊息）、DLR（電信網路回傳的投遞狀態），以及傳送中繼資料（時間、狀態、服務識別與必要的路由資訊）。

保存期間依資料類型、服務用途、契約與管理政策設定，不以「無限期保留」作為預設；到期資料依系統政策或管理程序進行刪除或清除，降低歷史資料累積。傳送中繼資料僅保留營運、對帳、客服或稽核所必要的範圍。實際保存期限依服務方案與雙方契約約定。

OTP 的安全不能只依賴簡訊本身。訊息端建議搭配有效期限、驗證次數限制與後端風險控制；內容上應避免將完整密碼、完整金融敏感資訊或不必要的個資直接放入簡訊。

平台端則從三個環節控管：訊息流程、帳號權限與 API 存取安全。OTP 類訊息也應避免不必要的長期保留，降低驗證碼歷史資料累積的風險。

EVERY8D 以角色權限、職責分離與最小權限原則配置存取權，權限依工作職責分配，避免使用共用或過度授權帳號執行日常作業。管理性操作與一般使用者操作區隔，高權限存取採較高強度的驗證策略，包含 MFA 等機制（適用範圍依角色與政策設定）。

架構上，核心資料與系統服務採權限限制與存取邊界，避免一般操作帳號直接接觸底層資料。重要登入、權限異動與管理操作保留必要紀錄，以支援稽核與異常調查；重要帳號與權限定期盤點，確認仍符合現行職責。

客戶端也負有共同責任：應妥善保管管理者帳號、API Key 與介接憑證，避免多人共用；可行時採來源限制、強密碼與定期輪替，並在同仁離職、委外關係結束或系統汰換時立即撤銷不再需要的權限。

偵測：對身分與登入、系統與主機、應用與 API、資料與管理操作、網路與邊界五類活動建立必要的日誌與告警，並依時間、來源、帳號與事件類型進行關聯，找出單一設備看不見的異常。

處置：依嚴重度與可疑程度觸發告警，交由指定角色判讀；針對高風險活動啟動阻擋、隔離、權限處置、調查與紀錄。

恢復：重要系統、設定與資料納入備份與復原管理，採異地或雲端備援，避免備份與正式環境完全依賴同一故障域。復原程序明確區分基礎設施、應用、資料與對外服務的恢復順序，並依服務影響程度決定核心功能與依賴系統的優先序。RTO／RPO 等復原目標依服務方案、風險與契約需求定義，非所有系統採相同數值。

可要求的項目包含四類：

資安問卷——依合理範圍回覆企業供應商資安評估、個資或委外管理問卷。架構與控制說明——提供資安白皮書、資料流與必要的控制機制說明，協助資訊／資安單位判讀。資料治理說明——依服務類型說明資料欄位、用途、保存、查詢與刪除等原則。測試與佐證——涉及弱點掃描、第三方檢視或其他報告時，依保密義務、適用範圍與版本提供必要資訊。

安全與資料處理責任以正式合約、SLA、個資約定及雙方確認的服務範圍為準。若貴公司要求特定認證、特定控制框架或產業規範，建議在採購／導入階段共同確認適用範圍。