Strategic Study India  |  Maj Gen PK Mallick, VSM (Retd)

Abstract

For decades, cybersecurity has been organised around protecting networks, systems, and organisational perimeters. Firewalls, intrusion-detection systems, secure gateways, virtual private networks, endpoint controls and network segmentation were developed on the assumption that an organisation possessed a relatively identifiable and controllable digital boundary.

The expansion of cloud computing, remote work, software-as-a-service, application programming interfaces, third-party dependencies, and artificial-intelligence systems has weakened the assumption that organisations can protect information primarily through a stable network perimeter.

This paper examines the transition from perimeter-centric cybersecurity to data-centric security, defined here as protecting information according to its sensitivity, context, value, and intended use throughout the data lifecycle. Using qualitative comparative analysis of the Equifax, SolarWinds, Colonial Pipeline, and All India Institute of Medical Sciences Delhi incidents, the paper examines how different initial compromise vectors produced data exposure, operational disruption, or loss of trust when post-compromise controls were insufficient.

The paper examines the limitations of traditional perimeter-based security; the relationship between data-centric security and Zero Trust; the protection of data at rest, in motion, and in use; data governance and accountability; and the emerging implications of artificial intelligence and agentic AI. The paper further examines the implications of agentic artificial intelligence, whose non-human identities, delegated authority, and tool access create new challenges for least privilege and continuous verification.

As digital boundaries dissolve, security must shift from defending networks to protecting data itself. This paper argues for a doctrinal transition to data-centric security, integrating Zero Trust principles and resilience across the data lifecycle.

Index & Navigation

• Introduction
• Data & Sources of Big Data
• Situating Data-Centric Security Amid Emerging and Disruptive Technology
• Traditional Perimeter Security Vs Data-Centric Security
• Institutional Precedent: Lessons from the United States Department of Defense Data Strategy
• The Data Lifecycle and the Three States of Data
• Zero Trust as an Enabling Architecture for Data-Centric Security
• Operationalising Data-Centric Security
• Lessons from Real-World Breaches (Equifax, SolarWinds, Colonial Pipeline, AIIMS)
• Discussion: Toward a Doctrine of Resilience & Implementation Roadmap
• Conclusion
• References

Introduction

The digital transformation of organisations has fundamentally altered the nature of the cybersecurity problem. For many years, the central question in cybersecurity was relatively straightforward: How do we keep attackers out of our network? This question shaped the development of firewalls, secure gateways, intrusion protection systems, intrusion detection systems, segmented networks, endpoint controls, security operations centres and virtual private networks.

These controls remain essential. However, they were designed primarily for an environment in which an organisation had a relatively identifiable digital boundary. Employees generally worked within organisational facilities, applications were hosted in organisation-controlled data centres and sensitive information was stored in a comparatively limited number of systems.

That operating environment has fundamentally changed. The network remains a critical layer of defence and operational resilience. However, the network can no longer be treated as the sole or final boundary of security.

Contemporary data environments are distributed across private data centres, public clouds such as Amazon Web Services, Microsoft Azure and Google Cloud, software-as-a-service platforms, mobile devices, collaboration systems, data lakes, APIs, contractors, partners and artificial-intelligence platforms. Users increasingly access information through identities rather than through a traditional corporate network. Employees work from homes, airports and coffee shops with untrusted or externally managed networks; developers pull production data onto local laptops to train machine-learning models; vendors and partners may possess Application Programming Interface (API) credentials or privileged access that bypass gates the organisation spent years building. Access is increasingly mediated by identity rather than by network location. Internet-of-Things devices and other connected systems create additional points through which data can be generated, accessed or transmitted.

Consider a scenario in which an organisation's firewall, endpoint protection and identity controls all function exactly as designed, yet a confidential file is downloaded by an authorised user, copied to a personal cloud drive, and shared with an unauthorised person. At what point did the security model fail? The uncomfortable answer is that it may never have been designed to protect the file itself. Consequently, the traditional concept of an organisational perimeter is becoming increasingly difficult to sustain.

The central security question therefore needs to evolve. It is no longer sufficient to ask whether an organisation can keep an attacker outside its network. Organisations must also ask: If data is accessed, copied, moved or exposed, can it remain protected?

Research Question. Why are conventional perimeter-centric cybersecurity architectures increasingly insufficient for protecting high-value information in distributed, cloud-enabled and AI-enabled environments?

This paper argues that cybersecurity must increasingly be organised around persistent protection of data throughout its lifecycle rather than relying primarily on the security of the infrastructure in which that data temporarily resides.

Method and Scope. This paper uses qualitative comparative case analysis to examine how distinct initial compromise vectors translated into data exposure, loss of availability, or operational disruption. The cases were selected because they represent application vulnerability, software supply-chain compromise, credential compromise, and network-segmentation failure. The analysis evaluates each case against four data-centric questions: what data or mission service was at risk, which control failed, what protection existed after initial compromise and which controls could have limited the consequences.

The paper has been organised as follows:

• Section 1. Data. Organisations need to know what data they hold, where it resides, how sensitive it is, and what rules should govern it, the central premise of data-centric security.
• Section 2. Situating Data-Centric Security Amid Emerging and Disruptive Technology. Examines why perimeter-based models are becoming inadequate.
• Section 3. Traditional Perimeter Security Vs Data-Centric Security. Defines data-centric security and analyses.
• Section 4. Institutional Precedent: Lessons from the United States Department of Defense Data Strategy. Draws on the U.S. DoD Data Strategy as an institutional precedent for treating data as a strategic asset.
• Section 5. The Data Lifecycle and the Three States of Data. Sets out the data lifecycle and the three states of data.
• Section 6. Zero Trust as an Enabling Architecture for Data-Centric Security. Discusses Zero Trust Architecture as the operational backbone of data-centric security, including the complications introduced by agentic artificial intelligence.
• Section 7. Operationalising Data-Centric Security. Addresses monitoring, governance and auditability.
• Section 8. Lessons from Real-World Breaches. Draws lessons from four major breaches.
• Section 9. Discussion: Toward a Doctrine of Resilience. Discusses implications for doctrine and implementation roadmap.
• Section 10. Conclusion.

Data

For the purpose of this paper, data refers to digitally represented facts, observations or records that possess operational, commercial, personal, intelligence or strategic value. Information is data interpreted within context, while metadata describes the origin, characteristics, ownership, classification, handling restrictions and relationships of data. Data-centric security is concerned not merely with the storage infrastructure but with the protection, use, movement, provenance and lifecycle of these data assets.

Sources of Big Data

• Video streaming (applications, websites, conferencing, networks)
• Social networks (Facebook, Twitter, LinkedIn, Baidu, WhatsApp)
• Emails
• Cloud computing storage and platforms (energy, financial, commercial, health care, transportation)
• Internet of Things (routers, networks, sensors, chips, M2M, P2P)
• Geospatial information (GPS, satellite, IP, geocached)
• Video cameras (IP, private, satellite, commercial, public, security)
• Videogames: mobile, online, network, and single player (game servers)
• Apps: streams, stores, and networks
• Dark web domains and dark networks (illicit online communities, auctions, exchanges, markets)
• Industrial and manufacturing systems, local and networked
• Financial transactions (banks, commercial, sovereign, individual)
• Telecommunications user transactions (VoIP, P2P, M2M)
• Search engine usage (keywords, images, audio, video)
• Telecommunications networks (IP, cellular, POT, satellite, mesh)
• Mobile and online web chat and messaging information
• Digital crypto-currency transactions (Bitcoin, Ethereum, P2P, P2M, M2M, mobile, online, offline, local device)
• Health care information and transaction devices and networks (quantified self, commercial, personal fitness)
• Mobile and internet image networks (storage, collaborative, cloud)
• Cross-border sovereign and commercial transaction and information flows (air, sea, land supply chains, logistics, distribution networks)
• Cloud storage networks for every government and industry
• Media networks (entertainment, business, government, public)
• Physical information storage (not digital, online or network-accessible)
• Human genetic information databases
• AIs (chatbots, trading algorithms, digital agents)

Situating Data-Centric Security Amid Emerging and Disruptive Technology

The pressure to rethink security architecture does not arise in isolation; it is a direct consequence of the same technological forces reshaping every other domain. A disruptive technology is an innovation that significantly alters or replaces existing technologies, markets or industries by introducing new ways of doing things, often at lower cost, with greater accessibility or improved performance — the printing press, electricity, the internet, penicillin and the steam engine are among the most consequential examples in history. Contemporary parallels include artificial intelligence, the Internet of Things, ride-sharing platforms, big data, nanoengineering, quantum sensing and unmanned vehicular systems.

Each of these technologies both generates and depends upon vast volumes of data. Big data is conventionally characterised by five properties — volume, velocity, veracity, variety and value — and it is precisely this expansion in the sources, speed and diversity of data that has rendered perimeter-based protection increasingly insufficient. As data multiplies across sensors, platforms, and AI pipelines, the unit that most urgently requires protection is no longer the network segment where the data happens to sit, but the data object itself.

The National Security Science and Technology Strategy (NSSTS), August 2026 of USA identified the following Critical and Emerging Technologies as critical domains Advanced manufacturing and materials, AI and autonomy, Communications and networking, Directed energy, Future computing technologies, Hypersonics and advanced missile technologies, Information management and cybersecurity, Nuclear energy, Positioning, navigation, and timing (PNT), Semiconductors and microelectronics, Sensing and signature management and Space technologies.

The Erosion of the Perimeter: Why Traditional Security Models Are Becoming Inadequate

The Vanishing Perimeter. Traditional security models are perimeter-based, or location-centric: they place significant trust in the network boundary and treat the location of a user, device or workload as an important security signal. That model carries at least three structural weaknesses in a contemporary enterprise environment.

Traditional Perimeter Security Vs Data-Centric Security

The perimeter is no longer clearly defined. An organisation's data may reside across several clouds, SaaS applications, employee devices, backups and third-party platforms, some managed by the organisation and many not. A firewall can protect a network boundary, but it cannot protect a sensitive document once it has been downloaded to a laptop, synchronised to a personal cloud drive, sent to a supplier, or copied into an analytics platform. The average enterprise now uses more than one hundred SaaS applications, over which the organisation controls neither the infrastructure nor the network.

Trust-Once-Inside Is a Liability, Not a Convenience. Most serious breaches of the past several years have originated from stolen credentials, a compromised vendor, or a malicious or careless insider — an actor already "inside" the network and therefore invisible to perimeter defences. In several documented cases, the intrusion arrived through a trusted software-update channel, after which the attacker moved laterally for months without detection. Infrastructure controls do not always protect the information itself: a security team may know that a database server is technically protected without knowing what sensitive information the database contains, who can access individual records, whether permissions have accumulated unchecked over time, where copies of the information now exist, or whether the data remains protected once it leaves the original system.

