PDPP Act 2023 and NGO Websites: What Actually Changes for Indian Non-Profits

India's Digital Personal Data Protection Act 2023 (PDPP Act) received Presidential assent on 11 August 2023.

For Indian non-governmental organizations, this isn't an abstract policy document. It governs every form submission, every donor record, every volunteer registration, and every beneficiary database your website touches.

Most NGO websites — the vast majority of which run on shared WordPress hosting — are not ready for this.

This article explains what the Act actually requires for non-profits, where the most common compliance gaps live, and how the architectural decisions I make when building NGO platforms address them by design.

What the PDPP Act Covers That Applies to NGOs

The Act defines "personal data" broadly: any data that can identify an individual. For a typical NGO website, this includes:

• Volunteer application forms (name, phone, email, address)
• Donor records (name, contact, transaction references)
• Beneficiary registrations (especially sensitive — these often include income, health, and family details)
• Newsletter subscriber lists
• Event attendance records
• Contact form submissions

If your website collects any of these, the PDPP Act applies to your organization.

The Core Obligations for Data Fiduciaries

NGOs that collect personal data are classified as Data Fiduciaries under the Act. The key obligations:

1. Lawful Purpose and Consent

You must collect data only for a specific, lawful purpose. For each category of data, you must:

• State the purpose clearly before collection
• Obtain explicit, informed consent — not a pre-ticked checkbox
• Store consent records (who consented, when, and to what)

The typical NGO violation: A contact form with "By submitting this form you agree to our privacy policy" in tiny text at the bottom. That's not PDPP-compliant consent.

What's required: An explicit consent checkbox per data category, a clear statement of purpose, and server-side storage of the consent event with a timestamp.

2. Data Minimisation

You may only collect data that is necessary for the stated purpose.

The typical NGO violation: A volunteer registration form that asks for passport number, father's name, and alternate phone number — none of which are needed for volunteer coordination.

What's required: An audit of every form field. If you can't state why you need a field, remove it.

3. Storage Limitation

Personal data must not be retained beyond the period necessary for the stated purpose.

The typical NGO violation: A WordPress database containing 8 years of contact form submissions, donor records, and event registrations that nobody has reviewed or purged.

What's required: A defined data retention policy with automated enforcement — or at minimum, manual purge processes with documented frequency.

4. Security Safeguards

You must implement "reasonable security safeguards" to prevent breaches.

The Act doesn't define "reasonable" precisely, but the Data Protection Board (when operational) will assess adequacy. Accepted baseline for small organizations includes:

• Encrypted data at rest and in transit (HTTPS + encrypted DB)
• Access controls — only authorized personnel can access personal data
• Audit logs for access to sensitive data
• A defined breach notification process (72 hours to the Board)

The typical NGO violation: A shared WordPress admin account with a weak password, a database accessible over a public port, and no HTTPS on older hosting plans.

5. Data Principal Rights

Individuals whose data you hold have rights the Act enforces:

• Right to access — provide their own data on request
• Right to correction — correct inaccurate records on request
• Right to erasure — delete their data on request
• Right to grievance redress — a named contact person for data complaints

You must be able to fulfill these requests within a defined timeframe (the Board will specify this in future rules, but 30 days is the emerging standard).

Why Traditional WordPress Stacks Struggle with Compliance

A standard WordPress installation creates compliance problems at multiple layers:

The Plugin Attack Surface

Most WordPress NGO sites run 15–30 plugins. Each plugin that processes form data is a potential compliance gap:

• Contact Form 7, WPForms — store submissions in wp_posts indefinitely by default
• WooCommerce (used for donations) — stores transaction data without automatic purge
• Newsletter plugins — rarely implement consent record storage

There is no centralised view of what data is stored where, which makes the "right to access" obligation nearly impossible to fulfill efficiently.

Shared Hosting Data Isolation

On shared CPanel hosting, the database server is typically shared across hundreds of accounts. The security model is: each account's database is password-protected. That's it.

