29 Lakh+ Cyber Incidents Later: What India's DPDP Rules Mean for SaaS Companies

29 Lakh+ Cyber Incidents Later: What India's DPDP Rules Mean for SaaS Companies

By Rex Cyber Solutions

India recorded 29,44,248 cybersecurity incidents reported to and tracked by CERT-In in 2025, according to a government update published by the Press Information Bureau. That is more than 29 lakh incidents in one year, compared with 20,41,360 in 2024.

These are national cybersecurity figures, not a count of SaaS data breaches or violations of the Digital Personal Data Protection framework. They nevertheless provide a useful backdrop to a question every SaaS leadership team should ask: if personal data is exposed, can we explain what happened, contain the damage and meet the applicable reporting duties?

The Digital Personal Data Protection Act, 2023 and the final DPDP Rules, 2025 make that question relevant to product design, customer contracts and day-to-day operations. For SaaS companies, readiness means understanding who uses personal data, why it is needed, how it is protected and what happens when something goes wrong.

In this article

1. What DPDP means for your SaaS company

2. When the DPDP requirements take effect

3. Five areas to review inside your product

4. Breach reporting and the different clocks

5. An illustrative SaaS data exposure

6. Seven questions for SaaS leadership

7. Frequently asked questions

8. Make readiness part of running the business

9. Get a DPDP readiness review with Rex

CERT-In’s national incident figures rose from 15,92,917 in 2023 to 29,44,248 in 2025. Source: PIB, 14 August 2026.

1. What DPDP means for your SaaS company

DPDP concerns digital personal data: information about an identifiable individual that is collected digitally, or collected in another form and later digitised. A SaaS company should consider user accounts, employee records, support tickets, contact information and other identifiable customer content when assessing its processing.

B2B software is not outside the discussion simply because the customer is a company. Business accounts can contain information about real people. Start by identifying the relevant processing and any applicable exclusions or exemptions, rather than treating every database as identical.

Are you a Data Fiduciary or a Data Processor

A Data Fiduciary determines the purpose and means of processing personal data. A Data Processor handles personal data on its behalf. A SaaS provider may play different roles for different activities: processing customer-uploaded records under instructions while deciding how its own sales contacts are used.

The Act places responsibility on a Data Fiduciary for processing undertaken by it or on its behalf. It also requires a valid contract when engaging a processor for relevant goods-or-services activities. Assign the role before deciding who must issue notices, respond to individuals or coordinate an incident.

Not sure where your SaaS business stands? Take Rex’s DPDP readiness assessment. Use it as a starting point to identify areas that need a closer review, rather than as proof of compliance.

2. When the DPDP requirements take effect

The final Rules were notified in November 2025. Their commencement is staggered: some institutional provisions began at publication; Rule 4 on Consent Managers follows a one-year period; and most operational rules follow an eighteen-month period. The Act’s commencement notification sets out a corresponding phased schedule for its provisions.

The core eighteen-month phase falls in May 2027 under the notified schedule. The twelve-month phase is not the general start date for all SaaS privacy, security and breach-notification obligations. Those duties need to be mapped to the provisions that govern them.

Use the final Rules with their corrigendum and the Act commencement notification. A press announcement, a draft rule or a generic countdown is not a substitute for that mapping. Existing obligations under other laws do not disappear during the DPDP transition.

Turn the transition period into a scoped plan. Explore Rex’s DPDPA compliance services for data discovery, an obligation-by-obligation gap assessment and a prioritised remediation roadmap.

Rule 1 specifies the commencement phases. The Act has its own commencement notification; match each obligation to the applicable phase.

3. Five areas to review inside your product

Clear notice and usable consent controls

Rule 3 sets out notice requirements, including an itemised description of personal data and the specified purposes of processing. It also addresses how individuals can withdraw consent, exercise rights and complain to the Board. The Act permits consent and specified legitimate uses; do not import GDPR legal bases into DPDP without checking the Indian provisions.

For your product, review the places where information enters the system. Can a user understand why a field is needed? Is a new use reflected in the notice? Can the team find the consent record when answering a question? Keep the interface understandable rather than hiding everything inside a long document.

Security safeguards that protect actual data

Rule 6 addresses security measures, access controls, logs and monitoring, continuity measures such as backups, and contractual safeguards with processors. The requirement concerns protection of personal data, not merely the possession of a security policy.

For a multi-tenant product, investigate whether customer records remain isolated, whether support staff have unnecessary access and whether privileged actions are recorded. Test restoration as well as backup creation. Keep evidence of the controls and the fixes made when testing exposes a weakness.

Need evidence that your safeguards work? Explore web application penetration testing for application weaknesses, and cloud security audits for access, configuration and logging gaps. Use the findings to inform your wider DPDP remediation plan.

Retention rules that reach beyond the main database

Deletion needs a purpose-by-purpose assessment. The Act’s erasure duties must be read alongside the Rules’ retention provisions and other legal requirements. Rule 8(3) includes a minimum one-year retention requirement for specified processing data and logs for the Seventh Schedule purposes; Rule 6 also contains a one-year security-related retention provision.

Avoid both extremes: retaining everything indefinitely and promising that closing an account immediately removes every copy. Map records in backups, support tools, exports and processor systems. Explain which records remain, why they remain and who will ensure deletion when the applicable retention requirement ends.

Rights and grievances with a named owner