Supply Chains and Third Parties Have Multiplied the Attack Surface. Every vendor, managed service provider, and open-source library an organisation depends on is now a door into its data — a door the organisation did not build and does not fully control. Critical information infrastructure sectors such as power, telecommunications, and finance are particularly exposed because operational-technology vendors, system integrators, and cloud providers routinely hold privileged access to environments that were never designed with such external access in mind.

The Human Element. According to Verizon's 2023 Data Breach Investigations Report, the human element — encompassing error, privilege misuse, use of stolen credentials, or social engineering — was present in seventy-four per cent of breaches in the dataset analysed that year. A perimeter says little about an authorised employee misusing legitimate access, or a well-intentioned staff member misconfiguring a cloud storage bucket, which remains among the most common causes of large-scale data exposure worldwide.

The Changing Logic of Ransomware. Ransomware operators no longer simply encrypt systems; they exfiltrate data first and threaten publication irrespective of whether the victim restores from backup. Traditional security asks, "How do we keep attackers out?" Data-centric security also asks, "If they get in, what can they actually do with the data?" Framing the problem this way sharpens the distinction between perimeter-centric and data-centric security, and reframes the central question of practice: it is no longer only whether an attacker can enter an environment, but whether, having entered, the attacker can access, understand, modify or exfiltrate the organisation's most valuable data.

In summary, infrastructure security can establish that a database server is protected, but that alone does not answer the following critical questions:

• What sensitive information does the database contain?
• Who can access individual records?
• Have permissions accumulated over time?
• Where do copies of the information exist?
• Is the information being used for an authorised purpose?
• What happens to the information after it leaves the original system?
• Can access be revoked after the information has been distributed?

Data-centric security addresses these questions directly. The central proposition can therefore be expressed as follows:

• Traditional security asks: "How do we keep attackers out?"
• Data-centric security additionally asks: "If they get in, what can they actually do with the data?"

This distinction does not mean perimeter security is obsolete. Firewalls, network segmentation, identity controls and endpoint security remain important defensive layers. Rather, they are no longer sufficient by themselves. Data-centric security adds protection that follows the information across different systems and environments.

Toward a Data-Centric Paradigm

Defining Data-Centric Security. Data-centric security protects information according to its sensitivity, context, and business value, wherever it resides, how it moves, and who attempts to use it. It assumes that networks, devices, applications, identities and perimeters may eventually fail, and that the data itself must therefore carry appropriate protection, policy and accountability throughout its lifecycle. Data-centric security does not replace network or endpoint security; it adds a layer of protection that follows the data across systems and environments, so that when a system, account, device or boundary fails, the sensitive data it held does not automatically become unprotected.

What Data-Centric Security Means in Practice. Data-centric security places the data object — not only the network, server, application, or device — at the centre of protection. Under this approach, data should be discovered and classified; protected according to its sensitivity and business value; accessed only under appropriate conditions; monitored throughout its lifecycle; and governed consistently wherever it is stored or used. A traditional approach might protect the file server, require a virtual private network (VPN) connection, and grant access to members of an engineering group.

A data-centric approach asks further questions: Is the document confidential or highly restricted? Is the user authorised for this specific project? Is the device managed and trusted? Is the user connecting from an expected location? Is the document being downloaded, shared or copied unusually? Should the document remain encrypted after download? Should an external recipient be prevented from forwarding or printing it? Can the organisation revoke access after the fact?

Reasons for Inadequacy of Traditional Security Models

Several developments have contributed to the erosion of the traditional security perimeter.

Cloud and Software-as-a-Service. Organisations increasingly depend upon cloud infrastructure and SaaS applications. External providers may operate the infrastructure, while organisational data may exist across multiple cloud services. The organisation therefore does not necessarily control the underlying infrastructure or network through which its data moves.

A firewall can protect a network boundary, but it cannot protect a sensitive document once it has been downloaded to a laptop, copied to a cloud drive or transferred into a third-party application.

Remote and Distributed Work. Remote working has weakened the traditional distinction between an organisational "inside" and an external "outside".

Users may connect from homes, hotels, airports, public networks or other locations. The user's physical location is therefore an increasingly unreliable basis for establishing trust. Security must instead evaluate the user's identity, the device being used, the requested information, the purpose of access and the circumstances surrounding the transaction.

APIs and Data Flows. Modern applications are increasingly interconnected through APIs, microservices, data pipelines and third-party integrations. Data is therefore no longer stationary. It is copied, transformed, processed and transmitted automatically between systems. A perimeter-based architecture struggles to describe and control these continuous information flows because the security boundary does not necessarily match the data boundary.

Artificial Intelligence and Machine Learning. Artificial intelligence introduces another dimension to the problem. AI systems require large datasets for training, testing and operation. Data may consequently be moved into training environments, analytical platforms and AI applications that were not necessarily designed with the same security controls as production systems.

The emergence of AI creates new ways to interact with sensitive information. Users may provide confidential information to AI systems, while automated systems may access and process information at a scale and speed beyond conventional human activity.

Insider Risk. Perimeter security is inherently limited in addressing authorised users who misuse legitimate access. A valid account can be compromised. An employee can make a mistake. A privileged administrator can misuse access. A third-party account can be excessively privileged.

The fundamental issue is therefore not simply whether access was granted. The more important question is whether a particular user, device, application and context justify access to a particular piece of data at a particular moment.

Perimeter-Centric Security Vs Data-Centric Security

Dimension	Perimeter-Centric Security	Data-Centric Security
Unit of Protection	Network boundary, devices, and systems	The data object itself (file, record, dataset)
Core Question	"How do we keep attackers out?"	"If attackers get in, what can they do with the data?"
Trust Model	Location-based trust (inside vs. outside)	Contextual, adaptive trust (identity, device, purpose, sensitivity)
Failure Assumption	Perimeter can hold; breaches are exceptional	Perimeter will eventually fail; resilience depends on data protection
Access Control	Broad, role-based, often static	Granular, attribute-based, dynamic, revocable
Visibility	Focus on infrastructure status (servers, networks)	Continuous classification, monitoring, and lineage of data
Response to Insider Risk	Limited; assumes insiders are trusted	Explicitly addresses misuse, over-permissioning and context-based access
Supply Chain Exposure	Indirectly managed via vendor contracts	Directly managed by binding controls to data across third-party environments
Resilience Outcome	Systems restored after breach; data often exposed	Data remains protected, auditable, and revocable even after breach
Doctrinal Analogy	Fortress defence (walls, moats, gates)	Manoeuvre and layered defence (protecting the mission asset itself)

Institutional Precedent: Lessons from the United States Department of Defense Data Strategy

The clearest large-scale institutional articulation of data-centric thinking is found in the United States Department of Defense (DoD) Data Strategy, released in October 2020 and reinforced by the Deputy Secretary of Defense's 2021 memorandum "Creating Data Advantage," which opens with the declaration that data is a strategic asset and that transforming the Department into a data-centric organisation is critical to creating decision advantage from the battlespace to the boardroom.

Guiding Principles. The DoD Data Strategy establishes eight guiding principles said to be foundational to all data efforts across the Department:

• Data is a Strategic Asset. DoD data is a high-interest commodity that must be leveraged for both immediate and lasting military advantage.
• Collective Data Stewardship. Data stewards, data custodians and functional data managers must be assigned to achieve accountability across the data lifecycle.
• Data Ethics. Ethics must be placed at the forefront of how data is collected, used and stored.
• Data Collection. Electronic collection must occur at the point of creation, maintaining the pedigree of data at all times.
• Enterprise-Wide Data Access and Availability. Data must be made available to all authorised individuals and non-person entities through appropriate mechanisms.
• Data for Artificial Intelligence Training. Datasets for AI training and algorithmic models are increasingly among the Department's most valuable digital assets and require a framework for protected visibility and responsible brokerage.
• Data Fit for Purpose. Ethical concerns in collection, sharing, use and rapid integration must be weighed, alongside minimisation of unintended bias.
• Design for Compliance. IT solutions must automate the information-management lifecycle while properly securing data and maintaining end-to-end records management.

Source: US DoD Data Strategy 2020

Seven Goals for Data as a Strategic Asset. A core tenet of the DoD Data Strategy is that data is not an information-technology asset but an integral part of the mission itself. Weapons platforms, connected devices, sensors, training facilities, test ranges and business systems generate enormous volumes of data that must be high-quality, accurate, complete, timely, protected and trustworthy. The strategy therefore commits DoD data to seven properties summarised below.

Goal	What it means for consumers of the data
Visible	Consumers can locate the data they need.
Accessible	Consumers can retrieve the data.
Understandable	Consumers can find descriptions of the data sufficient to recognise its content, context and applicability.
Linked	Consumers can exploit complementary data elements through their innate relationships.
Trustworthy	Consumers can be confident in the data for decision-making.
Interoperable	Consumers and producers share a common representation and comprehension of the data.
Secure	Consumers know the data is protected from unauthorised use and manipulation.

Operationalising "Make Data Secure". The DoD Data Strategy treats protecting data at rest, in motion, and in use — within applications, with analytics, and so on — as a minimum barrier to entry for future combat and weapon systems. A disciplined approach to data protection, such as attribute-based access control applied across the enterprise, is intended to let the Department maximise the use of its data while employing the most stringent security standards available.

The strategy will be judged to have made progress toward securing data when granular privilege management governs access, use and disposition of data; when data stewards regularly test classification criteria against the risk of unintended aggregation; when approved standards for security markings and records management are implemented; when data-loss-prevention technology is in place; when only authorised users can access and share data; when access and handling-restriction metadata are bound to the data in an immutable manner and when access, use and disposition of data are fully auditable.

Interoperability receives comparable emphasis: achieving both semantic and syntactic interoperability, using common data formats and machine-to-machine communication, is treated as essential for successful decision-making in joint and coalition operations.

Although the DoD Data Strategy is an American defence-sector document, its underlying logic — that data quality, protection, and governance must be engineered as deliberately as any weapons platform — travels well beyond that specific institutional context. It is directly relevant to any organisation, defence or civilian, operating critical information infrastructure that depends on the confidentiality, integrity and availability of large, distributed datasets.

The Data Lifecycle and the Three States of Data

The Data Lifecycle. Data security is best understood as a lifecycle problem rather than a point-in-time control. Six stages recur across most data-governance frameworks:

• Creation / Collection. Data is generated or captured through a form submission, a sensor reading, a database write, or an authored document. Classification should begin here, tagging sensitivity at the point of creation rather than retroactively.
• Storage. Data comes to rest in a database, file system, backup, cloud store or data lake.
• Use / Processing. Data is actively read, computed upon or displayed in an application, a query, an analytics job, or on a screen.
• Sharing / Transmission. Data moves between users, systems, business units, suppliers, customers or regulators, through an API call, an email attachment, or a replication job.
• Archival. Data is preserved for legal, regulatory, operational or historical reasons but is no longer actively used; this is often the most neglected stage from a security standpoint.
• Destruction. Data is permanently deleted or cryptographically shredded once it is no longer needed.

Three States of Data. Overlaid on the lifecycle are three states in which data can exist at any given moment, each carrying a distinct risk profile and requiring distinct protections.

The data lifecycle mapped against the three states of data — at rest, in motion and in use — with representative protections for each state.

Data at Rest. Stored in databases, cloud object stores, devices, backups, laptops, and USB drives. Its principal risks are theft, leaks, misconfiguration, unauthorised access, stolen devices, excessive retention and weak backups; its typical protections are encryption, access controls and backup resilience.

Data in Motion. Moves across networks through emails, APIs, file transfers, database replication and cloud synchronisation. Its principal risks are interception, man-in-the-middle attacks, manipulation, misdirected transfers, and compromised endpoints; its typical protections are Transport Layer Security (TLS) / Secure Sockets Layer (SSL), virtual private networks and secure tunnels. The 2013–2014 Target Corporation breach, in which attackers pivoted from a compromised third-party vendor connection into the retailer's payment network, is a widely cited illustration of the risks attaching to data in motion across a trusted supply-chain link.

Data in Use. Data is actively accessed, viewed, calculated or modified — an employee viewing a record, an application querying a database, or an analytics job processing data. Its principal risks are privilege abuse, credential theft, malware, screenshots, memory theft and unauthorised copying. Its typical protections are identity and access management, continuous monitoring and, increasingly, confidential computing. Data in use is generally the hardest state to protect because legitimate applications and users need the data in a usable and therefore exposed form.

Traditional encryption typically requires data to be decrypted before ordinary applications can process it, which is why access control, isolation, monitoring and careful application design remain essential. Advanced techniques such as confidential computing and encrypted computation can reduce exposure in particular scenarios but should complement, not replace, these basic controls.

Illustration: A Hospital Patient Record. The lifecycle and the three states can be traced through a single, concrete example. A clinician enters a patient's symptoms and identity information (creation). The record is stored in an electronic health-record database and included in backups (at rest). A doctor views it, and an analytics system processes de-identified copies (in use). The record is transmitted to a laboratory or specialist through an API (in motion). The hospital retains it for the required statutory period (retention/archival), after which expired copies, including temporary files and obsolete backups, are securely deleted (disposal). At every step, the institution should be able to state what data is present, who can access it, why access is needed, where it travels, and when it should be deleted.

Typical Technical Protections Mapped to the Data Lifecycle

Control	Description
Encryption	Encrypt databases, disks, cloud storage, backups and removable media.
Key management	Store encryption keys separately, restrict key access, rotate keys, and monitor their use.
Access control	Apply least privilege, role-based access control, or attribute-based access control.
Data minimisation	Collect and retain only what the organisation actually needs.
Classification	Label information by sensitivity — public, internal, confidential, or restricted.
Tokenisation and masking	Replace sensitive values with tokens, or display only partial values.
Backup security	Protect backups from unauthorised access and ransomware, including through offline or immutable copies.
Discovery and monitoring	Find sensitive data in unexpected locations — old shares, test environments, developer repositories.

Zero Trust as an Enabling Architecture for Data-Centric Security

Zero Trust is not a product but a philosophy — never trust, always verify. It assumes the network is hostile, the user may be compromised, and a breach has, in effect, already happened. Every access request must therefore be authenticated, authorised and encrypted regardless of its origin. The United States National Institute of Standards and Technology (NIST) formalised this approach in Special Publication 800-207, Zero Trust Architecture, published in August 2020, which describes zero trust as an evolving set of cybersecurity paradigms that move network defences from static, network-based perimeters toward a focus on users, assets and resources, removing the implicit trust historically granted based on network location alone.

In practice, Zero Trust means identity-aware proxies in place of Virtual Private Networks (VPN), micro-segmentation in place of flat networks, continuous validation in place of one-time login and least-privilege access in place of broad standing access. If data-centric security defines what an organisation protects, Zero Trust defines how it protects it. Together they replace the castle-and-moat model with something closer to a distributed immune system, in which no single compromised component grants an attacker the run of the enterprise.

Zero Trust provides an important access-control and decision architecture through which many data-centric security principles can be operationalised. However, data-centric security also requires capabilities beyond Zero Trust, including data discovery, classification, encryption, tokenisation, digital rights management, data loss prevention, provenance, retention management, and governance.

Agentic Artificial Intelligence and the Inversion of Zero Trust. Agentic AI refers to AI-enabled systems that can plan and execute multistep tasks, invoke tools or applications, maintain task state and act with limited human intervention. Unlike a conventional conversational model, an agent may retrieve, transform, transmit or modify data through connected systems.

A significant complication has emerged from the rapid adoption of agentic artificial intelligence. AI systems, sometimes described as bots that crawl through networks with a degree of autonomous initiative, are designed to complete assigned tasks with limited human supervision. According to Doug Cossa, Intelligence Community Chief Information Officer (IC CIO) at the Office of the Director of National Intelligence (ODNI), speaking at the DODIIS 2026 conference in Tampa, agentic AI is forcing the Defense Department and the Intelligence Community to rethink how Zero Trust is implemented at the enterprise level, because such systems are designed to operate autonomously and therefore may require broad access to data, tools and systems to function at all. Cossa noted that this development has, in effect, inverted the logic of Zero Trust. Organisations have moved from a default posture of least-privilege or no access toward a model in which an AI agent is granted nearly everything it needs to operate independently. This is precisely the opposite of the incremental, continuously verified access that Zero Trust was designed to enforce. His remarks reportedly included the suggestion that government may need to develop verifiable "digital birth certificates" for AI agents, so that identity and precisely scoped permissions can be established and audited for non-human actors in the same way they are for human users.

