Written by

Sumeshwar Pandey

View Profile
14 min read
India DPDP Act 2023 Security governance

What Counts as a Reasonable Security Safeguard under DPDP?

How Indian B2B leadership teams can turn DPDP’s security duty into a defensible operating model.
Key takeaways
  • Under Section 8(5) of the DPDP Act, your organisation must protect personal data with reasonable security safeguards across both in-house systems and processors, with failures exposing you to penalties at the upper end of the Act’s schedule.
  • Rule 6 of the DPDP Rules 2025 turns “reasonable” into a minimum baseline of encryption, access control, logging, backups, and one-year log retention, which then scales up depending on your sector, data sensitivity, and outsourcing footprint.
  • The Data Protection Board is likely to judge reasonableness based on your risk profile, alignment with recognised frameworks (such as ISO/IEC 27001, NIST CSF, CERT-In Directions, and sectoral norms), and the quality of your governance, testing, and incident response.
  • A defensible approach combines a risk-based control baseline, clear accountability across the board and CXOs, disciplined vendor management, and consistent evidence generation that you can put on the table quickly after a breach.
  • Most Indian B2B organisations can reach a defensible level of reasonable security over roughly 12–18 months by sequencing work across governance, data mapping, control implementation, incident readiness, and independent assurance.

Why “reasonable security safeguards” is now a board-level issue

Picture the moment after a serious incident: an attacker exploits a weak credential on a third-party support tool, and personal data for hundreds of thousands of Indian customers is exposed. Within days, your organisation is before the Data Protection Board, and the first question is not about which firewall you bought. It is, “Show us why you believed your security safeguards were reasonable for the data you held and the risks you understood.”
At that point, the discussion stops being purely technical. The Board will be looking for a trail of decisions: how you assessed your data protection risks, which frameworks you chose, what budgets and trade-offs the board approved, how you supervised processors, how often you tested incident response, and what you learned from earlier near-misses. If those decisions are undocumented, or if your controls clearly lag sector norms, it becomes difficult to argue that you took reasonable care.
The DPDP Act makes this a balance-sheet issue. The penalty for failing to take reasonable security safeguards to prevent a personal data breach can go up to INR 250 crore per instance, which sits at the top end of the Act’s penalty schedule. Beyond regulatory fines, a significant breach can trigger contractual claims from enterprise customers, parallel action from sector regulators, and loss of deal flow if you can no longer sign data protection addenda with confidence.[1]
The practical cost of inaction is not just the risk of an extreme penalty; it is the lack of defensibility. Two organisations may both suffer a breach, but the one that can demonstrate a risk-based programme, aligned to recognised standards and actively overseen by its board, will almost always be in a stronger position. Treating reasonable safeguards as a board-governed discipline, rather than an IT housekeeping task, is now a competitive necessity for Indian B2B enterprises.
How different security postures affect outcomes when a breach occurs.
Security posture What the Board will see Likely regulatory and legal outcome Commercial impact
Minimal controls and little documentation Ad hoc decisions, outdated or missing policies, weak or absent logs, and unclear oversight of processors. High probability of a finding that safeguards were not reasonable, with exposure to large fines and follow-on regulatory action. Enterprise customers question your reliability; new deals stall; existing clients may renegotiate or exit.
Baseline technical controls but weak governance Some controls in place, but risk assessments, board visibility, and vendor oversight are patchy or undocumented. Outcome depends on specifics; the breach may still be treated as partly avoidable and penalties can be material. Customers may accept continued engagement if you commit to a clear remediation plan, but sales teams face prolonged security due diligence.
Risk-based programme with board oversight Documented risk assessments mapped to recognised frameworks, with evidence of testing, incident rehearsals, and processor management. Board more likely to view safeguards as reasonable, which can moderate penalties even if the incident is serious. You retain credibility with customers and regulators, and remediation can be framed as strengthening an already-serious programme.

What DPDP actually requires on security safeguards

