Cybersecurity and Threat Intelligence: A DPDP Act Impact Study

Executive summary

Overall impact: High.

This study covers managed security service providers (MSSPs) and security operations centres (SOCs), penetration testers and CERT-In empanelled auditors, threat intelligence and dark-web monitoring, digital forensics and incident response (DFIR), and identity and fraud-detection vendors. Their business is examining other people's data.

Under the Digital Personal Data Protection Act, 2023 (the DPDP Act), most of this work is done as a data processor for a client who is the data fiduciary, the party that decides why and how personal data is processed. Threat-intelligence providers collecting leaked data, and fraud vendors pooling signals across clients, act for themselves, with no consent route and no general "security" ground. Five of our twelve scorecard rows are High.

Three changes matter most.

• The offences exemption becomes the legal foundation. Section 17(1)(c) disapplies most of the Act for processing "in the interest of prevention, detection, investigation or prosecution of any offence". In our view private providers can rely on it where the processing has a real link to an offence, but it never removes security duties.
• A vendor's alert starts its clients' clocks. CERT-In's six hours run from noticing an incident, the RBI's from detection by the service provider, and the DPDP Rules add a 72-hour Board report. Contracts must define detection and escalation in minutes.
• Evidence is personal data. Forensic images and audit working papers hold whole lives. CERT-In's audit guidelines already require auditee data to stay in India and be wiped with a certificate; the DPDP Act adds retention discipline.

The main obligations commence on 13 May 2027. No members of the Data Protection Board had been appointed as of October 2026.

Background

MSSPs and SOCs pull logs and telemetry from clients' endpoints, networks, email and cloud accounts into a security information and event management (SIEM) platform, often shared across clients. Analysts see user names, IP addresses, email headers and sometimes content.

Penetration testers and auditors access production systems under scope letters and keep screenshots and sample records as proof.

Threat intelligence and dark-web monitoring services crawl forums, paste sites, messaging channels and leak sites for clients' domains, brands and executives. Their collections hold leaked credentials of people with no link to the client.

DFIR firms image laptops, servers and mailboxes and reconstruct attacks, often with litigation or a police complaint in view.

Identity and fraud vendors verify documents and faces, score devices and behaviour, and keep cross-client lists of suspect numbers and devices.

The data principals, the people the data is about, are clients' employees and customers, third parties named in leaks, people being verified and attackers. Typical sub-processors are cloud and SIEM platforms, threat feeds, malware sandboxes and AI model providers.

Legal framework

The DPDP Act and Rules

• Roles (ss.2(i), 2(k), 8(1), 8(2)). The fiduciary stays responsible "irrespective of any agreement to the contrary", including for processors engaged under contract.
• Grounds (ss.4, 7). Processing needs consent or a listed legitimate use. Section 7(i) covers employment and "safeguarding the employer from loss or liability"; nothing covers security or fraud prevention generally.
• Public data (s.3(c)(ii)). Only data made public by the data principal, or by someone legally obliged to publish it, falls outside the Act. A leak is neither.
• Security and breach (ss.8(5), 8(6); Rules 6, 7). Rule 6 requires encryption or masking, access control, logs and monitoring to detect and investigate unauthorised access, backups, processor contract terms, and one year's retention of logs. Rule 7 requires notice to the Board and each affected person on becoming aware of a breach, and a detailed Board report within 72 hours.
• Exemptions (s.17(1)). Chapter II (except ss.8(1) and 8(5)), Chapter III and s.16 do not apply where processing is necessary for enforcing a legal right or claim (clause (a)), or is "in the interest of prevention, detection, investigation or prosecution of any offence or contravention of any law for the time being in force in India" (clause (c)).
• Penalties. Up to ₹250 crore for failing to take security safeguards and ₹200 crore for failing to notify a breach.

Section 44(2) omits s.43A of the Information Technology Act, 2000 (IT Act) from 13 May 2027; its offences remain.

Cyber law and sector rules

The National Critical Information Infrastructure Protection Centre (NCIIPC), a unit of the National Technical Research Organisation, is the nodal agency under s.70A, set up by notification of 16 January 2014. It runs incident and vulnerability-disclosure channels for critical information infrastructure.

How the layers fit

