DPA Annex 2 — Technical & Organisational Measures

HM-LEGAL-003B·Privacy

Annex 2 — Technical and Organisational Measures (TOMs)

Document ID: HM-LEGAL-003B Title: DPA Annex 2 — Technical & Organisational Measures Version: 1.0-draft Last updated: 2026-06-14 Publisher: Headshot Marketing Private Limited (Burdenoff Group) Canonical location: https://burdenoff.com/contracts/headshotmarketing/HM-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 HeadshotMarketing subgroup at https://burdenoff.com/contracts/headshotmarketing/. Every referenced contract is identified by its Document ID (HM-LEGAL-### / HM-PRICING-###) and incorporated by reference.

This Annex describes the security measures HeadshotMarketing 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 HeadshotMarketing processes marketing, contact, CRM and engagement 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 contact, CRM and engagement 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 (PostgreSQL, graph database), the managed cache (where supported), and object storage. Application-layer secrets and signing keys are encrypted with AES-256-GCM.
  • Key management: managed in the cloud key-management subsystem (AWS KMS and Secrets Manager per environment) with key rotation; customer-managed keys available for Enterprise on request.

4. Network and infrastructure security

  • Production runs on AWS EKS (Kubernetes) 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; marketing-relevant actions (record changes, campaign edits, asset 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 employees with access to production or Personal Data, where permitted by local law.
  • Confidentiality undertakings.
  • Mandatory annual security and privacy training, including handling of sensitive marketing 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.).
  • HeadshotMarketing / 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:
    • Marketing 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 / background-check 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 contacts.
  • 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 marketing 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 leads, users, freelancers and customers.

15. Customer responsibilities

  • Customer is responsible for enabling SSO/MFA for its users, configuring RBAC (especially for contact/CRM/engagement data), applying retention policies, reviewing audit logs, ensuring the lawful basis and consents/notices for marketing data, correct provider classification, and discharging deployer obligations for marketing-AI tools.

Reference and incorporation

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