DPDPA Section 8: Fiduciary Obligations

Section 8 - The Operational Core of DPDPA Compliance

If Section 4 is the gateway to lawful processing and Sections 5-7 govern how processing is authorised, Section 8 is the operational core - it defines what Data Fiduciaries must do once they are processing personal data. Section 8 imposes six categories of general obligations on every Data Fiduciary, regardless of size, sector, or volume of data processed. These obligations apply to startups and conglomerates alike, to private companies and government agencies, to domestic businesses and foreign entities processing Indian personal data. The penalties for failing to meet these obligations are among the highest in the Act - up to two hundred and fifty crore rupees for failure to implement reasonable security safeguards resulting in a data breach. Understanding and implementing Section 8 is not optional - it is the minimum compliance standard that every Data Fiduciary must meet from the day the Act's provisions come into force.

Section 8(1): Data Accuracy and Completeness

Section 8(1) requires that a Data Fiduciary make reasonable effort to ensure the completeness, accuracy, and consistency of personal data, especially where such data is likely to be used to make a decision that affects the Data Principal or is likely to be disclosed to another Data Fiduciary. This obligation recognises that inaccurate data can cause real harm. If an employer maintains incorrect salary records that lead to wrong tax deductions, or if a lender uses outdated credit information to deny a loan, the Data Principal suffers tangible consequences. The standard is 'reasonable effort' - not absolute perfection. What constitutes reasonable effort depends on the context: for high-impact decisions like credit scoring, employment verification, or healthcare, the standard is higher. For low-impact processing like website analytics, the standard is lower. Practical measures include implementing data validation rules at the point of collection, providing self-service portals for Data Principals to update their information, conducting periodic data quality audits, and establishing workflows to flag and correct inconsistencies across systems.

• Ensure accuracy and completeness especially for data used in decision-making
• Higher standards apply to high-impact data: credit, healthcare, employment, government benefits
• Implement data validation at collection points and periodic quality audits
• Provide Data Principals with self-service mechanisms to update their data

Section 8(2): Reasonable Security Safeguards

Section 8(2) requires every Data Fiduciary to protect personal data in its possession or under its control by taking reasonable security safeguards to prevent a personal data breach. This is arguably the most consequential obligation in the entire Act because a failure to implement reasonable security safeguards that results in a data breach attracts the highest penalty - up to two hundred and fifty crore rupees. The Act does not prescribe specific technical measures, using instead the standard of 'reasonable security safeguards'. This gives organisations flexibility to implement measures proportionate to their risk profile but also creates uncertainty about what the Data Protection Board will consider adequate. Drawing from industry standards and international best practices, reasonable security safeguards should include encryption of personal data at rest and in transit, access controls and authentication mechanisms, regular vulnerability assessments and penetration testing, employee security awareness training, incident response planning, network security measures including firewalls and intrusion detection, and secure software development practices. The Board will likely consider the nature and sensitivity of data, the size and resources of the organisation, industry standards, and whether the organisation followed recognised frameworks like ISO 27001 or NIST when assessing reasonableness.

• Encryption of personal data at rest and in transit
• Role-based access controls and multi-factor authentication
• Regular vulnerability assessments, penetration testing, and security audits
• Employee security awareness training and acceptable use policies
• Incident response plan tested through periodic tabletop exercises
• Adoption of recognised security frameworks such as ISO 27001 or SOC 2

Section 8(3)-(5): Data Breach Notification

Section 8(6) requires the Data Fiduciary to notify the Data Protection Board and each affected Data Principal in the event of a personal data breach. The notification must be made in such form and manner as may be prescribed by rules. While the specific timelines and formats await prescription through rules, the obligation itself is immediate once the Act's provisions are in force. The notification to the Board should include the nature of the breach, the categories and approximate number of Data Principals affected, the likely consequences, and the measures taken or proposed to mitigate the breach. The notification to affected Data Principals should include a description of the breach in plain language, the likely consequences for them, and the steps they can take to protect themselves. International best practice and the likely rules will require notification without undue delay - typically within seventy-two hours of becoming aware of the breach. Organisations must establish breach detection and response capabilities to meet this timeline, including automated monitoring, incident classification procedures, communication templates, and designated response teams. The Indian Computer Emergency Response Team (CERT-In) also imposes parallel reporting obligations that must be coordinated with DPDPA requirements.

• Notify the Data Protection Board of India of every personal data breach
• Notify each affected Data Principal individually
• Notification form and manner to be prescribed by rules - expect 72-hour standards
• Include breach nature, scope, consequences, and mitigation measures in notification
• Establish breach detection, classification, and response workflows before a breach occurs

Section 8(7): Data Erasure and Retention Obligations

Section 8(7) imposes a dual obligation regarding data retention and erasure. First, when the purpose for which personal data was collected has been served and retention is no longer necessary for the stated purpose, the Data Fiduciary must erase the personal data. Second, where the Data Principal has not approached the Data Fiduciary for the performance of the specified purpose or has not exercised any rights under the Act, the Data Fiduciary must erase the data at the end of a prescribed period. This creates a proactive deletion obligation that connects directly to the Data Principal's right to erasure under Section 12 - organisations cannot retain personal data indefinitely 'just in case'. They must define retention periods for each category of data and each processing purpose, implement automated deletion mechanisms that trigger when retention periods expire, and handle situations where a Data Principal has gone dormant. The interaction with other legal retention requirements complicates this - tax laws may require retention of financial records for specified periods, sector-specific regulations may impose their own retention mandates, and litigation holds may require preservation of data relevant to ongoing or anticipated legal proceedings. Organisations must map these overlapping requirements and build retention policies that satisfy all applicable obligations.

