Section 4 Personal Data Classification in Marathon Events: 5 Key Regulatory Buckets

Applies to	Sports events organizers & marathons collecting participant registration data under DPDPA 2023
Primary law	DPDPA 2023 · Section 4
Penalty ceiling	up to ₹150 crore per violation
Enforcement status	Data Protection Board accepting complaints — 2026-07
Source	DPDPAReady Compliance Team

What Section 4 Actually Says About Your Marathon Data

A 5,000-runner marathon in Mumbai collects participant names, ages, addresses, phone numbers, payment card details, T-shirt sizes, medical conditions, and emergency contacts in a single registration form. The event organizer assumes this is all just “personal data”—one category, one storage rule, one backup protocol. Six months later, a data handler uploads the full database to an unencrypted cloud server. A regulator reviews the breach. The organizer discovers they held at least three distinct data categories under Section 4 of DPDPA 2023, each with different storage, sharing, and retention rules. The misclassification alone triggers a ₹150 crore liability.

Section 4 of DPDPA 2023 does not create a single “personal data” bucket. It creates three legally distinct categories, each with different rights for data principals and duties for handlers:

Section 4(a): Personal data means any information relating to an individual who is identifiable by reference to an identifier such as a name, an identification number, location data or an online identifier, or factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of such individual.

Section 4(b) adds sensitive personal data—a subset of personal data. Section 4(c) introduces deemed sensitive personal data—personal data that becomes sensitive only in a specific context. For marathon organizers, this three-tier system governs what you can collect, who you must notify, how long you store it, and what penalties apply when you get it wrong.

Three Data Categories: Which Participant Fields Fall Where

Personal Data (Broadest Category)

Personal data under Section 4(a) is any information that identifies or can identify an individual. For marathon registration, this includes:

• Participant name, email address, and phone number
• Age, date of birth, or residential address
• T-shirt size or race bib number (if linked to a participant ID)
• Payment card last four digits
• Participant photo or social media handles (if collected for prize notification)
• Race completion time or pace statistics

Regulatory duty: Personal data requires notice (Section 5), a lawful processing ground, and reasonable security measures. No additional restrictions apply to this tier alone—but any false claim that data is not personal data is the violation triggering penalties.

Sensitive Personal Data (Restricted Subset)

Sensitive personal data is a specific subset defined in Section 4(b) that relates to:

• Health or medical status
• Medication lists or disability status
• Genetic data or biometric data for identification
• Financial account details (full card number, bank account)
• Race, ethnicity, caste, religion, or sexual orientation
• Gender identity

For marathon organizers, the most common sensitive personal data points are:

1. Health conditions: “Asthma,” “diabetes,” “heart condition,” “knee injury,” or “pregnancy” disclosed in registration or medical questionnaires
2. Medication or emergency medical data: “On beta-blockers,” “insulin-dependent,” “carries EpiPen,” or “allergic to penicillin”
3. Full payment card numbers or bank account details (even if stored for one-time use)
4. Disability status: “Wheelchair access required,” “hearing aid,” or “visual impairment”
5. Age under 18 combined with health disclosures: A minor’s age plus asthma or allergy disclosure becomes sensitive personal data under DPDPA’s intersectional approach

Regulatory duty: Sensitive personal data requires explicit consent (Section 6), restricted processing grounds (Section 5), higher encryption standards, and subject to withdrawal of consent (Section 8). Unauthorized processing of sensitive personal data triggers ₹200 crore penalties under Section 8; misclassification triggers ₹150 crore penalties under Section 4.

Deemed Sensitive Personal Data (Context-Dependent)

Deemed sensitive personal data is personal data that does not fit Section 4(b) definitions but becomes sensitive because of how it is processed. The DPDPA rulebook (under finalization as of July 2026) will specify which contexts trigger this classification.

Likely deemed-sensitive scenarios for marathons:

1. Participant GPS coordinates during the race: Personal data by itself, but deemed sensitive because continuous location tracking (every 100 meters) reveals daily patterns, home proximity, and personal movements
2. Aggregated health inferences: Individual heart-rate monitor readings (130 bpm) are personal data; aggregated data showing “40% of 50+ participants exceed 160 bpm” infers population health vulnerability
3. Participant contact lists: Email addresses of all marathoners—personal data individually, but deemed sensitive when aggregated as an exploitable mailing list
4. Race completion time + age: A 70-year-old’s 3-hour finish time infers fitness and health status, crossing into deemed-sensitive classification
5. Financial payment patterns: Registration fee payment timing + race category choice infers income level or sponsorship status

Regulatory duty: Deemed sensitive personal data is subject to Section 6 and 8 rules (explicit consent, restricted grounds, withdrawal rights) pending the final rulebook. Misclassification—treating deemed-sensitive data as ordinary personal data—triggers ₹150 crore liability.

Data Classification Checklist for Marathon Event Organizers

Use this checklist when designing your registration form and implementing data workflows:

1. Audit every registration field — List all data points (name, age, email, phone, address, health condition, payment method, etc.). For each field, ask: “Does this identify or can it identify someone?” If yes, it is at least personal data.

2. Flag health, payment, and biometric fields — Medical conditions, medications, disabilities, and allergies = sensitive personal data. Full payment card numbers and bank accounts = sensitive personal data. GPS coordinates and biometric timers = personal data (potentially deemed sensitive).