Section 38 makes the DPDP Act additional to these laws, prevailing only in a conflict, and conflicts are rare: the others add clocks and audit rules. Section 16(2) preserves stricter location rules, such as CERT-In's for audit data and the RBI's outsourcing terms.

Analysis

The Trayambic DPDP Impact Scorecard

Overall impact: High

Security is a duty, not a ground

The Act demands security but offers no general basis for processing in its name. In our view the position differs for each group of data principals.

• Clients' customers. Monitoring that protects data the client already holds lawfully is part of the security it owes under s.8(5) and Rule 6, and needs no fresh ground while it stays within security purposes. The MSSP acts as processor.
• Clients' employees. Section 7(i) covers security monitoring that guards the employer against loss or liability; productivity tracking labelled as security fits less well. Trayambic's article on background checks and employee monitoring covers this in more detail.
• Attackers and strangers in logs. Nobody can ask the owner of an IP address probing a login page for consent. Detecting intrusions rests on s.17(1)(c).
• The provider's own uses. An MSSP that matches one client's user activity against another client's logs, or posts indicators containing a phishing victim's email address to a sharing community, is setting purposes itself and is a fiduciary for that step. It should strip personal data from shared indicators and get each client's written authority for cross-client correlation.

Fraud vendors face the same split. Scoring a payment for a bank is processing for the bank, and the RBI's Authentication Directions expressly allow location, behaviour and device signals; a cross-client list of suspect devices serves the vendor's own purpose. For children's accounts, s.9(3) bars behavioural monitoring unless s.17(1)(c) applies, so fraud models for minors must stay confined to fraud. The DoT's Mobile Number Validation platform comes with an express reminder that data protection law governs validation.

Section 17(1)(c): does it reach private investigators?

The clause is framed by purpose, not by actor. When the Act means the State it says so: s.17(2)(a) is limited to instrumentalities the Centre notifies, and ss.7(b) and 7(c) to State functions. In our view, therefore, a DFIR firm investigating ransomware, a bank's fraud team or a threat-intelligence provider tracing stolen credentials can rely on s.17(1)(c), as fiduciary or as processor for a client that relies on it.

The exemption has firm edges.

1. 1.An offence or contravention is needed. Policy breaches, contract disputes and performance concerns are outside it unless they also involve an offence, such as data theft under IT Act s.66.
2. 2.The link must be real. Reusing investigation data for marketing, product training or resale falls outside it.
3. 3.Security and accountability survive. Sections 8(1) and 8(5) still apply, with penalties of up to ₹250 crore.
4. 4.It does not legalise the method. If collecting the data is itself an offence, the exemption cannot cure that.
5. 5.It may be read narrowly. The Act will be read in light of the privacy right recognised in K.S. Puttaswamy v Union of India, (2017) 10 SCC 1, and the Board has not ruled. Providers should keep a documented, proportionate purpose.

For investigations preparing for litigation, s.17(1)(a), on enforcing legal rights or claims, gives a second basis.

Leaked data: a fiduciary with no one to ask

A dark-web monitoring provider decides what to collect, how long to keep it and whom to tell, so it is a fiduciary for everyone in its collection. Nobody consented, s.3(c)(ii) does not apply because the leak was not their act, and no s.7 ground fits. Section 17(1)(c) is the only route, and in our view it supports a service designed around it:

• Collect the minimum: hashed or truncated credentials and matching fields, not whole records.
• Tell the right party: the exposed organisation or the individual; never sell or enrich the data.
• Set a short life: delete once the exposure is fixed.

How the data is obtained matters as much. Section 66B of the IT Act punishes dishonestly receiving or retaining a stolen "computer resource", and s.2(1)(k) defines that term to include data. Paying criminal sellers for dumps invites the charge that the buyer dishonestly received stolen data. Checking leaked passwords by logging in to victims' accounts is access without the owner's permission under s.43, and an offence under s.66 if done dishonestly or fraudulently. In our view passive collection from openly accessible sources, with a recorded protective purpose, is the defensible model.

Detection is a legal event

Each regime counts from a different moment.

SEBI-regulated clients also report within six hours by email under SEBI's circular of 24 August 2026.

