Without copying any of it. We read the catalogue your systems already publish — table names, column names, types — and never a row.
Every DPDP obligation rests on knowing where personal data sits. You cannot answer an access request in a system you forgot, erase from a table nobody documented, or scope a breach across an estate you last mapped in a spreadsheet eighteen months ago.
We connect to each system and read its structure. What comes back is a list of tables and columns — the raw material of your data map, gathered in minutes rather than by interviewing every department.
Column names suggest what they hold: patient_mobile looks like a contact
number. We propose, your team confirms one column at a time. Nothing is classified as
personal data because software guessed.
Re-run the read and new columns surface as changes to review. A map built once decays; this is the part that keeps the record of processing honest a year later.
For a database, we query the information schema — the catalogue the database keeps about itself. Not the tables. This is a structural limit rather than a policy we promise to keep.
RuleExpertappointments, patientsmobile_no, dob, aadhaar_last4varchar, date, intYour systems stay where they are. We hold a description of them, which is why a compliance tool does not become another place your data can leak from.
Systems differ enormously in what they do and very little in how they let you read their structure. We build to the shape, which is why the fifth system of a given kind costs nothing to add.
PostgreSQL and Microsoft SQL Server today — between them, most hospital, ERP and line-of-business systems running in India. We read the information schema over a read-only login.
S3 and anything S3-compatible. We list what buckets and prefixes exist and how objects are named — enough to find the scan archive nobody had written down.
Zoho and HubSpot today, and the pattern generalises: authenticate, ask the tool which objects and fields it holds, take the field list. Most business SaaS answers that question the same way.
Some things cannot be queried and still hold personal data — a CCTV estate is the one every hospital forgets. Those are declared rather than connected: site, camera count, retention, whether minors are in frame. It enters the same register.
Everything else — paper registers, a departmental spreadsheet, a legacy system with no interface — is entered directly or imported from CSV. A map that only contains what happens to be machine-readable is not a map of your organisation.
A connector has to do three things: check the credentials work, list what structures exist, and describe itself back to you without ever echoing a secret. That is a small, fixed shape — the ones we already run are between twenty-eight and forty-six lines each.
So when a system is missing, the honest estimate is days of our engineering time, not a quarter of roadmap. Tell us what you run at the discovery stage and it is scoped then, before you have committed to anything.
We build it — it is not something you are expected to write against a public SDK.
Most organisations underestimate their estate by a factor of two. Bring the list you have and we will tell you which of it we can read today and which needs new connectors.
The most common reason a compliance project stalls is that it turns into an engineering project nobody scheduled. This one should cost your team an afternoon.
Per system, scoped to read the catalogue. No schema changes, no agent installed on your servers, nothing deployed into your environment.
Outbound from us to the system, or a scheduled read from inside your network where the system is not reachable from outside.
The one part that genuinely needs your people: confirming what each column holds. It is reviewed column by column, and it is the difference between a real register and a guess.
Encrypted at rest with AES-256-GCM, decrypted only for the moment a read runs, never written to a log, and wiped when you revoke the connection. What you can see afterwards is a summary — host, database, user — never the secret you typed.
If you came here expecting an API reference, we do not publish one, and that is deliberate. RuleExpert is bought by a DPO and run by a compliance team. A product that needs your engineers before it does anything useful has moved the work rather than removed it.
The single exception is consent capture on your own website, which genuinely has to live in your page. That is a script tag and a three kilobyte file — no framework, no build step, no dependency on anything of ours at runtime.
Building against our API is possible for enterprise work, and it is a conversation rather than a self-serve portal.
No, and not because we promise not to. For a database we query the information schema, which is the catalogue the database maintains about itself — table names, column names, data types. The read never touches a user table, so there is no row for us to return. For object storage we list bucket and object names, not object contents. For a SaaS tool we ask which fields exist, not what is in them. If you want to verify that rather than take it on trust, point the connection at a test instance first and watch what comes back.
No agent, no software in your environment, no schema changes. You issue a read-only credential and allow the connection. Where a system is not reachable from outside your network — which is normal for hospital systems — the read is scheduled from inside instead, and the same rule applies to what it sends back.
Then we build one, and the honest estimate is days rather than a roadmap item. A connector has to check credentials, list what exists and describe itself safely — the ones already running are under fifty lines each. Say what you run during discovery and it gets scoped before you commit to anything. What we will not do is pretend a system is supported and find out during implementation that it is not.
Encrypted at rest with AES-256-GCM on infrastructure in India, decrypted only for the moment a read runs, and wiped when you revoke the connection. It is never written to a log — the summary shown back in the product is host, database and user, never the secret. Revoking is immediate and does not delete the map already built.
Not publicly, and we would rather say that than list one we do not maintain. The product is built so that a compliance team can run it without engineering support, and the only thing that has to live in your codebase is the consent widget — a script tag and three kilobytes. If you have an enterprise case for programmatic access, it is a conversation with us rather than a portal you sign up to.
As often as you want it to, and the point is that it is repeatable. A data map built by interview is accurate on the day it is finished and wrong within a quarter. Re-reading the structure surfaces new tables and columns as changes to review, so the register stays defensible rather than becoming a document you dread being asked about.
Real client quotes, attributed by role and sector — we never name a client.
Working across
Discovery usually finds the ones you did not. That is the point of it, and it is the fastest way to see whether any of this fits your estate.
Thank you — we have it. Someone will reply by email, usually within one working day.
Nothing else is needed from you. If it is urgent, email tushar@ruleexpert.com and it will reach the same people.