Annex 2 — Technical and Organisational Measures (TOMs)

Document ID: BRA-LEGAL-003B Title: DPA Annex 2 — Technical & Organisational Measures Version: 1.0 Last updated: 2026-10-24 Publisher: Timecampus Technologies Pvt. Ltd. (Burdenoff Group) Canonical location: https://burdenoff.com/contracts/brainyrich/BRA-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 BrainyRich subgroup at https://burdenoff.com/contracts/brainyrich/. Every referenced contract is identified by its Document ID (BRA-LEGAL-### / BRA-PRICING-###) and incorporated by reference.

Status: Published v1.0 — effective 2026-10-24. Reviewed against the production platform and approved for publication on 2026-10-24 under the founder's delegated legal sign-off (India jurisdiction); outside-counsel review checkpoints are tracked in BRA-LEGAL-REG.

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 BrainyRich processes book, financial-account, document and verification 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 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 financial-account, document and verification 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; mTLS between internal services where supported.
At rest: AES-256 for primary databases (Amazon RDS for PostgreSQL, Amazon Neptune), the Amazon ElastiCache for Valkey cache (where supported), and object storage (Amazon S3). Application-layer secrets and signing keys are encrypted with AES-256-GCM.
Key management: managed in AWS Secrets Manager and AWS KMS per environment, with key rotation; customer-managed keys available for Enterprise on request.

4. Network and infrastructure security

Production runs on Amazon EKS in AWS ap-south-1 (Mumbai) 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; wealthtech-relevant actions (record changes, account 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 assessment.
Annual third-party penetration testing (target). Findings tracked to closure.
Coordinated vulnerability disclosure programme.

8. Personnel security

Background checks for account-holders with access to production or Personal Data, where permitted by local law.
Confidentiality undertakings.
Mandatory annual security and privacy training, including handling of sensitive financial data.
Termination process revokes access promptly.

9. Physical security

Production hosted in tier-3+ cloud regions (AWS ap-south-1, Mumbai, India) 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:
- Financial 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 verification / KYC 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 clients.
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 financial-account 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 prospects, account-holders, independent advisors and advisors.

15. Customer responsibilities

Customer is responsible for enabling SSO/MFA for its users, configuring RBAC (especially for financial-account/document/verification data), applying retention policies, reviewing audit logs, ensuring the lawful basis and consents/notices for financial data, correct client classification, and discharging deployer obligations for financial-advice-AI tools.

Reference and incorporation

All Burdenoff Group contracts, addenda, exhibits, policies and registers referenced in this document are identified by their Document ID (BRA-LEGAL-### or BRA-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.