
In November 2025, the Indian government notified the Digital Personal Data Protection Rules under the DPDPA 2023. Most Indian businesses heard about it, filed it under “something to deal with later,” and moved on.
If your business runs on a Linux server — and that server holds customer data, employee records, or any personal information belonging to Indian citizens — “later” has arrived.
Here is what the law actually requires, what it means for your Linux infrastructure specifically, and what you need to have in place before an audit or a breach forces the issue.
The Digital Personal Data Protection Act 2023 and the Rules notified in November 2025 place compliance obligations on any organisation that collects, stores, or processes personal data of Indian citizens — regardless of where the organisation is based or where the data is stored.
Personal data under the Act means any data that can identify a person. Names, phone numbers, email addresses, customer records, employee data, transaction histories — all of it.
The Act designates your organisation as a Data Fiduciary. The obligations that come with that designation are specific and documented. The ones most relevant to Linux server owners are these:
You can only process personal data for the purpose it was collected. Customer billing data cannot be repurposed for marketing without fresh consent. Employee records cannot be used for anything beyond employment-related purposes. The data on your server needs a documented purpose — not an assumed one.
You should only hold data that is necessary for the stated purpose. If your server has been running for 3 years, there is almost certainly data sitting in databases or log files that serves no current operational purpose. Under the DPDP Rules, holding data without justification is a compliance gap — not a neutral state.
The Rules require Data Fiduciaries to implement reasonable security safeguards to prevent personal data breaches. The Act does not prescribe a specific technical standard — but “reasonable” in the context of a 2026 regulatory environment means, at minimum: access controls, patch management, and the ability to detect and respond to unauthorised access.
An unpatched Linux kernel with known CVEs is not a reasonable security safeguard. An active SSH key belonging to a former employee is not a reasonable security safeguard. A backup that has not been tested in six months is not a reasonable security safeguard.
If a personal data breach occurs, the Data Protection Board of India and the affected data principals must be notified. The Rules specify the notification timeline and content. You cannot notify effectively if you do not know a breach has occurred — which means monitoring is not optional under DPDP. It is a compliance requirement.
Indian citizens whose data you hold have rights under the Act: access, correction, erasure, and grievance redressal. You need a documented process for handling these requests and a named grievance officer. You also need to be able to actually locate and delete specific personal data when requested — which requires knowing where it is stored on your server.
The DPDP Rules do not mention Linux. They do not mention servers at all. They are technology-neutral. But the practical compliance obligations land squarely on whoever manages the server where personal data lives.
Most Indian SMEs running Linux servers have customer data in a MySQL or MariaDB database, employee records in an ERP or HR system, transaction logs that accumulate indefinitely, and application logs that may capture personal data incidentally. All of it sits on a Linux server. All of it is in scope under DPDP.
You need to know who has access to the server and the data on it. That means a current inventory of user accounts, SSH keys, and database credentials — not a list from when the server was set up, but a verified current state. Under DPDP, you need to be able to demonstrate that access to personal data is limited to authorised personnel with a documented business reason.
In 25 years of auditing Linux servers in Mumbai, the single most common finding is active credentials belonging to people who left the organisation months or years ago. A former developer’s SSH key with root access is not just a security problem. Under DPDP, it is a documented compliance failure.
The “reasonable security safeguards” standard requires demonstrable action. A documented monthly patching cycle — kernel updates, package updates, CVE tracking — is the evidence that reasonable safeguards exist. An unpatched server is not just a security risk. It is a compliance gap with a paper trail that leads directly to the organisation’s liability.
You need to know what personal data is on the server, where it is stored, what it is used for, and how long it is retained. Most Indian SMEs have no formal data inventory. The DPDP Rules make this a requirement, not a best practice. Without it, you cannot demonstrate purpose limitation, respond to erasure requests, or notify affected individuals after a breach.
You cannot notify a breach you do not know about. Continuous monitoring — service availability checks, authentication log review, anomaly detection — is the technical foundation of the breach notification obligation. A server with no monitoring is a server where breaches develop undetected until they surface as customer complaints or regulatory enquiries.
The Rules place the compliance burden on the Data Fiduciary. If a breach occurs and the Data Protection Board investigates, what they will ask for is documentation: evidence of security measures, evidence of access controls, evidence of a patching process, evidence of a breach response procedure.
“We thought the server was secure” is not documentation. “We patched the server on these dates, maintained these access controls, and followed this procedure” is.
A managed Linux retainer produces exactly this documentation as a standard output. Monthly maintenance reports document every patch cycle. Access audits document the current state of user accounts and SSH keys. Incident reports document detection, response, and resolution. The compliance paper trail is a byproduct of the management process — not a separate exercise.
If your business holds personal data of Indian citizens and runs on a Linux server, three things need to happen regardless of your current management arrangement:
1. Audit the current access state. Who has SSH access to your server right now? Are there credentials belonging to former employees or contractors? Are database passwords documented and controlled? This is the most immediate compliance exposure and the easiest to close.
2. Establish a patch management process. Monthly security patching with a documented record is the minimum required to demonstrate reasonable security safeguards. If this is not currently happening on a formal schedule, it needs to be.
3. Start a data inventory. What personal data is on the server? Where is it? What is its stated purpose? How long is it retained? This does not need to be exhaustive on day one — but it needs to exist and be maintained.
None of this requires a large budget or a dedicated compliance team. It requires someone who knows what is on your server, has the access to verify it, and produces the documentation that demonstrates the work was done.
AV Services has managed Linux infrastructure for Mumbai businesses since 1999. The monthly retainer includes OS patching, access audits, monitoring, and written health reports — the documentation that DPDP compliance requires, produced as a standard output of ongoing server management.
If you want to know the current compliance exposure of your Linux server, the free 30-minute infrastructure audit is the right starting point. No write access needed. No commitment. A written report within 5 business days covering patch status, access control gaps, and monitoring state — the three pillars of DPDP compliance for Linux server owners.
For businesses that need to demonstrate DPDP compliance: how a managed Linux retainer satisfies DPDP obligations →