Rule 6 - Reasonable security safeguards

Rule 6 gives practical content to the obligation imposed by Section 8(5) of the Digital Personal Data Protection Act, 2023. Section 8(5) requires a Data Fiduciary to protect personal data in its possession or under its control, including personal data processed on its behalf by a Data Processor. Rule 6 then identifies the minimum components of the security framework that must support that protection.

The Rule treats security as a continuing operational responsibility. It is not satisfied merely by adopting an information-security policy, purchasing cybersecurity software, entering into a standard vendor contract or obtaining an external certification. The safeguards must be appropriate to the processing, implemented in the relevant systems, extended to Data Processors, monitored in practice and capable of supporting detection, investigation, recovery and prevention of recurrence.

Commencement position: Rule 6 and Section 8(5) are scheduled to come into force on13 May 2027. Until then, Rule 6 is a notified but prospectively operative requirement against which organisations should design and test their security programmes.

1.1 The statutory relationship between Section 8(5) and Rule 6

Section 8(5) creates the substantive duty to take reasonable security safeguards. Rule 6 does not replace that duty. It prescribes the minimum elements through which the duty must be discharged.

The combined effect is that a Data Fiduciary must:

• protect personal data in its possession;

• protect personal data that remains under its control even if another organisation stores or processes it;

• ensure that processing undertaken on its behalf by a Data Processor is appropriately secured;

• implement every applicable category of safeguard identified in Rule 6;

• adopt additional safeguards where the nature and risks of processing make them necessary; and

• maintain sufficient evidence to demonstrate that the safeguards existed and functioned in practice.

The words “shall include, at the minimum” are significant. Encryption, access control, logging, monitoring, continuity, retention, processor-contract provisions and technical and organisational measures are not merely optional examples from which a Data Fiduciary may select one or two controls. They form a mandatory baseline. The specific method and strength of implementation may vary, but each relevant security objective must be addressed.

At the same time, Rule 6 is not an exhaustive checklist. Compliance cannot be established by mechanically ticking off its clauses while leaving an obvious or serious risk uncontrolled. If a Data Fiduciary processes large volumes of financial data, health information, identity documents, children’s data or biometric information, additional safeguards may be necessary even though the Rule does not name each of them.

1.2 Meaning of “reasonable” security

“Reasonable” does not mean perfect or incapable of being defeated. No security system can eliminate every possibility of human error, malicious conduct, technical failure or sophisticated attack. The legal obligation is to identify foreseeable risks and apply safeguards proportionate to those risks.

Reasonableness must be assessed in context. Relevant considerations include:

• the nature of the personal data;

• the volume and concentration of the information;

• the number of Data Principals affected;

• the vulnerability of those individuals;

• the processing purpose;

• the systems and technologies involved;

• the consequences of unauthorised disclosure, alteration, destruction or unavailability;

• the organisation’s dependence on Data Processors;

• known vulnerabilities and threat patterns;

• the availability and effectiveness of security measures;

• the history of breaches or control failures; and

• the organisation’s response to known risks.

A neighbourhood retailer processing customer names and delivery addresses will not necessarily require the same security architecture as a hospital processing medical histories or a bank processing account credentials and transaction data. But the retailer is not exempt from security. It must still protect its systems, limit access, monitor relevant activity, maintain recoverability and appropriately supervise vendors.

Reasonableness also changes over time. A control that was adequate when a system was deployed may become inadequate because:

• the organisation begins collecting more consequential data;

• the number of users increases substantially;

• the service becomes internet-facing;

• a known vulnerability is discovered;

• a new Processor is introduced;

• attackers begin exploiting a particular technique;

• an earlier incident exposes a weakness; or

• a stronger and reasonably available safeguard becomes standard.

Security under Rule 6 is therefore not a one-time implementation project. It requires continuing assessment and improvement.

1.3 A personal data breach does not automatically establish a security failure

A breach may occur even where reasonable safeguards were in place. A well-secured organisation may still face a sophisticated attack, malicious insider or previously unknown technical vulnerability.

The occurrence of a breach and breach of the security obligation are related but distinct questions:

1. Did an event affect the confidentiality, integrity or availability of personal data?

2. Did the Data Fiduciary fail to maintain reasonable safeguards required by Section 8(5) and Rule 6?

The Board should examine the safeguards that existed before and during the incident, not infer non-compliance solely from the fact that an attacker succeeded.

Example

For example, suppose an organisation:

• maintained current security patches;

• used strong multifactor authentication;

• encrypted the affected database;

• restricted privileged access;

• detected the attack rapidly;

• blocked the compromised account;

• preserved complete logs;

• notified affected persons appropriately; and

• corrected the underlying weakness.

A breach may still have occurred, but the circumstances may support the conclusion that the organisation maintained reasonable safeguards.

The opposite is also true. An organisation does not become compliant merely because it has not discovered a breach. It may lack the monitoring capability needed to detect one. Absence of detected harm is not evidence that access controls, logs, backups or Processor safeguards are adequate.

