Built from the ground up for DPDP 2023, with JWT auth, bcrypt passwords, row-level tenant isolation, and encrypted offline storage.
JWT HS256 tokens with a 2-hour expiry and secure refresh-token rotation. Passwords are hashed with bcrypt (cost factor 12), API keys are bcrypt-hashed before storage, and enumerator sessions time out after 30 minutes of inactivity.
Every form carries a consent-tracking field and purpose declaration meeting Section 6's free, specific, informed consent standard. All data changes write to full audit logs, and a data-erasure endpoint anonymizes data_json on request to honour a Data Principal's right to correction and erasure — built end-to-end for India's Digital Personal Data Protection Act 2023. See the full clause-by-clause DPDP compliance mapping →
Offline data lives in the browser's OPFS (Chrome/Android) or IndexedDB (Safari/iOS) — never in localStorage or plain cookies. It is bound to its origin and inaccessible to other sites, syncs over HTTPS with TLS 1.3, and is never written to disk unencrypted.
A 4-tier role hierarchy (master_admin → org_admin → supervisor → enumerator) with tenant isolation enforced by SQLAlchemy row-level security on every query. Enumerators see only their assigned forms, supervisors only their tenant's submissions, and cross-tenant leakage is blocked at the database layer.
Photos and audio are stored on private VPS storage — not in public cloud buckets or S3 public URLs. Downloads use presigned URLs with a short TTL, filenames carry a non-guessable UUID, and files sit outside the web root so they can't be browsed directly.
Every status change (flag / approve / reject) is logged with a timestamp, actor ID, and previous state. The submission-history panel is visible to supervisors, entries are append-only and non-repudiable, and the full log exports alongside submission data.
India's Digital Personal Data Protection Act 2023 (DPDP Act) is the law that says: only collect the personal data you actually need, tell people clearly why you're collecting it, get their real consent, let them see or delete their own data if they ask, and report it fast if there's ever a breach.
FieldGovern is built so a research team can say yes to all of that without hiring a compliance team — consent is captured on the form itself, deletion is one click, and everything is logged automatically.
Row-level security means one organisation's data is physically walled off from another's inside the same database — not just hidden in the app, blocked at the database itself. Encryption means your data is scrambled into unreadable text both while it travels over the internet and (for offline devices) while it sits on a phone or laptop, so even a stolen device or an intercepted connection reveals nothing.
Under the DPDP Act, FieldGovern's customers act as the Data Fiduciary (the entity that determines the purpose and means of processing), respondents are Data Principals, and FieldGovern itself acts as a data processor bound by a written Data Processing Agreement (DPA). Core obligations mapped into the platform: Section 6 consent (free, specific, informed, unconditional, and revocable), Section 8 purpose and storage limitation, Section 8(5) breach notification to the Data Protection Board of India and affected Data Principals, Section 9 verifiable parental consent for minors' data, and Sections 11–13 rights to access, correction, erasure and grievance redressal.
Multi-tenant isolation is enforced with Postgres row-level security (RLS) policies bound to a restricted, non-superuser database role — every query is scoped by tenant_id at the database engine, not filtered only in application code, so a bug in application logic can't leak cross-tenant data. Data in transit uses TLS 1.2+ with HSTS; passwords use bcrypt hashing (cost factor 12); session tokens use JWT signed with HS256; offline records are held in the browser's sandboxed OPFS/IndexedDB, origin-isolated and inaccessible cross-site.
Read the full DPDP Act 2023 compliance mapping, our Trust Centre, or the Data Processing Agreement template.
FieldGovern is built DPDP-aligned by design: every form captures free, specific, informed consent with a timestamped audit trail; personal data can be localised to servers in India; row-level security enforces purpose and access limitation at the database layer; and a data-erasure endpoint lets a Data Fiduciary honour a Data Principal's right to correction and erasure under Sections 11–13. See the full clause-by-clause DPDP compliance mapping for section-by-section detail.
Data in transit is encrypted with TLS 1.2+/HSTS end to end. Passwords are hashed with bcrypt (never stored in plaintext), API keys are bcrypt-hashed before storage, and JWT HS256 signs every session token. Offline data on an enumerator's device lives in the browser's sandboxed OPFS or IndexedDB storage, never in plain cookies or localStorage.
All submission data is stored on an India-based VPS. We do not use third-party cloud databases (AWS RDS, Google Cloud SQL, etc.). Media files (photos, audio) are stored on private server storage — not in public S3 buckets or CDN.
No. Row-level security is enforced at the SQLAlchemy query layer — every database query includes a tenant_id filter. Additionally, enumerators can only see forms assigned to them and their own submitted records. Supervisors can see all submissions within their organization only.
FieldGovern provides an erasure endpoint designed to meet DPDP's data-erasure expectations. When called, it anonymizes the data_json field for a given submission — replacing identifiable fields with null values while preserving the submission record for audit purposes. The action is logged in the audit trail with actor and timestamp.
Offline data is stored in the browser's OPFS (Chrome/Android) or IndexedDB (Safari/iOS). These are sandboxed storage APIs — other websites cannot access them. When the enumerator syncs, data is transmitted over HTTPS and then cleared from local storage. If a device is lost before sync, only locally-captured unsynced records are at risk.
Yes. API keys are bcrypt-hashed before storage — the plaintext key is shown once at creation and never stored. This means even a database breach would not expose usable API keys. Keys can be revoked instantly from the Org Admin panel.
Questions about compliance or data residency? Talk to us.
Contact Us →