Compliance
12 regimes that decide how the software gets built.
Not a compliance checklist. What each Indian regulation actually requires of a system — the retention, the audit trail, the consent model, the hosting decision — and the mistake we see most often against each one.
- Regimes covered
- 12Regimes covered
- Sectors mapped
- 10Sectors mapped
- When these are designed in
- Phase 2When these are designed in
The short answer
Indian enterprise software is shaped by a handful of regimes that are far cheaper to design for than to retrofit: DPDP for personal data, RBI outsourcing and payment data localisation for financial services, GST and e-way bills for anything moving goods, GFR and STQC for government buyers, and validated-system rules for pharma. Each one constrains architecture before it constrains process.
This page is about the rules you operate under. Our own security posture — access model, data handling, certifications and what a reviewer can ask for — is a separate page, because merging them produces one that answers neither question.
Digital Personal Data Protection Act 2023
India's personal data law. It governs consent, purpose limitation, retention and the rights of the individual whose data you hold.
What it requires of the software
- Consent has to be recorded as an artefact with a timestamp and a purpose, not implied by a ticked box in a form nobody kept.
- Erasure must reach every copy — including the analytics warehouse, the search index, the backups and any downstream report.
- Purpose limitation means a field collected for one reason cannot silently feed another, which constrains how a data platform is modelled.
- Breach notification obligations require you to know what was in a system at a point in time, which is a retention and logging design decision.
The mistake we see most
Implementing consent capture at the front door and nothing downstream. The regulation is satisfied at the point of collection and quietly broken everywhere the data was copied to — which is where a data-protection review actually looks.
RBI outsourcing directions
Rules governing how a regulated financial entity may use a technology vendor, and what it must retain control of when it does.
Where this comes up
What it requires of the software
- Audit rights have to be contractual and real: the regulated entity, and the regulator, must be able to inspect what the vendor does.
- Sub-processors must be disclosed. An undisclosed cloud service in the architecture is a finding.
- Exit has to be planned before it is needed — the material, the data and the runbooks a successor would require.
- Access is granted, never owned: the vendor works inside the client's accounts rather than holding infrastructure on their behalf.
The mistake we see most
Treating this as a procurement annexure rather than an architecture constraint. Audit rights and exit obligations decide where systems run and who holds the keys, and retrofitting them after go-live means rebuilding the access model.
Payment data localisation
RBI's 2018 circular requires payment system data to be stored only in India.
Where this comes up
What it requires of the software
- Cloud region selection is decided by this before any other consideration.
- Backups, disaster recovery and any cross-region replication must all stay in country.
- Analytics copies count. A warehouse in another region holding payment data is the same violation as the primary store.
- Managed services with opaque multi-region behaviour have to be assessed individually rather than assumed compliant.
The mistake we see most
Getting the primary database right and the disaster-recovery region wrong. It is the single most common thing a vendor without Indian BFSI experience misses, and it is the one an inspection finds.
NPCI certification
UPI, NACH and IMPS integrations are certified before they go live, not merely built.
Where this comes up
What it requires of the software
- The certification calendar sets the release date, not the sprint plan.
- Test environments and mandated scenarios are prescribed; you build to their harness rather than your own.
- Reconciliation and dispute handling are part of the certified scope, not features to add afterwards.
- Changes to a certified integration can require re-certification, which changes how the release process has to work.
The mistake we see most
Planning the launch date from the build estimate. The build is rarely the long pole — the certification slot is.
GST and e-way bills
Indirect tax, place-of-supply rules, e-invoicing and the e-way bills that accompany goods in transit.
What it requires of the software
- Place of supply decides the tax treatment, and it is derived from data an ERP has to model correctly — not a field somebody types.
- E-way bill generation has to happen at dispatch and reconcile against invoicing, or the mismatch surfaces at assessment months later.
- E-invoicing means an IRN round-trip inside the invoicing flow, with a failure path that does not lose the invoice.
- At high volume this stops being a form and becomes an integration with retry, idempotency and reconciliation requirements.
The mistake we see most
Treating e-way bill generation as a reporting step after invoicing. It travels with the goods, so a system that generates it late is a system that stops trucks.
GFR 2017, GeM and STQC
How a government body may buy software, and what it must be able to prove about it afterwards.
Where this comes up
What it requires of the software
- The evaluation matrix is published with the tender. A proposal that ignores its weighting loses on arithmetic rather than on merit.
- STQC certification is expected before a citizen-facing system goes live, and designing for it costs far less than retrofitting.
- Government workloads must sit on MeitY-empanelled infrastructure, which constrains architecture from the first design session.
- Audit trails have to survive a CAG or vigilance review, which is a retention and immutability requirement rather than a logging preference.
The mistake we see most
Bidding on capability and ignoring the eligibility floors. Turnover and headcount minimums are applied before any assessment of fit, and a strong response to a tender you are not eligible for is wasted work on both sides.
NABH and ABDM
Hospital accreditation record requirements, and the national health-data interoperability programme.
Where this comes up
What it requires of the software
- Record completeness and retention decide how clinical data is modelled and how long it stays retrievable.
- ABDM interoperability means health IDs, consent artefacts and registry integration for anything patient-facing.
- Consent under ABDM is its own artefact with its own lifecycle, separate from DPDP consent and not satisfied by it.
- Accreditation audits ask for evidence out of the system, so reporting is a deliverable rather than a later phase.
The mistake we see most
Building ABDM integration as an add-on to an existing patient record. The consent and identity model has to sit underneath the record, not beside it.
21 CFR Part 11 and CDSCO validation
Electronic records, electronic signatures and computerised system validation for regulated pharmaceutical and life-sciences processes.
What it requires of the software
- Audit trails must be immutable and attributable, which is a storage and access-control design decision taken in the first phase.
- Change control is validated: a deployment process that cannot evidence what changed and who approved it fails the inspection, not the test suite.
- IQ/OQ/PQ evidence is produced as a deliverable alongside the software rather than assembled afterwards.
- Any interface into a validated system inherits part of the validation envelope.
The mistake we see most
Scheduling validation as a workstream after go-live. Validation is not documentation of a finished system — it is a constraint on how the system is built, and retrofitting it usually means rebuilding the audit and change-control layers.
IFSCA (GIFT City)
The regime governing financial entities operating from GIFT City, distinct from mainland RBI and SEBI regulation.
Where this comes up
What it requires of the software
- Permitted activities, reporting and data expectations differ from the mainland regime — assuming RBI rules produces a system that is wrong in ways only an inspection surfaces.
- Reporting obligations are to IFSCA rather than to the mainland regulator, on a different schedule and format.
- Cross-border data flows are treated differently from mainland payment data, which changes the hosting decision.
The mistake we see most
Reusing a mainland BFSI architecture unchanged. The two regimes look similar from outside and diverge exactly where it is expensive to be wrong.
RERA
Project registration and periodic reporting for real-estate developers, administered separately by each state.
What it requires of the software
- Reporting is per project and per state portal, so a developer with projects in three states is filing into three systems on three calendars.
- The source data spans construction progress, sales and finance — usually three systems that were never reconciled.
- Filing accuracy is enforced, so the reporting layer needs a reviewable trail back to the underlying records.
The mistake we see most
Building a reporting screen without solving the reconciliation underneath it. The filing is the easy half; agreeing what the number is across three systems is the project.
CEA metering and RDSS
Metering, data retention and distribution-reform reporting obligations for power utilities.
Where this comes up
What it requires of the software
- Metering regulations decide what a utility's data layer must retain and for how long.
- RDSS ties funding to loss-reduction evidence, which has to come out of systems not designed to produce it.
- Reconciliation across generation, transmission and billing is the hard part, and it is where the reporting obligation actually bites.
The mistake we see most
Treating the reporting requirement as a dashboard. The obligation is evidentiary, so the data model has to support proving a number, not just displaying it.
MSME and Udyam
Registration-linked benefits and the statutory payment timeline under the MSMED Act.
Where this comes up
What it requires of the software
- The 45-day payment rule changes how vendor ageing and payables have to be modelled and reported.
- Supplier classification has to be captured and kept current, because the obligation depends on it.
- Disclosure requirements draw on payables data that most systems hold but few report on correctly.
The mistake we see most
Holding supplier MSME status as a static flag set at onboarding. It changes, and the obligation follows the current status rather than the recorded one.
By sector
The same rules, indexed the other way.
If you would rather start from your industry than from a regulation, every sector page lists the regimes that shape a build there — and each city page adds the state-level ones.
Before you ask
Questions about compliance work.
Do you handle compliance, or do we?
You own the obligation; we build a system that can meet it and evidence it. The distinction matters in a review — a vendor claiming to 'ensure compliance' is claiming something it has no standing to promise. What we commit to is that retention, audit trails, consent and reporting are designed in the Define phase rather than added after go-live.
Which of these applies to us?
Usually three or four at once, and the combination is what makes it hard. A lending platform in Mumbai carries RBI outsourcing directions, payment data localisation, DPDP and NPCI certification simultaneously, and they constrain each other. Discovery maps which apply before any architecture is proposed.
Is this page a substitute for legal advice?
No. This is what each regime means for software design, written by engineers who have built inside these constraints. Your compliance function and your counsel decide what the obligation is; this describes what meeting it does to an architecture.
What is the most common compliance mistake you see?
Sequencing. Almost every regime here is cheaper to design for than to retrofit, and almost every project treats it as a phase near the end. Audit trails, consent models and data residency are structural — changing them late means changing the data model, the access model and the deployment process at once.
Next step
Which of these apply to you?
Discovery maps the regimes in scope before any architecture is proposed, because they decide it. You keep that map whether or not we build.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything