Zero Trust
A security approach that trusts no user or device by default and checks every access request.
Zero trust is a security approach that never assumes a user, device or network is safe just because it is inside the company; every request is checked each time, and only the access needed is granted.
Meaning of Zero Trust
Zero trust is not a DPDP term, but it fits the Act's duty to protect personal data. It means verifying identity, device health and permissions each time, instead of trusting anyone inside the network.
Traditional security resembled a castle: a strong perimeter, with anyone inside the walls trusted. That model fails when staff work from home, applications live in the cloud, vendors connect remotely and one phished laptop gives an attacker a free run of the internal network. Zero trust replaces it with the idea of "never trust, always verify". Each request to reach data is evaluated on identity, device health, location, behaviour and the sensitivity of the resource, whether it comes from the office or a coffee shop.
Zero trust is an architecture and a mindset, not a product, and it is not a DPDP term. Published frameworks, such as NIST SP 800-207, describe its principles: verify explicitly, grant least privilege, and assume breach. Its link to the Act runs through Section 8(5), which requires reasonable security safeguards to prevent a personal data breach, and Section 8(4), which requires appropriate technical and organisational measures. Rule 6 names access control, monitoring and logs, and data protection techniques such as encryption, which are the building blocks of zero trust.
Core components include strong identity with multi-factor authentication, device posture checks, micro-segmentation that confines movement inside the network, short-lived and context-aware access, encryption in transit and at rest, and continuous monitoring with logging. In a zero-trust design, a compromised account or device can reach only a small slice of data, and unusual behaviour triggers extra checks or a block. That containment is valuable for personal data, where the aim is to limit both the likelihood and the size of a breach.
It differs from a VPN-based model, where a successful login opens broad network access. It also differs from simply buying more tools: zero trust is adopted in stages, starting with the most sensitive data and the most exposed users. Organisations that process data for many clients, or that qualify as a Significant Data Fiduciary, often find it the most practical way to demonstrate that safeguards match the risk, as Rule 13 expects an annual audit.
Examples of Zero Trust
A company requires every employee to log in with MFA and gives access only to the systems their job requires.
A SaaS start-up with fifty staff moves from a shared office VPN to single sign-on with MFA. Engineers can reach production databases only through a short-lived, approved session, so a stolen laptop cannot reach customer data.
A hospital segments its network so that medical devices, administrative PCs and the patient-records system sit in separate zones. When a front-desk computer is infected, the malware cannot spread to the records database.
A fintech firm grants a vendor's support engineer read-only access to one dashboard for four hours, on a managed device, with all actions recorded. After the ticket closes, the access disappears automatically.
Why Zero Trust matters
The attacks that cause the largest data protection failures, such as phishing, credential theft, insider misuse and ransomware, share one feature: once inside, the attacker moves freely. Zero trust attacks that feature directly. By narrowing what any single identity can reach, it limits how many people's data a single compromise can expose. Given penalties of up to ₹250 crore for failing to take reasonable security safeguards, designing for containment is cost-effective protection.
It also supports modern work. Employees can use approved devices from anywhere, contractors can be given narrow time-bound access, and acquisitions or new vendors can be connected without opening the whole network. For regulators and clients, a documented zero-trust roadmap with access reviews and logs shows that safeguards were designed, not merely bought.
How it works in practice
- 1Map your sensitive data and who needs it. Identify systems holding personal data, classify them by risk, and list the users, services and vendors that use each. You cannot restrict what you have not located.
- 2Strengthen identity first. Deploy single sign-on with multi-factor authentication for every user, remove shared accounts, and give administrators separate privileged accounts with extra controls and session recording.
- 3Check devices and context. Allow access to sensitive applications only from managed, patched devices, and add conditions on location, time and risk signals so that suspicious requests face extra checks.
- 4Segment the network and applications. Put sensitive databases in isolated zones, allow only the specific connections they need, and replace broad VPN access with per-application access.
- 5Log everything, review continuously and test. Retain access logs for at least a year as Rule 6 expects, set alerts for abnormal behaviour, and use penetration tests to confirm that the segmentation really holds.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Treating zero trust as a product purchase. It is a way of designing access, so tools help only when policies and processes change with them.
Trying to change everything at once. Start with the crown jewels, such as customer databases and admin accounts, and expand in stages.
Verifying users at login and then ignoring them. Continue to evaluate behaviour and context during the session.
Compliance tips
Use a phased roadmap with measurable milestones, such as the share of users on MFA or applications behind per-app access, and report progress to leadership.
Include vendors and contractors in the model. Give them least-privilege, time-limited access instead of general network entry.
Document your design choices and access reviews. Written reasons for each control help show reasonable safeguards if the Board ever asks.
Common questions about Zero Trust
Does the DPDP Act require zero trust?
No. The Act and Rules do not name any architecture. They require reasonable security safeguards under Section 8(5) and Rule 6. Zero trust is a recognised way to meet such expectations through strong access control, monitoring and containment, but other designs can also qualify.
Is zero trust the same as multi-factor authentication?
No. MFA is one important building block, verifying who the user is. Zero trust also checks device health, limits access to what is needed, segments the network and monitors continuously. MFA alone leaves a trusted user free to roam widely.
Is zero trust only for large companies?
No. Small firms can apply the principles using cloud tools: single sign-on, MFA, least-privilege roles and managed devices. The investment scales with risk and size, so begin with the most sensitive data and most exposed accounts.