Data processing addendum
What TDACorp Identity processes, why, and on whose behalf, written in the shape of a data processing addendum. It describes current practice rather than being a signed contract.
On this page
Draft
Status
Last reviewed 5 October 2026. TDACorp Identity is pre-production. This page describes current practice and is not a signed contract. Every clause that reads as legal text is marked pending legal review by the owner. A specific signed data processing agreement is a conversation with TDACorp directly.
Parties and roles
TDACorp Identity exists to provide sign-in and access control to other TDACorp products. Its own purpose is narrow: verify who someone is, keep their session alive, and enforce what they are allowed to do. Each product built on it decides why an account exists and what it is used for beyond signing in. That is outside this platform's scope and this page does not speak for it.
| Party | Who | Role in this addendum |
|---|---|---|
| Operator of the platform | TDACorp Private Limited, an Indian company incorporated on 17 July 2026 | Processes personal data on behalf of the product a person is using, for authentication and permission enforcement |
| The product | A TDACorp product (or other application) that signs people in through this platform | Decides why an account exists and what it is used for beyond sign-in. Responsible for its own legal basis and its own notice |
| The data subject | A person with an account on the platform, including a person invited by an organization | Exercises the rights described below |
| Subprocessors | Infrastructure vendors used to run the platform | Listed on the subprocessor register |
Concretely, TDACorp Identity processes personal data on behalf of the TDACorp product a person is using, for the purpose of authenticating them and enforcing their permissions. For the platform's own account area, sessions and security records, TDACorp Private Limited determines the purpose as well, and the privacy policy governs that processing.
Note
The repository does not name a separate customer legal entity, a signatory, an address or a data protection officer. None is stated here. Naming the contracting entity for each product is pending decision by the owner.
How the roles apply
| Situation | Role of TDACorp Identity | Source of the basis for processing |
|---|---|---|
| A person self-registers | Holds the account for authentication | The consent given at registration |
| A person is invited by an organization | Holds the account for authentication on that organization's behalf | The organization's basis for inviting the person, recorded in the membership |
| A product reads a profile claim | Releases claims only per the scopes requested. A third-party application also needs the person's consent; a first-party TDACorp product is not shown a consent screen | The consent record for that connected application |
| The platform's own security processing (rate limiting, alerts, recovery) | Acts for its own security purpose | Delivering the service and protecting accounts |
Subject matter, nature and purpose
| Item | Description |
|---|---|
| Subject matter | Authentication, session management, authorization decisions and the security records that support them |
| Nature of processing | Collecting, storing, hashing, encrypting, comparing, transmitting by email, exporting on request, and deleting |
| Purpose | Verify who someone is, keep their session alive, enforce what they may do, detect and limit abuse, notify them of security events, and honour their requests to export or delete |
| Not a purpose | Advertising, behavioural profiling, analytics or sale of data. No such feature exists to opt out of |
| Instructions | Processing follows the platform's configuration and the account holder's own actions. There is no mechanism by which a product instructs the platform to process data for a different purpose |
Note
Pending legal review by the owner: the formulation of documented instructions from a product to the platform.
Categories of data subjects
| Data subject | Description |
|---|---|
| Account holders | People who register themselves |
| Invited members | People invited into an organization on the platform |
| Administrators | Platform and organization administrators, whose actions are audited |
| Sign-in attempters | People or automated clients who attempt to sign in or recover an account, whether or not an account exists |
| Developers | People who register an OAuth client or create a personal access token |
Categories of personal data
| Category | Examples | How it is protected |
|---|---|---|
| Identity and contact | Email addresses (each verified before use), display name, optional locale and time zone | Stored in the primary database |
| Profile picture | An optional image (PNG, JPEG or WebP) | Stored as a database row, not with a storage vendor. Served from a public address keyed to the account identifier |
| Password credential | A salted Argon2id hash (64 MiB, 3 passes, 4 lanes) | One-way hash. The password is never stored |
| Passkey credential | A WebAuthn public key and signature counter | The private key never leaves the person's device |
| Second-factor material | Authenticator (TOTP) secret; 10 recovery codes per batch | Authenticator secret sealed with AES-256-GCM. Recovery codes stored only as HMAC-SHA256 keyed hashes |
| Session data | Network address, user-agent hash, a label parsed from the user-agent, a country and city derived from the network address by the host (and, only when an operator enables the geo-delta risk flag, a whole-degree coarse position), how the session was authenticated, times of activity | Session secret stored only as a SHA-256 digest |
| Device data | A device record per browser with an optional name and trust level; a random device cookie value | Cookie value stored only as a hash |
| Sign-in alert records | The label, country, address and method of a new-browser sign-in | Deleted when used or after 7 days |
| Consent and membership | Consent records for connected applications; organization memberships and role bindings | Stored in the primary database |
| Tokens | Refresh tokens, authorization codes, personal access tokens | Stored only as hashes or digests |
| Audit log | Security events with time, actor, target, event kind, request id and, for some events, the network address | Append-only and hash-chained. Payloads reference identifiers and hashes, not names or addresses |
| Request records | Request log lines (route, method, status, duration, tenant, client, an HMAC of the caller address) | Filtered through an allow-list. Never the raw address, secrets or tokens |
| Email in transit | The recipient address and message text of each email | Magic-link, recovery and registration mail is queued with a sealed address and body, then sent through the email provider. Security notices and sign-in alerts are sent to the provider directly |
| Requests | The record that an export or deletion was requested | Stored in the primary database |
Special categories of data (health, biometric templates, financial, children's data) are not collected. A passkey authenticator's biometric check happens on the person's device and no biometric data reaches the platform.
Duration of processing
Processing lasts as long as the account exists, plus the retention periods in the retention schedule.
| Event | Duration |
|---|---|
| Active account | Records persist for as long as the account exists, except the short-lived records listed in the retention schedule |
| Account deletion requested | The account is deactivated at once. Personal data is erased by a background job 30 days after deactivation |
| Personal-data export | Downloadable for 7 days, then deleted by a background job |
| Audit log | Kept 2920 days (8 years) by default. No automated pruning is enabled today, so audit records are currently retained indefinitely |
On the current hosting plan the background jobs run from a daily scheduled job plus ordinary traffic, so they can run up to about a day late.
Processor obligations
The platform commits to the following as its current practice. The right-hand column states what exists in the code today.
| Obligation | Current practice |
|---|---|
| Process only on documented instructions | Processing follows the platform's configuration and the data subject's own actions. No other processing path exists |
| Confidentiality | Staff access to the database is a break-glass procedure through the provider console. Application roles cannot log in. The repository describes a solo operator today |
| Security of processing | See the security measures table below |
| Subprocessors | Only those on the subprocessor register. The register is read off configuration and code |
| Assist with data subject requests | Export, deactivation, consent withdrawal and session revocation are self-service. See below |
| Assist with breach handling | Runbooks and a notification template exist. See breach notification below |
| Delete or return data at the end | See return and deletion below |
| Make information available for audits | See audit rights below |
| Records of processing | The audit log records security-relevant events. A separate formal register of processing activities is not published |
Note
Pending legal review by the owner: the wording of each obligation as a contractual covenant.
Security measures
| Measure | Detail | Where it is stated |
|---|---|---|
| Password hashing | Argon2id at 64 MiB memory, 3 passes, 4 lanes, random salt, parameters pinned in code | Security practices |
| Breached-password check | Have I Been Pwned range API with a 5-character hash prefix and padded response. If unreachable the password is accepted and the event logged (class only). No scheduled job rechecks it; instead it is checked in the background on every successful password sign-in | Security practices |
| Secrets at rest | AES-256-GCM envelope encryption with per-purpose data keys wrapped by a key-management provider. In pre-production that provider is software, not a cloud KMS or hardware module | Security practices |
| Opaque secret storage | Sessions, refresh tokens and personal access tokens stored as SHA-256 digests | Security practices |
| Session controls | Cookie __Host-tdaid_sid, HttpOnly, Secure, SameSite=Lax, no Domain. Idle 12 hours, absolute 14 days. The session is looked up in the database on every account request | Security practices |
| Token controls | Access tokens at most 15 minutes, single audience, sender-constrained unless the client is a first-party web application. Refresh tokens rotate with reuse detection and a 10-second retry grace | Security practices |
| Step-up | Sensitive account actions (export, deletion, factor changes, personal access tokens) need a second factor used in the last 30 minutes. A completed step-up is valid for 10 minutes | Security practices |
| Abuse limits | Rate limits on sign-in, recovery, token and API endpoints | Security practices |
| Transport | HTTPS only, HSTS with includeSubDomains, strict content security policy with a per-response nonce, no framing, no referrer | Security practices |
| Database isolation | Forced row-level security on tenant tables, three non-login application roles, append-only event tables enforced by trigger and grants | Operations reference and security audit |
| Audit integrity | Hash-chained append-only audit log. Anchors are published by an operator command | Security practices |
| Telemetry minimisation | Telemetry attributes pass an allow-list. Free text, tokens and raw addresses cannot be emitted | Operations reference |
| Supply chain | Locked dependencies, a 7-day minimum release age, automated advisory scanning | Operations reference |
| Backups | A nightly encrypted dump workflow and a monthly restore drill are written but not yet run. See the retention schedule | Retention schedule |
| Staging and production separation | Enforced in code before any secret is read | Operations reference |
| Account notices | Email notices to every verified address after credential, recovery and other security changes, sent on a best-effort basis: a failed send is logged and not retried from a queue, and an account with no verified address gets none | Security practices |
Note
No outside party has verified these measures. TDACorp holds no SOC 2 report and no ISO 27001 certificate. There is no penetration test report.
Subprocessors
The platform uses a small number of infrastructure vendors: hosting, the primary database and transactional email, plus optional telemetry and the backup arrangements described on the register. The list, with what each is used for and what data it sees, is kept on its own page so there is one place to check it against reality.
| Subprocessor | Purpose | Detail |
|---|---|---|
| Vercel | Hosting | See register |
| Neon | Primary database | See register |
| Resend | Transactional and security email | See register |
| Grafana Cloud (optional) | Telemetry, only when configured | See register |
Read the subprocessor register
Authorisation and change
General authorisation of the listed subprocessors is how this page is written. The register is updated when a vendor is added, and its change process is described on that page. The repository records no advance-notice period and no formal objection procedure beyond emailing security@tdacorp.in. See the register.
Note
Pending legal review by the owner: whether to commit to a notice period before adding a subprocessor.
Data subject requests
| Request | How it is handled | Needs sign-in |
|---|---|---|
| Access and portability | Export from Privacy and data in the account, after a recent second-factor check. A signed JSON document of profile, emails, credential metadata, sessions, consents, memberships and own audit events. No secrets are included | Yes |
| Erasure | Delete (deactivate) the account from the same page. Erasure follows after 30 days | Yes |
| Withdraw consent for an application | Connected apps page. Withdrawal revokes the application's access | Yes |
| Review and end sessions | Sessions page | Yes |
| Correction | Edit profile fields and email addresses in the account | Yes |
| Anything else, or if you cannot sign in | Email security@tdacorp.in | No |
An operator command can also erase a deactivated account on request, and a worker erases accounts 30 days after deactivation. A request made by an operator on behalf of a person who cannot sign in is manual. No response time is promised for emailed requests.
All five self-service requests require being signed in, because each acts on the requester's own account only. The export is stored in the platform database as a sealed blob, encrypted with AES-256-GCM under a per-file key wrapped by the key provider.
Personal data breach notification
| Item | Current state |
|---|---|
| Detection | An operations monitor raises email alerts to the configured operator address for stale background workers, stale backups, break-glass activations, elevations, webhook auto-pauses, dead-lettered deliveries, authentication anomalies and email budget exhaustion. It runs once per daily scheduled pass. See Incident response |
| Runbooks | Seven operator runbooks exist: signing key, product client key, database read breach, admin account compromise, audit chain mismatch, support material exposure and solo break-glass recovery |
| Internal clocks | The runbook template records two clocks measured from awareness: 6 hours for CERT-In reporting for listed incident classes, and 72 hours for a detailed report to the Data Protection Board. The template states that intimation of affected principals is to happen without delay |
| Notifying affected people | Manual. The system has no export of affected principals for a breach report, and the automated delivery of session-revoked and account-disabled signals to receivers is not built. Affected-principal intimation is a manual mail merge from a database query |
| Notifying a product or controller | No contractual notice period to a product is defined. This is pending decision by the owner |
| Public commitment | This page makes no breach-notification commitment beyond what applicable law requires |
Note
Pending legal review by the owner: a contractual notification period to products, and whether to publish one.
Audit rights
TDACorp holds no external audit, certification or attestation of this platform. The repository defines no customer audit procedure, no audit schedule and no questionnaire process. What exists for verification is open to anyone who works with the operator:
| Mechanism | State |
|---|---|
| Account-level activity log | Each person sees their own security events on the Activity page |
| Audit chain verification | The chain can be verified from the last good anchor by an operator. An offline verification command (idctl anchor verify) and a scheduled anchoring job are built. The scheduled job is off by default and not enabled in the production configuration |
| Published policy pages | This page and the other trust pages are written against the code |
| Customer audit of the platform | Not defined. A request is a conversation with TDACorp |
Note
Pending legal review by the owner: whether to grant customer audit rights, on what notice, and at whose cost.
Return and deletion
| Stage | What happens |
|---|---|
| Account deletion requested | The account is deactivated at once. Every session, token and personal access token is revoked and sign-in stops |
| Export before deletion | A personal-data export is available while the account is active, and can be downloaded for 7 days after it is made |
| 30 days after deactivation | A background job erases the account's personal data: the profile, email addresses, credentials and their children, devices (name nulled), stored exports and the profile picture. The account becomes erased, which is terminal |
| What survives | The audit log keeps the account's identifier and events so its integrity chain stays intact. It is designed to reference identifiers and hashes rather than names or email addresses, but every event kind has not been audited for that. Linkage-only records such as token families and relying-party sessions keep ids and timestamps. Records that cannot be edited after the fact may keep a network address or a user-agent hash, and the address an invitation was sent to |
| Whether to change what survives | An open owner decision, stated here rather than hidden |
| Backups | A nightly encrypted dump workflow is written but not yet run. Erasure does not reach into a dump. See the retention schedule |
| End of a product's relationship | Not defined by the repository. A tenant deletion is specified as a 30-day state with an export, then a hard delete of tenant-scoped rows except audit. A product leaving the platform is a conversation with TDACorp |
International transfers
TDACorp Private Limited is an Indian company and its own processing is governed by Indian law, including the Digital Personal Data Protection Act, 2023.
| Item | State |
|---|---|
| Intended placement | The platform specification calls for primary and replica databases in India and backups in a second Indian region |
| Actual primary database | Not in India during pre-production. The database provider has no Indian region, and the owner waived the placement on 2026-09-30, to be revisited before launch |
| Region of each vendor | Hosting: Vercel, function region iad1 (US East, N. Virginia), no failover. Database: Neon, AWS US East 1 (N. Virginia). No region is declared for the other vendors |
| Telemetry endpoint | The documented optional endpoint host contains the string ap-south-1. That is a hostname fact, not a statement about where data is processed |
| Transfer mechanism | No transfer mechanism document exists in the repository |
Note
Pending legal review by the owner: whether and how to restate the cross-border position before launch.
Liability
Liability for use of the platform is dealt with in the terms of service. No separate cap, indemnity or insurance statement exists for this addendum. TDACorp has no payment relationship with end users at this layer.
Note
Pending legal review by the owner: any liability or indemnity terms specific to a product agreement.
Governing law and changes
This addendum is governed by the laws of India, including the Digital Personal Data Protection Act, 2023, as a statement about TDACorp's own processing. It is revised as the product changes, not on a fixed schedule. The date at the top of the page is the date the copy was last reconciled against the code.
Note
Pending legal review by the owner.
What this page does not claim
| Not claimed | Detail |
|---|---|
| A signed contract | This describes current practice and is not legal advice |
| Data in India | The primary database is not in India during pre-production, by owner waiver |
| A cloud KMS | Key management in pre-production is a software provider |
| Certifications | No SOC 2, no ISO 27001, no privacy certification, no uptime guarantee |
| A breach-notification period | None beyond what applicable law requires. Affected-principal intimation is manual |
| A named contracting entity, address, signatory or data protection officer | None is stated in the repository |
| Audit rights for customers | None defined |
| A notice period for new subprocessors | None defined |
| Coverage of a product's own data | A product built on this platform is responsible for its own data beyond authentication, and for its own legal basis |
| Strength of export encryption at rest | Exports are sealed per file, but the pre-production key provider is software, so whoever obtained both the database and the master key could open them |
| Any backup retention period in code | Retention in object storage is configured outside code and is not yet set |