This tension is directly relevant to data-centric security. If users and devices are permitted to request, store and manipulate data under Zero Trust discipline, autonomous AI agents will increasingly do the same and at a scale and speed that make manual review impractical. A data-centric posture, in which protection travels with the data object rather than resting solely on the identity making the request, offers a partial answer: even where an agent's access scope must be broad to be useful, encryption, classification-aware access policies and continuous monitoring of what is actually done with data can constrain the damage a compromised or misdirected agent can cause.

Operationalising Data-Centric Security

Monitoring and Detection. Security teams require visibility into data access itself, not only into infrastructure events. Signals worth monitoring include an unusual volume of downloads or queries; access to data outside a user's normal role; sudden changes in geographic or behavioural patterns; bulk access by a service account; repeated access-denied events; sensitive data moving toward an unsanctioned application; permissions that expose information more broadly than intended; and attempts to bypass classification or handling controls.

Governance and Accountability. Data-centric security is not solely a technology project. An organisation must decide who owns each category of data, how long information should be retained, which uses are permitted, which regulations apply, who may approve exceptions, how incidents involving sensitive data are escalated, and which metrics demonstrate improvement over time. A useful organising principle is that the data owner defines acceptable use, while security and technology teams provide the enforceable controls that make that definition operational.

Auditability. Organisations should be able to answer, for any given dataset: who accessed it; what exactly they accessed; when and from where; through which application or device; whether the access was authorised; whether the data was copied, modified, shared or deleted; and which policy permitted or blocked the action. Auditability supports incident response, regulatory compliance, investigations and institutional learning, and it creates accountability not only for end users but for data owners, administrators and third parties alike.

Lessons from Real-World Breaches

Four widely documented incidents illustrate, from different angles, what happens when perimeter and identity controls hold or fail while data-level protections are absent or insufficient.

Equifax (2017). On 7 March 2017, Apache disclosed a critical remote-code-execution vulnerability in the Apache Struts web framework, designated CVE-2017-5638, and released a patch the same day. Equifax's security team received alerts about the vulnerability but failed to apply the patch across all affected systems. On 13 May 2017, attackers exploited the unpatched flaw on Equifax's online dispute portal and, over the following seventy-six days, moved laterally across forty-eight internal databases, discovering plaintext database credentials stored in configuration files. The breach exposed the personal information of approximately 147 million people, including Social Security numbers, dates of birth, addresses, and roughly 209,000 payment card numbers. Equifax's chief executive, chief information officer and chief security officer departed the company, and in 2019 Equifax agreed to a settlement with the U.S. Federal Trade Commission, the Consumer Financial Protection Bureau and forty-eight states worth up to US$700 million — at the time the largest data-breach settlement in U.S. history. The proximate failure was a missed patch; the scale of the loss, however, stemmed from the absence of network segmentation and sensitive data sitting fully accessible once the perimeter was breached. The vulnerability opened the door; poor data isolation determined how much the attacker could take.

SolarWinds (2020). A state-sponsored threat actor, subsequently attributed by the United States and United Kingdom governments to Russia's Foreign Intelligence Service (SVR) and tracked as APT29 or Cozy Bear, compromised the software build process of SolarWinds' Orion network-management platform and inserted a backdoor known as SUNBURST into routine software updates. When customers installed the trojanised updates, the attackers gained a potential foothold in approximately 18,000 organisations, including multiple United States federal agencies and Fortune 500 companies, although only a much smaller subset was selected for active follow-on exploitation. The episode demonstrates that trust extended to a vendor should never automatically become unrestricted trust in that vendor's software: security is not only about protecting databases, but about protecting the software, configuration, credentials, secrets, and integrity of the entire data and software supply chain.

Colonial Pipeline (2021). In May 2021, the ransomware group DarkSide gained access to Colonial Pipeline's information-technology network using a compromised password for a legacy virtual private network account that was still enabled, though no longer in active use, and that lacked multi-factor authentication. The attackers exfiltrated approximately 100 gigabytes of data before deploying ransomware against the company's billing systems. Colonial Pipeline shut down roughly 5,500 miles of fuel pipeline across the U.S. East Coast as a precaution, producing a six-day disruption and fuel shortages across multiple states, and ultimately paid a ransom of 75 bitcoin, worth approximately US$4.4 million at the time, of which U.S. authorities later recovered a majority. The incident shows how the failure of a single identity control — one password, without multi-factor authentication, on an account that should have been deactivated — can escalate from an information-security event into the disruption of physical, real-economy infrastructure. The decisive vulnerability was not simply that ransomware entered the network; it was that the operator could not rapidly establish what remained trustworthy once it had.

AIIMS Delhi (2022). On 23 November 2022, the All India Institute of Medical Sciences (AIIMS), Delhi — India's premier public hospital and medical research institute — suffered a ransomware attack that encrypted approximately 1.3 terabytes of data across five servers, disrupting the eHospital suite that supports patient registration, admissions, billing, discharge, laboratory reports, radiology and outpatient workflows. The hospital was forced into a two-week shift to manual, paper-based operations.