1.4 Personal data in the Data Fiduciary’s possession or control

Rule 6 applies to personal data in the Data Fiduciary’s possession or under its control.

“Possession” ordinarily covers data stored directly by the organisation. “Control” extends the security perimeter beyond its own physical premises and servers. Personal data may remain under the Data Fiduciary’s control when held by:

• a cloud-hosting provider;

• payroll company;

• recruitment platform;

• customer-support vendor;

• software-as-a-service provider;

• payment processor;

• managed service provider;

• analytics company;

• marketing platform;

• document-storage provider;

• reservation system;

• laboratory service;

• AI provider; or

• another Data Processor.

A company cannot reduce its statutory responsibility simply by transferring data to a vendor. If the vendor processes the information on the company’s behalf, the Data Fiduciary remains responsible for ensuring appropriate protection.

This requires an accurate understanding of where personal data exists. The security inventory should cover not only the principal production database but also:

• laptops and mobile devices;

• email attachments;

• spreadsheets;

• shared folders;

• development and testing environments;

• data exports;

• reporting systems;

• temporary storage;

• caches;

• replicas;

• archives;

• backups;

• security logs;

• vendor environments; and

• decommissioned systems.

A database may be securely protected while an exported spreadsheet containing the same information is available through an unrestricted shared folder. Rule 6 concerns protection of the personal data, not merely protection of one designated system.

1.5 Appropriate data-security measures

Rule 6(1)(a) requires appropriate measures to secure personal data. It expressly refers to encryption, obfuscation, masking and virtual tokens mapped to personal data. These techniques perform different functions and may be used individually or together according to the processing context.

1.6 Encryption

Encryption converts readable information into a protected form that cannot ordinarily be understood without the correct cryptographic key.

It may be used for:

• databases;

• file storage;

• backups;

• portable devices;

• communication between systems;

• information transferred to a Processor;

• email attachments; and

• removable media.

The mere presence of encryption does not establish adequate protection. Its effectiveness depends on matters such as:

• the strength and suitability of the encryption;

• where and how the keys are stored;

• who can access the keys;

• whether keys are rotated;

• how compromised keys are revoked;

• whether different environments use separate keys;

• whether backups of keys are protected; and

• whether the same administrator can access both the encrypted data and all decryption credentials without oversight.

1.7 Illustration: Encrypted database with exposed keys

A company encrypts its customer database but stores the decryption credentials in a configuration file accessible through the same compromised server.

The company may accurately state that the database was encrypted, but the protection may be ineffective because the attacker could obtain both the data and the means of decrypting it. Rule 6 assesses the complete control environment, not the label attached to a security feature.

1.8 Illustration: Laptop loss

An employee loses a company laptop containing customer records. If the device uses strong full-disk encryption, has secure authentication and can be remotely disabled, the likelihood of unauthorised access may be materially reduced.

If the same records were stored in an unencrypted folder and the laptop had no effective screen lock, the loss is considerably more serious.

1.9 Masking

Masking hides some or all of a data value from users who do not need to see the complete information.

Example

For example:

• a customer-support employee may see only the last four digits of a card;

• a finance screen may display a partially obscured bank-account number;

• an identity number may be redacted in an ordinary operational report;

• salary information may be hidden from HR users who do not administer compensation;

• a telephone number may appear only partially in a verification screen.

Masking supports least-privilege access. A person may need enough information to identify or verify a record without needing the full underlying value.

Masking must be implemented consistently. Hiding a card number on the application screen is of limited value if the full number appears in downloadable reports, email notifications, system logs or support tickets.

1.10 Obfuscation

Obfuscation reduces the direct intelligibility or usefulness of personal data to unauthorised persons.

It is particularly relevant in development, testing, demonstrations, troubleshooting and analytics. These environments frequently receive less protection than production systems even though they may contain complete copies of production data.

1.11 Illustration: Testing environment

A software team needs realistic data to test a payroll update. It copies the entire employee database, including names, salaries, addresses, bank accounts and identity numbers, into a test environment accessible to numerous developers.

The team needed realistic data structures, not the employees’ actual identities. Using masked, synthetic or otherwise protected data would have reduced the exposure. The unnecessary use of complete production records may indicate that the Data Fiduciary did not take appropriate safeguards.

1.12 Tokenisation

Tokenisation replaces the original data with a substitute value or token. The corresponding original information is held separately and protected through stricter controls.

Example

For example, an application may store a transaction token rather than a complete payment credential. A health-analytics system may use a coded patient reference while the identifying information remains in a separate secured repository.

Tokenisation reduces exposure across systems that do not need the original value. However, it does not necessarily remove the data from the DPDPA. If the token can be mapped back to the individual using information available within the processing arrangement, it remains associated with identifiable personal data.

1.13 Choosing the appropriate protection

Rule 6 does not require every piece of personal data to be encrypted, masked, obfuscated and tokenised simultaneously. The Data Fiduciary must determine which safeguards are appropriate to the particular operation.

A mature design may use:

• encryption for data at rest and in transit;

• masking for ordinary operational screens;

• tokenisation for payment or identity references;

• obfuscation in development environments;

• strict role-based access to original values; and

• logging of all attempts to retrieve unmasked information.

The essential question is whether the protection corresponds to the actual risk and follows the personal data throughout its lifecycle.

1.14 Access control

Rule 6(1)(b) requires appropriate control over access to computer resources used by the Data Fiduciary or its Data Processors.

Security begins with deciding who and what may access personal data. Access should not be granted merely because a person works for the organisation, holds a senior designation or belongs to a broadly defined department.

1.15 Unique identities

Each user should ordinarily have a unique account. Shared accounts make it difficult to establish who accessed or altered information.

If several employees use a common account called “Admin” or “Reception,” the organisation may be unable to determine:

• who viewed a record;

• who exported information;

• who changed a permission;

• whether credentials were shared externally; or

• which individual should be investigated.

Where common functional accounts are unavoidable, additional controls are necessary to identify the actual user and restrict the account’s capabilities.

1.16 Least privilege

Least privilege means that each person or system receives only the access necessary for the approved function.

1.17 Illustration: Hotel operations

A concierge may require access to a guest’s name, arrival information and requested service. That does not automatically justify access to:

• complete passport details;

• payment-card information;

• historical disputes;

• full reservation history; or

• unrelated personal preferences.

1.18 Illustration: Human resources

A recruiter may require access to candidate CVs and interview assessments. A payroll employee may require access to salary and bank information. An employee-relations manager may require access to disciplinary records.

Giving each of them unrestricted access to the entire HR database would disregard the different purposes for which the information is needed.

1.19 Privileged access

Administrative and privileged accounts require enhanced control because they can often:

• view large databases;

• change access permissions;

• disable monitoring;

• delete records;

• alter configurations;

• create accounts;

• access backups; or

• export information.

Appropriate controls may require:

• separate administrative identities;

• multifactor authentication;

• approval before privileged access;

• time-limited access;

• recording of privileged sessions;

• monitoring of administrator activity;

• prohibition of routine use of administrator accounts;

• periodic access review; and

• immediate revocation when the role ends.

1.20 Joiner, mover and leaver controls

Access must change when the user’s relationship or role changes.

A common failure occurs where:

• a new employee receives excessive default access;

• an employee transfers departments but retains earlier permissions;

• a contractor continues to have access after completing the project;

• a departing employee’s credentials remain active;

• a vendor-support account is never disabled.

The access lifecycle should therefore cover:

1. approval when access is created;

2. review when responsibilities change;

3. periodic certification while access continues; and

4. prompt revocation when access is no longer required.

1.21 Access by applications and automated systems

Access control applies to machines as well as people.

Applications, APIs, bots, service accounts, integrations and AI tools should receive only the information necessary for their authorised function.

An analytics tool requiring aggregate sales trends should not automatically receive names, contact information and payment records. A chatbot assisting with general customer questions should not receive the customer’s complete account history before identity and necessity are established.

1.22 Logs, monitoring and review

Rule 6(1)(c) requires visibility over access to personal data through appropriate logs, monitoring and review. The objective is to detect unauthorised access, investigate it, remediate the weakness and prevent recurrence.

1.23 What should be logged

Depending on the system and risk, relevant events may include:

• successful and unsuccessful logins;

• multifactor-authentication failures;

• access to sensitive records;

• searches involving large numbers of Data Principals;

• bulk downloads;

• exports;

• printing;

• copying;

• deletion;

• modification;

• changes to permissions;

• creation of privileged accounts;

• API calls;

• changes to security configurations;

• access to backups;

• vendor-support sessions; and

• transmission of data to another system.

The appropriate level of detail depends on the processing. A bank or hospital may need more granular logging than a small customer-contact system.

1.24 Logging is not the same as monitoring

An organisation does not comply merely because the application automatically generates log files.

Logs must be capable of being used. This requires:

• accurate timestamps;

• sufficient detail;

• secure central storage;

• restricted access;

• protection against alteration;

• alerts for suspicious behaviour;

• periodic review;

• escalation procedures;

• trained investigators; and

• documented resolution.

1.25 Illustration: Unreviewed data export

An employee downloads 50,000 customer records outside ordinary working hours. The system records the event, but no alert is generated and nobody reviews the logs for six months.

The organisation technically had logs, but lacked effective monitoring and review. The Rule requires visibility that enables detection, not merely passive generation of records.

1.26 Protection of logs

Logs themselves may contain personal data, including:

• usernames;

• IP addresses;

• device identifiers;

• actions performed;

• records accessed;

• location information; and

• communication metadata.

They must therefore be protected against unauthorised access and misuse.

The person whose actions are recorded should not ordinarily be able to alter or delete the relevant logs without detection. Administrative access to logging systems should be separately controlled.

