Meeting the reasonable security safeguards

Overview

Breach under the Digital Personal Data Protection Act, 2023 involves three pieces of work that belong together: putting the required protections in place, finding out when someone has reached data they should not have, and telling the Data Protection Board and the people affected. The protections come first.

For two years the Act asked for reasonable security safeguards and left the phrase open. Companies had no way of knowing what would satisfy a regulator, and advisers filled the gap with judgement. Rule 6 of the Digital Personal Data Protection Rules, 2025 closed that gap. It now lists the measures a Data Fiduciary has to take, and the list is short enough to work through and specific enough to plan against.

The list covers:

• encryption, obfuscation, masking or the use of virtual tokens to secure personal data;
• control over who can access personal data and the systems that hold it;
• logs, monitoring and review that can detect unauthorised access, investigate it and support remediation;
• backups and other measures so that processing can continue if personal data is destroyed, lost or corrupted;
• keeping those logs, and the related personal data, for one year, unless another law requires something different;
• contract terms that require your Data Processors to take reasonable security safeguards too;
• appropriate technical and organisational measures so that all of the above is actually observed.

Each measure asks something specific of a real system in an ordinary Indian company. This is a practical reading of the Rules and does not constitute legal advice.

Getting this right carries the highest financial exposure in the Act. Most of these duties commence eighteen months after the Rules were notified, around 13 May 2027; check for later amendments. Detection and reporting both depend on what gets built here.

Where the obligation comes from

A phrase that stayed open for two years

The Act places a plain duty on every Data Fiduciary in section 8(5): protect the personal data in your possession or under your control, including data processed on your behalf by a Data Processor, by taking reasonable security safeguards to prevent a personal data breach. That sentence sat in the statute from August 2023 without a definition attached.

Rule 6 settled it. The Rules were notified on 13 November 2025, and the measures in Rule 6 read as a floor. Meeting them does not prove that a company has done enough for its particular circumstances. Falling short of them, though, makes the position very hard to defend, because the government has now written down what it expects.

One point about the list repays attention. Rule 6 does not tell a company which technique to apply to which data, how tight an access rule should be, or how often to test a restore. It names the categories and leaves the detail to the Data Fiduciary. The list therefore settles what has to exist and leaves open how well it has to work. That second half is where judgement still lives, and where a company has to be ready to explain its choices.

For anyone planning work, this is useful. A defined list can be turned into a project with owners and dates, and the months before May 2027 are the window in which it has to become real inside your systems.

What the exposure looks like

The penalty attached to this duty sits at the top of the Schedule. Failing to take reasonable security safeguards to prevent a personal data breach can draw a penalty of up to ₹250 crore. Failing to notify the Board or affected people of a breach can draw up to ₹200 crore. No other duty in the Act carries a higher figure than the first. The Board decides the actual amount after weighing the nature, gravity and duration of the failure, the type of data affected, whether the failure repeats, and what the company did to mitigate it.

Two consequences follow. The safeguards duty stands on its own, so a company can be penalised for weak protection even where no data ever leaks and nobody is harmed. The two duties also tend to fail together. A company with poor logging will often fail both, first by not protecting the data and then by being unable to report properly on what happened to it.

A third point matters for planning. Because the safeguards duty is separate, a company cannot satisfy it by responding well to incidents. What satisfies it is protection that was already in place on the day.

Most of the measures in Rule 6 are also things a well run technology function would want anyway. Encryption, access control, logging and tested backups improve a system whatever the law says. Only the contractual work with processors is purely a compliance activity, and even that brings into view vendor risk that a company benefits from seeing.

Protecting the data itself

Four techniques, and where each one fits

The first item on the list gives four options: encryption, obfuscation, masking, or the use of virtual tokens. A company may use one or several, and the choice depends on what the data is for. The four do different jobs, and treating them as interchangeable leads to poor decisions, so it helps to be clear about each.

Encryption turns data into a form nobody can read without a key. It suits data at rest in a database or a backup, and data moving across a network. The protection is strong, and it depends entirely on how the keys are handled. Keys stored beside the data they protect, or available to every engineer, remove most of the benefit while keeping the appearance of it.

Masking replaces part of a value with a placeholder. A call centre agent at an NBFC sees the last four digits of a PAN or a loan account number, enough to recognise the customer and no more. It suits screens and reports where a person needs to identify a record without seeing all of it.

Obfuscation covers a broader family of techniques that make data harder to interpret, such as scrambling values in a test copy of a database. It is generally weaker than encryption, because a determined reader may still work it out.

Virtual tokens replace a real value with a stand-in that carries no meaning outside the system holding the mapping. A payment token in place of a card number is the familiar example. Tokens work well when many systems need to refer to the same person or account without any of them holding the sensitive value. They shrink the number of places that need heavy protection.

Deciding what to apply where

A company cannot encrypt everything and continue to function, because data has to be readable at the point of use. The practical approach starts from the data inventory. Take each category of personal data, note where it sits and which systems and people use it, and then choose the technique that suits that use.

Some patterns hold across most organisations:

• Aadhaar copies, bank statements, salary slips and health records warrant encryption at rest, with keys held separately from the data.
• Screens used by staff warrant masking, so that opening a record does not mean seeing everything in it.
• Data flowing to analytics dashboards or reporting tools warrants tokens or removal of identity altogether, because those systems rarely need to know who a person is.
• Backups warrant encryption without exception, since a backup is a complete copy of your data sitting outside the controls that protect the live system.
• Test and development copies warrant obfuscation or synthetic data, because they are usually far less protected than production.

One trap catches companies that treat this as a purchase. Buying a database with encryption at rest, switching it on and marking the item complete leaves most of the exposure in place, because data spends much of its life outside the database. It sits in application memory and application logs, in the spreadsheet someone exported last quarter and shared on WhatsApp, in a message queue, in an email attachment, and in the backup. Encryption at rest covers one of those. The measure only becomes effective when you follow where a category of data actually travels and protect it along that path.

Whatever a company decides, the decision belongs in writing. Rule 6 does not say which technique applies to which data, which leaves the judgement with the Data Fiduciary. A short record naming each data category, the technique applied and the reason will answer the question when somebody asks it, and somebody will.

Controlling who can reach the data

Access control as the Rules mean it

Second on the list comes control over access to personal data and the computer resources that hold it. The requirement sounds obvious and it fails in predictable ways, so the detail matters. Access control means that each person and each system can reach the personal data needed for their work and no more. A company where every engineer can query the production database has not met this, even with a login screen in front of that database.

Three groups need separate thought. Staff who use applications should reach data through those applications, with permissions that match their role. A collections executive needs the amount due and a phone number, and rarely the full KYC file. Engineers and administrators who can reach data directly need tighter control, because their access bypasses whatever the application enforces, and their activity needs recording. Service accounts, the credentials one system uses to talk to another, are the group most often forgotten. They frequently hold broad permissions granted years ago for a reason nobody remembers.

Reviewing this is a defined piece of work. List every route to personal data. Name who or what holds each one. Check whether the permission still matches a current need. First reviews usually find dormant accounts and at least one integration with far more access than it needs. A shared login used by six people in a call centre is a common finding, and it defeats access control and logging at the same time.

The moments when access changes

Access drifts through ordinary events, and controlling it means handling those events reliably. Someone joins and needs permissions. Someone moves from collections to customer service and gets new permissions, while the old set often stays alongside. Someone resigns, and their access has to end on their last day. A contractor finishes an engagement. A vendor relationship ends. Each of these is a point where a company either keeps its access list accurate or lets it slip.

The mechanism that works is a joining and leaving process connected to whatever system holds employment status, often the HR or payroll system, so that a departure removes access without depending on somebody remembering. Where that connection cannot be automated, a monthly reconciliation between the staff list and the access list catches what manual handovers miss.

Direct database access needs its own rule, since it is the route that causes the most damage and receives the least attention. An engineer with a production connection can read every record in a table, and no application permission stands in the way. Companies that handle this well remove standing access altogether and grant it for a defined period when somebody needs it, with a reason recorded and the session logged. It turns the largest single exposure in most systems into a controlled and visible event.

Dormant access is worth a specific check. An account nobody has used for ninety days is either unnecessary or belongs to somebody who has left, and in both cases it is a route into personal data that nobody is watching. Closing dormant accounts on a schedule removes a whole class of risk cheaply.

Logs, monitoring and the one year rule

What Rule 6 asks for here

The third and fifth items on the list work as a pair. Rule 6 asks for visibility of access to personal data through appropriate logs, monitoring and review, for the purpose of detecting unauthorised access, investigating it, and remediating to prevent it happening again. It then asks for those logs, and the personal data concerned, to be retained for one year, unless another law requires otherwise.

Two duties sit there. Records have to be produced, and records have to be kept. Many cloud services and logging tools keep data for thirty days by default, sometimes seven, because storage costs money and nobody chose a longer figure. Under the Rules that default falls short.

Logging carries its own detail: what each entry should contain, where logs should live, and how they become detection. One point shapes the order of work. Every other measure on this list can be strengthened after an incident. A log that was not being written on the day cannot be created afterwards.

Keeping the data available

The obligation nobody expects

The backup item surprises people, because it addresses availability. A Data Fiduciary has to take reasonable measures for continued processing if personal data is destroyed, lost or its integrity compromised, such as through keeping data backups. Losing data is therefore a security failure, alongside exposing it.

That reading matches how the Act defines a personal data breach, which covers loss of access and destruction alongside unauthorised disclosure. A ransomware attack that encrypts a hospital's patient records and copies nothing out has still caused a breach. So has an engineer running a delete command against the wrong environment, or a failed storage device with no working copy behind it.

What the requirement asks for is ordinary practice done properly:

• backups that run on a known schedule and cover the data that matters;
• copies kept somewhere the live system cannot reach or alter;
• encryption on those copies, with keys held separately;
• a written restore procedure that someone other than its author could follow;
• a set interval for testing restores.

The last item matters most. A backup nobody has restored has not been shown to work. A restore either succeeds or it fails, and testing is how a company finds out which.

Testing what you would rely on

A restore test is a short exercise with a clear result. Pick a system, restore it into an isolated environment from a real backup, confirm the data is complete and readable, and record how long the whole thing took. That last figure is the one operations people need, because it tells the business what an outage would actually cost.

Doing this every quarter catches failures that produce no visible symptom. Backups that stopped running when a service moved to a new cloud account. Coverage that never extended to a database added last year. Encryption keys nobody can locate. Restore instructions that refer to a server switched off two years ago. All of them are cheap to find and fix on an ordinary weekday.

Ransomware changes the backup calculation in one specific way. An attacker who reaches a company network will look for the backups and encrypt those too, because a company that can restore has no reason to pay. Backups held on the same network with the same credentials offer little protection against this. Copies kept offline, or in storage that the live environment has no permission to change for a set period, survive it. That separation is the single most useful property a backup arrangement can have.

Backups also shape the reporting duties. If a company loses data and cannot restore it, the loss is reportable to the Board, and the report has to describe the extent of what was lost. A company with tested backups can state precisely what it lost and what it recovered. A company without them will be estimating, in writing, to a regulator.

Binding the processors you use

Duties that travel with the data

Rule 6 requires a Data Fiduciary to put terms in its contracts with Data Processors obliging them to take reasonable security safeguards as well. The reasoning is straightforward. A company that meets every requirement internally and then sends personal data to a vendor with weak protection has moved the risk elsewhere without reducing it. Under the Act, the Data Fiduciary stays answerable for that data.

Meeting this starts with a list of processors, and building the list is usually the harder half. Personal data reaches outside services through arrangements made by many people over many years, including tools adopted by individual teams without any purchase order. The exercise worth running is an enumeration of every outbound flow of personal data. It regularly turns up services the compliance function had never heard of: the SMS gateway, the WhatsApp messaging provider, the analytics script on the website, the agency that runs social media, the payroll bureau.

Two kinds of processor tend to be missed. The first is the small tool adopted by one team, such as a scheduling service, a survey platform or a transcription tool. Each holds a little personal data and none appears in any register. The second is the sub-processor, the service your vendor uses, which holds your data at one further remove. Your agreement should require notice before a vendor appoints one. Without that, your data reaches parties you have never assessed and cannot name.

With the list in hand, some agreements will already carry adequate terms. Some carry terms written for a different framework, often the European GDPR, and need review against the Indian Act. Some processors operate with no written agreement at all. Each case needs a different action, and renegotiation depends on the other party's legal team, so this workstream needs to start early.

What the terms should require

A useful set of terms covers a few specific points:

• the processor maintains security safeguards appropriate to the data it holds, in line with Rule 6;
• it processes personal data only on your instructions and only for the agreed purpose;
• it tells you about a breach quickly enough for you to meet your own reporting duties, which means hours and should never stretch to days;
• it keeps logs that would support your investigation, for the period the Rules require;
• it deletes or returns data when you instruct it to, and confirms in writing that it has;
• it does not appoint further processors without telling you first.

The breach notification term repays careful drafting. Your own reporting duties under Rule 7 run from the moment you become aware of a breach. If a processor takes a week to tell you about an incident in its systems, your position with the Board becomes difficult through no act of your own. A term requiring notice within a short defined period, with a named contact on each side, keeps your own reporting position intact.

Alongside the contract sits a practical question about assurance. Whether to accept a vendor's own statement, ask for an independent audit report, or run your own assessment depends on how sensitive the data is and how central the vendor is to your operations. Deciding that consistently, and writing down the basis, puts a company on firmer ground than applying one rule to every vendor in either direction.

Making the measures stick

The last item on the list is easy to skim past. Rule 6 asks for appropriate technical and organisational measures to ensure that the safeguards are effectively observed. In plain terms, the measures have to keep working after the project that installed them has closed.

That means a named owner for each measure, a short written procedure, training for the people who operate it, and a calendar of checks. The quarterly restore test, the monthly access reconciliation, the review of logging settings after each major release and the annual review of processor contracts are the kind of routines this item points to. A company that can show the routine running, with dates and outcomes, can show the safeguards are real.

What reasonable means in your case

A floor, and still your judgement

Rule 6 gives a list, and the statutory phrase remains reasonable security safeguards. Both facts matter. A company that implements every item has done what the Rules name. Whether it has done what is reasonable for its own circumstances is a separate question, and the answer varies with the sensitivity of the data, the size of the holding and the harm a breach would cause.

A hospital chain holding treatment records for two lakh patients and a design studio in Kochi holding contact details for four hundred clients both fall under the same rule. Nobody expects the same programme from each. The larger and more sensitive the holding, the more a regulator will expect beyond the minimum.

The nature of the data belongs in that assessment as well. Financial details, health information, identity documents and anything concerning children carry more consequence if exposed, and the expectation rises accordingly. An edtech platform holding modest volumes of records about school students may need stronger protection than a company holding a large list of ordinary business contacts, so volume alone is a poor guide.

Working out where your organisation sits on that scale is a judgement, and the useful discipline is to make it explicitly. Note what data you hold, how much, how sensitive it is and what would follow for people if it leaked. Then state what you have put in place and why that is proportionate. The Board will look for exactly that reasoning, and it is far easier to assemble now than after an incident.

Where this leaves you

The measures in Rule 6 form a project with a clear shape. Encryption, masking and tokens follow from the data inventory. Access control follows from an enumeration of every route into personal data. Restore testing goes on a schedule. Processor contracts start early, because they depend on other parties. Owners and routine checks keep all of it working.

One last point on logging. Rule 6 asks for logs, monitoring and review capable of detecting unauthorised access, and for those logs to be kept for a year. Of everything on the list, this is the one measure that cannot be added late. Everything else can be improved after an incident. A log that was not running when the incident happened cannot be recovered afterwards, and discovering a personal data breach sets out what that means in practice.

Key points

Rule 6 turned an open phrase into a list a company can work through. Protect the data with encryption, masking, obfuscation or tokens, choosing the technique that suits each category and recording the reasoning. Control who can reach the data, including engineers with direct access and the service accounts that talk between systems, and keep that control accurate as people join, move and leave. Keep logs and monitoring able to detect unauthorised access, and hold those logs for a year. Make sure you can continue processing if data is lost, which means backups you have actually restored. Put terms in your processor contracts requiring the same standard from them, with fast breach notice among those terms.

None of this is unusual. Most of it is practice a careful technology team would want without any law requiring it, and the contractual work with processors gives a company a clear view of a risk it usually carries without seeing. What raises the stakes is the penalty, which reaches ₹250 crore for a failure of security safeguards and applies whether or not a breach ever happens. The measures differ in one respect that shapes the order of work. Each one can be strengthened after the event except the records, since nothing recreates an entry nobody was writing at the time.

For the duties that follow an incident, see our guide to breach notification, and for the full penalty Schedule, our guide to penalties.