Reasonable security safeguards begin with knowing your data

A business cannot protect a customer list it does not know exists. The main application may have careful permissions while a weekly export sits in a former employee’s personal drive. Buying another security product will not resolve that mismatch unless someone follows the data beyond the application.

Reasonable safeguards begin with a practical inventory: what personal data the business holds, why it holds it, where copies travel and who can act on them. The inventory is a way to choose controls and test them. It should not become a perfect diagram that is too expensive to maintain.

As of 22 October 2026, the general DPDP safeguard duties and related rules are scheduled to commence on 13 May 2027 under the commencement notification. Other applicable security and incident obligations need their own current assessment.

Follow one record through its useful life

Take a hypothetical home cleaning service. A booking contains a name, telephone number, address, appointment time and instructions about entering the property. The dispatcher sees it, a cleaner receives part of it, customer support may read it and a payment provider handles a separate transaction.

List those locations and recipients. Ask whether information also appears in email, messaging groups, downloaded files, printed schedules and backups. Record the person responsible for each location. A system without an owner is difficult to secure or remove from service.

Then distinguish necessary access from convenient access. A cleaner may need the address and entry instructions for a visit. They may not need the customer’s full booking history or every other customer’s details. This practical distinction gives the access design a purpose.

Translate the legal safeguard categories into checks

Section 8(5) of the Act addresses reasonable security safeguards, including processing undertaken on the fiduciary’s behalf. Rule 6 sets minimum safeguard categories, including appropriate protection measures, access control, visibility through logs and monitoring, continuity arrangements, contractual provisions and technical and organisational measures.

The rule refers to measures such as encryption, obfuscation, masking or virtual tokens. It does not name a vendor whose purchase guarantees compliance. Nor should a team read the examples as a reason to skip the broader question of whether the arrangement protects the data appropriately.

For the cleaning service, useful checks include whether staff have individual accounts, whether departing workers lose access, whether a bulk export is visible to administrators and whether a lost phone can expose tomorrow’s customer addresses. Each check should correspond to a risk in the actual journey.

Protect availability and integrity as well as secrecy

An incident is not limited to someone stealing a file. The Act’s personal data breach definition includes specified compromises of confidentiality, integrity or availability. A mistaken bulk update or loss of access can therefore be relevant alongside unauthorised disclosure.

Ask how the business would recover a corrupted schedule and how it would determine which version is reliable. A backup is useful only if the team understands what it contains and can restore it when needed. Testing a recovery procedure is a recommended operational practice; the precise frequency should reflect the system and its risks.

Monitor actions that matter. A log collecting millions of events is of limited use if nobody can identify an unexpected export or a failed administrative change. Assign responsibility for reviewing important signals and responding to them.

Include suppliers and retention

Security responsibilities should continue through suppliers. Rule 6 includes appropriate contractual provisions for processors. Ask how the supplier restricts its own access, reports incidents, preserves relevant evidence and supports recovery. Record which safeguards the business must configure itself.

Retention also needs an explicit design. Rule 6(1)(e) provides for one-year retention of relevant logs and personal data for detection, investigation, remediation, prevention of recurrence and continued processing after a compromise, unless applicable law requires otherwise. Separately, rule 8(3) requires at least one year from processing for personal data, associated traffic data and processing logs, for Seventh Schedule purposes. It then requires erasure unless other law or a Government notification requires further retention. These purpose-limited provisions do not authorise unrestricted reuse of retained information.

Build an evidence list that stays manageable

For each important system, keep the current owner, access list, relevant configuration, supplier terms, recovery result and unresolved security actions. Date the evidence so a reviewer can distinguish a current control from an old screenshot.

Prioritise obvious exposure first: public links, obsolete accounts, shared administrator credentials and unnecessary exports. Then work through less visible dependencies. A small business can make meaningful progress without pretending that one checklist, certification or security purchase settles every question about reasonable safeguards.