Section 8(5) of the Digital Personal Data Protection Act, 2023 sets out a clear duty: as a Data Fiduciary, you must protect the personal data in your possession or control, including data processed on your behalf by Data Processors, by taking reasonable security safeguards to prevent a personal data breach.[1]
In substance, this is an obligation to apply appropriate technical and organisational measures so that confidentiality, integrity, and availability of personal data are not compromised through unauthorised access, disclosure, alteration, loss, or destruction.
The DPDP Rules 2025, in particular Rule 6, move this from principle to baseline practice. They specify that reasonable safeguards include at least five concrete elements: using encryption appropriate to the sensitivity of personal data and the risk of harm, enforcing access controls and strong authentication so only authorised personnel can access personal data, maintaining logs and monitoring of systems that process personal data, implementing regular backups and tested restoration procedures, and retaining relevant security logs and records for a minimum of one year. The Rules also point towards wider organisational measures, such as documented security policies, periodic risk assessments, and training for personnel who handle personal data.[3]
Critically, the Rules treat this as a floor, not a ceiling. If you process high-risk data at scale, or operate in a heavily regulated sector, the expectation is that you will go beyond the baseline. Conversely, simply turning on encryption without meaningful access control, monitoring, and response capability is unlikely to satisfy the duty in practice. The Act’s penalty schedule underlines the stakes: failures to take reasonable security safeguards sit among the most serious violations, separate from penalties for issues such as not notifying a personal data breach or not honouring data principal rights. When penalties are assessed, the Data Protection Board will weigh not only the fact of the breach but whether your safeguards, given your context, reflect current standards of due care.

Interpreting “reasonable” for your business model and risk profile

Reasonableness under DPDP is not a fixed checklist; it is anchored in context. The safeguards expected from a 50-person B2B SaaS provider processing limited contact details are not the same as those expected from a systemically important financial institution handling detailed financial profiles. When the Data Protection Board evaluates your safeguards, it is likely to weigh the nature and sensitivity of the personal data you process, the volume and diversity of that data, whether it concerns children or other vulnerable groups, how complex your processing activities are, the extent of cross-border transfers, your reliance on external processors, your sectoral regulatory environment, and your history of incidents or near-misses.[2]
Take a mid-market B2B SaaS platform that manages HR data for corporate clients. It processes large volumes of contact details, employment histories, and performance information, mostly for employees rather than retail consumers, and runs on a mainstream public cloud provider. For such an organisation, a reasonable baseline would typically include strong identity and access management with multi-factor authentication for internal and administrative access, encryption of personal data at rest and in transit on the cloud, regular patching and vulnerability management, structured logging and monitoring of access to personal data, tested backup and recovery procedures, secure software development practices, periodic penetration testing, and formal incident response playbooks. Many enterprise customers will also expect alignment with frameworks such as ISO/IEC 27001 or the NIST Cybersecurity Framework, backed by independent assurance.
Now contrast that with a regulated financial institution or NBFC that collects KYC documents, credit histories, and transaction data, and that falls under the direct supervision of the Reserve Bank of India. Here, the same DPDP Rule 6 baseline still applies, but reasonableness almost certainly extends further. Board-approved information security and cyber strategies, dedicated security operations with 24/7 monitoring, strict network segmentation between internet-facing systems and core banking applications, privileged access management with just-in-time elevation, regular red-team exercises, strong data loss prevention controls, and coordinated compliance with RBI, CERT-In, and DPDP requirements would be expected. Operating materially below sectoral norms and your own regulator’s expectations would be difficult to defend as reasonable, even if the Act itself does not spell out each control.
A useful decision frame for leadership is to ask, for each major processing activity, what a fair-minded external observer would expect to see in place, given the scale of harm a breach could cause to data principals and to the wider system you operate in. If your safeguards, documentation, and investments look thin compared to that expectation, it is a signal that your interpretation of reasonable is too narrow and that your risk appetite and security posture need to be revisited.

How DPDP security duties interact with CERT-In and sectoral regulations

