Data protection by design and by default applies protections to the data itself, regardless of where it moves. Traditional perimeter security primarily protects the network or application boundary. In a GDPR context, data-centric controls can preserve encryption, access rules, and auditability across downloads, external sharing, and cross-border transfer, which is essential when data leaves the original system.
Data-centric protection changes the unit of security
data protection by design and by default is a shift from boundary thinking to object-level protection. The control follows the data through storage, download, email, APIs, removable media, and cross-border transfer, so the protections remain attached even when the original application boundary no longer exists. That is why this approach is better suited to privacy and GDPR-driven handling of personal data than perimeter-only models.
Traditional perimeter security assumes a trusted inside and a less trusted outside. That model can still help with network filtering, segmentation, and gateway enforcement, but it weakens once users collaborate externally, systems integrate across clouds, or data is copied into endpoints and third-party services. The practical difference is that perimeter controls protect access paths, while data-centric controls protect the content and its permitted use.
A useful way to read the distinction is that one model answers “who can reach the environment?” and the other answers “what may this data do wherever it goes?” Data-centric controls therefore depend on encryption, rights management, classification, retention, and auditable policy enforcement, not just firewalls or application gateways. External sharing and offline copies are where the difference becomes most visible.
Why the difference matters in GDPR and modern sharing workflows
In a GDPR context, data protection by design and by default is not only about access restriction, it is about building privacy and security into the processing model from the start. A browser session, downloaded file, or exported report should still carry the relevant protections where possible, including encryption, access rules, and auditability. That is the core advantage over perimeter-only security, which can no longer observe or control the data once it leaves the guarded zone.
This matters most when data moves across organisational and jurisdictional boundaries. If sensitive records are sent to vendors, collaborators, or remote staff, a network boundary alone cannot ensure the same handling constraints follow the information. Data-centric design reduces reliance on a single trust perimeter and makes policy enforcement more resilient to workflow changes.
For the regulatory lens, the issue is not whether perimeter security exists, but whether the organisation can demonstrate that the data was protected in a way that was appropriate from collection through disposal. That makes design decisions, default settings, and evidence of ongoing control far more important than a one-time network hardening exercise. The EU General Data Protection Regulation (GDPR) is the clearest reference point for that distinction.
Risk and Threat Considerations
Perimeter-first protection fails when the data is replicated, forwarded, cached, synced, or exported into places the perimeter does not govern. The main risk is not only loss of confidentiality, but also loss of visibility into who can open, change, or re-share the data after it leaves the original environment.
Failure mechanism: Controls are anchored to a network or application boundary, so a legitimate download, integration, or external share creates a copy that is no longer protected by the same enforcement point. That leaves the organisation dependent on secondary controls that may be inconsistent, misconfigured, or absent.
Impact: Sensitive data can be exposed outside the original trust zone while retaining too much readability or reuse capability. The result is broader breach impact, weaker auditability, and higher compliance risk when data is handled across endpoints, partners, or jurisdictions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8.3 — Data Protection | Protects sensitive data itself rather than only the network boundary. |
| 6.3 — Data Recovery | Supports recoverability when data is copied, shared, or lost outside the original boundary. | |
| 6.6 — Access Control Management | Limits who can access data after it leaves the perimeter. | |
| Recommendation — Apply data protection controls to preserve confidentiality and integrity across storage, sharing, and transfer. Ensure protected data remains recoverable and verifiable after export or endpoint use. Enforce least-privilege access rules on data objects and their sharing paths. | ||
| EU AI Act | General AI literacy and governance obligations | Relevant when automated processing materially shapes how personal data is protected by default. |
| Recommendation — Align automated data-handling workflows with documented governance and accountability. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Directly addresses protecting data at rest, in transit, and in use. |
| PR.AC — Identity Management, Authentication and Access Control | Controls who may access data even after it moves to new environments. | |
| Recommendation — Apply data-security controls that follow the information beyond the perimeter. Enforce access control consistently across systems, devices, and sharing scenarios. | ||
Practitioner Guidance
What to prioritise: Start with the data classes that are most likely to leave the perimeter, especially personal data, regulated records, and high-value business data. If the information is routinely exported, shared externally, or accessed on unmanaged devices, perimeter controls should be treated as supporting controls, not the primary protection model.
What to verify: Confirm that default configurations are restrictive, that access rules survive common workflows such as download and sharing, and that audit logs still provide usable evidence after the data moves. If the only protection disappears when the file leaves the system, the control is not truly data-centric.
Practitioner takeaway: The real test is not whether the boundary is strong, but whether the data remains protected after normal business use breaks that boundary.
Framework alignment: Use the GDPR to anchor data protection by design and by default, and map implementation to CIS Controls v8 for data protection and access control, plus CISA Secure by Design for default-secure product and configuration choices.
Related resources: Ultimate Guide to NHIs, What are Non-Human Identities is useful when data protection depends on the credentials, tokens, or service identities that move or access the data. Touchpoints Between AI and Non-Human Identities is relevant where automated systems are part of the data-sharing path.
Related resources from NHI Mgmt Group
- What is the difference between perimeter-based CAD security and data-centric protection for neutral files?
- What is the difference between perimeter-based data protection and data-centric security for shared content?
- What is the difference between identity-based microsegmentation and traditional perimeter security?
- What is the difference between cybersecurity mesh architecture and traditional perimeter-based cloud security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
