DPA Annex 2 — Technical & Organisational Measures

TC-LEGAL-003B·Privacy

Annex 2 — Technical and Organisational Measures (TOMs)

Document ID: TC-LEGAL-003B Title: DPA Annex 2 — Technical & Organisational Measures Version: 1.1 Last updated: 2026-10-24 Publisher: Timecampus Technologies Pvt. Ltd. (Burdenoff Group) Canonical location: https://burdenoff.com/contracts/timecampus/TC-LEGAL-003B Burdenoff Group Contract Registry — root at https://burdenoff.com/contracts (one subgroup per product). The contracts referenced in this document belong to the TimeCampus subgroup at https://burdenoff.com/contracts/timecampus/. Every referenced contract is identified by its Document ID (TC-LEGAL-### / TC-PRICING-###) and incorporated by reference.

This Annex describes the security measures Timecampus implements to protect Personal Data. Measures are reviewed at least annually and may be updated provided overall protection is not materially diminished. Detail is given in the Security Exhibit; this Annex is the contractual summary. Given that TimeCampus processes team, expense, document and monitored-activity data, heightened controls apply to those data classes.

1. Information security programme

  • Information security programme aligned to ISO/IEC 27001 control families.
  • Designated security owner reporting to senior management.
  • Annual risk focus-score assessments and management reviews.
  • Security policies covering acceptable use, access control, incident response, change management, vulnerability management, vendor management, and business continuity.

2. Access control

  • Single sign-on for internal access; MFA required for all administrative access and cloud accounts.
  • Least privilege and role-based access control; quarterly access reviews.
  • Just-in-time elevation for production; break-glass accounts with full audit.
  • Strong password policy; no shared accounts.
  • Customer-side access in the Service is governed by the workspace/tenant RBAC model (GraphQL @rbac directives enforced at the gateway, backed by the platform RBAC services), with heightened restrictions on expense, document and monitored-activity data so that such data is visible only to roles Customer grants.

3. Encryption

  • In transit: TLS 1.2+ on all public endpoints; HSTS; modern cipher suites; certificate-verified TLS (verify-full) from services to managed databases.
  • At rest: AES-256 (AWS KMS-managed keys) for the primary relational databases (Amazon RDS PostgreSQL), the graph database (Amazon Neptune), the cache and event-stream layer (Amazon ElastiCache Valkey) and object storage (Amazon S3). Application-layer secrets and signing keys are encrypted with AES-256-GCM.
  • Key management: managed in the cloud key-management subsystem (AWS KMS for encryption keys and AWS Secrets Manager for application secrets, separated per environment) with key rotation; customer-managed keys available for Enterprise on request.

4. Network and infrastructure security

  • Production runs on Amazon EKS (Kubernetes) in AWS ap-south-1 with private networking, default-deny network policies, and segregation by environment.
  • Public traffic via Cloudflare WAF → API gateways; internal M2M via internal gateways only.
  • Bastion / Cloudflare Zero Trust access for operators; no direct public administrative access.
  • Firewall and network rules reviewed regularly; default-deny posture.

5. Application security

  • Secure SDLC: code review on all changes; static analysis on CI; dependency scanning; secret scanning.
  • Container image scanning (Trivy) for CVEs, IaC misconfigurations and SBOM.
  • Strict input validation; parameterised queries (Prisma) to prevent SQL injection.
  • GraphQL query depth/cost limits and RBAC enforcement at the gateway.
  • Strict TypeScript repo standards (no any, no eslint-disable, no @ts-ignore).

6. Logging, monitoring and audit

  • Centralised logging, metrics and traces with dashboards.
  • Application audit logs available to Customer per Plan retention; time-and-record actions (record changes, expense and billing edits, document access) are auditable.
  • Production action logs retained for at least 180 days for security investigation purposes (and CERT-In compliance).
  • Security event monitoring with on-call rotation (best-effort outside business hours for non-Enterprise).

7. Vulnerability management and patching

  • Continuous CVE scanning of base images and dependencies.
  • Patch cadence: critical vulnerabilities within 7 days; high within 30 days; medium within 90 days, subject to operational risk focus-score assessment.
  • Annual third-party penetration testing (target). Findings tracked to closure.
  • Coordinated vulnerability disclosure programme.

8. Personnel security

  • Personnel screening for staff with access to production or Personal Data, where permitted by local law.
  • Confidentiality undertakings.
  • Mandatory annual security and privacy training, including handling of sensitive team data.
  • Termination process revokes access promptly.

9. Physical security

  • Production hosted in tier-3+ cloud regions (AWS ap-south-1, Mumbai) operated by cloud providers with their own physical-security certifications (ISO 27001, SOC 2 etc.).
  • Timecampus / Burdenoff offices: badge-controlled access; CCTV; clean-desk policy.

10. Business continuity and disaster recovery

  • Production databases with automated backups: hot tier rolling 30 days; cold tier up to 90 days.
  • Multi-AZ deployments for production-tier services.
  • BCP / DR plans reviewed annually; recovery objectives:
    • Team data: RPO 1 hour, RTO 8 hours (Enterprise; SaaS default RPO 24h / RTO 24h).

11. Incident response

  • Documented IR playbooks; on-call rotation.
  • Severity classification, internal escalation, customer notification within 72 hours of confirmed Personal Data Breach (or shorter where required by law).
  • Post-incident review and remediation tracking.

12. Sub-processing controls

  • Vendor security review prior to engagement (including payroll/accounting export providers).
  • Contractual obligations equal to or stricter than this DPA.
  • Annex 3 list maintained and notified on change per DPA §6.

13. Data minimisation and pseudonymisation

  • Service Generated Data is aggregated/de-identified before any analytical use; no behavioural profiling of individual workers.
  • Customer Data is logically segregated by tenant; multi-tenant isolation enforced at the resolver layer.
  • Test/staging environments use synthetic or anonymised data; copying production Personal Data into non-production environments is prohibited.

14. Data subject / principal rights enablement

  • Account exports for Personal Data of Authorized Users and team records.
  • Admin tooling for Customer to correct and delete records and content.
  • Workflows to honour deletion / correction / data principal requests routed through Customer (Data Fiduciary), including requests from team members, employees, contractors and team members.

15. Customer responsibilities

  • Customer is responsible for enabling SSO/MFA for its users, configuring RBAC (especially for expense/document/monitored-activity data), applying retention policies, reviewing audit logs, ensuring the lawful basis and consents/notices for team data, lawful use of monitored time and activity data, and discharging deployer obligations for automated time-and-activity analytics tools.

Reference and incorporation

All Burdenoff Group contracts, addenda, exhibits, policies and registers referenced in this document are identified by their Document ID (TC-LEGAL-### or TC-PRICING-###) and are published at https://burdenoff.com/contracts. Each such referenced document is incorporated into this document by reference. The version of a referenced document that applies is the version published at https://burdenoff.com/contracts as at the Effective Date of the applicable Order Form (or, where no Order Form exists, the version current at the date of acceptance), unless an executed Order Form specifies a frozen version.

Back to TimeCampus Contracts