DPDP does not operate in isolation. Most Indian B2B organisations already fall under the Information Technology Act and directions issued by the Indian Computer Emergency Response Team. Those directions require entities such as service providers, intermediaries, data centres, and corporates to maintain system logs in India, keep systems time-synchronised, report specified types of cyber incidents within tight timelines, and designate points of contact for incident coordination.[4]
There is substantial overlap between what CERT-In expects and what DPDP Rule 6 describes as reasonable safeguards, particularly around logging, monitoring, incident response, and record retention. The key difference is scope: CERT-In cares about a broad set of cyber incidents, while DPDP is focused specifically on personal data breaches and the rights of data principals. A ransomware attack on a system hosting personal data might trigger both sets of obligations, and in some sectors, separate notifications to the sector regulator as well. Designing your safeguards and playbooks so that a single incident handling process can efficiently meet all these reporting and evidence requirements is far more practical than treating each regulation separately.
Sectoral regulators add another layer. RBI, IRDAI, SEBI, and telecom regulators all issue their own guidance or directions on information security, cyber resilience, outsourcing, and business continuity. In practice, these frameworks often set the bar for what is considered reasonable in those industries. If you are a bank or an insurance provider, the Data Protection Board is unlikely to view a security posture that falls below your sector regulator’s published expectations as adequate, even if you nominally meet the DPDP Rule 6 baseline. For less regulated sectors such as general B2B SaaS, aligning to internationally recognised frameworks like ISO/IEC 27001 or NIST CSF, while also meeting CERT-In and DPDP-specific requirements, can provide a coherent structure for your safeguards.
For leadership, the implication is clear: aim for one integrated control and evidence set that can be mapped to DPDP, CERT-In, and any sectoral regimes you face. This reduces duplication, improves consistency of implementation, and puts you in a stronger position when multiple regulators or enterprise customers ask, in slightly different language, whether your safeguards are reasonable.

Turning legal language into an operating plan

Once you are clear on what DPDP expects, the question becomes how to embed that duty into how you run technology, operations, and vendor relationships. A practical approach is to treat reasonable safeguards as a programme with clear stages rather than a one-off compliance project.
At a high level, leadership teams can organise the work into the following moves, adjusted for size and sector.
  1. Clarify governance and executive ownership
    Ensure the board explicitly acknowledges DPDP security obligations within the enterprise risk framework and assigns a named executive, such as a CISO, CIO, or Chief Risk Officer, accountability for meeting them, supported by a cross-functional steering group spanning security, legal, compliance, product, and business.
    • Record personal data and breach risk on the board or risk committee agenda at a defined cadence.
    • Define how decisions on risk acceptance, control deferral, and major investments are documented and revisited.
  2. Map personal data and classify systems
    Build and maintain an inventory of where personal data sits across applications, databases, data lakes, end-user devices, and third-party services; identify the categories of individuals involved; and group systems into high, medium, and lower-risk from a data protection perspective based on volume and sensitivity.
    • Include processors and sub-processors in the inventory, noting which data they handle and any cross-border transfers.
    • Use the classification to decide which systems must meet the strictest interpretation of Rule 6 and where a lighter control set is acceptable.
  3. Define a risk-based control baseline
    For high- and medium-risk systems, set a minimum bar that includes encryption of personal data at rest and in transit, role-based access control with strong authentication, detailed logging and centralised monitoring of access and administrative actions, regular tested backups, and retention of relevant security logs and records for at least one year, and then extend this with multi-factor authentication for privileged and remote access, structured patch and vulnerability management, endpoint protection, secure software development and change management, security awareness training, and clear joiner/mover/leaver processes, typically organised using frameworks such as ISO/IEC 27001 or the NIST Cybersecurity Framework as the spine for your controls.[2]
    • Document the baseline as policies and technical standards, not just as tool configurations.
    • Explicitly state where you are going beyond the Rule 6 baseline because of sectoral or customer expectations, so those choices are visibly intentional.
  4. Embed safeguards into vendors and incident response
    Extend your safeguards into processor contracts and operational playbooks so that third parties and internal teams respond in a coordinated way when something goes wrong.
    • Bake DPDP-aligned security obligations, breach notification timelines, and audit or assurance rights into contracts with processors and key sub-processors.
    • Design an incident response plan that coordinates detection, triage, containment, forensics, impact assessment for data principals, and timely notifications to the Data Protection Board, affected individuals, CERT-In, and any sectoral regulators.
    • Assign clear roles for regulatory engagement and customer communication during incidents, and rehearse those roles through simulations.
  5. Build evidence and sequence a 12–18 month roadmap
    Treat evidence generation as part of operations, not an afterthought, so that risk assessments, board minutes, policies, training records, test results, audit reports, change tickets, and logs can be assembled quickly after an incident. Many Indian B2B organisations can reach a defensible baseline over roughly 12–18 months if they focus first on governance and data mapping, then close obvious control and contractual gaps, and finally mature monitoring and independent assurance.
    • Months 0–3: confirm governance, define risk appetite for personal data, and complete an initial data inventory.
    • Months 3–12: implement or tighten core controls and processor clauses for high- and medium-risk systems.
    • Months 12–18: strengthen monitoring, automation, and third-party assurance so that your programme is demonstrably operating, not just designed.

