NexusSec.The split that matters
DPDP readiness projects tend to be presented as a documentation exercise, and a meaningful part of one genuinely is: notices, consent, grievance handling, contracts with processors. That work belongs with your legal advisers and we do not do it.
But underneath the paperwork are questions that only the infrastructure can answer. Which systems hold personal data. Who can reach those systems, from where, and with what authentication. Whether you would know if data left. Whether an access log exists to show anyone. Those are engineering questions, and they are usually where the real gap is.
What we actually do
- Find where the data is. Not a full data-discovery product, but a practical map of which servers, shares and applications hold personal data, built with the people who use them.
- Establish who can reach it. Frequently the honest answer on a flat network is everyone. Fixing that is segmentation plus access control, and it is the single most substantive technical improvement most businesses make.
- Close the obvious exposure. Multi-factor authentication on remote access and email, dormant accounts removed, and whatever is unnecessarily reachable from the internet taken off it. Our assessment produces that list.
- Make it evidenceable. Centralised logging with defined retention, so that if you are asked who accessed what, there is an answer rather than a shrug.
A realistic sequence
If you are starting from nothing, the order that produces the most defensible position for the least disruption is fairly consistent.
- Establish who holds administrative access to the systems that hold personal data, and remove what should not be there. This is usually the fastest meaningful improvement available.
- Put multi-factor authentication on remote access and email. Most incidents involving personal data start with a stolen password, and this makes a stolen password insufficient on its own.
- Map where personal data actually sits. Which servers, which shares, which applications. Built with the people who use the systems rather than inferred from a diagram.
- Separate those systems from general office traffic, so a compromised laptop does not reach them.
- Turn on logging with a defined retention period, so access can be evidenced rather than asserted.
None of this requires a compliance product, and all of it survives whatever the final enforcement posture turns out to be.
What we will tell you not to buy
We would rather say this plainly than have you find out later. A data-discovery platform is rarely worth it at mid-market scale; the map can be built by talking to people who use the systems. A SIEM at this size generates alerts nobody has time to read, which is worse than no alerts because it manufactures a sense of coverage. And a consultancy engagement that bundles legal opinion with technical work is usually weak at both.
An honest position on timing
There is a lot of urgency being sold around this. Our view is more measured: the technical work worth doing for DPDP is almost entirely work that was worth doing anyway. Knowing where your data is, controlling who reaches it, and keeping logs are good engineering regardless of any statute.
So we would not recommend a DPDP-branded project at a premium. We would recommend an assessment, which answers most of the same questions, and then the remediation it surfaces. If that also happens to put you in a defensible position under the Act, so much the better.
Further reading
We have written at more length on what to actually do in 2026. For advisories relevant to Indian infrastructure, CERT-In is the authoritative source, and the CIS Critical Security Controls cover the same technical ground in a vendor-neutral way.
