Aadhaar, PAN, and GSTIN records need their own DLP rules - here's how Custelis handles them
Client financials, KYC scans, and tax filings all pass through your team's laptops carrying Aadhaar numbers, PAN details, and GSTIN records that don't exist in a US or EU-built monitoring tool's threat model. Custelis lets you classify them explicitly and enforce real DLP rules around them - warn, block, or require approval before they leave.
What this actually is - and isn't
We won't claim Custelis scans file contents for Aadhaar or PAN numbers, because it doesn't. The monitoring agent never uploads raw file content or the file path to our servers - a file's path is hashed on the device before anything is stored, and the content itself is never captured at all. That's a deliberate privacy commitment, not a gap we're working around. It also means no vendor honestly selling "automatic Aadhaar-number detection inside your files" is doing it without either reading those files' contents on a server somewhere, or running fragile, false-positive-prone local pattern matching. We'd rather tell you what's real.
What Custelis does instead: you classify a client engagement, folder, or record type as Aadhaar, PAN, or GSTIN-linked once - the same way you'd tag anything else "Client Confidential" in the client-data registry - and from that point on, the same rule engine that runs every other DLP policy in Custelis enforces it. No content scanning required, because the classification comes from a person who already knows what the data is, not a guess from a filename.
How a rule actually runs
| Step | What happens |
|---|---|
| 1. Classify | Tag the client engagement, folder, or record type as Aadhaar / PAN / GSTIN-linked in the client-data registry - a one-time setup step, done by a partner or IT lead. |
| 2. Define the rule | Build a DLP rule scoped to that classification: who it applies to, where it's allowed to go, and what happens if someone tries to move it somewhere it shouldn't. |
| 3. Enforce | The next time a matching record moves toward personal webmail, an unmanaged cloud drive, or a USB device, the rule fires: log it, warn the employee before it sends, block it outright, or require approval from a partner first. |
| 4. Review | Every match is logged as a DLP event with full context - who, what classification, where it was headed, what action was taken - visible in the same DLP events log as every other rule. |
Why classification beats content-scanning for this specific case
No false positives from format-matching
A 12-digit number that looks like an Aadhaar number often isn't one. Pattern-matching against file content produces a steady stream of false warnings; classifying the engagement itself doesn't.
Nothing sensitive has to leave the device
Content-scanning approaches usually mean uploading file content, or at least a hash of it, to a server for inspection. Custelis's architecture never receives raw content in the first place - there's nothing to leak from us.
The person who knows the data classifies it
A partner or engagement lead already knows which client folder holds Aadhaar-linked KYC scans. That's a better source of truth than a regex guessing from a filename.
Where this fits your existing setup: this uses the exact same client-data registry and DLP rule engine described on the CA and audit firm page - Aadhaar/PAN/GSTIN is a classification you apply within it, not a separate product or a higher pricing tier.
Setting this up
From your DLP policy screen: create a rule, set its "what" clause to your Aadhaar/PAN/GSTIN classification, choose the destinations you want restricted (personal webmail, unmanaged cloud storage, USB), and pick an action. Start with warn while you establish a baseline, then move to block or require approval once you've confirmed the rule isn't catching legitimate workflow. See the full DLP model on the DPDP-readiness guide.
Set up your first Aadhaar/PAN/GSTIN rule
No credit card to start. Intrusive features stay off until your own DPIA is recorded.
Try for free