Strategic design choices in building your safeguard baseline

Even with the same legal duties, two organisations may legitimately choose different designs for their security safeguards. The right questions for leadership are less about which individual technologies to buy and more about how you structure responsibilities and operating models so that DPDP obligations are met in a way the business can sustain.
One key decision is how centralised your security function should be. A highly centralised model, with a strong CISO team setting standards and directly operating key controls, can be more consistent and easier to present as a coherent programme to regulators and enterprise customers. However, it can also feel slower to line-of-business teams unless it is well integrated with product and operations. A more federated model, where business units have their own security leads, can move faster and better reflect local needs, but it requires strong central oversight to ensure that core DPDP duties—such as incident reporting, data subject rights handling, and Rule 6 controls—are applied uniformly. For many mid-sized Indian B2B organisations, a pragmatic middle ground is a central security and privacy team that owns policies, tooling, and assurance, supported by nominated security champions in each major business unit.
Another strategic choice concerns how much of your security operations you build in-house versus outsource. Running your own security operations centre offers deep context, direct control over logs and tools, and easier coordination with internal teams. It also demands steady investment and the ability to attract and retain scarce talent. Outsourcing monitoring and certain specialised functions to a managed security provider can be more cost-effective and speed up coverage, but you remain accountable. Under DPDP, you cannot point to an external partner and claim that your duty ended there; you must still ensure they meet baseline expectations, integrate them into your incident response plan, and maintain enough internal capability to understand and act on their findings. Finally, organisations that serve multiple jurisdictions need to decide how they set their global baseline. One option is to build an India-specific DPDP programme alongside existing compliance efforts for regimes such as GDPR. Another is to define a single global standard that meets the strictest requirements you face and then add local obligations—such as DPDP’s log retention requirements, grievance redressal timelines, and specific consent and notice rules—as jurisdictional overlays. The latter approach often offers better operating leverage: one set of controls and evidence that can be explained to regulators and enterprise customers in India and abroad, with clear mapping to each law. The trade-off is that your internal standard may become more demanding than what DPDP strictly requires for some business lines, which is usually a safer position than having to explain why a lower bar was chosen.
Key strategic design choices when building a reasonable safeguard baseline.
Decision area Option Upside Risks / constraints
Security ownership model Highly centralised CISO-led team Strong consistency of controls and easier to present a single programme to regulators and enterprise customers. Can feel slower or remote to product and business teams if not well integrated with day-to-day delivery.
Security ownership model Federated security with BU ownership Closer to local needs and faster response to business changes and client demands. Higher risk of inconsistency and gaps in DPDP core duties without strong central standards and assurance.
Security ownership model Hybrid (central standards with BU champions) Balance between control and agility; central team owns frameworks and tooling, while BU champions localise and execute. Requires investment in coordination and clear escalation paths to avoid fragmentation.
Security operations capability In-house SOC and engineering team Deep understanding of your environment, tighter control over logs and tools, and easier integration with internal teams and processes. Higher fixed costs and dependence on scarce security talent; requires strong management to stay current.
Security operations capability Managed security provider (outsourced SOC) Accelerates coverage and brings specialised expertise without building everything in-house. You remain accountable under DPDP; must actively manage the provider, integrate them into incident plans, and avoid over-reliance on their reports.
Global compliance strategy India-specific DPDP programme Can tailor controls and documentation tightly to Indian requirements and regulators. Risk of duplicated effort and inconsistent standards if other regimes (such as GDPR) are managed separately.
Global compliance strategy Single global baseline with local overlays One control set and evidence base that can be explained to regulators and enterprise customers across jurisdictions, with clear mapping to each law. Internal standard may exceed the minimum DPDP requirements for some business lines, but that is usually safer than defending a lower bar.

Executive checklist for “reasonable” security under DPDP

Use these questions in board or leadership discussions to gauge whether your current safeguards and evidence would likely be viewed as reasonable if scrutinised after a breach.
  • Has the board explicitly recognised DPDP security obligations in the risk register or equivalent, and does it review progress at a defined cadence?
  • Is there a named executive owner for security and data protection who reports regularly to the board or its risk committee?
  • Do security, legal, compliance, product, and business leaders meet in a cross-functional forum to review incidents, risk assessments, and major changes that affect personal data processing?
  • When significant security trade-offs are made—such as accepting a residual risk or deferring a control investment—are those decisions and rationales documented and revisited?
  • For each major system that processes personal data, is encryption appropriate to the sensitivity of the data in place for data at rest and in transit?
  • Are access controls role-based and supported by strong authentication, with prompt removal or adjustment of access when people change roles or leave?
  • Do you maintain and actively review logs for privileged access and key administrative actions, with relevant logs retained for at least one year?
  • Are backup and restoration procedures for critical systems tested often enough that you are confident you can recover without excessive data loss or downtime?
  • Do you have an incident response plan that has been rehearsed and that explicitly covers DPDP breach notification steps alongside CERT-In and any sectoral requirements you face?
  • Is security awareness training tailored to different roles, delivered on a defined schedule, and recorded so you can evidence completion?
  • Do you maintain an up-to-date register of all processors and sub-processors that handle personal data on your behalf, including what they process and where they are located?
  • Do contracts with those entities include security obligations that meet or exceed the DPDP Rule 6 baseline, clear breach notification timelines, and rights for you to obtain independent assurance of their controls?
  • If the Data Protection Board or a major customer asked tomorrow for proof that your safeguards are reasonable, could you assemble a coherent package of risk assessments, policies, training records, penetration test and audit reports, incident logs, and relevant board minutes within days rather than months?

Common questions about reasonable security safeguards under DPDP

Executives often share similar concerns when they start translating DPDP’s security duties into concrete plans. Clarifying a few common points can help align expectations across leadership, security, and legal teams.
FAQs

An ISO/IEC 27001 certificate is strong evidence that you have implemented an information security management system aligned to an internationally recognised standard, but it is not an automatic guarantee that your safeguards will be viewed as reasonable under DPDP. The Data Protection Board is likely to look beyond certificates at the actual scope of your implementation, how well controls operate in practice, whether you have addressed DPDP-specific requirements such as log retention and breach notification, and how your safeguards line up with the sensitivity and scale of personal data you process. A narrow-scope certification, outdated controls, or weak incident response can still be problematic even if a certificate exists. Treat standards and certifications as part of your evidentiary package, not as a shield that replaces risk-based judgement.

DPDP does not exempt smaller organisations from implementing meaningful security safeguards, but it does allow for proportionality. A mid-sized SaaS provider processing business contact data and HR information will generally not be expected to match the security investment of a major bank, but it will still be expected to meet the Rule 6 baseline—encryption where appropriate, strong access control, effective logging and monitoring, backups, and one-year log retention—alongside basic good practice such as multi-factor authentication for administrative access, timely patching, secure development, and rehearsed incident response. If you sell to larger enterprises, their vendor risk assessments will often set a practical bar for you: failing those due to obvious gaps or informal processes is a sign that your safeguards may not be reasonable for your market position, even if you are relatively small.

No. Using established cloud platforms and security service providers can significantly improve your technical baseline, but under DPDP you remain the Data Fiduciary and carry the primary duty to take reasonable safeguards. You must understand which security responsibilities sit with you versus the provider, ensure that configurations are appropriate for the sensitivity of your personal data, and verify that your processors meet at least the DPDP Rule 6 baseline. Contracts should address security measures, breach notification timelines, cooperation in investigations, and audit or assurance mechanisms. In an investigation, the Data Protection Board is likely to examine how you selected, managed, and monitored your processors, not just which vendors you use.

