The common security controls behind India's regulatory wave

India’s security and privacy rulebook has changed quickly. But beneath the new layers of requirements, a common control set is emerging: encryption, tokenization and masking, least-privilege access, audit logging and retention, and controls for keeping regulated data inside India. 

Over the last decade, India has strengthened several major security and privacy requirements, including the Digital Personal Data Protection (DPDP) Rules, the Securities and Exchange Board of India’s (SEBI) Cybersecurity and Cyber Resilience Framework (CSCRF), the Indian Computer Emergency Response Team’s (CERT-In) cybersecurity directions, and the Reserve Bank of India’s (RBI) payment data localization mandate. For organizations operating in India, especially in banking, financial services, payments, or the securities markets, these obligations now stack across regulators, deadlines, and enforcement regimes.  

It’s tempting to treat each one as a separate compliance project, staffed and solved on its own track. But line the technical requirements up, and a recognizable pattern emerges. Collectively, the mandate is clear: The sensitive data, and the credentials that protect it, should be looked after from creation to deletion, reachable only by those who genuinely need them, with a provable record of who touched what. 

This post focuses exclusively on the security control aspects of the frameworks discussed and should not be considered as compliance assessment. The content is provided solely for informational purposes and should not be construed as legal advice and/or regulatory advisory. Organizations should conduct their own legal and compliance assessments before relying on or taking any action based on the information contained herein. This highlights areas where HashiCorp Vault, with support from HashiCorp Boundary and Hashicorp Consul, may be considered when addressing common controls for secrets, encryption, access, auditability, and service-to service protection. Consent, notice, data-principal rights, and other legal obligations are out of scope. 

»Four frameworks, one direction

»DPDP Rules: Security safeguards

The DPDP Rules were notified in November 2025, with phased commencement dates. Any organization that determines why and how the digital personal data of people in India is processed may be impacted, regardless of industry. The fines are serious. Failing to put reasonable security safeguards in place can draw a penalty of up to ₹250 crore. For most boards, a number that size is what escalates data security from an IT task into an enterprise-risk concern.  

Companies need to be focused on several key areas that any security architect would recognize, including but not limited to:  

• Protecting personal data using measures such as encryption, obfuscation, masking, or virtual tokens mapped to that personal data 

• Controlling access to the systems that hold personal data 

• Keeping visibility on access through logs, monitoring, and review 

• Maintaining backups for continued processing 

• Retaining logs and personal data for one year 

»SEBI CSCRF: Cybersecurity for regulated entities

Issued by SEBI in August 2024, the Cybersecurity and Cyber Resilience Framework created one standard built around five resilience goals: anticipate, withstand, contain, recover, and evolve. It reaches across the securities market — stock exchanges, clearing corporations, depositories, mutual funds, portfolio managers, alternative investment funds, stockbrokers, and KYC registration agencies — with requirements scaled to each entity’s size and risk.  

»CERT-In directions: Stringent reporting requirement

Effective June 2022, CERT-In’s directions come down to two core requirements: better observability and faster incident reporting. And they apply to a very wide net: service providers, intermediaries, data centers, body corporates, and government organizations. Notably, covered entities must report specified cyber incidents in accordance with the timelines stipulated under CERT-In. A single incident can also trigger reporting requirements for both CERT-In and DPDP.

»RBI: Data localization and IT security directions 

In 2018, the RBI-mandated payment data must be stored only in India. And where any processing happens abroad, the data must be brought back within 24 hours. It applies to payment system operators and the providers in their chain. This was a turning point, and the rules have only expanded since.  

Table 1. The frameworks at a glance 

Different regulators, different deadlines, different penalties. Underneath, the same handful of technical controls. The below image shows how HashiCorp can help:   

Figure 1. The four frameworks converge on five shared controls, which map to Vault. Filled dots show which frameworks require each control; DPDP does not mandate residency.  

»The common control emergence

Across many of the key rules and requirements, the same five controls come up: 

• Encryption of data at rest and in transit, so intercepted or stolen data is unreadable 

• Tokenization or masking of sensitive fields, so the data flowing through your systems isn’t the real thing in the first place 

• Least-privilege access, so people, applications, and partners reach only what they need, only for as long as they need it 