• Erase data when the purpose is fulfilled and retention is no longer necessary
• Erase dormant Data Principal data after a prescribed period of inactivity
• Map legal retention requirements from tax, sectoral, and other laws before deleting
• Implement automated retention schedules and deletion workflows
• Document retention decisions for audit trail and regulatory defence

Section 8(8)-(9): Engaging Data Processors and Contractual Obligations

Section 8(8) provides that a Data Fiduciary may engage, appoint, use, or otherwise involve a Data Processor to process personal data on its behalf only under a valid contract. Section 8(9) extends the Data Fiduciary's obligations - where a Data Fiduciary engages a Data Processor, the Fiduciary remains responsible for compliance with the Act's provisions in respect of the processing carried out by the Processor. This means the Data Fiduciary cannot outsource compliance responsibility by outsourcing processing. If your payroll vendor suffers a data breach, you are responsible for notifying the Board and affected employees - not the vendor. Your contracts with Data Processors must therefore include robust obligations regarding security safeguards, breach notification, data handling instructions, sub-processor restrictions, audit rights, and data return or deletion upon termination. The contract should mirror your own Section 8 obligations and provide you with the information and access needed to comply with Data Principal rights requests, Board inquiries, and breach notification requirements. Reviewing and updating all vendor and processor contracts for DPDPA compliance is an essential but often overlooked compliance workstream.

• All Data Processor engagements must be governed by a valid contract
• The Data Fiduciary retains compliance responsibility for processing by its Processors
• Contracts must include security, breach notification, audit, and data deletion obligations
• Sub-processing restrictions and approval mechanisms should be contractually specified
• Conduct periodic audits of Data Processor compliance with contractual obligations

Section 8(10): Grievance Redressal Mechanism

Section 8(10) requires every Data Fiduciary to publish the business contact information of a Data Protection Officer or other designated person who will be responsible for answering questions and addressing grievances from Data Principals. This is a transparency and accessibility obligation - Data Principals must have a clear, accessible channel to raise concerns about how their data is being processed. The contact information must be published prominently, not hidden in fine print. Best practice is to include it in your privacy notice, on your website's privacy page, in your mobile app's settings, and in any communication related to data processing. The designated person must be empowered to respond to grievances meaningfully - not merely acknowledge receipt. Typical grievances include requests for information about what data is held, requests for correction or erasure, complaints about processing activities, and questions about security practices. Organisations should establish internal workflows to route grievances to the appropriate teams, set response time targets, track grievance resolution, and escalate unresolved issues. The Data Protection Board will consider the effectiveness of your grievance mechanism when assessing compliance and determining penalties.

• Publish business contact details of DPO or designated grievance officer
• Make contact information prominently accessible across all platforms
• Establish internal workflows for grievance routing, response, and resolution tracking
• Set response time targets aligned with reasonable expectations and eventual rules
• Document grievance handling for audit trail and regulatory reporting

What 'Reasonable' Means - The Standard That Governs Section 8

The word 'reasonable' appears throughout Section 8 - reasonable effort for data accuracy, reasonable security safeguards, reasonable timeframes. This standard is deliberately flexible, allowing the Board to assess compliance based on the specific circumstances of each organisation. However, this flexibility also creates uncertainty for businesses trying to determine what is 'enough'. Drawing from judicial interpretation of reasonableness in Indian law and international data protection enforcement, the standard is likely to be assessed considering the following factors: the nature and sensitivity of the personal data processed, the volume of data and number of Data Principals affected, the size and resources of the organisation, industry standards and prevailing practices in the relevant sector, the state of technology available at the relevant time, and the cost of implementing the measures relative to the risk. A small startup processing limited customer data will be held to a different standard than a large bank processing millions of financial records. However, no organisation - regardless of size - can claim that doing nothing is reasonable. The minimum floor includes basic encryption, access controls, breach response planning, and privacy notices. Building above this floor in proportion to your risk profile is what 'reasonable' requires.

How Kraver.ai Helps

Kraver.ai's compliance platform addresses every obligation in Section 8 through an integrated, AI-powered approach. Our data quality monitoring module continuously assesses the accuracy, completeness, and consistency of personal data across your systems, flagging issues before they affect decision-making or regulatory compliance. The security posture assessment evaluates your technical and organisational measures against the 'reasonable security safeguards' standard, benchmarking you against industry peers and recognised frameworks like ISO 27001. Our breach detection and response module provides automated monitoring, incident classification, and notification workflow management - including pre-built templates for Board and Data Principal notifications aligned with expected regulatory formats. For data retention and erasure, Kraver.ai maps your retention obligations across DPDPA and sector-specific requirements, implements automated retention schedules, and manages deletion workflows with audit trails. The vendor management module tracks Data Processor contracts, monitors compliance, and alerts you to gaps in contractual obligations. And our grievance management system provides a branded portal for Data Principal inquiries, automated routing, SLA tracking, and resolution documentation. Start your comprehensive Section 8 compliance journey with Kraver.ai today.