The Indian Computer Emergency Response Team's (CERT-In) preliminary technical analysis, presented to Parliament by the Minister of State for Electronics and Information Technology, attributed the compromise to unknown threat actors exploiting improper network segmentation within the AIIMS information-technology environment. Media reports cited a demand of approximately ₹200 crore in cryptocurrency, though this was not officially confirmed and no formal public attribution to a named group was made; Indian authorities described the perpetrators as unknown or foreign-based elements. Separate investigative journalism linked indicators to Chinese and Hong Kong-based infrastructure, pointing specifically to the ChamelGang threat cluster.

Official disclosures established the occurrence and operational consequences of the attack, while details concerning attribution, ransom demands and the scale of potential data exposure remain dependent on media reporting or investigative analysis.

The AIIMS Delhi breach serves as a stark warning of the limits of perimeter defence in critical national infrastructure. Although a network-boundary gap was the initial point of vulnerability, the incident's true scale — potentially exposing 30 to 40 million patient and staff records — was determined entirely by the lack of protections at the data layer. Because sensitive medical and personally identifiable information (PII) was fully reachable and unencrypted once the external boundary failed, the attackers could easily lateralise and compromise both operational systems and backups. To mitigate such risks, critical infrastructure must implement strict micro-segmentation to isolate core clinical databases from public-facing portals and backup servers. Furthermore, encrypting patient records at rest and applying automatic cryptographic classification would ensure that even if a network is breached, the underlying data remains safe.

Cross-Case Synthesis. Across all four cases, the perimeter was breached through a different initial vector — an unpatched application vulnerability, a compromised software-build pipeline, a single unprotected credential, and a network-segmentation gap. In each case, the initial compromise vector differed. Still, the scale and persistence of harm depended on how strongly identity, network, application, data, and resilience controls constrained post-compromise activity.

The following table summarises the cross-case synthesis of four major breaches, showing that the initial vector of entry differed in every case while the scale of harm was determined by data-layer controls.

Incident	Entry vector	Preventive control	Post-compromise containment	Data-centric protection
Equifax	Unpatched vulnerability	Patch management	Segmentation	Encryption, least-privilege access
SolarWinds	Supply-chain compromise	Build integrity	Behaviour monitoring	Data classification and restricted access
Colonial Pipeline	Compromised VPN credential	MFA	Segmentation	Protection of sensitive operational data
AIIMS	Segmentation weakness	Secure architecture	Micro-segmentation	Encryption and classification

Discussion: Toward a Doctrine of Resilience

The evidence above supports a small number of doctrinal conclusions for defence establishments and critical-infrastructure operators, several of which apply with particular force to Indian critical information infrastructure sectors such as power, telecommunications and finance, where operational-technology vendors, system integrators and cloud providers routinely hold privileged access to environments never designed with such external dependencies in mind.

• Know Your Data. An organisation cannot protect what it cannot see; continuous discovery and classification are foundational, not optional.
• Apply Encryption According to Data Sensitivity, Risk and Operational Requirements. Encrypt data at rest and in transit according to risk, with customer-managed keys wherever feasible, while reducing exposure during processing through isolation, access control, tokenisation, confidential-computing techniques, privacy-enhancing technologies, and application-level safeguards where technically and operationally justified.
• Minimise and Delete. Collect only what is needed, and enforce retention policies with automated deletion.
• Verify Every Access. Zero Trust must apply to data itself; no implicit trust should be extended to users, devices or applications.
• Monitor the Supply Chain. Third-party tools that process an organisation's data require controls at least as strong as those applied internally.
• Treat Immutable Data as Immutable Risk. Genetic, biometric and other permanent data categories require the highest protection tier, since compromise cannot be remediated by reissuing a credential.
• Patch or Compensate. Where a patch cannot be applied immediately, compensating data-level controls — segmentation, tokenisation, restricted access — must be implemented in the interim.

Traditional perimeter security is not obsolete, but it is no longer sufficient on its own. The perimeter is now distributed, identities are variable, and data moves continuously. Data-centric security changes the unit of protection: instead of asking only whether a network or application is secure, it asks whether the data remains protected wherever it travels. This transformation should be risk-driven — beginning with the data that matters most, establishing visibility, reducing excessive access, applying layered protection, and measuring results over time. The objective is not to prevent every possible intrusion, which is not realistic for any large or federated organisation; it is to ensure that when systems, accounts, devices or boundaries eventually fail, sensitive data does not automatically become unprotected as a result.

Implementation Roadmap

Phase 1: Discover

• Build an inventory of high-value data assets.
• Map data owners, custodians, repositories, flows, and copies.
• Identify shadow data in test, development, backup, and SaaS environments.

Phase 2: Classify

• Establish a mission- and risk-based classification scheme.
• Define handling rules for each classification.
• Attach machine-readable labels and provenance metadata.

Phase 3: Reduce Exposure

• Remove stale data and dormant accounts.
• Reduce excessive permissions.
• Separate production, development, backup, and analytics environments.
• Tokenise or mask sensitive fields.

Phase 4: Enforce

• Apply attribute-based or policy-based access.
• Integrate identity, device posture, application, location, mission, and data sensitivity.
• Use data-loss prevention and rights-management controls where appropriate.
• Protect keys separately from the data.

Phase 5: Monitor and Recover

• Monitor access, movement, copying, modification, and deletion.
• Establish behavioural baselines for humans, service accounts, and AI agents.
• Test recovery and data-integrity procedures.
• Measure whether controls reduce blast radius after compromise.

Conclusion