• Audit logging with monitoring and retention, so every access is visible and reviewable after the fact 

• Data residency, so regulated data and logs stay inside India 

Build each well, and companies answer many of their compliance challenges at once.  

»Vault in the context of control set

Vault is an identity-based secrets and encryption platform, a single audited place to store credentials and keys, encrypt and tokenize data, and control who can do what. It is not a compliance product, and it is not a database that holds all your personal data. It protects the secrets, keys, and sensitive fields routed through it and records every interaction. Vault can help organizations implement several of these controls through:

Figure 2. Vault’s model for hybrid environments: identity-based security, centralized control, and automated secret lifecycles.

»Encryption: Sensitive data encrypted at rest and in transit, using strong, current algorithms

Vault’s Transit engine offers encryption as a service. An application sends Vault a piece of plaintext and gets back ciphertext. The encryption keys themselves never leave Vault and are never exposed to the application. That means developers don’t have to implement cryptography themselves or manage raw keys in their code — a common source of mistakes — and the organization can rotate keys and re-encrypt centrally.

»Tokenization and masking: Sensitive values swapped for tokens that mean nothing on their own

Vault’s Transform engine — a Vault Enterprise and HCP feature — does tokenization, format-preserving encryption, and data masking. Tokenization swaps a real value, such as an account or identity number, for a token that systems can store and pass around freely, while the real value stays locked away in Vault. Format-preserving encryption keeps the shape of the data — a 12-digit number stays a 12-digit number, for example — so it still fits existing databases and screens.  

»Least-privilege access: Access to sensitive systems and data restricted to authorized identities, on a need-to-know basis 

Vault is deny-by-default. Policies grant a named identity access to exactly the paths it needs and nothing more. Vault can also issue dynamic secrets. Instead of a long-lived database password shared across an application fleet, Vault generates a unique, short-lived credential on request and automatically revokes it when its lease ends. A credential that exists for an hour and is tied to one identity is a much smaller risk than a static password that lives for years.  

»Audit logging and retention: A visible, reviewable record of who accessed sensitive data and when, retained for a defined period

Vault’s audit devices records authenticated requests, including which identity accessed which path, whether the request succeeded, and where it came from. To support regulatory retention and investigation requirements, organizations should stream those events to a SIEM or log platform configured for the required retention period, access controls, and tamper-resistant storage.  

»Hardware-backed keys: Dedicated hardware security module and strong cryptographic standards 

Vault Enterprise integrates with hardware security modules and supports architectures that need to remain compliant with the Federal Information Processing Standards (FIPS). An HSM can guard Vault’s own root of trust — the key that unseals Vault — so even someone with the storage disks cannot read what Vault protects.  

»A closer look: API key security and the secrets lifecycle

Controls rarely arrive alone. Instead, a single, ordinary process usually pulls several of them together at once. The clearest example is an industry-specific use case: the API keys a bank gives to its partners.  

When a bank exposes APIs to partners, they authenticate with API keys — long-lived, high-value credentials that, if leaked, can be used to impersonate a trusted partner. India’s rules treat such credentials the way they treat any sensitive secret. The RBI’s IT governance direction expects strong cryptographic controls, restricted access, and audit trails around credentials and the systems that use them. It’s digital payment security direction adds web application firewall and DDoS protection in front of internet-exposed services.  

»Exploring the role of Vault

Vault implements that lifecycle as a platform capability, so a single deployment can answer the same control across multiple mandates: 

• Secure storage. Keys and secrets are encrypted at rest inside Vault and never sit in application code or config files, meeting the “stored securely” expectation directly. 

• Rotation. Vault can rotate keys automatically on a set schedule, keeping the old key valid until the new one is fully in use, so you can rotate often without breaking partner traffic. 

• Least-privilege access. Fine-grained policies set exactly which identity can read which secret, so each one reaches only what it needs — the need-to-know rule these frameworks expect. 

• Gateway-fronted, not partner-facing. Partners never touch Vault directly. The API gateway sits in front of it, and one Vault identity serves the whole partner tier, so Vault stays behind the gateway and firewall the rules ask for, and you manage one Vault client instead of one per partner. 

