PII Policy

1Why this document exists

Our Privacy Policy sets out the firm's overall privacy posture under the DPDP Act. This PII Policy goes one level deeper: it describes the actual categories of personal data that flow through our engine in the course of a tax engagement, where each category sits, who can read it, and what happens to it at the end.

We publish this for three reasons:

• Transparency to data principals. If a booking record about you ended up in our system because your employer is our client, you have a right to understand what we hold and why.
• Defensibility to security teams. Vendor questionnaires routinely ask for the kind of detail we have set out here. Publishing it means the answers do not depend on a sales conversation.
• Discipline for ourselves. A policy that is published cannot drift quietly. If our handling changes, this document changes with it, and the change is dated.

2Categories of PII we hold

The personal information we receive or generate during a typical engagement falls into the following categories:

3Where each category sits in the engine

The categories above are not held in one place. Each sits in the module of our engine that needs it:

• Traveller identifiers and carrier invoices, in SkyDoc (airline capture) and StayDoc (hotel capture).
• Employee → entity mappings and cost-centre data, in TripStream, which pipes the client's master data live from their HRMS and finance system.
• Approver records and expense records, in TripStream and TripConnect, depending on whether the source is the client's internal system or the TMC.
• Reconciliation records and tax positions, in SkyLedger and StayLedger.
• Posted journal entries with attached PII, in AlignIQ, at the moment of posting into the client's ERP, and then in the client's ERP thereafter.
• The audit trail of every read and write, in the firm's append-only event log.

All of these run inside a single security envelope. See the Security page for the architecture, and Section 4 below for the specifics of client isolation.

4Client isolation

Each client's data is logically isolated within the engine. Specifically:

1. Every client has separate encryption keys for data at rest, managed in a key management service with strict access controls;
2. Application-level queries are scoped to a single client at every layer of the engine, there is no code path that aggregates personal data across clients;
3. Tax desk members work on one engagement at a time and have access only to the engagements they have been authorised onto;
4. The audit log records, for every read and write, the engagement identifier and the actor, access without an associated engagement is impossible by construction.

The firm does retain methodological knowledge from prior engagements, how a particular type of gap is identified, which scrutiny questions tend to arise, but this knowledge stays at the level of practice, not at the level of identifiable data.

5What we never collect

We do not collect, and have no operational need for, any of the following:

• Aadhaar numbers, virtual ID, or any UIDAI-issued identifier;
• PAN numbers of individuals (we work with entity-level GSTINs and entity PANs, not individual PANs);
• Passport numbers, visa numbers, or travel document numbers;
• Photographs of travellers, biometric data, or any image-based identifier;
• Bank account numbers, UPI handles, or other payment-instrument data of individuals;
• Personal contact information of travellers (we receive corporate email and corporate phone, not personal);
• Special categories of personal data such as health, religion, sexual orientation, or political opinion.

If any of these appear in a source document we are required to hold for tax-defence purposes, for example, a PAN printed on an invoice header, the document is held in its original form and the identifier is not extracted, indexed, or used for any other purpose.

6What never leaves the firm

A subset of the personal data we generate during the engagement is held internally and is never written into the client's books or shared back. This includes:

• Internal tax-desk routing and triage notes, the working commentary between partners and the tax desk on how a gap was approached, what alternatives were considered, what was discarded;
• Draft positions and partial opinions, positions that were considered but not adopted, partial drafts that were superseded by a cleared position;
• Cross-engagement methodological signals, patterns observed across the firm's broader practice that informed how a position was reached, but never the underlying data;
• Engagement-margin and commercial data, the firm's internal view of the engagement's economics.

This boundary is enforced at the data layer of the engine. The AlignIQ module is the only point at which engagement data crosses into the client's books, and only the cleared, evidence-backed claim crosses. See the AlignIQ page for the boundary specifics.

7What gets written into your books

When AlignIQ posts a cleared claim into the client's ERP, the following are written as part of the journal entry record:

• The journal entry itself: GL accounts, debit/credit, amount, narration;
• The source invoice as a PDF attachment;
• The reconciliation excerpt that matched the invoice to the filing as a PDF attachment;
• The tax desk opinion that authorised the claim as a PDF attachment;
• The approver metadata: name, designation, timestamp.

The personal data on this trail, principally the approver name and any traveller name on the source invoice, becomes part of the client's accounting record. From the moment of posting, the client is the Data Fiduciary for this record under their own retention policy. We retain the audit trail of the posting itself for the duration set out in Section 8.

8End of engagement

At the end of an engagement, we hold engagement data for a defined retention period of five years from the date the engagement concludes. This is to support:

• Defence against any future tax scrutiny of claims we filed during the engagement;
• Statutory record-keeping obligations under Indian tax law;
• Restoration of access for the client, on request, during the retention period.

After the retention period, all personal data associated with the engagement is securely deleted or fully anonymised so that it cannot be associated with any identifiable individual. The firm's audit-log entries are reduced to the minimum required for our own statutory obligations and then deleted on the same schedule.

If a client requires earlier deletion, for example, where their retention policy is stricter than ours, this is agreed in the engagement contract and we honour it within the agreed window. Where statutory law requires us to retain a record despite a deletion request, we will say so and explain which provision applies.

9If you are a traveller

If you are reading this because a booking record about you ended up in our system through your employer, here is what you should know:

1. Your employer is the primary Data Fiduciary for the data. We process it on their behalf, under contract. Your first point of contact for any question about your data is normally your employer.
2. You still have rights under the DPDP Act, the right to a summary of what we hold, the right to correction, and the right to grievance redressal. These are set out in our Privacy Policy.
3. If you write to us directly, we will route your request to the appropriate party (your employer or, where we hold the data directly, ourselves) and confirm to you the action taken.
4. We will never contact you for marketing, send promotional material to your contact details, or share your data with any third party except for the legitimate purposes of the engagement.

10Contact

For any question, request, or grievance relating to the personal information we hold, please contact our Data Protection Officer: