Meeting the Reasonable Security Safeguards

Abstract

This article opens a three part series on breach under the Digital Personal Data Protection Act 2023. The series covers three pieces of work that sit 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. This first article deals with the protections.

For a long time the Act asked for reasonable security safeguards and left the phrase open. Companies had no way to know 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.

Six items make up the list. Encryption or masking or obfuscation or the use of virtual tokens. Controls on who can reach the data. Logging and monitoring able to detect somebody reaching it without permission. Arrangements that keep the business processing if data is lost or destroyed. Retention of those logs for a year. Contract terms put the same duties on any processor handling data on your behalf. The article takes each in turn and sets out what it asks of a real system.

Getting this right carries the highest financial exposure in the Act. A failure to maintain reasonable security safeguards can attract a penalty of up to two hundred and fifty crore rupees, the top tier in the schedule. The obligations become enforceable in May 2027. The two articles that follow cover detection and reporting, and both of them depend on what gets built here.

1. Where the Obligation Comes From

1.1 A phrase that stayed open for two years

The Act places a plain duty on every data fiduciary. Take reasonable security safeguards to prevent a personal data breach. That sentence sat in the statute from 2023 onwards without a definition attached, and the absence caused real difficulty. A company willing to comply had no way to establish what compliance looked like. Two organisations in the same industry could reach different conclusions in good faith, and neither could be sure.

Rule 6 settled it. The Rules notified in November 2025 set out the measures a fiduciary has to take, and they read as a floor and not a ceiling. Meeting them does not guarantee that a company has done enough for its particular circumstances. Falling short of them 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 fiduciary. The list therefore settles what has to exist while leaving open how well it has to work, and the second half of that question is where judgement still lives.

For anyone planning work, that change is useful. A defined list can be turned into a project with owners and dates. An open standard cannot. Companies that spent the last two years waiting for clarity have it, and the time between now and May 2027 is the window in which the list has to become real inside their systems.

1.2 What the exposure looks like

The penalty attached to this obligation deserves attention because it sits at the top of the schedule. Failing to take reasonable security safeguards can draw up to two hundred and fifty crore rupees. Failing to notify a breach draws up to two hundred crore. No other duty in the Act carries a higher figure than the first of those.

Two things follow. The safeguards obligation stands on its own, so a company can be penalised for weak protection even where no breach ever occurs and nobody is harmed. The two obligations also compound, because 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 independent, a company cannot satisfy it by responding well to incidents. Handling a breach competently helps with the notification duty and does nothing for this one. What satisfies this duty is protection that was already in place on the day, which makes the whole obligation a question of preparation and nothing else.

Boards asking where to spend a compliance budget have a clear answer in the numbers. The measures in Rule 6 are also, with one exception, things a well run technology function would want anyway. Encryption, access control, logging, and tested backups improve a system regardless of the law. Only the contractual work with processors is purely a compliance activity, and even that surfaces vendor risk a company benefits from seeing.

2. Protecting the Data Itself

2.1 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. Treating the four as interchangeable leads to poor decisions, so it helps to be clear about what each does.

Encryption converts 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 on how the keys are handled. Keys stored beside the data they protect, or held by every engineer, remove most of the benefit while leaving the appearance of it.

Masking replaces part of a value with a placeholder, so a support agent sees the last four digits of an account number and nothing more. It suits screens and reports where a person needs to recognise a record without seeing all of it. Obfuscation covers a broader family of techniques that make data harder to interpret, and it is generally weaker than encryption because a determined reader may still get through.

Virtual tokens replace a real value with a substitute that carries no meaning outside the system holding the mapping. A payment reference that stands in for 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, and they reduce the number of places that need heavy protection.

2.2 Deciding what to apply where

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

Some patterns hold across most organisations. Identity documents, financial details, and health information warrant encryption at rest with keys held separately. Data on screens used by staff warrants masking, so that seeing a record does not mean seeing everything in it. Data flowing to analytics or reporting 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 sitting outside the controls that protect the live system.

One trap catches companies that treat this as a procurement exercise. Buying a database with encryption at rest, switching it on, and marking the item complete leaves a gap, because data spends most of its life outside the database. It sits in application memory, in log files, in exports somebody generated last quarter, in a message queue, and in the backup. Encryption at rest covers one of those. Working through where a category of data actually travels, and protecting it along that path, is what makes the measure effective.

Whatever a company decides, the decision belongs in writing. Rule 6 does not name which technique applies to which data, which leaves the judgement with the 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 ask it.

3. Controlling Who Can Reach the Data

3.1 Access control as the Rules mean it

Second on the list comes control over access. 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 the database.

Three groups need separate thought. Staff who use applications should reach data through those applications, with permissions matching their role. Engineers and administrators who can reach data directly need tighter control, since their access bypasses whatever the application enforces, and their activity needs recording. Service accounts, meaning the credentials one system uses to talk to another, are the group most often forgotten, and 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, and check whether the permission still matches a current need. Companies doing this for the first time usually find dormant accounts, shared credentials, and at least one integration with more access than its function requires.

3.2 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 teams and needs different ones, though the old set often stays alongside the new. Someone leaves, and their access has to end that 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 of record holds employment status, 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 deserves 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. That arrangement takes a little effort to set up and it converts 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 class of risk cheaply, and it shortens the list of accounts an investigation has to examine.

4. Keeping the Data Available

4.1 The obligation nobody expects

The fourth item surprises people, because it addresses availability instead of secrecy. A fiduciary has to take measures allowing continued processing if personal data is destroyed or lost. Read plainly, this makes losing data a breach of the security obligation, not only exposing it.

That reading matches how the Act defines a personal data breach, which covers loss and destruction alongside unauthorised disclosure. A ransomware event that encrypts a company database and leaks nothing has still caused a breach. The same applies to an engineer running a delete 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, cover the data that matters, and sit somewhere the live system cannot reach. Encryption on those backups. A documented restore procedure. An interval for testing restores belongs there too, because a backup nobody has restored has not been shown to work. A restore either succeeds or it does not, and testing is how a company knows which.

4.2 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 number 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. Coverage that never extended to a database added last year. Encryption keys nobody can locate. Restore instructions that reference a server which no longer exists. None of these announce themselves, and all of them are cheap to find and fix on a Tuesday afternoon.

Ransomware changes the calculation around backups in one specific way that deserves stating. 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 no protection against this. Copies kept offline, or in storage the live environment has no permission to write to, survive it. That separation is the single most useful property a backup arrangement can have.

One connection to the third article in this series is worth making here. 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.

5. Binding the Processors You Use

5.1 Duties that travel with the data

Rule 6 requires a fiduciary to include terms in its contracts with data processors obliging them to take reasonable security safeguards of their own. The reasoning is straightforward. A company that meets every requirement internally, then sends personal data to a vendor with weak protection, has moved the risk instead of reducing it. Under the Act the 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 procurement. The exercise worth running is an enumeration of every outbound flow of personal data, which regularly turns up services nobody in the compliance function knew about.

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

With the list in hand, the contractual work becomes visible. Some agreements already carry adequate terms. Some carry terms written for a different framework and need review against the Act. Some processors are operating with no agreement at all. Each case needs a different action, and renegotiation depends on the other party, so this workstream needs starting early.

5.2 What the terms should require

A useful set of terms covers a few specific points. The processor takes security safeguards appropriate to the data it holds. It processes 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 duty, which means hours and not days. It deletes data when you instruct it to, and confirms that it has. It does not appoint further processors without telling you.

The breach notification term repays careful drafting. Your seventy two hour clock, covered in the third article, starts when 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 is difficult through no act of your own. A term requiring notification within a short defined period, and a named contact on both sides, keeps your own reporting position intact.

Alongside the contract sits a practical question about assurance. Whether to accept a vendor 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 operation. Deciding that consistently, and writing down the basis, puts a company on firmer ground than applying one rule to every vendor in either direction.

6. What Reasonable Means in Your Case

6.1 A floor, not a full answer

Rule 6 gives a list, and the statutory phrase remains reasonable security safeguards. Those two facts sit together and both matter. A company that implements the six items 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 holding treatment records for two hundred thousand patients and a design studio 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, and the studio that implements the six items sensibly is in a sound position.

One further factor belongs in that assessment, and it is the status of the data itself. Financial details, health information, identity documents, and anything concerning children carry more consequence if exposed, and the expectation rises accordingly. A company holding a modest volume of highly sensitive records may need stronger protection than one holding a large volume of ordinary contact details, 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. A regulator asks for exactly that reasoning, and assembling it after an incident takes longer than assembling it now.

6.2 Where this leaves you

The six measures in Rule 6 form a project, not a policy, and the project has a shape. Encryption and masking follow from the data inventory. Access control follows from an enumeration of every route into personal data. Backup and restore testing goes on a schedule. Processor contracts start early because they depend on other parties. Logging sits at the centre and reaches into the next article.

Logging deserves a closing word because of that. Rule 6 asks for logs, monitoring and review capable of detecting somebody reaching data without permission, and it asks for those logs to be kept for a year. Of all the measures on the list, this is the one 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 the second article in this series takes up what that means.

Conclusion

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 through joiners, movers and leavers. Keep logging and monitoring able to detect somebody reaching data without permission, 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 notification among those terms.

None of these are unusual. Most of them are practices a careful technology function would want without any law requiring them, and the exception, 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 schedule, where a failure of security safeguards reaches two hundred and fifty crore rupees and stands on its own whether or not a breach ever happens. The measures also differ in one respect that shapes the order of work. Every item on the list can be strengthened after the event except the records, since nothing recreates an entry nobody was writing at the time. The second article in this series deals with that.