When should organisations prioritise file-level controls over perimeter security for DPDP?

Why file-level controls become the better control plane

File-level controls matter when the sensitive record no longer stays inside a controlled application or network segment. Once a file is downloaded, emailed, synced to shared storage, or handed to a processor, perimeter security can still protect the system, but it no longer explains or governs the data item itself. CIS Controls v8 is a useful baseline here because it aligns protection with data handling, access control, logging, and account management rather than relying only on boundary defence.

The practical shift is from blocking access to governing the object. Perimeter controls answer whether a user or system can reach an environment; file-level controls answer whether a specific file can be opened, forwarded, printed, expired, watermark-protected, or revoked after it leaves that environment. For DPDP, that distinction matters because accountability depends on proving control over the personal data itself, not only over the network that once hosted it.

This becomes most important in workflows with attachments, exports, offboarded users, collaboration links, or processor transfers. In those cases, file classification, encryption, and usage restrictions often do more to preserve traceability than another firewall rule or segmentation layer. Standards such as ISO/IEC 27001:2022 Information Security Management reinforce the same point: control selection should follow the information asset and its lifecycle, not just the hosting system.

Where perimeter security still helps, and where it stops

Perimeter security remains valuable for reducing bulk exposure, stopping commodity threats, and controlling inbound and outbound traffic. It is still the right first line for endpoint hardening, gateway filtering, malware scanning, and blocking obviously unauthorised channels. The limitation is that these measures are strongest before the file is separated from its original trust boundary.

Once a file is outside the perimeter, the relevant failure mode changes. A copied spreadsheet, PDF, archive, or export can be redistributed through personal accounts, unmanaged devices, or partner systems without ever touching the original application again. That is why file-level governance is often the only control that can follow the data across boundaries and preserve the organisation’s ability to demonstrate handling discipline under DPDP.

Cloud collaboration and third-party transfer make this sharper, not weaker. When data is shared through drives, portals, or processor workflows, the organisation needs controls that travel with the document, because the enforcement point is no longer the network edge. CSA Cloud Controls Matrix is helpful as a control-map because it ties cloud handling to data governance, access, and lifecycle management rather than assuming a single perimeter.

What “prioritise” should mean in practice for DPDP

Prioritisation is not an all-or-nothing choice. Organisations should use perimeter controls to reduce exposure at the boundary, but give file-level controls the lead role wherever personal data is expected to move. The deciding factor is not whether a control is technically available, but whether the data’s normal journey exits the system of record.

A sensible rule is to prioritise file-level controls when the answer to any of these is yes: the data is routinely exported, the data is shared with processors or external users, the data is sent as attachments, or the data must remain governable after download. In those situations, classification, encryption, rights management, expiration, and auditability become the evidence layer for compliance, while perimeter controls stay as supporting guardrails.

That also changes the assurance question. Instead of asking only whether traffic was blocked or allowed, teams should be able to show who accessed the file, where it went, whether it was copied onward, and whether revocation or expiry still worked after distribution. For that reason, a file-centric control model usually produces better audit evidence than a perimeter-only model when DPDP obligations attach to downstream handling.

Practitioner Guidance

What to prioritise: Start with the data paths that leave your application boundary most often, especially exports, attachments, shared-drive synchronisation, and processor exchanges. Those paths should receive classification, encryption, expiry, and traceable access controls before you spend time hardening edges that never see the data after release.

What to verify: Confirm that the organisation can still answer four questions after a file leaves the source system: who opened it, whether it was forwarded or copied, whether access can be revoked, and whether the event is auditable. If those answers are weak, perimeter controls are not the main control plane for DPDP.

Practitioner takeaway: Use perimeter security to reduce exposure, but use file-level controls to prove governance over personal data once it is no longer inside the original boundary, because that is where DPDP accountability is won or lost.

Related resources from NHI Mgmt Group

• When should organisations prioritise CMMC 2.0 Level 1 controls over broader security programmes?
• When should organisations prioritise workload-level inspection over relying only on perimeter NGFW controls?
• Should organisations prioritise workload-level AI security over prompt-level controls?
• When should organisations prioritise browser security over other identity controls?