There's no encryption at rest, no per-request audit logging, and no way to enforce that only specific roles can access specific tables.

The Consent Storage Problem

Pre-ticked consent boxes and vague privacy policies are endemic to WordPress themes. Retrofitting PDPP-compliant consent mechanisms onto an existing WordPress site requires custom development work that most NGOs aren't resourced to do.

How a Modern Static Architecture Addresses This by Design

When I build a Next.js + modular API architecture for an NGO, several compliance requirements are addressed structurally:

1. Minimised Data Surface

Static site generation (SSG) means the public-facing website contains no database. The only personal data that reaches the backend is what a user explicitly submits through a form.

Compare this to WordPress, where the entire website — including admin sessions, plugin states, and transient caches — shares a database with donor and volunteer records.

2. Encrypted Transit and Storage

• All traffic to the website goes through Vercel's CDN with enforced HTTPS
• The API endpoint uses Traefik with automatic Let's Encrypt SSL
• The PostgreSQL database runs in an isolated Docker container on a private network — not exposed to the public internet

This satisfies the "reasonable security safeguards" baseline without additional configuration.

3. Structured Consent Records

The inquiry and volunteer forms I build include explicit consent fields. The API stores the consent event:

// The consent record stored at submission time
interface ConsentRecord {
  submitterId: string;
  purpose: 'volunteer_application' | 'newsletter' | 'beneficiary_registration';
  consentGiven: boolean;
  consentTimestamp: Date;
  ipAddress: string;  // For audit trail
  formVersion: string; // Track if the consent language changes
}

When a data principal requests their records, the system can return their submissions and their consent records in a structured export.

4. Data Retention Enforcement

The API includes a scheduled purge job that flags records older than the defined retention period:

// Weekly job: flag records past retention window for review
async function flagExpiredPersonalData() {
  const retentionDays = env.DATA_RETENTION_DAYS || 730; // 2 years default
  const cutoff = new Date();
  cutoff.setDate(cutoff.getDate() - retentionDays);
  
  const expired = await db.inquiry.findMany({
    where: {
      createdAt: { lt: cutoff },
      retentionReviewedAt: null,
    },
    select: { id: true, createdAt: true, segment: true },
  });
  
  logger.info({ count: expired.length }, 'Records flagged for retention review');
  // Notify admin — they confirm purge or extend retention with documented reason
}

This doesn't automatically delete records — it surfaces them for human review. The human decision is logged.

5. Role-Based Data Access

The admin panel implements role-based access control at the API layer. Only authenticated admin sessions can retrieve personal data. Every access to a record containing personal information generates an audit log entry:

// Every query on personal data in the admin domain
logger.info({
  adminId: req.adminId,
  action: 'DATA_ACCESS',
  resourceType: 'inquiry',
  resourceId: inquiryId,
  requestId: req.requestId,
}, 'Admin accessed personal data record');

This satisfies the audit trail requirement without requiring manual process discipline.

What NGOs Should Do Now

The PDPP Act is in force. The Data Protection Board isn't fully operational yet, but enforcement mechanisms will activate. Organizations that wait will face a retrofit problem that is significantly harder than building compliance in from the start.

Practical steps for any NGO website:

1. Audit every form — list every field, state the purpose for each, remove fields you can't justify
2. Add explicit consent checkboxes — per purpose, not a blanket "agree to everything" clause
3. Review plugin data storage — check what Contact Form 7, WPForms, newsletter plugins are storing and for how long
4. Document your retention policy — even a simple "we delete volunteer records after 2 years" counts
5. Name a grievance officer — a real person, not "[email protected]"
6. Enable HTTPS if you haven't already — this is table stakes

If you're due for a website rebuild, this is the right time to build compliance in architecturally rather than bolt it on later.

*If your NGO is evaluating a WordPress migration or a new platform build, reach out. I can assess your current data exposure and architect a PDPP-compliant solution.*

*Disclaimer: This article is written by a software architect, not a lawyer. For legal advice on PDPP Act compliance specific to your organization, consult a qualified privacy law practitioner.*