Trust & compliance
Compliance & security
NRD is designed from the ground up for the regulatory environment that Indian insurers operate in. What follows is not a checklist — it is how the system is built.
Built for a regulated buyer
India-resident · audit-logged · isolatedData stays in India
All claimant data is processed and stored in India (the AWS Mumbai region), with consent tracking, automatic deletion after set periods, and a 72-hour breach process.
DPDPA 2023Government security standard
Logs kept 180 days, incidents reported within 6 hours, clocks synced to an official time source, and continuous monitoring.
CERT-In 2022Encrypted, a key per insurer
Bank-grade encryption. Each insurer's records are locked with its own key, in write-once storage that can't be altered.
AES-256 · WORMEach insurer walled off
One insurer's claim file can never be read by another. Insurer and lawyer work stay on separate tracks — enforced, not promised.
per-insurerChain of custody
Every retrieved document carries a tamper-proof, timestamped certificate that stands up in court.
BSA S.63India's data-protection law
DPDPA India’s Digital Personal Data Protection Act, 2023 says personal data must be used lawfully, only for a clear purpose, and kept only as long as it's needed. We built NRD around exactly those rules.
-
Your data stays in India
Claimant data is stored and processed in the AWS Mumbai region. Names, IDs and raw records never leave the country.
-
Consent is captured up front
When a claim comes in, we record the person’s consent and what the data is for. That purpose can’t change without asking again.
-
Kept only as long as needed
Active claim records are held for 7 years (the standard limitation period), then deleted on schedule — with every deletion logged.
-
Fast breach reporting
If a breach is detected, an incident workflow starts at once and the required notice goes out within 72 hours of confirmation.
Illustrative — personal data is processed and stored in the AWS Mumbai region.
One honest detail. Personal data stays in India. To read and summarise a claim, NRD sends only de-identified text — never names or IDs — to the AI model, and that model may run in another AWS region. The raw records themselves never leave India.
Meeting India's security directions
CERT-In India’s government cybersecurity authority (Computer Emergency Response Team) requires companies to keep detailed logs, report incidents fast, and keep their clocks accurate. NRD does this in the way the system actually runs — not just on paper.
-
Logs kept for 180 days
System and access logs — who did what, and when — are kept for at least 180 days in storage that shows if anyone tampers with it.
-
Incidents reported within 6 hours
Any qualifying security incident starts the reporting workflow. The 6-hour clock is tracked automatically from the moment we detect it.
-
Clocks synced to official time
Everything runs on clocks tied to an official time source, so the timestamps on certificates and audit records are trustworthy.
-
Watched around the clock
Automated alarms and log analysis run continuously. Anything unusual pages an on-call engineer within minutes.
Something looks wrong. The incident workflow kicks off automatically.
The 6-hour reporting window is tracked from the first confirmed signal.
Notice reaches India's cyber authority — comfortably inside 6 hours.
Illustrative timing — the reporting clock is tracked automatically from the moment we confirm an incident.
Locked down, and unchangeable once saved
Records are scrambled with bank-grade encryption bank-grade encryption (AES-256) , and each insurer gets its own key — managed by a separate key service the system that manages encryption keys, with a separate key per insurer . The audit trail uses write-once storage write-once storage — records can’t be changed or deleted once saved , so once a record is written it can't be altered or deleted.
Scrambled where it sits
Every stored record is encrypted with that insurer’s own key. Nobody without the key can read it.
Can’t be changed later
The audit trail is write-once storage — records can’t be edited or deleted for as long as the law requires them.
Scrambled on the move
Every connection uses modern encryption. Old, weak standards are refused outright.
Only Insurer A's key opens Insurer A's record. No shared master key.
Illustrative — each insurer gets its own key, and records can't be changed once saved.
Every insurer walled off from every other
Each insurer's data is completely walled off each insurer’s data kept completely walled off from every other insurer — one insurer can never read another's claims. The insurer side and the lawyer side also run on separate tracks insurer and lawyer workflows run on separate tracks that never mix ; they only meet at the moment records are officially handed over, and every hand-off is logged.
-
A separate key per insurer
One insurer’s key can’t open another’s records — even where the same software serves both.
-
Records tagged by insurer
Every record is stamped with which insurer it belongs to, and the system blocks any attempt to read across that line.
-
Separate storage per insurer
Each insurer’s documents live in their own storage area, closed off to everyone else.
-
Two separate lanes
The insurer side and the lawyer side use different screens, data and permissions. They meet only through clear, logged hand-offs.
Its key can't open anyone else's records.
Its key can't open anyone else's records.
Builds the claim file. Its own screens and rules.
gate every crossing logged
Sends records in. Its own separate track.
The two lanes only meet at the gate — and every hand-off is recorded.
Illustrative — each insurer runs on its own walled-off track with its own key and storage.
Every document, provably itself.
From the moment a record is retrieved, NRD hashes it, timestamps it, and locks it. If a single byte changes, the certificate breaks. You can hand it to a tribunal and prove it is the original — admissible under the Bharatiya Sakshya Adhiniyam, Section 63.
Verifiable · timestamped · locked 7 yearsSub-processor list
These are the outside services we rely on. The list is short and fixed. Each one is bound by a data-processing agreement, and — apart from de-identified text sent to the AI model — personal data stays in the AWS Mumbai region.
| Sub-processor | Purpose | Location | Personal data |
|---|---|---|---|
| Amazon Web Services (AWS) | Runs the system: computing, storage, database, keys, email, logs | Mumbai, India | Yes — main service, all in India |
| AWS Bedrock (AI model) | Reads and summarises claim documents | India, or another AWS region for the AI step | De-identified text only — never names or IDs |
| Google Fonts | Delivers fonts for this marketing website only | Global | IP address (logging turned off) |
| Twilio / WhatsApp Business | How lawyers send in record requests | India | Phone number, message text |
Sub-processor list last updated 2026-05-22. Changes are notified to customers with 30 days' notice.
Need a full security overview for your InfoSec team? Security overview available on request — contact us.
Talk to us about your compliance requirements.
We'll walk your InfoSec and legal teams through the architecture.