TimePlate — SlashHub Limited
Last updated: 2026-10-12 · Version 1.0.0
Parties / precedence. This Schedule forms part of the Master Services Agreement ("MSA") and describes SlashHub's security measures. It prevails over the MSA on security matters. It should be read with the Data Processing Agreement. Language. Drafted in English with a 繁體中文 translation. The English version governs unless a signed contract states otherwise.
This Schedule describes the technical and organisational measures SlashHub uses to protect Customer Data, including the Personal Data of the Customer's employees, processed through TimePlate. It is provided in support of Data Protection Principle 4 of the Personal Data (Privacy) Ordinance (Cap. 486) ("PDPO") and, where the EU/UK GDPR applies, Article 32.
Capitalised terms not defined here have the meaning in the MSA or the DPA. Where a requirement in this Schedule cannot be met, SlashHub will say so in writing rather than paper over it.
2.1 SlashHub maintains a written security programme with an accountable owner, a documented risk assessment, incident-response procedures and an access-review process.
2.2 SlashHub performs security reviews on a scheduled basis and after material changes. [roadmap] A formally audited ISMS (ISO 27001) and an independent SOC 2 Type II report.
3.1 In transit. Data is encrypted in transit using TLS (TLS 1.2 or later, TLS 1.3 preferred).
3.2 At rest. Data is encrypted at rest using AES-256, by the managed data stores we use (database, object storage).
3.3 Field-level encryption. Sensitive identifiers — including the HKID number and bank account
details used for statutory reporting and payroll export — are additionally protected with AES-256-GCM
application-layer encryption and a blind index for lookup, so the plaintext is not stored in a
queryable form. (Implementation: apps/api/src/lib/field-crypto.ts.)
3.4 Photo storage. Employee photos and attendance images are stored in a private object store; they are never public. Access is via short-lived signed URLs (time-limited, e.g. 6 days maximum, with refresh-on-demand), not permanent links.
3.5 Credentials. Passwords are never stored in plaintext. Authentication is delegated to a managed identity provider; session and service tokens are signed and time-limited.
4.1 Least privilege and RBAC. Access to Customer Data is role-based and scoped. Modules and per-record access follow the Customer's configuration; sensitive modules can be restricted.
4.2 Tenant isolation. Each customer's data is logically segregated by tenant, and every request is validated against the authenticated user's tenant, role and scope. Cross-tenant access is denied by default.
4.3 MFA. Multi-factor authentication is available and required for sensitive operations.
4.4 Session and token controls. Administrative changes can be revoked immediately (token-version invalidation). Kiosk/shared-device access is scoped (for example a login-only session can see only the authenticated employee).
4.5 Audit logging. Security-relevant events (authentication failures, permission denials, CSRF rejections, sensitive administrative actions) are written to a restricted audit log with configurable retention.
4.6 Access reviews. Access rights are reviewed on a scheduled basis; access is removed promptly on offboarding.
5.1 SlashHub uses managed cloud providers. Our current provider categories are: cloud hosting and database (Google Firebase / Google Cloud — Firestore, Authentication, Cloud Storage, Cloud Messaging), application hosting (Railway for the backend API), frontend hosting (Vercel), payment processing (Airwallex), error monitoring (Sentry), push notifications (Expo) and AI-model providers. The authoritative, current list is maintained under the DPA (sub-processors) and provided on request.
5.2 Provider certifications. The certifications that exist are held by these providers, not by SlashHub — for example, our hosting providers maintain recognised certifications (such as ISO 27001 and SOC 2 Type II) for their infrastructure. [roadmap] SlashHub's own SOC 2 / ISO 27001.
5.3 SlashHub contractually requires sub-processors to apply data-protection obligations no less protective than the DPA, and remains responsible for their performance as stated in the DPA.
6.1 Secure development lifecycle. Changes are made on branches, reviewed, and pass automated checks before merge. Production changes are not made directly on the main line.
6.2 CI security gates. The build pipeline runs secret scanning and credential detection, dependency audits, and container/dependency vulnerability scanning, and fails on high-severity findings.
6.3 Secrets management. Credentials and service keys are kept out of source control and rotated. A guard blocks the accidental commit or read of secret files; a scanner checks the repository.
6.4 Vulnerability management. Dependencies are monitored and patched; vulnerabilities are triaged by severity. [roadmap] Scheduled third-party penetration testing (not currently performed) and a formal public bug-bounty programme.
6.5 Responsible disclosure. Security issues can be reported to security@slashhub.hk; the API
publishes an RFC 9116 /.well-known/security.txt on the backend host
(apps/api/src/index.ts). SlashHub will not pursue good-faith researchers who follow that policy.
7.1 Roles. The Customer is the data user (PDPO) / controller; SlashHub is the processor. SlashHub processes Personal Data only on the Customer's documented instructions (see the DPA).
7.2 Data Protection Principles. This Schedule supports, in particular, DPP4 (security). The DPA addresses DPP1 (collection/notice), DPP2 (accuracy/retention), DPP3 (use), DPP5 (openness) and DPP6 (access/correction).
7.3 Retention defaults. TimePlate retains data according to configurable policy, with defaults including: attendance/kiosk photos ~90 days (configurable); notification history ~90 days; security audit logs ~365 days; and payroll/employment records needed to support tax and statutory-entitlement calculations retained for up to 7 years under the Inland Revenue Ordinance (Cap. 112) s.51C (s.51C is a business-records rule; it does not require, and SlashHub does not default to, retaining every HR document for seven years). The Customer may configure retention within the product's controls; the Customer is responsible for setting retention to match its own legal obligations.
7.4 Data-subject requests. SlashHub provides functionality (and, on request, reasonable assistance) for the Customer to locate, export, correct or delete Personal Data so the Customer can meet its statutory time limits; SlashHub redirects requests it receives directly to the Customer (see the DPA).
7.5 Cross-border transfers. Data may be processed in Hong Kong and in other jurisdictions where our providers operate, as described in the DPA. PDPO §33 is not in force; the DPA addresses DPP3 and, where applicable, GDPR transfer mechanisms.
8.1 Applications emit structured logs. A redaction allow/deny list and an error-reporting scrubber remove credentials and personal identifiers from logs and crash reports.
8.2 SlashHub monitors service health and error rates and maintains operational metrics. Security metrics track authentication failures, permission denials and related signals.
8.3 Personal Data is not used in logs, test data or analytics beyond what is necessary to operate and secure the service.
9.1 SlashHub maintains an incident-response process covering detection, triage, containment, eradication, recovery and post-incident review.
9.2 On becoming aware of a Security Incident affecting Customer Data, SlashHub notifies the Customer without undue delay and provides the information the Customer reasonably needs for its own notification obligations (for example to the PCPD, to a supervisory authority, or to data subjects). Where the GDPR applies, SlashHub supports the Customer's 72-hour notification obligation.
9.3 Notification is not an acknowledgement of fault or liability. The Customer decides whether and how to notify data subjects and regulators (see the DPA).
9.4 SlashHub will take reasonable steps to mitigate an incident and remediate its cause, and will provide a post-incident summary for material incidents.
10.1 SlashHub relies on managed services that provide data redundancy and automated backups.
10.2 SlashHub takes backups and can restore data on a best-effort basis. SlashHub does not warrant specific recovery-point or recovery-time objectives at any service tier unless a signed Order Form or a separate business-continuity schedule states them. The Customer should export and retain the data it is required to keep (for example for IRO Cap. 112 or Employment Ordinance Cap. 57 purposes).
10.3 [roadmap] A formally tested continuity and disaster-recovery plan with stated RTO/RPO.
11.1 SlashHub complies with applicable law, including the PDPO and (where applicable) the EU/UK GDPR.
11.2 SlashHub maintains an anti-bribery/anti-corruption position and screens against applicable sanctions and restricted-party lists, consistent with MSA clause 17.
11.3 Certifications — status. SlashHub does not currently hold a SOC 2 report or ISO 27001 certification for its own operations. [roadmap] SOC 2 Type II and/or ISO 27001. Until then, SlashHub will respond to customer security questionnaires and share the controls described in this Schedule.
12.1 Sub-processors are authorised and governed as described in the DPA clause 5.
12.2 AI-model providers are contractually barred from training on Customer Data, and SlashHub does not train its own models on Customer Data (see the AI Addendum). AI tool calls are logged, and irreversible AI actions require human confirmation.
13.1 Personnel with access to Customer Data are bound by confidentiality obligations and receive security and privacy training. Access is granted on a least-privilege basis and removed on offboarding. Background checks are conducted where lawful and proportionate.
14.1 The Customer is responsible for: administering its users and roles correctly; safeguarding its own credentials, devices and network; configuring retention and the features it enables (including biometric and location features and their consents); and its own statutory, employment, tax and social-security obligations.
15.1 SlashHub will make available the information reasonably necessary to demonstrate compliance with this Schedule and the DPA, and will allow audits by the Customer (or an auditor it mandates) subject to the conditions in DPA clause 11: reasonable notice, a confidentiality agreement, no disruption, no competitor auditor, and the Customer bearing the costs.
15.2 Where a current independent report or certification exists in future, the Customer may rely on it instead of an on-site inspection.
16.1 SlashHub may update this Schedule to reflect improvements in security, provided the overall level of protection does not materially decrease during the term. Material adverse changes follow MSA clause 19. An updated version will be published with a new version number and date.
16.2 Security questions, questionnaires and incident contacts: security@slashhub.hk.
最後更新:2026-10-11 · 版本 1.0.0(草擬本) · 狀態:範本 — 待香港法律審閱
請先閱讀。 本文件為借助 AI 起草的範本,並非法律意見,使用前必須由合資格香港律師審閱及簽署。 誠實原則。 SlashHub 本身並無 SOC 2 報告,亦並無 ISO 27001 認證。僅部分基礎設施供應商持有該等認證。切勿向客戶作出相反陳述或暗示。 平台尚未具備的事項均標示為 [路線圖]。 優先次序。 本附表構成主服務協議(「MSA」)的一部分,說明 SlashHub 的保安措施,並就保安事宜優先於 MSA。本附表應與資料處理附錄一併閱讀。 語言。 本文件以英文草擬並附繁體中文譯本。除經簽署的合約另有訂明外,以英文版本為準。
本附表說明 SlashHub 為保護客戶資料(包括客戶僱員的個人資料)所採用的技術及組織措施,以支援《個人資料(私隱)條例》(第 486 章)(「PDPO」)的保障資料原則 4,以及在歐盟/英國 GDPR 適用時的第 32 條。任何無法達成的規定,SlashHub 將以書面如實說明,而非掩飾。
2.1 SlashHub 維持一份書面保安計劃,包含問責負責人、書面風險評估、事故應變程序及存取審查流程。
2.2 SlashHub 定期及在重大變更後進行保安審查。[路線圖] 經正式審核的資訊保安管理系統(ISO 27001)及獨立 SOC 2 Type II 報告。
3.1 傳輸中。 資料以 TLS(TLS 1.2 或以上,優先 TLS 1.3)加密傳輸。
3.2 靜態。 資料由我們使用的受管資料儲存(資料庫、物件儲存)以 AES-256 靜態加密。
3.3 欄位層級加密。 敏感識別資料 — 包括用於法定申報及薪酬匯出的香港身份證號碼及銀行帳戶資料 — 另以 AES-256-GCM 應用層加密及盲索引保護,令明文不以可查詢形式儲存。(實作:apps/api/src/lib/field-crypto.ts。)
3.4 照片儲存。 僱員照片及出勤影像儲存於私有物件儲存,永不公開。存取透過短期簽署 URL(有時限,例如最長 6 日,並按需重新簽發),而非永久連結。
3.5 憑證。 密碼從不以明文儲存。身份驗證交由受管身份供應商處理;工作階段及服務權杖經簽署並有時限。
4.1 最小權限及角色為本存取。 對客戶資料的存取以角色為本並受範圍限制。模組及逐筆記錄存取依客戶配置;敏感模組可予限制。
4.2 租戶隔離。 每個客戶的資料按租戶邏輯隔離,每個請求均對照已驗證使用者的租戶、角色及範圍進行驗證。跨租戶存取一概預設拒絕。
4.3 MFA。 提供多重認證,並就敏感操作要求使用。
4.4 工作階段及權杖控制。 管理變更可即時撤銷(權杖版本失效)。Kiosk/共用裝置存取受範圍限制(例如僅登入的工作階段僅可見已驗證的僱員)。
4.5 審計記錄。 與保安相關的事件(認證失敗、權限拒絕、CSRF 拒絕、敏感管理操作)寫入受限審計日誌,保留期可配置。
4.6 存取審查。 定期審查存取權限;離職時及時移除存取。
5.1 SlashHub 使用受管雲端供應商。目前的供應商類別為:雲端寄存及資料庫(Google Firebase / Google Cloud — Firestore、Authentication、Cloud Storage、Cloud Messaging)、應用程式寄存(後端 API 為 Railway)、前端寄存(Vercel)、付款處理(Airwallex)、錯誤監控(Sentry)、推送通知(Expo)及 AI 模型供應商。最新清單依 DPA(次處理者)維持並按要求提供。
5.2 供應商認證。 現存的認證由該等供應商持有,而非 SlashHub — 例如我們的寄存供應商就其基礎設施維持公認認證(如 ISO 27001 及 SOC 2 Type II)。[路線圖] SlashHub 本身的 SOC 2 / ISO 27001。
5.3 SlashHub 以合約要求次處理者施加不低於 DPA 的資料保護義務,並按 DPA 所述就其表現負責。
6.1 安全開發週期。 變更於分支上進行、經審閱,並在合併前通過自動檢查。生產變更不直接在主線上進行。
6.2 CI 保安關卡。 建置流程執行密鑰掃描及憑證偵測、依賴審計,以及容器/依賴漏洞掃描,並在發現高嚴重性問題時失敗。
6.3 密鑰管理。 憑證及服務金鑰不會納入原始碼控制並會輪換。防護機制阻止意外提交或讀取密鑰檔案;掃描器檢查儲存庫。
6.4 漏洞管理。 監控及修補依賴;漏洞按嚴重性分流。[路線圖] 定期的第三方滲透測試(目前並未進行)及正式公開漏洞賞金計劃。
6.5 負責任披露。 保安問題可舉報至 security@slashhub.hk;API 於後端主機發佈 RFC 9116 的 /.well-known/security.txt(apps/api/src/index.ts)。SlashHub 不會追究遵循該政策之善意研究人員。
7.1 角色。 客戶為資料使用者(PDPO)/控制者;SlashHub 為處理者。SlashHub 僅按客戶的書面指示處理個人資料(見 DPA)。
7.2 保障資料原則。 本附表尤其支援 DPP4(保安)。DPA 涵蓋 DPP1(收集/通知)、DPP2(準確性/保留)、DPP3(使用)、DPP5(公開)及 DPP6(查閱/更正)。
7.3 保留預設。 TimePlate 按可配置政策保留資料,預設包括:出勤/Kiosk 照片約 90 日(可配置);通知記錄約 90 日;保安審計日誌約 365 日;以及 HR 附件保留最多 7 年以符合《稅務條例》(第 112 章)第 51C 條的記錄保存要求。客戶可在產品控制範圍內配置保留;客戶須負責設定符合其自身法律義務的保留期。
7.4 資料當事人要求。 SlashHub 提供功能(並在要求下提供合理協助),讓客戶定位、匯出、更正或刪除個人資料,以便客戶在法定時限內履行義務;SlashHub 將其直接收到的要求轉介予客戶(見 DPA)。
7.5 跨境傳輸。 資料可能於香港以及我們供應商營運的其他司法管轄區處理,詳見 DPA。PDPO 第 33 條尚未生效;DPA 涵蓋 DPP3,並在適用時涵蓋 GDPR 的傳輸機制。
8.1 應用程式發出結構化日誌。遮罩允許/拒絕清單及錯誤報告清除器,會從日誌及崩潰報告移除憑證及個人識別資料。
8.2 SlashHub 監控服務健康及錯誤率,並維持營運指標。保安指標追蹤認證失敗、權限拒絕及相關訊號。
8.3 除營運及保護服務所需外,個人資料不用於日誌、測試資料或分析。
9.1 SlashHub 維持事故應變流程,涵蓋偵測、分流、圍堵、根除、復原及事後檢討。
9.2 在知悉影響客戶資料的保安事件後,SlashHub 及時(without undue delay)通知客戶,並提供客戶履行自身通知義務(例如向 PCPD、監管機構或資料當事人)合理所需的資訊。在 GDPR 適用時,SlashHub 支援客戶的 72 小時通知義務。
9.3 通知並非承認過失或責任。客戶決定是否及如何通知資料當事人及監管機構(見 DPA)。
9.4 SlashHub 將採取合理步驟紓緩事故並補救其成因,並就重大事故提供事後摘要。
10.1 SlashHub 依賴提供資料冗餘及自動備份的受管服務。
10.2 SlashHub 進行備份,並能以最佳努力基礎還原資料。除經簽署的訂購表格或另行的業務持續性附表訂明外,SlashHub 不保證任何服務級別的特定復原點或復原時間目標。客戶應匯出並保留其須保存的資料(例如為《稅務條例》(第 112 章)或《僱傭條例》(第 57 章)目的)。
10.3 [路線圖] 經正式測試並訂明 RTO/RPO 的持續性及災難復原計劃。
11.1 SlashHub 遵守適用法律,包括 PDPO 及(在適用時)歐盟/英國 GDPR。
11.2 SlashHub 維持反賄賂/反腐敗立場,並按適用的制裁及受限方名單進行審查,與 MSA 第 17 條一致。
11.3 認證 — 狀態。 SlashHub 目前並不持有就其自身營運的 SOC 2 報告或 ISO 27001 認證。[路線圖] SOC 2 Type II 及/或 ISO 27001。在此之前,SlashHub 將回應客戶保安問卷,並分享本附表所述的控制措施。
12.1 次處理者按 DPA 第 5 條授權及規管。
12.2 AI 模型供應商以合約禁止就客戶資料進行訓練,SlashHub 亦不就客戶資料訓練自身模型(見 AI 附件)。AI 工具呼叫會被記錄,不可逆的 AI 操作需人手確認。
13.1 可存取客戶資料的人員受保密義務約束,並接受保安及私隱培訓。存取以最小權限授予,並於離職時移除。在法律允許且相稱的情況下進行背景審查。
14.1 客戶須負責:正確管理其使用者及角色;保護其自身的憑證、裝置及網絡;配置保留及其啟用的功能(包括生物辨識及位置功能及其同意);以及其自身的法定、僱傭、稅務及社會保障義務。
15.1 SlashHub 將提供合理所需的資訊以證明其遵守本附表及 DPA,並允許由客戶(或其委任的審計師)進行的審計,惟須符合 DPA 第 11 條的條件:合理通知、保密協議、不干擾、非競爭對手審計師,以及由客戶承擔成本。
15.2 日後如有現行的獨立報告或認證,客戶可依賴該報告代替實地檢查。
16.1 SlashHub 可更新本附表以反映保安改進,惟整體保護水平不得在期間內大幅下降。重大不利變更按 MSA 第 19 條處理。更新版本將以新的版本號及日期發佈。
16.2 保安問題、問卷及事故聯絡:security@slashhub.hk。
SlashHub Limited © 2026 · For questions, contact legal@slashhub.hk