What Ahmedabad Businesses Get Wrong About IT Compliance Under India’s DPDP Act

The Digital Personal Data Protection Rules were notified in November 2025, and 2026 has turned out to be the year most Indian businesses were told to treat as their runway — build the systems, fix the processes, get ready before enforcement actually bites in 2027. Ahmedabad’s business community, spread across manufacturing, textiles, pharma, fintech and a genuinely large IT/ITeS base, has mostly heard the headline. What’s less consistent is whether the actual IT and process changes underneath that headline have happened, or whether the compliance conversation stopped at updating a privacy policy page and calling it done.

Having sat through enough of these conversations with local businesses, a handful of misunderstandings show up again and again. None of them are exotic — they’re mostly a mix of wishful thinking and genuinely reasonable assumptions that just happen to be wrong.

“We have time, so we don’t need to start yet”

It’s true that penalties and the harder enforcement provisions phase in through mid-2027, and it’s true that as of now the Data Protection Board hasn’t issued fines under the Act. That gap has quietly become the biggest reason Ahmedabad SMEs deprioritise DPDP work — a law with no visible enforcement yet doesn’t feel urgent next to a delivery deadline or a GST filing. The trouble is that the actual work — mapping where personal data lives, fixing consent flows, cleaning up vendor contracts, building IT breach response processes — takes months to do properly, not weeks. Businesses that wait until enforcement is visible will be trying to compress a year of process change into whatever runway is left, usually under pressure and usually badly.

“Updating the privacy policy on our website covers it”

This is probably the single most common gap seen across small and mid-sized Ahmedabad businesses. A privacy policy is a notice, not a system. DPDP compliance actually requires the consent, logging, retention and access-control mechanics behind that notice to function the way the document claims they do. A company that’s rewritten its privacy policy but still collects data through a pre-checked form, retains customer records indefinitely with no deletion process, or has no real way to log and honour a request to correct or erase someone’s data hasn’t done the underlying work — it’s done the paperwork around the work.

“DPDP is a legal problem, so IT doesn’t need to be involved”

This assumption causes more rework than almost any other. Consent has to be captured and logged somewhere technical. Data has to be findable, correctable and deletable across whatever systems actually store it — CRM, HR software, accounting tools, marketing platforms, sometimes an old server nobody’s audited in years. None of that is a legal team’s job to build; it’s an IT function, and it usually touches more systems than a first pass assumes. Businesses that treat DPDP purely as a legal exercise typically discover, months in, that their actual data footprint is far messier than the policy document implies, because nobody with technical visibility was in the room when the policy was written.

“All personal data must be deleted after one year”

This particular misreading comes from the Rules’ requirement to retain certain logs and audit trails for at least a year, which has been misread by a fair number of businesses as a blanket one-year deletion rule for all personal data. It isn’t. Retention periods depend on the purpose the data was collected for, and what actually matters to a regulator is that the business has a documented, consistently applied retention policy — not that everything gets purged on a fixed clock. Getting this backwards leads to two equally bad outcomes: businesses either delete records they were legally entitled to keep, or panic and build no retention discipline at all because the rule seemed too rigid to follow.

“Our IT vendor’s contract already covers this”

A lot of Ahmedabad businesses run core systems — accounting, payroll, customer data, sometimes production systems — through third-party vendors or an outsourced IT provider, and assume the vendor agreement already accounts for DPDP obligations because it mentions “data security” somewhere. Under the Act, the business collecting the data remains accountable as the data fiduciary regardless of what a vendor’s contract says, and vague, outdated vendor agreements with unclear breach-responsibility clauses are consistently flagged as one of the more damaging gaps businesses carry into an audit. Vendor contracts need to be reviewed specifically against DPDP obligations, not assumed to already cover them because they’re recent or from a reputable provider.

This is also where a locally engaged IT partner earns its keep over a generic vendor relationship — someone who actually understands your systems can tell you honestly where personal data sits and where the gaps are, rather than pointing back at a service agreement that was never written with DPDP in mind. It’s a conversation TechMonarch has increasingly with Ahmedabad clients who assumed their existing IT setup already had this covered and were surprised to learn it didn’t. In most cases the fix isn’t dramatic — clearer data-processing clauses, a defined breach-notification timeline, an actual record of which vendor touches which category of data — but it has to be done deliberately rather than assumed.

“This is a one-time project, not an ongoing responsibility”

Businesses that treat DPDP as a project — do the audit, update the policy, tick the box, move on — tend to drift out of compliance within a year, simply because systems change. A new CRM gets adopted, a new marketing tool starts capturing form data, an employee starts using a personal device for work data, and none of it gets checked against the original compliance work because nobody owns that ongoing review. The Rules effectively expect continuous governance — periodic assessments, updated consent mechanisms as systems change, and someone internally responsible for noticing when a new tool or process introduces a new data-handling gap. For a smaller Ahmedabad business without a dedicated compliance or privacy role, this usually means assigning the responsibility explicitly to someone, even part-time, rather than assuming it’s already covered by whoever handled the initial policy update.

Where the actual risk sits

None of these mistakes are unique to Ahmedabad, but the concentration of SMEs and mid-sized manufacturing and IT businesses in the city means a lot of local companies are making them simultaneously, without much local peer pressure to fix them yet. The businesses that get ahead of this aren’t necessarily the ones spending the most on compliance tools — they’re the ones who treated it early as a genuine IT and process exercise rather than a document to be filed away. Given how many enterprise and international clients now ask about data governance before signing a vendor agreement, that groundwork tends to pay for itself well before any regulator gets involved.

A reasonable starting point, for a business that hasn’t done much beyond the policy update, is a basic data inventory: what personal data actually gets collected, where it lives across your systems, who has access to it, and how long it’s kept. That single exercise tends to surface most of the gaps described above on its own, well before any consultant, audit, or regulator points them out.