The operating discipline behind privacy.

01Purpose of this document

TraCarta’s SkySuite platform receives, processes, and stores personally identifiable information (“PII”) belonging to the corporate customer’s employees and counterparties in the course of GST reconciliation. The most common categories are passenger names on airline invoices, employee identifiers from booking systems, and corporate GSTINs. Our customers’ risk and compliance teams need to understand how that PII is treated, not at the policy level, which is in the Privacy Policy, but at the operating level. This document is that operating description.

Where TraCarta is acting as a data processor on behalf of a customer (which is the case for the majority of PII we handle), this document supplements the data processing terms in the underlying agreement. Where the agreement specifies stricter handling than this document, the agreement governs.

02Categories of PII we handle

The PII reaching the SkySuite engine falls into four categories. We treat each according to its sensitivity:

We do not collect government-issued identifiers (PAN, Aadhaar, passport number) of passengers or employees. If such an identifier appears in a customer-supplied record, it is flagged for redaction before processing continues.

03Data minimisation

Our default position is that the engine should hold the smallest amount of identifiable data needed to do its work. The disciplines:

• SkyDox extracts only the invoice fields required for reconciliation, we do not capture passenger contact details, frequent-flyer numbers, or seat assignments, even where airline portals expose them.
• Booking exports the customer sends through SkyConnect are filtered on receipt, columns not used by SkyLedger are dropped at the ingestion boundary, not stored and then ignored.
• Where a customer’s SAP or Tally export contains employee identifiers not needed for the reconciliation, we encourage anonymising at source and provide guidance on the minimum field set during onboarding.

04Scrubbing & pseudonymisation

Output produced by SkySuite is scrubbed of PII by default. Specifically:

• Standard reports. The reconciliation report, the eight-verdict catalog output, and the financial-position summary use pseudonymised passenger references (e.g. PAX-04832) rather than names. The mapping is preserved within the customer’s tenant for drill-down; it is not exported.
• Draft journal entries from SkyIQ. Narrations reference the booking aggregate (cost centre, project code, period) rather than individual passengers.
• Aggregated platform telemetry. Any aggregate metric we compute across customers (recovery-rate benchmarks, mismatch-category statistics) is built from cohort-anonymised inputs; no record traceable to a single passenger, employee, or transaction is included.

05Where the data lives

All customer data, including PII, is stored on infrastructure physically located within India. We do not transfer customer data outside India in the ordinary course of operating the platform.

Specifically. Production storage is in the Mumbai region of our cloud provider, with disaster-recovery in the Hyderabad region of the same provider. Backups are encrypted and stored within the same regional footprint. No customer data is replicated to systems outside India.

Where a TraCarta engineer accesses production for legitimate operational reasons (incident response, deployment, audit), the access happens via a workstation physically located in India and the session is logged.

06Internal access controls

Internal access to customer PII follows the principle of least privilege:

• Default-deny. No employee has standing access to production customer data. Access is granted on a per-incident or per-task basis, expires automatically, and is logged.
• Two-person approval. Production access requires approval from a second authorised individual; the approver is not the requestor’s direct report.
• Audited access. Every read of a customer record is logged with the requesting user, time, purpose, and record reference. Logs are tamper-evident and retained for the same period as the underlying record.
• Background checks. Personnel with eligibility for production access are subject to background verification on hire.
• Off-boarding. Access is revoked on the same business day an employee’s engagement ends.

07What we never log

Operational logs are essential for running the platform: debugging, monitoring, audit. But operational logs are themselves data, and they can leak PII if disciplines aren’t in place. Our standing rules:

• Passenger names, ticket numbers, and PNRs are never written to operational logs. Where a log line would naturally include such a value (for example, on a reconciliation failure), the value is replaced with its pseudonymised reference before the line is emitted.
• Authentication credentials, session tokens, and API keys are masked in logs at the source.
• Body content of customer-uploaded files is never logged. Filenames, sizes, and processing outcomes are logged; payloads are not.
• Logs are retained for the minimum period required for operational and audit purposes, typically 90 days for debug-level logs and one year for security-relevant events, and then deleted.

08Sub-processors

TraCarta uses a small number of sub-processors to operate the platform. Each is bound by data-processing terms consistent with this document and is subject to annual security review. The current list:

The named entities providing these services are listed in our sub-processor schedule, available to active customers on request. We will provide thirty days’ written notice before adding or replacing a sub-processor in a category that handles customer PII, and customers may object to changes that materially affect their risk posture.

09Retention & deletion

PII retention follows the same windows as the broader retention policy in our Privacy Policy, Section 06. The two operational points worth restating here:

• GST record retention. Section 36 of the GST Act 2017 requires retention of records for six years from the relevant filing year. PII embedded in those records is retained for the same window and cannot be deleted earlier.
• Deletion on termination. At the end of a customer engagement, the customer has ninety days to export their data through SkyBoard. After ninety days, records are deleted, except those statute requires us to retain. Where deletion is technically impractical (for example, in tamper-evident audit logs), the records are irreversibly anonymised.

10Incident response

Our incident-response process is built around honest disclosure and rapid containment:

• Detection. Continuous monitoring of access patterns, anomaly detection on data egress, and alerting on access to sensitive records outside approved windows.
• Containment. On suspected breach involving customer PII, affected access paths are revoked within one hour of confirmation while investigation proceeds.
• Customer notification. Where we act as a processor and an incident involves a customer’s data, we notify the customer within 24 hours of confirmed scope.
• Regulator notification. Where the Digital Personal Data Protection Act 2023 requires notification to the Data Protection Board of India, we will notify within 72 hours.
• Post-incident review. Every confirmed incident is the subject of a written post-incident review, including root cause, scope, remediation, and what we changed structurally so the same class of incident cannot recur. The review is shared with affected customers.

11Assurance & review

This document describes the operating discipline. The practice is verified externally and internally:

• Annual third-party penetration test. Conducted against production systems by an independent firm. Summary findings and remediation status are available under NDA to active customers.
• Annual internal audit. Against this document and the Privacy Policy. Conducted by personnel independent of the team operating the platform.
• Customer right to audit. Where a customer’s contract includes audit rights, those rights are honoured on reasonable notice and at the customer’s expense.
• Document review. This document is reviewed at least annually and on any material change to our operating practice.