• Tamper-evident audit. Every access and rotation is recorded in Vault’s audit log, giving the “who did what, when” evidence auditors ask for; you can tag each entry with the partner it relates to, without creating a separate identity for each partner. 

»Agentic AI security: Extending the controls to non-human identities

AI agents create a familiar security problem in a new form: They are non-human identities that may need credentials, access to sensitive systems, and an auditable record of what they did. 

As regulated organizations begin using agents to retrieve data, call APIs, trigger workflows, or act on a user’s behalf, the same controls already required for people, applications, and API keys need to extend to agents as well. If an agent touches personal data, moves money, or participates in a regulated workflow, organizations need to know which identity was acting, what it was allowed to do, which credentials it used, and how its actions can be traced back to the right user, system, or approval. 

That makes the control questions practical:  

• Who or what is the agent?  

• What is it allowed to access right now?  

• Which credential or secret did it use? 

• What action did it take, and on whose behalf?  

• How can one agent be revoked, contained, or investigated without disrupting the rest of the environment?  

»Vault and IBM Verify in the context of agent controls

To help answer the questions, HashiCorp and IBM put together a runtime security pattern organized around four pillars:  

• Identity. Every agent gets its own verifiable identity instead of sharing a service account. Vault hands out short-lived credentials unique to each agent. No standing secrets, and no sharing API keys. 

• Least and runtime containment. Each action is checked when it happens, not waved through in advance. A policy as code check like Sentinel, for example, reviews each action. High-impact ones trigger a step-up approval to the delegating human through Verify before the call is made, and the resulting credential is tied to that one action for that one user. A misbehaving agent can be shut off on its own through Vault without impacting other agents. 

• Traceability. Using standard delegation flows, Verify links every action an agent takes back to the human who asked for it. Nothing the agent does is left untraceable. 

• Observability. With a tamper-evident trail — Vault’s audit log plus Verify’s event log, fed to the SIEM — there’s one place to know which user, which agent, what tool, what intent, and what outcome. 

Organizations don’t need a separate “AI security” program. They need their existing identity, secrets lifecycle, policy, and audit controls — the ones DPDP, CSCRF, and the RBI already require — extended to agents as first-class non-human identities. Same controls, new identity type. 

»Beyond Vault: Boundary and Consul

Access and encryption in transit are handled by two other HashiCorp products:  

Boundary provides identity-based access. Where Vault secures the secrets, Boundary secures the path a human or machine takes to reach infrastructure. Access is brokered by identity, credentials can be injected from Vault rather than handed to the user, and sessions are auditable. In plain terms, an operator can connect to a production database without ever seeing the password and without a standing network route to it.  

Consul handles service-to-service networking. A service mesh enforces mutual transport layer security (TLS) between services, encrypting the traffic that moves between your applications and tying each connection to a verified service identity. That covers the part of “encryption in transit” that lives inside systems, not just at the edge, and adds an access control layer at the network level. 

If the goal is to navigate India’s frameworks with a coherent toolset rather than a patchwork, the winning alignment is Vault for secrets and encryption, Boundary for access, and Consul for service networking. 

»Next steps

The work of building encryption, tokenization, least-privilege access, audit logging, and residency only needs to be done once. Designed against the common control set, strong secrets and identity strategy can help address multiple regulatory requirements through one coherent operating model.  

If you’d like help applying this to your environment, talk to the team at HashiCorp. 

Related resources 

• HashiCorp Vault 

• Vault transit secrets engine (encryption as a service) 

• Vault transform secrets engine (tokenization and masking — Enterprise/HCP) 

• Vault policies and access control 

• Support regulatory compliance with Vault 

• HCP Vault Dedicated logs and metrics 

• HashiCorp trust and compliance center 

• Agentic runtime security: Solving agentic AI identity and access gaps 

• Announcing native AI agent support in HashiCorp Vault 

• SPIFFE: Securing the identity of agentic AI and non-human actors 

• HashiCorp Boundary 

• HashiCorp Consul 

Disclaimer: Clients are solely responsible for assessing and meeting their own legal, regulatory, and compliance obligations. IBM does not provide legal advice, and no IBM product, service, or statement should be construed as guaranteeing compliance with any law, regulation, or regulatory requirement.  

No product or system is completely secure; IBM does not warrant immunity from malicious or illegal conduct.