Provide a practical route for individuals to exercise applicable rights and raise grievances. Rule 14 requires a published grievance-response period that is reasonable and does not exceed ninety days. That should not be presented as a universal ninety-day deadline for every possible request.

Your support team needs to know where to send a privacy question and how to establish the requester’s identity proportionately. Test whether the assigned team can find the relevant information without giving an unrelated user access to it.

Children and higher obligations where applicable

If your product handles children’s data, assess the Act’s under-eighteen definition and the verifiable parental-consent requirements, restrictions and applicable exceptions. An age field alone should not be treated as a complete assessment.

Additional duties apply to entities notified as Significant Data Fiduciaries. Do not assume every SaaS company has that status. The October 2026 removal-of-difficulties order also clarifies wording concerning guardian consent and data audits; use the current framework when assessing these provisions.

4. Breach reporting and the different clocks

When Rule 7 applies, a Data Fiduciary must inform affected individuals and give the Board an initial intimation without delay after becoming aware of a personal data breach. The detailed Board update follows within seventy-two hours, unless the Board allows more time on a written request. Seventy-two hours is not permission to wait before the initial notifications.

CERT-In’s separate directions require covered entities to report the specified cyber incidents within six hours of noticing them or being informed of them. A single event may require assessment under both regimes, with different recipients and triggers. Meeting one reporting duty does not automatically meet the other.

Build a shared incident record containing the discovery time, affected systems, data involved, containment actions and reporting decisions. Agree who can authorise communications before an incident forces the question. A processor should also escalate promptly to the customer according to its role and contract.

Need to establish what happened and preserve evidence? Explore Rex’s digital investigation services for data preservation, analysis and timeline reconstruction. If you are preparing before an incident, discuss breach readiness as part of the DPDPA programme.

CERT-In and DPDP reporting are distinct. DPDP Rule 7 belongs to the eighteen-month phase; CERT-In directions require a separate assessment.

5. An illustrative SaaS data exposure

Consider an illustrative HR platform where a support export includes employee details from the wrong tenant. The immediate task is to stop further exposure and preserve evidence. The next questions involve the extent of access, the provider’s role, the customer’s instructions, and the reporting requirements that apply.

Engineering may need to fix tenant filtering. Security needs reliable logs. The customer team needs verified facts rather than guesses. The privacy owner needs the applicable data and notification assessment. A generic policy cannot answer those questions without supporting records.

This is an example, not a reported customer incident. Its purpose is to show why SaaS readiness requires coordination across the people who build, operate and support the service.

6. Seven questions for SaaS leadership

Have we identified the personal data in the application and connected tools?

Have we assigned our role and the customer’s role for each activity?

Do notices and processing contracts reflect how the product works?

Can we demonstrate access controls, tenant isolation, monitoring and restoration?

Have we reconciled deletion promises with mandatory retention requirements?

Do we know which incident notifications apply and who will send them?

Have we mapped obligations to commencement phases and assigned remediation owners?

Use the answers to identify work that requires product changes, contract changes or operational testing. A completed questionnaire is useful only when the supporting evidence can be produced.

7. Frequently asked questions

Q1. Are the 29 lakh incidents all personal data breaches?

Answer: No. The figure refers to cybersecurity incidents reported to and tracked by CERT-In across India in 2025. It should not be labelled as the number of SaaS breaches, affected people or DPDP cases.

Q2. Does cloud hosting transfer all responsibility to the cloud provider?

Answer: No. Where your company is the Data Fiduciary, using a processor does not by itself remove your responsibility. Review the arrangement and the safeguards that protect the data.

Q3. Can an overseas SaaS provider be covered?

Answer: The Act addresses processing outside India connected to offering goods or services to Data Principals in India. Scope and exemptions require assessment. For Indian exporters, section 17(1)(d) also contains a specific exemption for certain processing of data about people outside India under overseas contracts; it is not a blanket exemption from every duty.

Q4. Does every breach automatically trigger a ₹250 crore penalty?

Answer: No. The Act’s Schedule sets different maximum penalties for different contraventions. Failure to take reasonable security safeguards can attract a penalty up to ₹250 crore. That is a statutory ceiling for the specified failure, not an automatic fine for every incident. Commencement and the facts matter.

Q5. Is a penetration test enough to demonstrate DPDP readiness?

Answer: No. Testing can identify security gaps, but it does not decide your processing purpose, validate notices or establish how rights and retention requirements are handled. Use technical evidence alongside the broader privacy assessment.

8. Make readiness part of running the business

The incident figures show the scale of cybersecurity activity; the DPDP framework defines a distinct set of responsibilities concerning personal data. The practical response is to understand your data, protect it, keep reliable evidence and prepare the people who will act when problems arise.

For SaaS leadership, the useful question is not simply whether a policy exists. It is whether the product, contracts and operating practices support the commitments being made to individuals and customers.

9. Get a DPDP readiness review with Rex

Rex Cyber Solutions works with teams on data discovery, notice and consent, processor controls, security safeguards and breach readiness. Start with a discussion of your product, customer data, vendors and the questions your buyers are asking. The next step can then be scoped around your actual risks.

Use the call to clarify your readiness gaps, identify priorities and understand the support your team needs.

Book a DPDPA readiness call with Rex

Prefer to review the service first? See the DPDPA assessment and readiness programme.

‍