1.27 Security monitoring must remain purpose-bound

The Rule supports monitoring for security. It does not automatically authorise unlimited surveillance of employees or customers.

Security logs collected to detect unauthorised access should not be silently repurposed for unrelated employee productivity scoring, marketing analysis or behavioural profiling without a separate legal assessment.

1.28 Investigation, remediation and prevention of recurrence

Rule 6 treats detection, investigation and remediation as connected stages of security management.

1.29 Detection

The organisation must be capable of identifying events suggesting that personal data has been:

• accessed without authority;

• disclosed incorrectly;

• altered;

• destroyed;

• encrypted by an attacker;

• copied in unusual volume;

• transferred to an unknown destination; or

• made unavailable.

Detection may arise through technical alerts, reports by employees, complaints by Data Principals, Processor notifications, law-enforcement intelligence or external researchers.

1.30 Investigation

The investigation should determine:

• what occurred;

• when it began;

• how it was detected;

• which systems were affected;

• which personal data was involved;

• whether the data was viewed, copied, altered or destroyed;

• which Data Principals were affected;

• whether a Processor was involved;

• whether the incident is continuing;

• whether the information remains usable to the attacker;

• what immediate containment is required; and

• whether notification obligations arise.

Evidence should be preserved carefully. A hurried attempt to rebuild or erase a compromised system may destroy information necessary to determine the scope of the breach.

1.31 Remediation

Remediation addresses the immediate weakness. It may require:

• disabling compromised accounts;

• resetting credentials;

• rotating encryption keys;

• patching vulnerable systems;

• correcting cloud permissions;

• removing malicious software;

• blocking unauthorised connections;

• restricting data exports;

• restoring trusted versions of records;

• correcting access roles; or

• suspending affected vendor access.

1.32 Preventing recurrence

Rule 6 expressly connects remediation with prevention of recurrence. Restoring normal operations is insufficient if the root cause remains.

1.33 Illustration: Repeated credential compromise

An employee account is compromised because the organisation uses password-only authentication. The company resets the password and closes the incident.

If it does not address the weak authentication model, similar compromise remains likely. Effective recurrence prevention may require multifactor authentication, login anomaly detection, improved training and stronger account-recovery controls.

1.34 Illustration: Excessive vendor access

A vendor-support account is used to download personal data outside the authorised task. The company asks the vendor to delete the file but leaves the same unrestricted account active.

The immediate file may have been addressed, but the systemic access problem remains. Remediation should include restriction or removal of the account, investigation of contractual compliance, review of similar accounts and implementation of monitored, time-limited access.

1.35 Continuity, recoverability and backups

Rule 6(1)(d) requires reasonable measures for continued processing when confidentiality, integrity or availability is compromised. Backups are expressly recognised as one such measure.

1.36 Confidentiality, integrity and availability

The Rule extends beyond unauthorised disclosure.

Confidentiality concerns unauthorised access or disclosure.

Integrity concerns unauthorised or accidental alteration, destruction or corruption.

Availability concerns the ability of authorised persons and systems to access accurate information when needed.

A personal data breach can therefore occur where information:

• is disclosed to the wrong person;

• is altered incorrectly;

• is deleted accidentally;

• becomes unavailable through ransomware;

• is corrupted;

• cannot be decrypted because keys are lost; or

• cannot be restored after system failure.

1.37 Continued processing does not mean uninterrupted processing at any cost

The organisation should maintain or restore processing that is necessary, secure and lawful. It need not continue every activity during a security incident.

A hospital may urgently need to restore access to patient-treatment records. A payroll system may need to recover employee payment information. By contrast, optional advertising analytics can remain suspended until the environment is verified as secure.

Continuing unsafe processing may worsen the breach. Systems should resume only after reasonable assurance concerning containment, integrity and access control.

1.38 Effective backups

A backup must be more than a duplicate file. It should be:

• complete enough to meet the recovery objective;

• created with an appropriate frequency;

• encrypted where necessary;

• protected by access controls;

• separated from production;

• resistant to the incident affecting the primary system;

• monitored;

• tested for restoration;

• covered by retention and deletion arrangements; and

• accessible to authorised recovery personnel.

1.39 Illustration: Ransomware

A company creates daily backups but stores them on the same network and under the same credentials as its production system. Ransomware encrypts both.

The backups existed, but they did not provide meaningful resilience. Appropriate measures may require isolated, immutable or otherwise protected backup copies and tested restoration procedures.

1.40 Illustration: Backup without restoration testing

An organisation has years of backups but has never tested recovery. After a database failure, it discovers that the backup files are incomplete.

Rule 6 concerns continued processing, not merely backup creation. Restoration testing is therefore essential evidence that the continuity safeguard is effective.

1.41 Retention of logs and personal data for one year

Rule 6(1)(e) requires relevant logs and personal data to be retained for one year to enable:

• detection of unauthorised access;

• investigation;

• remediation;

• prevention of recurrence; and

• continued processing following a compromise.