Two consequences follow. First, under CERT-In's FAQ Q13 any entity that notices an incident must report it and cannot pass the duty on. An MSSP that spots ransomware on a client's network therefore has its own reporting obligation, which a confidentiality clause cannot override (Q22). Both parties should file, with consistent facts. Second, for banks and NBFCs the RBI clock runs from the provider's detection, not the client's. Contracts should define "detection", set escalation in minutes and name on-call contacts.

Evidence, audits and testing

Forensic images. A laptop image captures personal email, medical records and family photographs alongside the evidence. The DFIR firm, usually the client's processor, should scope collection, encrypt and access-log images, and agree a destruction date. Section 17(1)(c) lifts the s.8(7) erasure duty while an investigation runs, not forever. Where images may reach court, s.63(4) of the Bharatiya Sakshya Adhiniyam requires a certificate from the person in charge and an expert, so custody records must last as long as the images. Files that may hold personal data should never go to public malware-scanning services.

Audit data. CERT-In's guidelines already set the standard the DPDP Act will expect: Indian systems, encryption, certified wiping and retention no longer than agreed or, by default, one year. Auditors should apply the same rules outside the guidelines' scope.

Testing. The scope letter separates a test from unauthorised access under s.43. Systems declared "protected" under s.70 may be accessed only by persons authorised in writing under s.70(2); unauthorised access carries up to ten years' imprisonment. Testers near critical information infrastructure should see that authorisation, and can report vulnerabilities through NCIIPC's disclosure channel.

Worked example: a managed security provider in Pune

A Pune MSSP with about 300 analysts (illustrative) runs a 24x7 SOC for 60 clients, including an NBFC and a SEBI-registered broker, offers a DFIR retainer and sells dark-web monitoring. Its plan for May 2027:

1. 1.Role map. Processor for client logs and investigations; fiduciary for its dark-web collection and its staff. A s.17(1)(c) note records the offence each fiduciary activity serves.
2. 2.Clocks. Detection means an analyst confirming an alert as an incident. The client is called within 30 minutes; the MSSP files its own CERT-In report within six hours and shares it. The NBFC contract records that the RBI's six hours run from the MSSP's detection.
3. 3.SOC terms. The NBFC and broker contracts map RBI para 95 and the CSCRF: client ownership of rules and logs, facility reviews, joint incident response.
4. 4.Location. Indian clients' logs stay in an Indian SIEM region for a year; offshore analysts get access, not copies.
5. 5.Dark-web service. Credentials are hashed, alerts go only to the affected client, records are deleted 90 days after closure, and nothing is bought.
6. 6.Evidence. Images are encrypted, logged and destroyed with a certificate when the matter closes.

Compliance framework

Phased roadmap

• Now to December 2026: role map; end credential validation and data purchases; inventory images and audit data.
• January to March 2027: contracts with detection definitions and dual reporting; SOC schedules for RBI and SEBI clients; retention rules.
• April to May 2027: identity-service notices; purge stale images and collections; train analysts on s.17(1)(c).
• Ongoing: joint incident drills; track Board guidance, CERT-In updates and sector clocks.

Recommendations

1. 1.Treat s.17(1)(c) as a licence with conditions: record the offence it serves and keep the data to that purpose.
2. 2.Write the clock into the contract and file your own CERT-In report.
3. 3.Keep client data out of your own products unless the client authorises it and personal data is removed.
4. 4.Run threat intelligence on clean sources: no purchases from criminals, no logging in with leaked passwords.
5. 5.Give every forensic image and audit file a destruction date.
6. 6.Keep Indian logs and audit data in India; give offshore teams access, not copies.
7. 7.Build to the strictest client: an RBI- or SEBI-ready SOC contract satisfies most others.

Key takeaways

• Most security work is processing for clients, but threat-intelligence collections and cross-client fraud lists make providers fiduciaries in their own right.
• The DPDP Act has no general security ground; s.17(1)(c) on offences is available to private providers in our view, but only for processing genuinely linked to an offence, and security duties always remain.
• Under CERT-In's FAQs any entity that notices an incident must report within six hours, and RBI's clock for banks and NBFCs runs from the provider's detection.
• Buying leaked data or testing leaked passwords risks offences under IT Act ss.66B, 43 and 66; passive collection with a recorded protective purpose is the safer model.
• Forensic images and audit data need Indian storage, encryption and destruction dates, as CERT-In's 2025 audit guidelines already require for audits.