While there is not yet an established body of case decisions under DPDP, experience from other regimes suggests several factors are likely to influence the Board’s view. These include the nature, sensitivity, and volume of the personal data affected; how foreseeable and preventable the breach was given known threats and published best practices; whether your controls broadly align with recognised frameworks and sectoral norms; the quality of your governance, including board oversight and documented risk assessments; how quickly and transparently you detected, contained, and reported the breach; and whether similar weaknesses had been identified earlier and left unaddressed. Organisations that can show a coherent, risk-based programme and a mature response to incidents are more likely to be seen as having taken reasonable safeguards, even if an attack still succeeded.

DPDP Rule 6 points to retaining relevant security logs and records for at least one year as part of reasonable safeguards, which sets a minimum rather than a maximum. CERT-In Directions, sectoral regulations, contractual obligations with customers, and your own forensic and internal investigation needs may justify or require longer retention for certain logs. At the same time, DPDP’s broader principles on storage limitation and data minimisation apply, so indefinite retention of all logs is unlikely to be appropriate. A practical approach is to define retention periods by log type, balancing regulatory requirements, business needs, and the sensitivity of any personal data those logs may contain, and to document the rationale so you can explain it if asked.

Sources
  1. The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) - Ministry of Law and Justice, Government of India
  2. India Digital Personal Data Protection Act, 2023 (DPDP Act) and Digital Personal Data Protection Rules, 2025 – Overview - EY India
  3. Overview and Key Highlights of The Digital Personal Data Protection (DPDP) Rules, 2025 - RSM India
  4. Guidelines on Information Security Practices for Government Entities - Indian Computer Emergency Response Team (CERT-In), MeitY
  5. Cyber Security Framework in Banks - Reserve Bank of India
  6. Identify, Protect, Detect, Respond and Recover: The NIST Cybersecurity Framework - National Institute of Standards and Technology (NIST)

Related pages

Updated At May 16, 2026

The 72-Hour Breach Clock: Incident Response Plan for DPDP

How Indian leadership teams can turn DPDP’s 72-hour breach reporting rule and CERT-In’s six-hour clock into a reliable incident response operating model by May 2027.

 Updated At May 17, 2026

The 2026 DPDP Audit Checklist: 50 Things Auditors Will Ask For

A procurement-focused guide for Indian business leaders that turns the DPDP Act 2023 and DPDP Rules 2025 into a 50-point 2026 audit checklist, with concrete artefacts, RFQ questions, and vendor scorecard criteria.

 Updated At Apr 18, 2026

Log Retention, Deletion, and Audit Trails: Building an Evidence Program

A business-style piece for technical evaluators that explains log retention, deletion, and audit trails— building an evidence program and turns policy

 Updated At May 17, 2026

What the DPDP Act Means for Indian Businesses in 2026

In 2026, India’s DPDP Act and 2025 Rules move from policy to enforcement. See how they reshape governance, data operations, vendors and risk—and what leadership teams must build now.

 Updated At May 26, 2026

DPDP Act penalty: board-level view of fines and 72-hour breach timelines

penalties under dpdpd act 2023 is upto 250 carore and breach notification timeline is 72 hours to the Data Protection Board of India

 Updated At May 19, 2026

Data Processors vs Data Fiduciaries: Operational Responsibilities Explained

For Indian procurement and leadership teams: a practical guide to data fiduciary vs data processor roles under the DPDP Act, with contract, RFQ, scorecard, and vendor-risk implications.

 Updated At Apr 18, 2026

Significant Data Fiduciary (SDF) Status: Checklist for Fast-Growing Companies

A business-style piece for decision-makers that explains significant data fiduciary (sdf) status— checklist for fast-growing companies and turns policy

 Updated At May 20, 2026

Board Reporting for Privacy: KPIs Every Leadership Team Should Track

Learn how Indian boards can use a focused privacy KPI stack aligned to DPDP, NIST and ISO 27701 to oversee regulatory exposure, operations and trust.

 Updated At Apr 18, 2026

The DPO Handbook for Indian Companies

A business-style piece for decision-makers that explains the dpo handbook for indian companies and turns policy requirements into an operating plan for

 Updated At Apr 18, 2026

Cross-Functional Privacy Governance: Legal, Product, Security, Marketing

A business-style piece for decision-makers that explains cross-functional privacy governance— legal, product, security, marketing and turns policy requirements