A different period applies where another law requires otherwise.

1.42 This is not a universal command to retain everything for one year

The provision should not be read to mean that every item of personal data processed by every Data Fiduciary must always be retained for at least one year.

The retention is expressly connected to security and continuity purposes. The Data Fiduciary should identify which logs and personal data are necessary for those purposes.

Example

For example:

• authentication logs may be required to investigate compromised credentials;

• access logs may be needed to determine which records were viewed;

• transaction records may be required to reconstruct unauthorised changes;

• configuration records may be needed to identify how access occurred;

• selected personal data may be necessary to identify affected Data Principals or restore corrupted information.

This does not automatically justify retaining every customer document, communication, marketing profile and historical dataset for one year.

1.43 Nor is one year a universal deletion deadline

Other laws may require longer retention. Financial, taxation, corporate, employment, anti-money-laundering and sectoral legislation may prescribe periods extending beyond one year.

The Rule expressly preserves such requirements. Where another law requires longer retention, the Data Fiduciary must comply with that law while continuing to protect the retained information.

Similarly, expiry of one year does not mean deletion is lawful if:

• litigation is pending;

• a legal claim must be established or defended;

• an investigation is continuing;

• another retention obligation applies; or

• the information remains necessary for another lawful purpose.

1.44 Relationship with Section 8(7)

Section 8(7) requires erasure when consent is withdrawn or the specified purpose is no longer being served, whichever is earlier, unless retention is necessary for compliance with law.

Rule 6(1)(e) creates a specific retention requirement for defined security purposes. The two provisions should be applied together.

The correct approach is:

1. identify the erasure trigger;

2. determine whether Rule 6 requires particular records for security purposes;

3. retain only the information necessary for those purposes;

4. identify any longer statutory retention requirement;

5. restrict retained information from ordinary or unrelated processing; and

6. erase it securely when the applicable legal justification ends.

Rule 6 should not become a pretext for indefinite or indiscriminate retention.

1.45 Restriction on secondary use

Information retained for security investigation should not automatically be used for:

• advertising;

• customer profiling;

• employee productivity assessment;

• commercial analytics;

• AI training;

• product development; or

• another unrelated purpose.

The retention basis and access permissions should reflect the security purpose.

1.46 Data Processor contracts

Rule 6(1)(f) requires appropriate provisions in contracts between Data Fiduciaries and Data Processors.

This provision recognises that security cannot be assured through informal expectations. The Data Fiduciary must translate its security requirements into enforceable contractual obligations.

1.47 Substance of the contract

An appropriate contract should address the actual processing arrangement. Depending on the service, it may need to specify:

• the personal data processed;

• permitted operations;

• authorised systems and locations;

• confidentiality obligations;

• access-control standards;

• protection of privileged accounts;

• encryption or equivalent measures;

• logging and monitoring;

• vulnerability management;

• patching;

• security testing;

• incident detection;

• notification to the Data Fiduciary;

• evidence preservation;

• investigation assistance;

• backup and recovery;

• subprocessors;

• data return;

• erasure;

• audit and assurance rights;

• regulatory cooperation;

• changes to the service;

• business continuity; and

• termination assistance.

A short clause stating that the Processor will maintain “industry-standard security” may not be sufficient where the processing involves high-volume, consequential or vulnerable personal data.

1.48 Contractual wording does not prove actual security

The Data Fiduciary must not treat signature of a contract as the end of Processor oversight.

A Processor may agree to maintain encryption, access controls and incident detection but fail to implement them. Reasonable oversight may require:

• pre-contract due diligence;

• review of technical information;

• certification or assurance reports;

• examination of the relevant service scope;

• periodic reassessment;

• review of material security incidents;

• recovery-testing evidence;

• tracking of remediation;

• control over subprocessors; and

• audit where risk justifies it.

1.49 Processor selection

Although the DPDPA does not reproduce the GDPR’s precise formulation requiring processors that provide “sufficient guarantees,” a Data Fiduciary cannot realistically satisfy Section 8(5) by appointing a Processor whose capabilities it has never assessed.

The depth of assessment should correspond to risk.

A vendor sending occasional operational communications may require a different review from a Processor holding:

• complete payroll data;

• health records;

• identity documents;

• payment data;

• children’s profiles; or

• millions of customer records.

1.50 Processor incidents

The contract should require the Processor to inform the Data Fiduciary promptly enough to enable:

• containment;

• investigation;

• identification of affected Data Principals;

• compliance with Rule 7;

• preservation of evidence;

• response to the Board; and

• prevention of further processing or disclosure.

A Processor should not delay notification until every forensic question has been answered. The Data Fiduciary may need early information to comply with its own legal duties.

1.51 Subprocessors

Where a Processor uses another provider, the Data Fiduciary should understand:

• who the subprocessor is;

• what processing it conducts;

• where processing occurs;

• what personal data it receives;

• what security standards apply;

• how incidents are escalated;

• whether further delegation is permitted; and

