Security Safeguard Requirements (R.6)

Rule 6 goes beyond the Act's general 'reasonable security safeguards' standard by prescribing specific technical measures: 1. Encryption (Rule 6(1)(a)): Personal data must be encrypted both in transit and at rest using appropriate cryptographic standards - a core requirement of Rule 6(1)(a). 2. Obfuscation (Rule 6(1)(a)): Techniques to obscure personal data elements to prevent unauthorised identification - explicitly listed as a primary technical safeguard. 3. Masking (Rule 6(1)(a)): Partial concealment of personal data fields (e.g., displaying only the last four digits of Aadhaar or bank account numbers). 4. Virtual Tokenisation (Rule 6(1)(a)): Rule 6(1)(a) includes 'the use of virtual tokens mapped to that personal data' - replacing personal data with non-sensitive tokens that can be mapped back only through a secure token vault. 5. Access Controls (Rule 6(1)(b)): Limiting access to personal data to authorised personnel only, with role-based access mechanisms - aligned with Rule 6(1)(b) on 'appropriate measures to control access to the computer resources.' 6. Log Retention (Rule 6(1)(e)): Rule 6(1)(e) explicitly mandates a one-year retention period for logs of all activities related to personal data processing.

The standard of safeguards must be commensurate with: • The nature of personal data being processed (sensitivity, volume) • The risks involved in the processing activity • The potential impact on Data Principals in case of a breach • The state of art of available security technologies This proportionality principle means that organisations processing large volumes of data or data that could cause significant harm if breached must implement more robust safeguards than those processing limited, low-risk data. While the proportionality principle is a general legal doctrine, it is operationalised in the DPDP framework through the classification of Significant Data Fiduciaries (SDFs), who face higher standards based on volume and risk (Section 10).

Organisations should take the following steps to comply with Rule 6: • Conduct a security assessment to identify gaps against Rule 6 requirements • While Rule 6 does not name specific algorithms (to remain technology-neutral), implement AES-256 or equivalent encryption for data at rest and TLS 1.2+ for data in transit - the current 'appropriate cryptographic standards' recognised by MeitY and CERT-In • Deploy data masking solutions for customer-facing interfaces and support systems • Implement tokenisation for payment data, identity numbers, and other high-risk data elements • Configure role-based access controls (RBAC) with least-privilege principles • Deploy comprehensive logging solutions covering data access, modification, and deletion events • Ensure log integrity through write-once storage or tamper-evident mechanisms - this supports Rule 6(1)(c) and (e) by ensuring logs used for 'investigation and remediation' cannot be altered by an attacker • Conduct periodic security audits to verify ongoing compliance • Document all security measures for regulatory review

Rule 6 requirements align with and may augment existing security frameworks: • ISO 27001: Organisations with ISO 27001 certification will find significant overlap, but should verify coverage of DPDPA-specific requirements (particularly the 1-year log retention mandate). • RBI Guidelines: Financial institutions already subject to RBI cybersecurity frameworks may need to extend existing measures to cover all personal data, not just financial data. • CERT-In Directives: The 2022 CERT-In directions on log retention (6 months) are now superseded by Rule 6's 1-year requirement for personal data processing logs. • SOC 2: Service organisations with SOC 2 compliance will have foundational controls in place but may need to add DPDPA-specific logging and tokenisation requirements.