Last reviewed: 5 August 2026.
This pillar maps the broader residency framework. The operational log-retention layer is covered separately in CERT-In 180-Day Log Retention: What It Means for Data Centres and Hosting Providers.
The central distinction: The DPDP Act does not create a blanket requirement that all personal data must be stored only in India. It allows the Central Government to restrict transfers to notified countries or territories, while sectoral laws may impose stronger localisation rules. CERT-In separately requires covered organisations to keep specified ICT logs for 180 days within Indian jurisdiction.
Data residency, localisation and sovereignty are not the same
| Term | Practical meaning | Procurement question |
|---|---|---|
| Data residency | The physical or logical location where a defined data set is stored or processed | Which city, facility, region and storage service holds each copy? |
| Data localisation | A legal or contractual requirement to keep specified data in a particular jurisdiction | Which law, regulator or contract requires India-only storage or processing? |
| Data sovereignty | The laws and governmental authority that may apply to data based on location, parties and processing | Which jurisdictions can assert authority over the provider, support team or subprocessor? |
| Cross-border transfer | Making personal data available for processing outside India, including through replication or remote access | Do backups, telemetry, support or security systems expose data outside India? |
A precise hosting requirement should state which data is covered, which activities are restricted and whether the rule applies to storage, access, processing, support, logs, backups and disaster recovery.
What the DPDP Act says about transfers outside India
Section 16 of the Digital Personal Data Protection Act, 2023 permits the Central Government to restrict transfer of personal data for processing to notified countries or territories. It also preserves the effect of other Indian laws that provide a higher degree of protection or a stronger restriction for particular data or classes of Data Fiduciaries.
This structure matters because the correct statement is not “DPDP requires all data in India.” The correct statement is:
- DPDP creates a national personal-data governance framework.
- Cross-border processing can be restricted through Government notification.
- Other laws and regulators may impose stricter localisation rules.
- A Data Fiduciary remains accountable for processing performed by its Data Processor.
- Indian hosting can reduce transfer complexity, but it does not complete compliance on its own.
The 2026 implementation context
The Government notified the DPDP Rules, 2025 in November 2025. The Government’s published explanation describes an eighteen-month phased compliance period. For infrastructure teams, 2026 is therefore a design and evidence year: inventory data, classify workloads, define locations, amend processor contracts, test breach workflows and remove undocumented transfers.
The final Rules describe reasonable security safeguards including encryption or comparable protection, access controls, monitoring and review, backup and continuity, log retention, processor-contract provisions and appropriate technical and organisational measures. These requirements turn “where is the server?” into only one line of a much larger control matrix.
What CERT-In requires from infrastructure operations
The CERT-In Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporates, VPS providers, cloud service providers and other listed entities. They create operational duties that are distinct from DPDP.
180-day logs within Indian jurisdiction
Covered entities must securely maintain logs of ICT systems for a rolling 180-day period within Indian jurisdiction. This is a genuine location requirement. It is not the same as a universal requirement that every customer database or backup remain in India.
A useful log-residency specification should cover:
- Network, firewall, authentication, hypervisor and administrative events
- Time synchronisation and timezone handling
- Integrity protection and privileged access
- Search and export capability
- Retention start and deletion method
- Whether a foreign SIEM receives a copy
- How logs are produced to CERT-In when lawfully required
Six-hour incident reporting
Specified cyber incidents must be reported to CERT-In within six hours of noticing the incident or it being brought to notice. The provider and customer should agree who reports, who supplies technical facts and how duplicate or conflicting notifications are avoided. A ticket marked “high priority” is not an incident-response plan.
Subscriber records for hosting services
Data centres, VPS providers, cloud service providers and VPN service providers must maintain specified validated subscriber or customer information for five years or longer where law requires after cancellation or withdrawal. This requirement concerns provider records such as validated customer identity and service period; it does not authorise indefinite retention of all customer workload data.
When sectoral localisation rules may be stricter
The DPDP Act expressly allows other Indian laws to provide stronger protection or transfer restrictions. Businesses should therefore classify the workload before selecting a region. Payments are a well-known example: the Reserve Bank of India’s Storage of Payment System Data direction requires covered payment-system data to be stored in systems only in India, subject to the direction’s detailed scope and clarifications.
Banking, insurance, securities, telecom, health, government and critical-infrastructure workloads may also be affected by regulator directions, contractual terms, procurement conditions or security classifications. A provider should not give generic legal conclusions for all industries. The buyer should supply the workload classification and required location boundary.
An India region must be defined across the full data path
Primary compute is only the visible centre of the architecture. A serious residency review maps every component:
| Layer | Location questions | Evidence |
|---|---|---|
| Production compute | Which city, facility and cluster run the VM or dedicated server? | Order form, deployment record and assigned IP/ASN |
| Storage | Where are block, object and file stores physically maintained? | Service architecture and region designation |
| Replication | Is data copied to another availability zone, city or country? | Replication policy and topology |
| Backups | Where are snapshots and off-site copies stored? Are they encrypted? | Backup schedule, target and restore report |
| Logs and SIEM | Where are security and operational logs retained and analysed? | Log architecture, retention and export controls |
| Monitoring and telemetry | Do metrics, traces, crash dumps or payload samples leave India? | Vendor list and data-field inventory |
| Support access | Can staff or partners outside India view consoles, tickets or data? | Access policy, locations and approval workflow |
| DNS, CDN and DDoS | Which metadata or content is processed at global network edges? | Product scope, routing and security architecture |
| Termination | Where do residual copies remain after deletion? | Deletion schedule and confirmation process |
Remote access can be a cross-border processing issue
A server may stay in Mumbai or Noida while an overseas support engineer accesses a database, receives a diagnostic archive or views a ticket containing personal data. Residency claims should therefore distinguish physical storage from access and processing.
Ask:
- Are operations and support teams located only in India for this service?
- Is offshore support optional, prohibited or subject to approval?
- Are privileged sessions time-limited, recorded and tied to a ticket?
- Can the customer disable provider access except during an approved intervention?
- Are diagnostic files sanitised before entering a global ticketing platform?
Backups are the most common hidden location
Backups can silently break a residency promise when a provider uses a global object-storage account, remote control-panel destination or overseas disaster-recovery service. The contract should state the backup country or facility, not merely “off-site.”
Also separate:
- Availability copy: a replica used for rapid failover
- Operational backup: a versioned copy used for recovery
- Immutable recovery copy: protected against alteration or ransomware
- Archive: long-retention data retained for legal or business reasons
Each copy needs its own location, retention, encryption, access and deletion rule.
Facility certificates do not prove workload residency
A certificate can provide assurance about a named organisation, management system, site and scope. It does not prove that a customer’s specific server is in that site or that every backup and support platform is covered.
Advika states that its infrastructure runs from Yotta Data Centre and clearly identifies the linked facility certificates as held by Yotta rather than by Advika directly. The dated evidence, holder names and validity issues are documented in Advika Datacenter Services: Network, Facilities and Certifications (2026 Fact Sheet).
For a specific deployment, request:
- Facility city and operator
- Certificate holder, site, scope and current validity
- Rack or cluster allocation where contractually relevant
- Backup and disaster-recovery locations
- Physical-access and remote-hands process
- Network origin ASN and security path
Data residency is a shared-responsibility control
The customer decides what data enters the workload, why it is processed and which legal or contractual boundary applies. The provider selects and operates portions of the physical, virtual and network stack. Both sides need a common location map.
| Customer responsibility | Provider responsibility to define |
|---|---|
| Classify personal, regulated and confidential data | Offer named regions and disclose the service topology |
| Identify applicable sector and contract requirements | State where production, backup and logs are located |
| Configure applications to avoid unnecessary data collection | Restrict and record administrative access |
| Select encryption and key ownership | Protect underlying platforms and agreed storage |
| Manage consent, notice and data-principal requests | Support export, snapshot deletion and evidence requests |
| Decide incident-reporting obligations | Escalate technical incidents and preserve evidence |
What buyers should ask Advika before deployment
- Which Advika legal entity will contract, invoice and process account data?
- Which city, facility operator, server cluster and ASN will serve the workload?
- Will any production data, replica, backup or snapshot leave India?
- Where are network, security, authentication and platform logs stored?
- Does any SIEM, monitoring, ticketing or telemetry service receive data outside India?
- Which personnel and partners can access the service from outside India?
- Which encryption, key-management and access-control features are included?
- How are CERT-In six-hour escalation and 180-day log requirements operationalised?
- What breach facts will be supplied to support DPDP notifications?
- What happens to data and credentials at termination?
- Which facility certificates cover the named site, and are the copies current?
- Which claims are included in the signed SLA or architecture document?
A practical residency clause should cover more than country
A strong order or data-processing schedule can define:
- Covered data categories and systems
- Permitted production, backup and disaster-recovery locations
- Remote-access countries and approval process
- Approved subprocessors and notice of changes
- Log location and retention
- Encryption and key responsibility
- Incident escalation and evidence delivery
- Deletion, backup expiry and termination confirmation
- Audit or assurance evidence
- Process for legal requests and compelled disclosures
This is more useful than a one-line warranty that “data is hosted in India.”
How Advika’s operating layers fit together
Advika markets cloud VPS, dedicated servers and custom infrastructure, while public routing records identify AS135682 with Advika Web Developments Hosting Pvt Ltd. StreamData Networks functions as a customer-facing catalogue and order path within the broader ecosystem, and Yotta supplies the facility layer disclosed on Advika’s site. The role of each name is mapped in The Advika Group: How Advika, StreamData Networks and Partner Brands Fit Together.
For residency, buyers should not infer that every product uses the same facility, backup location or security configuration. The exact deployment must be confirmed in the order.
Frequently asked questions
Does the DPDP Act require every Indian business to store personal data only in India?
No. The Act allows the Government to restrict transfers to notified countries or territories, and other laws may impose stricter sector-specific rules. There is no blanket India-only rule for every category of personal data.
What data must CERT-In-covered entities keep in India?
The 2022 Directions require logs of ICT systems to be maintained securely for a rolling 180-day period within Indian jurisdiction. Hosting providers also have separate subscriber-information retention duties.
Is an India-based primary server enough for data residency?
Not necessarily. Backups, replicas, support access, telemetry, logs, ticket attachments and security tools may create additional processing locations.
Can a Yotta facility certificate prove that an Advika workload is in a specific site?
No. It proves information about the certificate holder, scope and named sites. The customer’s order must identify the actual deployment location.
Does data residency make a workload DPDP compliant?
No. It can support compliance and risk objectives, but lawful processing, notices, security, retention, rights handling, processor governance and incident response remain necessary.
Bottom line
India’s data-residency question cannot be answered with a flag icon beside a server plan. The correct answer is a documented data-flow and location map covering production, replicas, backups, logs, monitoring, support access, partners and deletion. DPDP establishes accountability and transfer controls; CERT-In adds concrete cyber-operational duties; sectoral rules can be stricter. The infrastructure contract must bring those layers together for the exact workload.
This article provides infrastructure and compliance-planning information, not legal advice. Organisations should obtain sector-specific legal guidance before defining localisation or cross-border-transfer requirements.