• how the data is returned or deleted.

The security chain is only as effective as its weakest material participant.

1.52 Certification and processor assurance

External certification can provide useful evidence that an organisation maintains a structured information-security management system. It does not automatically establish compliance with Rule 6.

1.53 What certification can demonstrate

A valid certification may support confidence that the Processor has:

• an information-security management framework;

• defined responsibilities;

• a risk-assessment process;

• documented policies;

• internal audits;

• corrective-action processes;

• management review; and

• a programme of continual improvement.

This may provide stronger evidence than an unsupported vendor statement.

1.54 What certification does not necessarily demonstrate

Certification may not establish that:

• the relevant legal entity is certified;

• the specific product is within scope;

• every processing location is covered;

• the encryption used is sufficient;

• privileged access is appropriately controlled;

• logs are retained for the relevant Rule 6 period;

• backups meet the customer’s recovery needs;

• subprocessors are adequately governed;

• known vulnerabilities have been remediated;

• customer data is not used for an independent purpose; or

• the Processor satisfies non-security DPDPA obligations.

1.55 Illustration: Incorrect scope

A vendor provides an ISO/IEC 27001 certificate covering its corporate office and internal management systems. The service used by the Data Fiduciary is operated through another group company and a separate data centre outside that scope.

The certificate may be genuine but provide limited assurance for the actual processing.

1.56 No automatic safe harbour

Rule 6 does not create a legal safe harbour for certified organisations. Certification is evidence, not a substitute for judgment.

A Data Fiduciary should verify:

• certificate authenticity;

• validity;

• accreditation;

• certified entity;

• services and systems covered;

• locations;

• exclusions;

• applicable controls;

• material findings;

• recent incidents; and

• changes since certification.

The appropriate conclusion is not “the vendor is certified, therefore Rule 6 is satisfied.” It is “the certification supports baseline assurance for the processing within scope, subject to verification of the controls and risks relevant to this service.”

1.57 Technical and organisational measures

Rule 6(1)(g) requires appropriate technical and organisational measures to ensure effective observance of security safeguards.

This clause prevents security from being treated solely as an IT department issue.

1.58 Technical measures

Technical safeguards operate through systems and technology. Depending on risk, they may include:

• encryption;

• tokenisation;

• masking;

• network segmentation;

• multifactor authentication;

• privileged-access management;

• endpoint protection;

• secure configuration;

• vulnerability scanning;

• patch management;

• penetration testing;

• intrusion detection;

• data-loss prevention;

• database monitoring;

• secure APIs;

• backup isolation;

• integrity verification; and

• secure deletion.

1.59 Organisational measures

Organisational safeguards establish responsibility and disciplined operation. They may include:

• executive oversight;

• approved security policies;

• data and system ownership;

• risk assessments;

• access-approval procedures;

• background checks proportionate to role;

• confidentiality obligations;

• employee training;

• incident-response planning;

• Processor due diligence;

• audit;

• change management;

• business-continuity planning;

• exception management;

• disciplinary procedures; and

• management reporting.

1.60 Effective observance

The word “effective” is crucial. The Data Fiduciary should verify whether the control works.

Example

For example:

• an access policy should be tested against actual permissions;

• a backup policy should be tested through restoration;

• an incident plan should be exercised;

• Processor clauses should be supported by assurance;

• security training should address actual employee behaviour;

• monitoring rules should generate and escalate meaningful alerts;

• deletion procedures should reach all relevant systems.

A beautifully drafted policy that nobody follows is not effective observance.

1.61 Human error, insider conduct and physical security

Rule 6 is technologically framed but not limited to external hacking.

Personal data breaches frequently arise from:

• misdirected emails;

• incorrect attachments;

• exposed spreadsheets;

• shared passwords;

• employee curiosity;

• malicious insiders;

• unattended records;

• stolen devices;

• improper disposal;

• unauthorised photographs of screens;

• excessive printing;

• discussion of confidential information in public places; or

• use of unapproved applications.

Reasonable safeguards may therefore require:

• role-specific training;

• confidentiality commitments;

• restrictions on copying and printing;

• clean-desk practices;

• secure disposal;

• device controls;

• review of unusual employee access;

• sanctions for deliberate misuse;

• physical access restrictions; and

• prompt reporting of mistakes.

1.62 Illustration: Wrong email recipient

An employee sends a document containing salary and bank information to the wrong external recipient because email autocomplete selected a similar name.

Appropriate safeguards may involve:

• warnings for external recipients;

• encryption;

• delay-send functionality;

• prevention of certain attachments leaving the organisation;

• second-person review for high-risk transfers; and

• training.

The reasonableness of the response depends on the frequency, risk and foreseeability of the error.

1.63 Cloud, remote work and portable devices

Cloud processing does not reduce Rule 6 obligations. It changes the allocation of technical responsibility.

The cloud provider may secure physical infrastructure and platform components, while the Data Fiduciary remains responsible for matters such as:

• identity and access;

