Vendor due-diligence disclosureUpdated 2 August 2026

For temple trusts, boards & procurement committees

Due diligence without invented certainty.

BookMyMandir is a product of XALEN Technology Private Limited.

This page is a source-backed engineering and operating disclosure. It is not a legal opinion, security certification, DPA, statutory compliance certificate or executed vendor contract.

Legal entity
XALEN Technology Private Limited
CIN
U72900PN2024PTC230853
GSTIN
27AAACX6117C1ZL
Registered office
Pune, Maharashtra 411041, India

01 · Service boundary

The temple remains in control.

BookMyMandir is B2B operating software for temple institutions. Current bounded workflows include temple profiles, listings and enquiry records, devotee and consent records, internal donation records, forms, staff access and related operator tools. Availability is disclosed separately from roadmap outcomes.

BookMyMandir records and supports temple-operated workflows. The temple owns its offering destination, settlement, fulfilment, devotees and records; BookMyMandir does not collect, settle, refund or verify offering funds. The platform fee on temple offerings is 0%.

Subject to applicable law and agreements, temples retain their rights in their devotee data, temple-reported donation records and message content. The platform does not sell or rent personal data or use one temple's workspace records to benefit another temple.

02 · Data & DPDP posture

Controls exist. Legal allocation is still agreement-specific.

For temple-controlled devotee, enquiry, communication and operating records, the temple normally determines the purpose and authorised users; BookMyMandir processes workspace records where applicable. The company separately determines purposes for account, lead, support and security records. The exact data-fiduciary, processor or other statutory role depends on the record, agreement and law.

The primary application data plane is configured in AWS Mumbai. CloudFront is global, and approved email or identity services may process limited data outside Mumbai. This page does not claim that every byte or provider backup stays in India.

Source controls include per-channel consent states, purpose suppression, email withdrawal, bounded form-expiry snapshots and manual privacy-request intake. They are operational evidence, not independent proof that a temple's original notice or consent collection was legally sufficient.

Current application expiries include 365 days for booking enquiries and certain temple workflows, 180 days for company lead/claim/enterprise/support intake, and 30/90/180/365-day snapshots for temple-form responses. Some account, audit, consent and operational records do not yet have a complete automated deletion schedule.

Read the full privacy notice ↗

03 · Technical dependencies

Known providers, narrowly stated.

This is a current technical-dependency inventory, not a counsel-approved subprocessor schedule or DPA exhibit.

No payment processor, SMS-delivery provider or WhatsApp-delivery provider is active for the unavailable workflows described on this site.

Core hosting and cloud infrastructure

Amazon Web Services (AWS)

OpenNext/Lambda hosting, CloudFront delivery, Cognito identity, DynamoDB records, S3 objects, KMS encryption, queues/events and CloudWatch operations. The primary application data plane is configured in Mumbai (ap-south-1); CloudFront is a global edge service.

Conditional operational email transport

Resend

May receive a recipient address, message content and delivery metadata when a configured email workflow is admitted. Provider acceptance is not inbox delivery. Campaign delivery remains held where signed outcome authority is absent.

04 · Security summary

Source controls, not a certification badge.

  1. 01Cognito tokens are verified server-side; tenant identity and role are derived by the server rather than accepted from a request body.
  2. 02DynamoDB tenant records use protected tables with point-in-time recovery; tenant assets use versioning, HTTPS-only access and KMS encryption with key rotation.
  3. 03Sensitive routes use default-deny capabilities, bounded inputs, private/no-store responses, idempotency controls and audit evidence.
  4. 04CloudFront-origin access and stage secrets have explicit infrastructure boundaries; a configured provider or secret is not treated as proof of a completed customer workflow.

MFA is optional rather than mandatory. Human alert delivery is not fully proved. No current public evidence is offered for SOC 2, ISO 27001, an independent penetration test, complete WAF/challenge coverage, a contractual RTO/RPO or a completed formal disaster-recovery exercise.

05 · Grievance channel

Status: NOT MONITORED.

A named grievance officer and monitored grievance mailbox are not yet available. The first-party privacy-request form records an intake request, but it is not represented as a monitored statutory grievance channel and no response SLA is promised.

Receiving-domain status: NO MX RECORDS

Record a privacy request on the first-party intake form ↗

06 · Open evidence

Not currently available.

  • Counsel-approved DPA, subprocessor schedule, DPDP role matrix and cross-region transfer assessment
  • Named grievance officer, monitored grievance mailbox, escalation path and response SLA
  • Independent SOC 2 or ISO 27001 certification, penetration-test report, contractual RTO/RPO or completed disaster-recovery exercise
  • Complete retention/deletion schedule, physical purge proof, provider-held deletion and backup-deletion commitments
  • Counsel-approved governing law, forum, warranties, indemnities, liability cap, service levels and statutory notice terms
  • Paid subscription order, checkout, activation, usage billing, verified customer reference, testimonial or case study

Customer evidence

0 verified temples · 0 paid tenants · 0 authorised testimonials · 0 authorised case studies

No demo tenant, synthetic acceptance fixture or source-complete feature is presented as customer adoption.