Skip to main content

BRD-CMS

ASK for Consent Management System (CMS)

This document provides a knowledge-base friendly summary of the Approach (A), Scope (S) and Key Requirements (K) drawn from the Business Requirements Document for Consent Management under the Digital Personal Data Protection (DPDP) Act, 2023.

1. Approach (A)​

1.1 Purpose​

The Consent Management System (CMS) outlined in the BRD is designed to:

  • Support complete consent lifecycle management (collection, validation, update, renewal, withdrawal).
  • Provide transparency and control to Data Principals.
  • Enable Data Fiduciaries and Processors to operate in compliance with the DPDP Act.
  • Ensure auditability and reporting for regulators and stakeholders.

1.2 Guiding Principles​

  • User-Centricity: WCAG-compliant UI, multi-language support, granular and purpose-specific consent.
  • Compliance-First: Adherence to DPDP Act 2023 (purpose limitation, data minimization, secure processing).
  • Transparency and Accountability: Immutable audit logs, real-time notifications, grievance redressal.
  • Modularity: Clear functional modules—Consent Lifecycle, Cookie Consent, User Dashboard, Notifications, Grievance Mechanisms, Administration, and Logging.

1.3 Stakeholders​

  • Data Principals (users whose data is processed).
  • Data Fiduciaries (entities deciding purposes and means of processing).
  • Data Processors (entities processing data on behalf of Fiduciaries).
  • Data Protection Officers (DPOs) (oversight of compliance and grievance escalation).

2. Scope (S)​

2.1 Core Modules​

The BRD-CMS encompasses the following modules:

ModulePurpose
Consent Management LifecycleCollection, Validation, Update, Renewal, Withdrawal of consent artifacts.
Cookie ConsentGranular management of web/app tracking technologies.
User DashboardView consent history, modify/revoke consent, raise grievances/data requests.
Consent NotificationsUser and Fiduciary/Processor notifications with real-time updates.
Grievance RedressalComplaint logging, resolution tracking, escalation, and feedback.
System AdministrationRole management and data retention configuration.
Logging & AuditComprehensive immutable logs for every consent action.

2.2 Out of Scope​

  • Direct policy drafting for DPDP compliance (the BRD assumes legal rules already defined).
  • Non-consent-based processing exceptions under law (retained separately by Data Fiduciary).
  • External security certification and penetration testing (to be addressed in later phases).

2.3 Interfaces​

  • APIs for real-time consent validation and notification to Data Fiduciaries and Processors.
  • Dashboards for Data Principals, DPOs, and administrators.
  • Cookie Banners and preference panels for web and mobile.

3. Key Requirements (K)​

The BRD specifies the following detailed functional and non-functional requirements:

PhaseHighlights
CollectionPurpose-specific notices, explicit affirmative action, metadata logging, multi-language support, real-time synchronization of consent artifacts.
ValidationAPI-based real-time check of consent status (granted, expired, withdrawn), metadata validation, scope enforcement, audit logging.
UpdateNotify users when processing purposes change; allow granular updates and maintain metadata (timestamp, user ID, purpose IDs).
RenewalProvide time-limited consents with renewal reminders, seamless re-affirmation, and updated consent artifacts.
WithdrawalImmediate halt of processing upon withdrawal, notify all stakeholders, update consent artifact to “Withdrawn,” retain immutable logs.
  • Display banners on first visit.
  • Provide granular control (essential, performance, analytics, marketing).
  • Store and audit cookie preferences.
  • Auto-expiry of preferences per policy.
  • Notify users of cookie policy changes and request renewed consent.

3.3 User Dashboard Requirements​

  • View Consent History: Show all active, expired, withdrawn consents with metadata and export capability.
  • Modify/Revoke Consent: Immediate effect on data processing, stakeholder notifications.
  • Raise Grievances/Data Requests: Complaint form, reference ID generation, escalation workflow, real-time status updates.

3.4 Notification Requirements​

  • User Notifications: Renewal reminders, withdrawal confirmations, processing updates.
  • Fiduciary/Processor Alerts: Secure API-based alerts for consent changes, real-time compliance adjustments, escalation if unacknowledged.

3.5 Grievance Redressal Requirements​

  • Complaint logging with categories and secure submissions.
  • Resolution tracking dashboard with escalation triggers.
  • User notifications and feedback collection.
  • Integration with consent records for context.

3.6 Administration Requirements​

  • User Role Management: Role-Based Access Control, MFA, and SSO.
  • Data Retention Configuration: Automated purging of expired records, exception handling, secure deletion protocols.

3.7 Logging & Audit Requirements​

  • Immutable audit logs capturing user ID, purpose, timestamp, action type, and cryptographic hash.
  • Role-based access control to logs.
  • Audit readiness reports for regulators.

3.8 Non-Functional Requirements​

  • Security: TLS 1.3 encryption, MFA for admins, cryptographic erasure for deletion.
  • Performance: Real-time API response for consent validation and updates.
  • Scalability: Support for high volumes of concurrent users and consent artifacts.
  • Accessibility & Inclusivity: Support for all Eighth Schedule languages and WCAG compliance.