• configuration;

• encryption choices;

• public exposure;

• data classification;

• logging;

• retention;

• application security;

• user permissions; and

• vendor oversight.

A breach caused by an openly accessible cloud-storage bucket may arise from the Data Fiduciary’s configuration even if the cloud provider’s underlying infrastructure was secure.

Remote work similarly requires controls addressing:

• secure connectivity;

• managed devices;

• personal-device use;

• local downloads;

• paper records;

• screen visibility;

• removable media;

• patching;

• home-network risk;

• loss or theft; and

• access revocation.

Portable devices containing personal data should be protected according to the consequences of loss, including through device encryption, strong authentication, remote management and restrictions on local storage.

1.64 Artificial intelligence systems

Rule 6 applies wherever an AI system processes personal data on behalf of a Data Fiduciary. AI introduces security risks beyond ordinary database access.

1.65 Prompts and outputs

Employees may enter personal data into generative AI systems for drafting, analysis or summarisation. Relevant risks include:

• retention of prompts;

• vendor use of inputs for model improvement;

• exposure to vendor personnel;

• insecure plugins;

• transfer to subprocessors;

• output of another person’s information;

• prompt-injection attacks;

• retrieval from excessive internal sources; and

• inability to delete submitted data.

A Data Fiduciary should not permit unrestricted use of public AI tools for customer, employee or confidential information.

1.66 Illustration: HR use of an AI assistant

An HR employee enters an employee’s name, salary, performance assessment and disciplinary history into an unapproved AI writing service.

From a Rule 6 perspective, potential failures include:

• unauthorised external disclosure;

• absence of Processor assessment;

• lack of contractual safeguards;

• unknown retention;

• possible vendor model training;

• inadequate access control; and

• inability to investigate or erase the information.

The employee’s helpful intention does not eliminate the security failure.

1.67 Training data

Training environments should address:

• lawful and authorised data sources;

• access control;

• removal of unnecessary identifiers;

• separation from production systems;

• logging;

• export restrictions;

• secure development environments;

• protection against dataset poisoning;

• model memorisation;

• retention;

• deletion; and

• vendor access.

Customer data generated during ordinary service should not flow automatically into AI training because the technical platform supports it.

1.68 Model memorisation and leakage

A trained model may reproduce or reveal personal data under targeted prompting. Security testing may therefore need to consider:

• memorisation;

• model inversion;

• membership inference;

• extraction attacks;

• output filtering;

• retrieval permissions;

• rate limits;

• red-team testing; and

• deletion or unlearning arrangements.

If a retrieval-augmented AI assistant can search internal files, its responses should respect the requesting user’s underlying permissions. The AI must not become a route through which an employee accesses files that the employee could not view directly.

1.69 Relationship with breach notification

Rule 6 must be read with Section 8(6) and Rule 7.

Rule 6 enables an organisation to detect, investigate and understand the incident. Rule 7 governs notification to affected Data Principals and the Board.

A functioning process should connect:

1. security alert;

2. internal escalation;

3. containment;

4. investigation;

5. identification of affected data and individuals;

6. assessment of consequences;

7. notification;

8. recovery;

9. root-cause remediation; and

10. prevention of recurrence.

An organisation without reliable logs may be unable to identify affected persons or explain the scope of the incident. An organisation without Processor-notification clauses may learn of a vendor breach too late to comply with Rule 7.

Security and notification should therefore form one integrated incident-management framework.

1.70 Erasure and secure disposal

The obligation to protect personal data continues for as long as the Data Fiduciary possesses or controls it.

When erasure becomes necessary, it must be performed securely. Simply removing a record from the visible application may not erase:

• copies;

• exports;

• email attachments;

• archives;

• caches;

• test systems;

• analytics environments;

• Processor systems;

• AI datasets; or

• backups.

Deletion should be planned at system-design stage.

Where immediate removal from a protected backup is not technically feasible, the organisation should ensure that:

• the information is no longer used in ordinary processing;

• the backup remains isolated and secure;

• any restored copy is subjected again to the deletion instruction;

• the information exits through the defined backup cycle; and

• no indefinite exception is created merely because the data resides in a backup.

Secure deletion also requires evidence. The Data Fiduciary should record the completion of erasure without creating another unnecessary copy of the information supposedly deleted.

1.71 Interaction with other cybersecurity requirements

Rule 6 operates in addition to other applicable laws and regulatory requirements.

Depending on the organisation, parallel obligations may arise under:

• the Information Technology Act, 2000;

• CERT-In directions;

• banking regulation;

• securities regulation;

• insurance regulation;

• telecommunications requirements;

• health-sector obligations;

• employment laws;

• contractual commitments; and

• government-security standards.

A sectoral regulator may require:

• shorter incident-reporting periods;

• longer log retention;

• particular encryption standards;

• periodic penetration testing;

• localisation;

• outsourcing approval;

• specialised business-continuity arrangements; or

• additional security audits.

