Security and data
Security and data handling for tender and bid data
What your team shortlists, declines and bids is commercial intelligence. It stays in India, each client is isolated by the database itself, nothing you give us trains a model, and a source that goes quiet raises an alert within hours.
- Where it sits
- The database is in Mumbai and the functions that read it are pinned to the same region. Nightly backups go to object storage in Hyderabad. Your rules, matches and decisions do not leave India in the ordinary course of running the service.
- How long we keep it
- Tenders that never matched anyone are deleted after 90 days. Your matches, decisions and rules are kept while you are a customer. ScanX AI chats are deleted 90 days after their last message and are left out of backups, so a deleted chat does not survive in one.
- What we never store
- Copies of portal pages or bid PDFs. We keep structured facts, the source link and the exact span of text that caused a match. When a row looks wrong we re-fetch the source rather than consult a copy.
- Who can see a shortlist
- Row level security in the database decides what each session can read and change. The dashboard connects as a role that owns nothing, every request carries a verified identity, and every write is checked twice: by the route, and again by the database policy, so one client's team can never read or change another's rows.
- Signing in
- Named accounts on Team and Group, with roles on Group, and two step verification for administrators who need it. No self sign up and no password reset by email, so there is no email route to take over an account. Every administrative action is recorded. Desk uses one rate limited team sign in.
- The web application
- A strict content security policy with a fresh nonce on every response, HSTS with preload, framing refused, cross site requests to any action refused before they are read, and error messages that never carry database detail to the browser.
- AI providers
- Model calls go only to named hosts that keep no data, with data collection refused and fallback routing off. People's names are replaced with placeholders before anything reaches a model. Nothing you give us trains any model.
Silence is treated as a failure
A portal that returns nothing and a portal that is broken look identical downstream. Each source is judged on its extraction rate, the share of rows it parsed, against its own normal rate, not on how many rows it returned. A source quiet for three hours raises an alert to us, once per episode.
An external uptime check watches the service from outside the server, cron monitors confirm every backup ran, and a check after each run confirms the dashboard actually picked up its new matches.
The backup has been restored, not just taken
Backups run nightly at 02:30 IST and are uploaded with a credential that can write but cannot read, list or delete, so a compromised server cannot touch the backup history. On 9 September 2026 one was restored into a clean PostgreSQL 17 instance and checked: 15,299 tenders and 612 matches, all present.
On 21 September 2026 the collector's test suite passed 1,099 tests and the dashboard's 1,596, against a real database rather than mocks, and every change runs them before it ships.
Where the tender data comes from
Everything ScanX reads is published openly by the Government of India and its enterprises for anyone to read. Each adapter records the portal's reuse terms, and CPPP is attributed as its terms require.