Data-centric security shifts the primary focus of cyber defence from perimeter protection to protecting the data asset itself, wherever it resides or travels. This is not merely a technical adjustment; it represents a doctrinal shift comparable in scale to the earlier move from static to defence-in-depth security architectures. Traditional perimeter defences, built for a world of centralised data centres and on-premises workforces, are structurally ill-suited to an environment defined by cloud computing, mobility, extended supply chains, and increasingly autonomous AI agents operating with broad data access. As data volumes continue to surge and cloud-based, remote, and AI-augmented work becomes the operating norm rather than the exception, this transition is no longer optional; it is a precondition for operational resilience, regulatory compliance, and institutional trust.

Data is becoming the most persistent security boundary in a distributed digital environment. The future of cybersecurity lies in resilient data protection, ensuring that appropriate security controls travel with the data throughout its lifecycle and continue to protect it even when networks, systems or identities are compromised.

Organisations should classify and encrypt sensitive data, enforce policies governing its use and apply Zero Trust principles to both human users and autonomous AI agents. Cybersecurity must also assume that breaches will occur. The objective is not simply to keep attackers out, but to limit what they can access, copy, alter, destroy or exploit once they gain entry. Safeguarding data must become the foundation of modern security strategy for defence establishments and critical-infrastructure operators alike.

References

1. DoD Data Strategy: Unleashing Data to Advance the National Defense Strategy, U.S. Department of Defense, 2020. Link
2. National Security Science & Technology Strategy, USA, August 2026 . Link
3. Memorandum for Senior Pentagon Leadership, Deputy Secretary of Defense, U.S. Department of Defense, 05 May 2021. Link
4. Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly, Zero Trust Architecture, National Institute of Standards and Technology, Special Publication 800-207, August 2020. Link
5. 2023 Data Breach Investigations Report, Verizon, 2023. Link
6. Barry Rosenberg, Agentic AI turning Zero Trust cybersecurity 'on its head', Breaking Defense, 10 August 2026. Link
7. Equifax to Pay $575 Million as Part of Settlement with FTC, CFPB, and States Related to 2017 Data Breach, Federal Trade Commission, 22 July 2019. Link
8. Josh Amishav, Equifax Data Breach Case Study: Causes and Aftermath, Breachsense, 20 May 2026. Link
9. SolarWinds Compromise, MITRE Corporation. Link
10. Jen Easterly, The Attack on Colonial Pipeline: What We've Learned & What We've Done Over the Past Two Years, U.S. Department of Homeland Security, 07 May 2023. Link
11. Sharveya Parasnis, China Backed Hacker Group Behind 2022 AIIMS Attack: Report, MediaNama, 27 June 2024. Link
12. Ajith Athrady, Cyber attack on 5 servers of AIIMS: Minister, Deccan Herald, 10 February 2023. Link

About the Author

Maj Gen PK Mallick, VSM (Retd)

An Electronics and Tele Communication Engineering graduate from B E College, Shibpur, M Tech from IIT, Kharagpur and Fellow of Institute of Electronics and Telecommunication Engineers (IETE), Maj Gen P K Mallick, VSM is an alumni of Defence Services Staff College Wellington, College of Defence Management Secunderabad and National Defence College. Commissioned in Corps of Signals of Indian Army, the officer has varied experience in command, staff and instructional appointments. The officer has taken part in OP RAKSHAK (Punjab), OP RHINO and OP RAKSHAK in the Valley.

The officer has been DAAQMG in HQ 19 Infantry Division, Col GS(System) HQ Eastern Command, Deputy Chief Signals Officer HQ Northern Command and Chief Signals Officer HQ 15 Corps, DACIDS (DIARA) at HQ IDS and Chief Signals Officer in HQ Central Command. He had tenure of Instructor Class A and Officer Commanding Junior Wing in Military College of Telecommunication Engineering, Mhow. He has commanded a Divisional Signal Regiment in OP VIJAY and OP PARAKRAM in Western Command. A winner of COAS Gold Medal Essay Competition and second prize winner four times at USI Essay Competition the officer is a prolific writer, regularly contributes in defence related journals and has published large number papers in peer reviewed journals.

The officer has published Six books: The History of the Corps of Signals Vol IV, China in Cyber Domain, Information Cyber and Space Domain and Its application in Future Land Warfare, Offensive Cyber Operations (OCO): A 360 Degree View, Mind wars: the new battlefield of information warfare and The Profession of Arms: A Guide for Young Army Officers. He has been consultant with NTRO and Vivekananda International Foundation (VIF) and held the appointment of Chief of Army Staff Chair of Excellence at Centre of Land Warfare Studies (CLAWS).

He manages strategicstudyindia.com and indianstrategicknowledgeonline.com.

Suggested Citation:
Mallick, P. K. (2026). Protecting Data in Motion: The Rise of Data-Centric Security in a Borderless Digital World. Occasional Paper, Strategic Study India (SSI), New Delhi. ISBN: 978-93-344-7582-1. https://www.strategicstudyindia.com/2026/08/protecting-data-in-motion-rise-of-data.html/

Strategic Study India (SSI) | Occassional Paper

Protecting Data in Motion: The Rise of Data-Centric Security in a Borderless Digital World

Author: Maj Gen PK Mallick, VSM (Retd)
Publisher: Strategic Study India (SSI), New Delhi
Date of Publish: 28 Aug 2026
Address: New Delhi – 110010
ISBN: 978-93-344-7582-1

📄 Download (PDF)

Copyright © 2026 Maj Gen PK Mallick, VSM (Retd). All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without prior written permission.
Disclaimer: The contents of this book are based on the analysis of material accessed from open source and are the personal views of the author. The contents, therefore, may not be quoted or cited as representing the views or policy of the Government of India or Strategic Study India (SSI).