Those requirements ordinarily operate cumulatively with Rule 6. Compliance with a sectoral cybersecurity audit does not automatically establish compliance with the DPDPA, and compliance with Rule 6 does not remove separate sectoral obligations.

1.72 Demonstrating compliance

Rule 6 implicitly demands demonstrability. If an incident occurs, the Data Fiduciary should be able to show what safeguards existed and how they operated.

Relevant evidence may include:

• personal-data inventories;

• system inventories;

• data-flow maps;

• risk assessments;

• information-classification records;

• access-control matrices;

• privileged-access records;

• access-review reports;

• encryption standards;

• key-management procedures;

• vulnerability assessments;

• patching records;

• penetration-test reports;

• security alerts;

• log-review records;

• incident reports;

• investigation findings;

• remediation records;

• recurrence-prevention measures;

• backup inventories;

• restoration-test results;

• continuity exercises;

• Processor due diligence;

• contracts;

• certification reviews;

• audit reports;

• security-training records;

• retention schedules; and

• deletion evidence.

The quality of evidence matters. A policy dated shortly after the incident may not establish what safeguards existed before the breach. A certification covering another service may not prove security of the affected processing. A screenshot of a configured control may not prove that it operated continuously.

1.73 Testing effectiveness

A meaningful review should test questions such as:

• Do departed employees still have access?

• Can ordinary users view unmasked data?

• Are privileged accounts separately monitored?

• Do alerts trigger when large exports occur?

• Can backups actually be restored?

• Does the Processor report incidents promptly?

• Are development systems using real personal data unnecessarily?

• Can an unauthorised user obtain personal data through an AI assistant?

• Are logs protected from administrators who are being monitored?

• Does deletion reach downstream Processors?

• Have earlier audit findings been closed?

The strongest compliance evidence is not the number of policies held by the organisation. It is proof that the safeguards worked, weaknesses were identified and corrective measures were completed.

1.74 Enforcement and penalty exposure

The Schedule assigns the highest original penalty ceiling under the DPDPA to failure to take reasonable security safeguards under Section 8(5): up to ₹250 crore.

That amount is a maximum, not a standard fine imposed whenever a personal data breach occurs.

The Board must determine:

• whether the security obligation was breached;

• whether the breach was significant;

• the nature, gravity and duration of the failure;

• the type and nature of the personal data affected;

• whether the conduct was repetitive;

• whether the person obtained a gain or avoided a loss;

• whether mitigation was timely and effective;

• what amount would be proportionate and deterrent; and

• the likely impact of the penalty on the person.

Potentially aggravating circumstances include:

• failure to implement basic protections;

• shared or default credentials;

• known critical vulnerabilities left unpatched;

• absence of usable logs;

• ignored security alerts;

• unrestricted privileged access;

• unencrypted high-risk information;

• insecure vendor access;

• repeated incidents;

• concealment;

• absence of tested backups;

• ineffective Processor contracts;

• refusal to remediate; and

• exposure involving children, financial information, health data, identity records or biometrics.

Potentially mitigating considerations may include:

• robust controls in place before the incident;

• rapid detection;

• strong containment;

• encrypted information where keys were not compromised;

• effective cooperation;

• accurate notification;

• limited duration;

• prompt assistance to affected persons;

• independent investigation;

• complete remediation; and

• convincing measures preventing recurrence.

Security failure and notification failure remain distinct. A Data Fiduciary may face one finding for inadequate safeguards under Section 8(5) and another for failure to provide required breach notices under Section 8(6).

1.75 Overall interpretation

Rule 6 establishes a security framework with four connected dimensions.

First, it is preventive. Personal data must be protected through appropriate data-security techniques, access restrictions, Processor controls and organisational governance.

Second, it is detective. The Data Fiduciary must maintain visibility through logs, monitoring and review so that unauthorised access does not remain invisible.

Third, it is corrective. The organisation must investigate incidents, remediate weaknesses and prevent recurrence.

Fourth, it is resilient. It must maintain the ability to restore necessary and lawful processing when confidentiality, integrity or availability is compromised.

The Rule also establishes three important boundaries:

• outsourcing does not transfer statutory responsibility;

• certification does not replace processing-specific assurance; and

• the one-year security-retention requirement is neither a universal instruction to retain everything nor a universal deadline to delete everything.

A compliant Data Fiduciary must be able to explain not only what controls it has, but:

• which risks those controls address;

• where they apply;

• how they extend to Processors;

• how their effectiveness is tested;

• how incidents are detected and investigated;

• how the organisation recovers;

• what records are retained;

• why those records are retained; and

• how weaknesses are prevented from recurring.

Key point

Rule 6 requires security to be appropriate, operational and demonstrable. Personal data must be protected before a breach, visible during an incident, recoverable after disruption and subject to meaningful corrective action. The Data Fiduciary retains responsibility for that complete security lifecycle, including where the personal data is processed through vendors, cloud infrastructure, outsourced platforms or artificial-intelligence systems.