3. Check for intersectional sensitive data — Age under 18 + any health disclosure = sensitive personal data. Gender identity + race category = sensitive. Location data + caste/religion disclosure = potentially deemed sensitive.

4. Document your classification — Create a data map (field name → Section 4 category) and include it in your privacy policy. Update when the deemed-sensitive rulebook is finalized.

5. Apply different handling rules per category — Personal data: standard notice, lawful ground, encryption. Sensitive personal data: explicit consent (not pre-ticked), restricted grounds, higher security, withdrawal right. Deemed sensitive: apply sensitive-data rules until guidance published.

6. Train your data handlers — Tell volunteers, timing system operators, and payment processors which fields are sensitive. Sensitive data handlers require explicit contract language (Section 7) prohibiting unauthorized use.

7. Test your retention policies — Personal data (bib numbers, names): delete 1 year after race. Sensitive data (health info): delete 90 days after race (participants’ Section 12 erasure right). Deemed sensitive (aggregated location data): delete after race analytics finalization.

8. Prepare for regulatory audit — Keep your data classification map for 2 years. Document which category each field belongs to. If a breach occurs, regulators will ask: “Did you know this was sensitive data?” Your map is your defense.

Common Misclassifications and Real Penalty Scenarios

Scenario 1: Health Data Treated as Personal Data

A 10,000-runner half-marathon collects “Do you have any medical conditions?” responses (diabetes, asthma, hypertension) in the same database as participant names, with identical encryption. The organizer claims, “It’s all personal data; we treat it the same.”

Under Section 4(b), health conditions are sensitive personal data. Failure to seek explicit consent (Section 6), apply higher encryption, and implement restricted access violates DPDPA. A regulatory audit uncovers 3,000 health records with inadequate access controls. Penalties: ₹150 crore for Section 4 misclassification; additional ₹200 crore for Section 8 (sensitive data without consent) = ₹350 crore total.

Scenario 2: GPS Tracking Not Flagged as Deemed Sensitive

A trail running event uses GPS watches logging location every 30 seconds (2 million data points over 2 hours). The organizer claims, “It’s just location—everyone knows where everyone runs.” No explicit consent sought; no anonymization or deletion policy.

Under Section 4(c), continuous location tracking is deemed sensitive because it reveals daily movement patterns and infers health vulnerabilities (runner who stops mid-race). Lacking explicit consent and retention policy: ₹150 crore liability for misclassification.

Scenario 3: Payment Data Stored Permanently

A marathon payment processor stores credit card last-four digits on a shared Google Drive labeled “2023 Race Results.” Two years later, the file still exists. A regulator finds financial account data classified as personal data when it is sensitive personal data (Section 4(b)).

Sensitive financial data requires explicit consent and deletion within a reasonable period. Indefinite storage without consent: ₹150 crore for misclassification plus penalties for unlawful retention.

Frequently Asked Questions

Q: Our marathon registration form collects age but not health data. Is age personal data or sensitive personal data?

A: Age alone is personal data under Section 4(a). However, if age is combined with health data (e.g., “age 14 + has asthma”), the intersection becomes sensitive personal data. Section 4(b) does not list age as sensitive by itself, but Section 4(c) may deem it sensitive if processing context infers vulnerability. For marathons, store age separately from health disclosures until the deemed-sensitive rulebook clarifies the exact trigger points for context-dependent classifications.

Q: We use a third-party timing system that stores GPS coordinates of every runner. Does the timing company or the event organizer bear Section 4 classification responsibility?

A: Both bear responsibility. The event organizer is the data controller (determines purpose: “Run a fair race”); the timing company is a data processor (handles technical collection). Under Section 7, you must have a written contract specifying that GPS location data is personal (or deemed sensitive) and the processor must implement security matching that classification. If the processor fails to encrypt location data as required for sensitive data, both organizer and processor face penalties. Ensure your processor agreement explicitly states the Section 4 category and handling rules.

Q: We collect emergency contact information including health allergies (e.g., “emergency contact: my mother; allergic to penicillin”). Is this one data point or two?

A: This is sensitive personal data under Section 4(b) because it includes health information (allergy). The emergency contact name is personal data; the allergy is sensitive personal data. In practice, treat the entire field as sensitive because you cannot process the emergency contact name without exposing the allergy. Seek explicit consent for this field, restrict access to trained staff only, encrypt with higher standards, and allow participants to designate a separate emergency contact if they prefer not to disclose health details.

Q: We anonymize participant names and ID numbers after the race. Does that change the Section 4 classification?

A: True anonymization removes personal data entirely (no longer identifies anyone). However, merely redacting names while retaining race time, bib number, age, and health data leaves the record identifiable. For marathons, use one-way hashing or aggregate statistics instead. If you retain linkable identifiers (bib-to-name mapping), the data is still personal. Section 4 classification applies to data as collected and stored; anonymization is a later step. Classify before anonymization; anonymize within your retention window (90 days for sensitive data, 1 year for personal data).

Q: A participant opts out of sensitive data collection. Can we remove their health information and re-classify their record as personal data only?

A: Yes. Once explicit consent is withdrawn (Section 8 withdrawal right), you must delete or stop processing that sensitive data within a reasonable period. If you delete health information, the remaining fields (name, age, email) become personal data for legitimate purposes (race results archives, future invitations—provided you have a lawful ground under Section 5). However, Section 4 classification does not change retroactively; you must document that this participant previously provided sensitive data, you obtained explicit consent, and you deleted it on withdrawal. Regulators audit consent records, not just current data.